Project

General

Profile

Security process » History » Version 1

Dominic Cleal, 09/18/2015 06:04 AM
today's security process

1 1 Dominic Cleal
h1. Security process
2
3
*If you need to report a potential security issue, please email foreman-security@googlegroups.com (a private address) immediately so we can help investigate it.*
4
5
Please see http://theforeman.org/security.html for up to date information on known vulnerabilities and fixes.  This page is a development/triage resource only.
6
7
h2. foreman-security list
8
9
The foreman-security mailing list is an invite-only group of Foreman developers, distribution maintainers and security response experts.  At the time of writing, it has nine members, which for obvious reasons, we try to keep at a minimum.
10
11
The responsibility of the group is to triage incoming notifications from the public and other Foreman developers, analyse and write up the issue, assign a CVE identifier, and to ensure the fix is shipped correctly.  It isn't the responsibility of the security team to write the fix/patch.
12
13
h2. Vulnerability process
14
15
When an issue is reported, the following process should be followed by one or more people on the foreman-security list.
16
17
# Reporter emails foreman-security@googlegroups.com with information about the issue.
18
# Security team member replies to the reporter, CCing the list to acknowledge the report.
19
# Security team member investigates the issue and if invalid, replies to the reporter and list to reject it.
20
# If the report is valid, the security team member should judge the severity or email the list to decide on it.
21
#* Higher/critical severity issues will be embargoed.
22
#* Lower/medium severity issues will be handled in public as regular bug reports, but with a CVE assigned.
23
# Determine the affected versions of Foreman through code analysis, if possible.
24
25
For unembargoed/public issues:
26
27
# Security team "files a Redmine issue":http://projects.theforeman.org/projects/foreman/issues/new with all relevant details and reproducer information.
28
#* Set Category to Security
29
#* Set Release to the next minor/major depending on severity.
30
# Reply to the reporter and list to provide the ticket URL and inform them on how it's being handled.
31
# The Redmine ticket can be picked up and worked as usual.
32
#* Consider emailing foreman-dev to help get a developer assigned to the ticket.
33
# Email secalert@redhat.com (Red Hat Security Response Team), CCing foreman-security, providing all relevant details and requesting a CVE identifier.  Expect a response within 48 working hours.
34
# On receiving a CVE identifier:
35
## Update the "security webpage":https://github.com/theforeman/theforeman.org/blob/gh-pages/security.md with details.
36
## Prefix the Redmine ticket title with the CVE identifier.
37
38
For embargoed issues, handle in a similar way with these exceptions:
39
40
# Take extreme care to make no public comments, emails, pull requests or IRC conversations on the subject.  Ensure anybody working on the issue follows the same.
41
# Decide a suitable unembargo date (often ~2 weeks) when it would also be suitable to make a release of Foreman.
42
# File a Redmine issue, but +set the Private flag+ which makes the ticket visible to security team members and Redmine administrators.
43
# Attach proposed patches to the Redmine issue, review in comments preferably.
44
# On unembargo, change the Private flag of the Redmine ticket to false.  Submit the patch as a pull request and/or merge if tests are green.
45
# Have the release manager of the current stable branch(es) make a patch release.