Project

General

Profile

Security process » History » Version 3

Marek Hulán, 09/18/2015 06:21 AM

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 2 Dominic Cleal
When a vulnerability is found in a third party component that the project ships, the group should notify them of the vulnerability and help them handle it.  For plugins the responsibility of releasing falls to the maintainer(s) instead of the regular Foreman release manager(s).
14
15 1 Dominic Cleal
h2. Vulnerability process
16
17
When an issue is reported, the following process should be followed by one or more people on the foreman-security list.
18
19
# Reporter emails foreman-security@googlegroups.com with information about the issue.
20
# Security team member replies to the reporter, CCing the list to acknowledge the report.
21
# Security team member investigates the issue and if invalid, replies to the reporter and list to reject it.
22
# If the report is valid, the security team member should judge the severity or email the list to decide on it.
23
#* Higher/critical severity issues will be embargoed.
24
#* Lower/medium severity issues will be handled in public as regular bug reports, but with a CVE assigned.
25
# Determine the affected versions of Foreman through code analysis, if possible.
26
27
For unembargoed/public issues:
28
29
# Security team "files a Redmine issue":http://projects.theforeman.org/projects/foreman/issues/new with all relevant details and reproducer information.
30
#* Set Category to Security
31
#* Set Release to the next minor/major depending on severity.
32
# Reply to the reporter and list to provide the ticket URL and inform them on how it's being handled.
33
# The Redmine ticket can be picked up and worked as usual.
34
#* Consider emailing foreman-dev to help get a developer assigned to the ticket.
35
# 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.
36
# On receiving a CVE identifier:
37
## Update the "security webpage":https://github.com/theforeman/theforeman.org/blob/gh-pages/security.md with details.
38
## Prefix the Redmine ticket title with the CVE identifier.
39
40
For embargoed issues, handle in a similar way with these exceptions:
41
42
# 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.
43
# Decide a suitable unembargo date (often ~2 weeks) when it would also be suitable to make a release of Foreman.
44
# File a Redmine issue, but +set the Private flag+ which makes the ticket visible to security team members and Redmine administrators.
45 3 Marek Hulán
# Attach proposed patches to the Redmine issue, review in comments preferably. Don't use private comments.
46 1 Dominic Cleal
# 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.
47
# Have the release manager of the current stable branch(es) make a patch release.