Add Root Cause Analysis to OSPS-VM-04
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 166
- Forks
- 44
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 13
Description
Changes
I would like to include the requirements for a root cause analysis (either level 2 or 3) in OSPS-VM-04 (either add to OSPS-VM-04.01 or create a new subsection).
For every vulnerability, the maintainers of a project should analyze why things went wrong to avoid repeating mistakes and also to make sure no similar vulnerabilities are in the project.
External Framework Mappings
- NIST SSDF -
RV.3 - CRA §14 - 4.c.ii
Something like this could work:
diff --git a/baseline/OSPS-VM.yaml b/baseline/OSPS-VM.yaml
index 8445507..1e3f3ac 100644
--- a/baseline/OSPS-VM.yaml
+++ b/baseline/OSPS-VM.yaml
@@ -165,11 +165,13 @@ controls:
- 2.1
- 2.4
- 2.6
+ - 4.c.2
- reference-id: SSDF
identifiers:
- PO4.1
- RV2.1
- RV2.2
+ - RV.3
- reference-id: CSF
identifiers:
- ID.RA-01
@@ -188,8 +190,8 @@ controls:
Provide information about known vulnerabilities in a predictable
public channel, such as a CVE entry, blog post, or other medium.
To the degree possible, this information should include affected
- version(s), how a consumer can determine if they are vulnerable, and
- instructions for mitigation or remediation.
+ version(s), how a consumer can determine if they are vulnerable, a
+ root cause analysis and instructions for mitigation or remediation.
- id: OSPS-VM-04.02
text: |
While active, any vulnerabilities in the
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with baseline/OSPS-VM.yaml and inspect OSPS-VM-04.01 and its surrounding controls. Review the proposed NIST SSDF RV.3 and CRA §14 4.c.ii mappings, then determine whether the root cause analysis belongs in OSPS-VM-04.01 or a new subsection. Done means the requirement and mappings are updated consistently in the baseline YAML.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- yaml
- Domain
- security
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100