ghsa infosec proposal #1
Conversation
There was a problem hiding this comment.
PR Overview
This PR proposes a detailed process for handling GHSA vulnerability reports by outlining roles and stages in the Infosec GHSA process.
- Adds a comprehensive document defining roles and responsibilities.
- Introduces step-by-step stages for the vulnerability report submission, review, patching, and merging.
Reviewed Changes
| File | Description |
|---|---|
| infosec_instructions.md | Adds a full process proposal for the GHSA infosec workflow |
Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.
| During this stage, the `Remediation Coordinator` will inform the `Reporter` that the 180 (90?) day embargo has begun. The `Remediation Coordinator` should provide the `Reporter` with up-to-date information and be the **ONLY** voice discussing when patches will be available. | ||
|
|
There was a problem hiding this comment.
The specified embargo duration is ambiguous (180 vs 90 days). Please clarify the intended duration.
| During this stage, the `Remediation Coordinator` will inform the `Reporter` that the 180 (90?) day embargo has begun. The `Remediation Coordinator` should provide the `Reporter` with up-to-date information and be the **ONLY** voice discussing when patches will be available. | |
| During this stage, the `Remediation Coordinator` will inform the `Reporter` that the 180-day embargo has begun. The `Remediation Coordinator` should provide the `Reporter` with up-to-date information and be the **ONLY** voice discussing when patches will be available. |
Copilot is powered by AI, so mistakes are possible. Review output carefully before use.
Flickdm
force-pushed
the
doc/proposal/ghsa
branch
from
11906b4 to
bf7101f
Compare
Co-authored-by: Aaron <[email protected]>
|
|
||
| A `Reporter` will hit the `Security` tab on [Edk2](https://github.com/tianocore/edk2/security) to begin. | ||
|
|
||
|  |
There was a problem hiding this comment.
Can you update the image URLs so they show in the markdown preview?
|
|
||
| The following are the stages that a vulnerability goes through until being patched. | ||
|
|
||
| ### Stage: Vulnerability Report |
There was a problem hiding this comment.
Nit: But I think you can have an easy-to-follow process with single word stage names. (1) Report (2) Triage (3) Fix (4) Review (5) Publish (5) Merge.
I thought "Fix" is a little more precise than "Patch" since patch can be interpreted as actually patching the firmware versus a source code fix. Also, "Triage" instead of "Review" to differentiate initial triaging versus later code review.
|
|
||
| ### Stage: Submission Review | ||
|
|
||
| When a new CVE is identified, a `Remediation Coordinator` must be designated (usually at an Infosec meeting). |
There was a problem hiding this comment.
When a new CVE is identified, a `Remediation Coordinator` must be designated (usually at an Infosec meeting).
I think the entire process should avoid a meeting being a choke point. Meetings get cancelled, have lack of quorum, etc. that can stretch out the timeline.
|
|
||
| The `Remediation Coordinator` must then find the following: | ||
|
|
||
| 1. `Remediation Developer` |
There was a problem hiding this comment.
Is the current pool of available developers large enough for this to realistically be assigned without a long period of indecision?
| 1. `Remediation Developer` | ||
| 2. 2x `Remediation Reviewers` (ideally SMEs of the patch in the Infosec community) | ||
|
|
||
| Once these roles are filled, the process can move on to the patching stage. |
There was a problem hiding this comment.
Can you explicitly note how the assignees to these roles are recorded?
| The `Remediation Developer` will perform their work and create a patch as soon as possible. If they have questions | ||
| they should contact the `Remediation Reviewers` ASAP. | ||
|
|
||
| The `Remediation Developer` must update the appropriate package security vulnerabilities json to indicate what is being patched. |
There was a problem hiding this comment.
Link to an example or focused documentation on the JSON.
|
|
||
| ### Stage: Review | ||
|
|
||
| When the `Remediation Developer` is ready for a review, they will create a review on the private fork targeting the main branch. (NOTE: this review will be abandoned). |
There was a problem hiding this comment.
When the `Remediation Developer` is ready for a review, they will create a review on the private fork targeting the main branch. (NOTE: this review will be abandoned).
Expand on when the review will be abandoned to not leave it hanging.
|
|
||
|  | ||
|
|
||
| The pipelines are not expected to work. To reduce the work that will need to take place in the public, the `Remediation Developer` should run as many CI checks locally as they can (formatting, etc). |
There was a problem hiding this comment.
Link to stuart CI instructions at a minimum.
| ### Stage: Merge into Main | ||
|
|
||
| The final stage is to merge the patch into main. Here the *Remediation Coordinator* will work with the *Package Maintainer* to create a pull request against main. The community will have one final ability to comment but merging should be the priority over nitpicking. |
There was a problem hiding this comment.
| ### Stage: Merge into Main | |
| The final stage is to merge the patch into main. Here the *Remediation Coordinator* will work with the *Package Maintainer* to create a pull request against main. The community will have one final ability to comment but merging should be the priority over nitpicking. | |
| ### Stage: Merge into the Primary Branch | |
| The final stage is to merge the patch into the default/primary branch which is usually named `master` or `main`. Here the *Remediation Coordinator* will work with the *Package Maintainer* to create a pull request against main. The community will have one final ability to comment but merging should be the priority over nitpicking. |
| ### Stage: Merge into Main | ||
|
|
||
| The final stage is to merge the patch into main. Here the *Remediation Coordinator* will work with the *Package Maintainer* to create a pull request against main. The community will have one final ability to comment but merging should be the priority over nitpicking. |
There was a problem hiding this comment.
I suggest defining an actionable set of steps to take when time to merge takes priority over some maintainer feedback. For example, collect the feedback to a GitHub issue and assign it to the change author to follow up on.
Initial proposal to ghsa