...

1. Ensure that PTL and committers are available
2. On the disclosure hour:
   1. Remove embargo notice from ticket description
   2. Open the ticket to public
   3. Push attached patches for review on master
   4. Notify PTL and committers that patch is ready to be merged
3. Publish ONAP security advisory
4. Update the ticket title to “[OSA-$NUM] $TITLE”
5. Sent notification to MITRE about a publication

Handling public/leaked security issues

What is considered public?

...

There will be occasions where the vulnerability management workflow process is either not followed, or at some stage a party leaks the details of the flaw. In these cases a different workflow is applicable, as there is no longer any need to maintain an embargo. The private security issue workflow can be followed from the "Disclosure date" step onwards.

Communication

Confirmed public security issues

When an issue is leaked

 #security-status: confirmed-leaked

This issue has been confirmed as a security vulnerability in { project }. Unfortunately the details of this flaw have been made public { reference_to_leak }. 
Therefore it cannot be fixed under the ONAP embargoed security vulnerability process. 
As this issue is now public it is important that the flaw is addressed in a timely manner. The ONAP vulnerability sub-committee will ensure that a CVE is assigned for this issue.

When an issue was not reported privately

 #security-status: confirmed-public

...

not follow and the issue is publicly disclosed before reporting it to the vulnerability subcommittee. In this case it's important to properly identify the issue and create a task to make it traceable. As the flaw has been already disclosed there is no need to keep the Jira ticket private so it should be sent to publicly available in a very beginning of the process. In general, standard vulnerability management process should be followed, just embargoed disclosure should be skipped.

Steps to be executed:

1. Create ticket with issue description in Vulnerability Reporting Jira Project
2. Make the ticket publicly visible
3. Perform bug triage and CVE request if necessary
4. Send email containing triage results to /Agree on email recipients/
5. Rest of standard process should be followed, skipping embargoed disclosure step
   

Leaked security issue workflow

Occasionally it may happen that the bug reporter or some else break the embargo and disclose details of the flaw before official disclosure date. In this case a timely answer is extremely important.

Steps to be executed:

1. Make the related ticket publicly visible
2. If a patch has been already proposed push it immediately to gerrit
3. Skip embargoed disclosure.
4. Send email confirming that issue has been leaked to /Agree on email recipients/
5. Rest of standard process should be followed and finished as soon as possible.
   

Roadmap

Action Items

References

1. Common Vulnerabilities and Exposure (https://cve.mitre.org/about/faqs.html )
2. CVE  numbering authorities (https://cve.mitre.org/cve/cna.html)
3. CVE FAQ (https://cve.mitre.org/about/faqs.html#what_is_cve_identifier )

...