[DRAFT] Proposed RFC Feature: Security Disclosure Embargo List

[lmbr-pip]

Summary:

Provide a security disclosure list to allow disclosed O3DE community members to begin early patching of impactful security vulnerabilities. Taken from #14

What is the relevance of this feature?

The RFC proposes the creation and definition of an Embargo list for early disclosure of vulnerabilities. This would enable consumers of O3DE to be made aware of critical security issues that could impact their game/applications in development or in live service, so they can secure and patch prior to public disclosure of serious security vulnerabilities.

Feature design description:

Proposal defining a private list of O3DE members who get embargoed security notifications; anyone who meets the criteria can sign up for these messages.

Criteria should include:

• O3DE Partner or an active participant and active contributor in the community.
• Accept the Embargo Policy TBD (will cover what requester need to agree to gain access).
• Be willing to contribute back in some form for Security? (reviews, administration, reporting, scanning)
• Have someone already on the list vouch for the person requesting membership on behalf of your distribution.

Note: If TSC/SIG wants to define embargo list then, this section should be split into its own RFC to work out the nuances with the TSC. Kubernetes embargo instructions for reference identify one such mechanism for reference.

Technical design description:

• Explain the technical portion of the work in enough detail that members can implement the feature.

• Explain any API or process changes required to implement this feature

• This section should relate to the feature design description by reference and explain in greater detail how it makes the feature design examples work.

• This should also provide detailed information on compatibility with different hardware platforms.

What are the advantages of the feature?

• Explain the advantages for someone to use this feature

What are the disadvantages of the feature?

• Extra process overhead, need to ensure confidentiality of process is observered.
• Needs support from TSC

How will this be implemented or integrated into the O3DE environment?

• Explain how a developer will integrate this into the codebase of O3DE and provide any specific library or technical stack requirements.

Are there any alternatives to this feature?

• Provide any other designs that have been considered. Explain what the impact might be of not doing this.
• If there is any prior art or approaches with other frameworks in the same domain, explain how they may have solved this problem or implemented this feature.

How will users learn this feature?

• Detail how it can be best presented and how it is used as an extension or a standalone tool used with O3DE.
• Explain if and how it may change how individuals would use the platform and if any documentation must be changed or reorganized.
• Explain how it would be taught to new and existing O3DE users.

Are there any open questions?

• What are some of the open questions and potential scenarios that should be considered?