Intake Issue: #14
RFC proposes how SIG-Security (on behalf of O3DE) handles security vulnerability reports. This RFC follows on from #12, which covers how O3DE receives vulnerability reports.
O3DE/SIG-Security needs a process to handle and process security vulnerabilities reported to the project. The processes for reporting and handling security issues should be public knowledge, as per the Open Source Security Foundation's recommendations.
RFC proposes several mechanisms required for report handling:
- Creation and definition of a Security Issue Review (SIR) team.
- A runbook for handling issues that defines vulnerability life cycle and requirements from the wider O3DE community.
- Templates to aid communication around vulnerability reporting and disclosure.
Propose setting up a Security Issue Review/Response (SIR) team [SIR naming based on XFoundary naming] for O3DE. SIR Team will receive vulnerability reports sent to security@o3de.org and handle triage.
Initial team will be formed from:
- Current SIG-Security maintainers and chair(s)
- O3DE AWS Application Security Contact(s)
- TSC nominated contact(s)
- SIG-Release nominated contact(s)
SIR team members can be added following the Process for Nomination below. SIR team membership should be reviewed periodically by SIG-Chair(s) to ensure membership is large enough to scale to vulnerability report load.
Team members can leave or be removed following Process for Removal below.
- SIG-Chair(s), in conjunction with SIG-Build will provide appropriate permissions, on all relevant O3DE repositories, to SIR team members to view any/all O3DE GitHub Security Vulnerabilities, as well as to create/draft new vulnerabilities.
- SIG-Chair(s), potentially in conjunction with SIG-Ops own and manage giving access to security reporting emails to SIR team members.
- Provide guidance and expertise around security issues.
- Ensure the confidentiality of reported security issues until they can be publicly disclosed.
- Will, if nominated/volunteered to run triage, own handling a security report and ensuring it receives timely updates.
- Issues should either be closed or lead to disclosed security vulnerabilities.
SIG-security chair(s) can nominate members to the SIR team that:
- Are active SIG-Security chair(s) or current SIG maintainers.
- Or are members of the wider O3DE community that can demonstrate security and threat assessment knowledge.
- Or are nominated by the TSC for this purpose.
TSC must approve SIR team members once they are nominated.
SIG-Chair(s) can proposal removal of any SIR team member if they cannot fulfill their duties or act in a manner that causes harm to O3DE.
- SIG chair(s) can directly remove member if member is voluntary resigning. SIR team should be notified of resignation.
- Or SIG chair(s) can ask for a vote from SIR team if a member should be removed involuntarily if they fail to meet the expectations of SIR team membership. If the majority of SIR team are in favor, then member will be removed from SIR team by SIG-Chair(s) or at the request of the TSC.
- Chair(s) will notify TSC contact that SIR Team member has been removed.
- Removed member can appeal to TSC to have removal rescinded.
When the SIR team receives a vulnerability report, it should first see if the issue is publicly known (for O3DE or in standard reports such as https://nvd.nist.gov/) , in which case it can be discussed in SIG-security channels and at public meetings to drive consensus.
- Reporter should be thanked for their report and notified this is a known issue and be provided with existing issue links. This should happen within 3 working days of receiving report but ideally asap.
Otherwise, if the report appears to be a new issue or known but undisclosed vulnerability:
- In private SIR team Discord channel, raise issue and identify triage owner of issue. If issue is complicated/impactful enough consider holding meeting of SIR team within 1 week of issue being reported. Triage owner is not responsible for actual work of fixing issue, TSC and SIGs are responsible for providing resources to perform work unless its agreed that SIG-security is providing the resources.
- Triage owner should then acknowledge the receipt of the issue within 3 working days of initial report. Its important that we thank all reporters for raising the issue and let them know its being investigated. “Thanks for the report. The O3DE security response team is examining issue and will be in contact in the next x working days” [Expected time of response needs definition].
- Triage owner should work with reporter to capture sufficient details to ensure it can be assessed, if details are missing from initial report including:
- Ensuring there is clear information about what steps reporter took to identify the vulnerability.
- Understanding what platforms, packages and version the threat has been reported against.
- Triage owner should open new GitHub Issue (GHI) in SIG-Security-reports private repository [Process assumes we can use a private project under O3DE such as https://github.com/o3de/sig-security-reports]
- Asses threat
- Is it an actual vulnerability, is it a security feature etc.? Not everything reported as a vulnerability is a vulnerability. Generally, something is a vulnerability if it compromises data confidentiality, integrity, or availability. This may happen by enabling remote code execution, elevated permissions, or unintended access, but what separates a vulnerability from other unwanted behavior (a non-security bug) is a compromise in one or more of those areas.
- Identify initial impact level for issue.
- Discuss initial findings in private discord channel with SIR team.
- If an actual vulnerability, create a draft security advisory for issue, in the correct O3DE project/repository. See https://docs.github.com/en/code-security/security-advisories/creating-a-security-advisory for guidance.
- Update GHI with link to advisory link.
- Add SIR team members to draft advisory.
- Alert impacted SIGs via their chair(s) and the TSC. Add impacted chair(s) and TSC suggested contacts as collaborators on security advisory: https://docs.github.com/en/github/managing-security-vulnerabilities/adding-a-collaborator-to-a-maintainer-security-advisory
- Provide a draft security response and request comments/changes from collaborators
- If not a vulnerability, thank reporter for their time and provide a reason why this is not a vulnerability. Categories should include “Working as intended”, “Bug” but not security related or a “Feature Request”. Let the reporter know reason for closure and direct them to security policy for future reports.
- Close issue in triage queue and let SIR team know issue is closed.
- If an actual vulnerability, create a draft security advisory for issue, in the correct O3DE project/repository. See https://docs.github.com/en/code-security/security-advisories/creating-a-security-advisory for guidance.
- Respond to issue reporter with information from triage and work with reporter to agree on embargo period/disclosure timeline. We should aim for disclosure with90 days, even if no fix is available (For example https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy). If there are conflicts in agreeing embargo period, please communicate with SIR team for next steps.
- Asses threat
- Identify working group with impacted SIG(s) and SIR team. Group should contain at least one member of each impacted SIG, the SIR team triage owner plus a SIG-release and TSC observer (if requested).
- Working group needs to set up reproduction of vulnerability.
- Working group needs to identify impact of vulnerability - wider impact, scope and severity
- Working group needs to attempt to provide mitigation in private fork: https://docs.github.com/en/articles/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability to patch issue.
- Define a Common vulnerabilities and exposures (CVE) number for the issue.
- This RFC proposes using GitHub as CNA as GitHub is a CVE Numbering Authority (CNA) and is authorized to issue CVE numbers.
- Ask reporter if they want to be involved and invite them to collaborate on the CVE, if possible.
- CVE / GitHub security alert should be updated to contain mitigation steps, if known.
- CVE / GitHub security alert should contain acknowledgement of vulnerability reporter, we always want to acknowledge their efforts as long as they want to be publicly identified. See https://docs.github.com/en/github/managing-security-vulnerabilities/editing-a-security-advisory#about-credits-for-security-advisories
- Review draft of public disclosure issue
- Review with SIR team, which should include TSC observers
- Review with vulnerability reporter where possible, if possible to ensure issue captures their concerns.
- Notify SIG(s) via SIG-Chair(s) list and interested party of mitigation to begin patching processes via an Embargoed Notification list (See Proposal #3)
- Agree with disclosed O3DE members time to prepare and begin patching (if required).
- If possible, merge fix to main repro prior to public disclosure.
- Co-ordinate with SIG-release esp around Critical and High issues to see if we require patched installers.
- Publish public disclosure on agreed date with mitigation instructions.
- https://docs.github.com/en/code-security/security-advisories/publishing-a-security-advisory.
- Send notifications through identified public channels including: SIG-Security embargoed list as well as sig-security and sig-all Discord chat channels.
If there is security related public GitHub issue (GHI) exists that did not originate from SIG-Security:
- Raise with SIR team
- Message responder that security reports should be made through security@o3de.org.
- Save GHI content and delete public GitHub issue
- Move into internal issue queue.
Provide templates that act as starter guides when SIR team has issues to respond to. See https://github.com/ossf/oss-vulnerability-guide/tree/main/templates/notifications for examples.
These templates will aid SIR team in responding to ensure there is consistent communication.
- Provides clear process for SIG to follow
- Minimizes what parts of the process TSC has to own/operate on.
- Nature of SIR team is private. Unclear how public SIG reporting and private SIR team reporting should be handled.
- Best-effort, SIR team may not have capacity / resources / skills required for every reported vulnerability.
- In take of issues is manual, we could in future in co-operation with SIG-ops automate report->GitHub issue creation so triage queue is automatically populated.
SIG-Security will define and run process. TSC will provide input to any changes and own SIR team approval.
Proposed that once RFC is complete, SIG-Security run a full practice of patching O3DE with one person playing the reporter and other SIR team members providing the updates. Test will ensure team has practiced issue response all the way through to patching and disclosing the fix.
There are potentially many things we can do differently (mechanisms, process). However, much of this RFC is based on Open Source Security Foundation practices. As this is a process proposal, nearly everything here could be changed or adjusted as needed.
- Process should be publicly documented for any contributor to reference in SIG-Security and linked from the official O3DE.org security page(s).
- SIG-Security members can use process to provide guidance/training as possible.
- SLAs/time frames the SIG wants to adopt around runbook steps, have added defaults based on capacity.
- Are there any other alternative communication mechanisms we should use (ie something other than Discord or GitHub for security advisories).
- What happens if SIG is overloaded or no SIR team members have capacity to handle issues? Assume SIG-Chair(s) raise urgent issues with TSC.
- Unclear what public reporting/metrics SIR team should provide about work? This would be based on any requirements we have to report work to TSC/LF or other interested party.
- Should we consider a CVE CNA outside of GitHub as our CNA? Unclear about what requirements we may have for CVE/CNA.
Parts of this guide were influenced by the OSSF Recommendations, XFoundary Guide, Kubernetes Security Processes and GitHub Security Guides.