...
- PTL or project security contact point should be delivered with bug details to confirm initial severity
- Severity level should be fixed:
- If PTL or project security contact point agrees with initially assigned severity a "Severity-confirmed" label should be added to the task.
- If PTL or project security contact point disagrees with initially assigned a clear justification should be provided, severity level updated and "Severity-confirmed" added to the task.
- If a bug has been received via email the triage confirmation email should be sent to the reporter.
Hardening opportunities
...
- If received ticket is not a security bug which can be fix with a patch of reasonable size but a good hardening idea, the ticket visibility should be set to public and "Hardening" label should be added
- It's up to public discussion if resources should be assigned for this task.
Non-Security bugs
- If bug has been classified as a non-security the ticket should be made publicly visible
- PTL of impacted project is responsible for further handling of this bug
Patch development
Patch review
- classified as a non-security the ticket should be made publicly visible
- PTL of impacted project is responsible for further handling of this bug
Patch development
PTL or project security contact point is responsible for fixing the bug or delegating the work to the matter experts. Even through patch development can be delegated by PTL or project security contact, only the VMS has a right to add new people to the ticket. That's why PTL should explicitly request access for additional developers by adding a comment with their Jira id.
A fix should be prepared against current master branch and other affected branches and attached to the ticket. Do not sent it to the public code review system (gerrit) unless the ticket is already public.
Security fixes, especially critical should be treated as highest-priority tasks. If project-side delays are encountered at this or any subsequent stage of the process, the VMS and other interested parties may escalate the issue to the TSC but without providing any details on bug itself apart from reporter, severity, impacted project and versions.
Steps to be completed
- Develop the fix
- Do not sent it to the public code review system (gerrit) unless the ticket is already public.
Patch review
Once the patch has been attached to the ticket, patch should be reviewed and pre-approved by PTL or delegated committers. Privately-developed patches need to be pre-approved so that they can be fast-tracked through public code review later at disclosure time.
For public reports, usual public code review process apply.
Steps to be completed
- Review the fix
- Get the fix pre-approved by PTL and committers
Draft Vulnerability description
In the mean time, the VMS coordinator prepares a vulnerability description that will be communicated to downstream stakeholders, and will serve as the basis for the Security Advisory that will be finally published.
The description should properly credit the reporter, specify affected versions (including unsupported ones) and accurately describe impact and mitigation mechanisms. The VMS coordinator should use the template below.
Review impact description
The description is validated by the reporter and the PTL.
Send CVE request
If reporter did not request for a CVE number on his or her own, VMS coordinator should attempt to obtain one to ensure full traceability. This is generally done as the patch gets nearer to final approval. The approved impact description is submitted through MITRE’s CVE Request form. The request type is Request a CVE ID, the e-mail address should be that of the requester, and for critical reports the coordinator’s OpenPGP key should be pasted into the field provided.
In the required section set the checkboxes indicating the product is not CNA-covered and that no prior CVE ID has been assigned, select an appropriate vulnerability type (using Other or Unknown to enter a freeform type if there is nothing relevant on the drop-down), set the vendor to ONAP, and the product and version fields to match the affected project name and version from the impact description. In the optional section set the radio button for confirmed/acknowledged to Yes, choose an appropriate attack type in the drop-down (often this is Context-dependent for our cases), check the relevant impact checkboxes, attempt to fill in the affected components and attack vector fields if possible, paste in the suggested description from the prose of the impact description (usually omitting the first sentence as it’s redundant with other fields), put the $CREDIT details in the discoverer/credits field, and the bug URL (along with Gerrit URLs for patches if already public) in the references field. If the report is still private, note that in the additional information field like This report is currently under embargo and no disclosure date has been scheduled at this time.
At the bottom of the page, fill in the security code and click the submit request button. If some fields contain invalid data they will be highlighted red; correct these, update the security code and submit request again until you get a confirmation page.
Get assigned CVE
MITRE returns the assigned CVE. It is added to the jira ticket, and the bug is retitled to “$TITLE ($CVE)”.
Embargoed disclosure
Once the patches are approved and the CVE is assigned, a signed email with the vulnerability description is sent to the downstream stakeholders. The disclosure date is set to 3-5 business days, excluding Monday/Friday and holiday periods, at 1500 UTC. No stakeholder is supposed to deploy public patches before disclosure date.
For non-embargoed, public vulnerabilities no separate downstream advance notification is sent.
Coordinated disclosure
In preparation for this, make sure you have a commiter and a PTL available to help pushing the fix at disclosure time.
On the disclosure hour, open ticket to public, push patches to Gerrit for review on master.
PTL and committers who pre-approved the patch should, as soon as possible add +2 on pushed patch and merge it.
Update the ticket title to “[OSA-$NUM] $TITLE”.
Embargo reminder can be removed at that point.
MITRE’s CVE Request form should be used again at this point, but instead select a request type of Notify CVE about a publication and fill in the coordinator’s e-mail address, provide a link to the advisory (the URL to official OSA), the CVE IDs covered, and the date published. Once more, fill in the security code at the bottom of the page and submit request.
The security team should provide a judgement call for the severity of the issue for the most common use case of the project. Suggested impact rating categories:
...
- Common Vulnerabilities and Exposure (https://cve.mitre.org/about/faqs.html )
- CVE numbering authorities (https://cve.mitre.org/cve/cna.html)
- CVE FAQ (https://cve.mitre.org/about/faqs.html#what_is_cve_identifier )
Securi