Security Team Work Flow

Assisting with Vulnerability Patching

This is the work flow for helping fix security bugs in Fedora and EPEL.

1. Select an open security bug from -> Open issues.
2. Own the bug.
3. Examine the bug details and validate if it is really a security issue.
4. Determine if a fix is available and if the vulnerability is already fixed in Fedora by examining the current version and/or talking with the package maintainer.
5. If a fix is not available, work with the upstream developers via bug tracking/mailing list/IRC channels to obtain a patch or new version which fixes the issue.
6. Work with the package maintainer to get patch or fixed version packaged and pushed as a security update.
7. GOTO 1;

If you run into a nonresponsive package maintainer we follow Release Engineering policy to overcome these issues.

Bug Ownership

Each tracking bug should have an owner for several reasons. It would certainly be inefficient if the work was done twice. Collisions and misunderstandings might occur if two people tried to coordinate a fix with an upstream developer independently. For these reasons, we should indicate the fact that we are working on the tracking bug by filling the Whiteboard of the bug with Bugzilla user name of the owner:

   Whiteboard: fst_owner=<owner>,[<owner2>,<owner3>]

As <owner> FAS ID should be used; It simplifies further management. For the list of Bugzilla user names of the Fedora Security Team see the Security Team Roster.

Note: For multiple FST owners FAS IDs should be comma-separated and NOT contain spaces.

Bugzilla Links

• Open issues
  • Critical Vulnerabilities Unowned
  • Important Vulnerabilities Unowned
  • Moderate Vulnerabilities Unowned
  • Low Vulnerabilities Unowned
  • Unknown Vulnerabilities Unowned
  • Bugs in MODIFIED, ON_DEV, ON_QA states Unowned

Security Response

The Security Team helps packagers fix security vulnerabilities in packages they maintain. Most of these vulnerabilities come from the open source software community and packagers are notified by a ticket in Bugzilla.

TODO

Secure Coding

Secure coding is writing code with security in mind from the beginning. By not making security mistakes the code is more secure and time won't be wasted down the road having to rewrite or redesign features and functionality.

Projects

Defensive Coding book

The Defensive Coding book is published on the Fedora Docs website and is under development. The purpose of the book is to document common mistakes developers make and help educate developers on how to better their code from the beginning.

Training and Articles

In addition to the Defensive Coding book the Security SIG is charged with creating training resources. Videos and smaller articles on secure development can also be created to concentrate specific topics. These resources should be stored in the secure coding git repository.

Security Basics and HOWTO Articles

Basic Fedora security HOWTO is SecurityBasics

Code Auditing

Many security vulnerabilities are found with the help of a code audit. If you are interested in performing an audit please see our auditing resource page.

TODO