SIG-Security Reporting Proposal

[lmbr-pip]

SIG-Security Issue Reporting Proposal

Overview

O3DE needs to have a secure vulnerability reporting process for security related issues such that:

• External security processes can report issues - such as automated software scanning, security researchers etc.
• External security reporters can report securely - they can report issues to O3DE in a way that does not disclose any confidential information or identities.
• Malicious or false alarms are filtered to prevent causing concern or confusion to the O3DE community.
• The process provides a buffer to allow mitigation of critical issues, prior to public disclosure.

See https://docs.github.com/en/code-security/security-advisories/about-coordinated-disclosure-of-security-vulnerabilities for guidance.

Proposal #1: Setup monitored email list for reporting security vulnerabilities

Setup an O3DE owned monitored email list for reporting security vulnerabilities such as security-reports@o3de.org. Need to ensure email attachments can be audited for spam and malware.

Membership of the list needs to be strictly controlled so only SIG-security response team (definition and process TBD) and approved observers (nominated by TSC for example) see initial reports. The membership of this list and processes will be covered in a subsequent proposal.

List ideally should offer encryption mechanisms for reporting. For example, we offer public keys that reporters can use to encrypt secure content (public keys should be kept in the sig-security repro).

SIG-security will use the sig-security email list for reporting security notices when they reach their public disclosure period as well as publishing GItHub security vulnerability notices on the impacted repro.

Proposal #2: Add a Security Reporting Section to o3de.org

*Proposal: Add a security reporting section on o3de.org and also in mark down in README.md in the sig-security repro. Propose that SIG-security defines a release disclosure period similar to Kubernetes but with an initial longer disclosure default period while security reporting processes are built out.

Below is a rough first draft. Note: If reporting supports encryption, then should include instructions for signing/encrypting report.

---

Proposed Reporting Process

All security vulnerabilities should be reported through the security-reports@o3de.org (Note: actual email address needs to be confirmed and setup via TSC/SigOps) email list. Vulnerability reports should follow the same information reporting format as bug issues in the main o3de/o3de repro.

When to Report?

• You have discovered a potential security issue relating to O3DE.
• You have discovered or are aware of a security issue relating to an O3DE dependency that may impact O3DE.

When to not Report?

• You need help setting up issues related to security dependencies such as OpenSSL or TLS/DTLS
• You need help applying a security related fix to your O3DE applications.
• Issue is not related to security. Please report issue using the normal O3DE issue reporting process.

Release Disclosure Period

The public disclosure date of the vulnerability will be negotiated between SIG-Security and the reporter. The SIG aims to publicly disclose the issue as soon as mitigation as been identified and a patch is ready. SIG-Security aims to provide disclosure for within 14 days as long as the issue is well understood. If an issue is more complex and requires more time for reproduction and analysis, SIG-Security may delay disclosure.

---

Proposal #3: Separate Vulnerabilities from Bug Issues for O3DE Issue Reporting

Proposal: Modify issue reporting in O3DE repros to encourage folks to report security vulnerabilities correctly when they click “Create Issue”. This would create a new template in the repro, that links to the security reporting section of the O3DE website to discourage reporting via GitHub Issues (GHI).

An example from another github repro (need to add link to source)

Proposal #4: Provide a Security.md in o3de/o3de repro

Provide SECURITY.md in the main repro as per https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository#about-security-policies

• Kubernetes example: https://github.com/kubernetes/kubernetes/blob/master/SECURITY_CONTACTS

Once we have an agreed security.md file, SIG-Security will then copy / asks SIGs to add copies that link to this master Security.md

References

https://kubernetes.io/docs/reference/issues-security/security/
https://github.com/kubernetes/community/tree/master/sig-security
https://docs.github.com/en/code-security/security-advisories/about-coordinated-disclosure-of-security-vulnerabilities

[lmbr-pip]

Discussion was reviewed at SIG-Security meeting Jan 5th 2022 and we agreed we would create issues for each of the proposals directly while we wait for input from the Linux Foundation.

[lmbr-pip]

Migrated this to an actual RFC: #12