Roles & Responsibilities:

• Reporter
  • Responsibility:
    1. Submits apotential vulnerability to the Infosec group
• Remediation Coordinator
  • Responsibility:
    1. Coordinates the community
       • Finds aremediation developer
       • Finds (ideally) 2xRemediation Reviewers
    2. Acts as the one voice for responding to theReporter
    3. Should be aTianocore Owner or coordinate with one. They are the only ones who can create a new GHSA
• Remediation Developer
  • Responsibility:
    1. Patching the vulnerability
    2. Testing the patch
       • Must write up what tests they've ran and include information about Platforms / Conditions / Environment
• Remediation Reviewer
  • Responsibility:
    1. Subject matter experts (SMEs) that should be available to answer questions posed by theremediation developer
    2. Testing the patch
       • Must write up what tests they've ran and include information about Platforms / Conditions / Environment
• Package Maintainer
  • Responsibility:
    1. The final shepard of the patch from the advisory branch to main
• Security Advisory Writer
  1. This may be the same as theRemediation Coordinator
  2. Either a maintainer or a member of this group may create a target branch and approve merge to it
  3. Needs to be a member ofSecurity Advisory Writer

The following are the stages that a vulnerability goes through until being patched.

A Security Advisory begins when areporter reports a vulnerability.

AReporter will hit theSecurity tab onEdk2 to begin.

Now theReporter can begin submitting vulnerability details.

At this point theReporter is waiting for response from the EDK2 Info Sec group.

Alternatively a report may be given by VINCE. In that case, the reporter should be directedto the github security page to submit the security issue for internal tracking.

When a new CVE is identified, aRemediation Coordinator must be designated.

TheRemediation Coordinator must then find the following:

1. Remediation Developer
2. 2xRemediation Reviewers (ideally SMEs of the patch in the Infosec community)

TheRemediation Developer must find developers either within their own organization or within the Infosec community.

Once these roles are filled, the process can move on to theFix stage.

If the submission is not found to be a CVE, theRemediation Coordinator must work with the submitter to close the issue. TheReporter is allowed to (and probably will) write up public documentation.

During this stage, theRemediation Coordinator will inform theReporter that the 180 day embargo has begun. TheRemediation Coordinator should provide theReporter with up-to-date information and be theONLY voice discussing when patches will be available.

TheRemediation Coordinator should then create a new GHSA and a temporary fork for the Advisory. Each Advisory will have exactly one fork that may contain multiple branches, forked from EDK2.

TheRemediation Developer will perform their work and create a patch as soon as possible. If they have questionsthey should contact theRemediation Reviewers ASAP.

TheRemediation Developer must update the appropriate packagesecurity vulnerabilities json to indicate what is being patched.

Ideally this should be completed within 90 days. Leaving another 90 days at minimum for testing across a wide range of platforms and feedback.

When theRemediation Developer is ready for a review, they will create a review on the private fork targeting the primary branch.

The pipelines are not expected to work. To reduce the work that will need to take place in the public, theRemediation Developer should run as many CI checks locally as they can (formatting, etc).

Example: PatchCheck, Uncrustify, etc

During this stage, theRemediation Reviewers must be responsive. If one or both reviewers are unresponsive, theRemediation Coordinator should contact them as soon as possible. If unresponsiveness continues, theRemediation Coordinator should involve a maintainer to push the patch forward quickly.

TheRemediation Coordinator should encourage theReporter to review the patch and verify if they are able to reproduce the original vulnerability.

The review will be considered complete when bothRemediation Reviewers ormaintainer have accepted the patch. If two Remediation reviewers could not be found, then a maintainer may act as the additional or final approver.

Once the review is complete, and the team is ready to publish. The rest should follow in quick succession (1 Day)

TheRemediation Coordinator must work with (or be a)Security Advisory Writer or a maintainer to create a branch that follows the format "/security-advisory/cve-xxx-xxxx/advisory".

This special branch will not be the final destination but simply a means to publish the branch so that the community can be advised and comment. However this branch must be merged in within 24 hours.

Next, theRemediation Developer should target the new branch. Then the Remediation Developer may close their previous reviewed PR that was targeting master.

TheSecurity Advisory Writer orRemediation Coordination orMaintainer may merge the new branch. ThenRemediation Coordinator may then publish the GHSA and credit the appropriate parties.

The final stage is to merge the patch into the primary branch. Here theRemediation developer will create apull request against the primary branch. Any final CI issues should be address and the community has 24 hours to comment before being merged in.

Once merged the process is complete.