Add Root Cause Analysis to OSPS-VM-04

[maennchen]

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

[eddie-knight]

From today's SIG call:

Should we add a control for a post-incident response policy ?
Strong consensus that this would be level 3 (at least)
Vuln Mgmt control family probably is the right home
Template will be needed — add it to the list of policy templates we need
Some prior work exists: https://baseline.openssf.org/versions/devel#coordinated-vulnerability-disclosure
And https://baseline.openssf.org/versions/devel#osps-vm-01---the-project-documentation-must-include-a-policy-for-coordinated-vulnerability-disclosure-with-a-clear-timeframe-for-response was also recently updated to include the CVD reference as well

[funnelfiasco]

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.

A couple of scoping questions:

1. Should we require this for vulnerabilities introduced in dependencies or only in the project's code?
2. Do we need a severity threshold?

Requiring it for all vulnerabilities in any part of the stack is ideal from a consumer perspective, but I worry it would be overly burdensome on volunteer maintainers. I'm interested to know what others think.

[SecurityCRob]

I feel this is something we should add. We can bikeshed the precise wording to match our desired format if the team agrees.

[trumant]

Should we require this for vulnerabilities introduced in dependencies or only in the project's code?

I don't find the source of the vulnerability particularly relevant honestly

[funnelfiasco]

I don't find the source of the vulnerability particularly relevant honestly

I'm with you, to an extent. What I'm concerned about is asking maintainers to do a root cause analysis on a vulnerability that appears six levels deep in their dependency graph.

[david-a-wheeler]

Even one level deep is asking much. I have a chance at doing root cause analysis of something that I or my organization did. It's much harder to do root cause analysis of some other group. And what would be the point? The reason for root cause analysis is not to assign blame, but to determine the root cause so you can institute changes to prevent recurrence. Unless you're a government organization where you can cause changes (e.g., through legislation/regulation), it's best to focus root cause analysis on the areas where you are likely to be able to cause a useful change.

[trumant]

Even one level deep is asking much. I have a chance at doing root cause analysis of something that I or my organization did. It's much harder to do root cause analysis of some other group. And what would be the point?

1. Why did this vulnerability get introduced into our project? - because we depend upon library "X"
2. Why do we depend on "X"? - we rely on it for the "flutter" feature
3. Why did we believe "X" met our risk criteria for dependencies? - at the time its usage was introduced "X" had no vulnerabilities open against it
4. Why must "X" provide the "flutter" feature? - It is not the only answer. Alternative libraries "Y" and "Z" provide functional equivalence but with an API change. We can adopt either of them if we can adapt to the new API.

Getting a project to have this conversation seems to be the intent.