distinguish different kinds of vulnerability flows more explicitly

[raboof]

Thanks so much for getting the ball rolling on this!

I think we can distinguish 3 kinds of vulnerability flows:

1. "what to do about vulnerabilities in your own code" (clear point of contact, expectations around timelines, proper coordinated disclosure, etc)
2. "what to do when you find new still-undisclosed vulnerabilities in your dependencies" (inform upstream, share fixes)
3. "what to do when advisories have been published about your dependencies" (use of SBOM and automated tools)

My impression is that these flows are often confused in the field and when discussing the CRA. This document does a fairly good job of covering them all, but is also somewhat ambiguous on the different types in places. I think this document would be a great opportunity to make the distinction (and the different expectations) more clear.

If you agree with this general direction, I'd be happy to propose some refactors to the document to make this distinction more clear.

[mbarbero]

Thank you for the proposal and your enthusiasm for this early draft! Let’s wait to hear what others think before investing time in suggesting any refactors, but personally, I like it. 🙂

[mrybczyn]

@raboof Those are all three valid and real situations. I'm wondering what kind of refactoring you are thinking about? Personally I would love this document to stay as short as possible :)

[rjb4standards]

In my experience there are 2 scenarios that software consumers are concerned with to understand their risk exposure with vulnerabilities:

1. Reporting on a vulnerability affecting products (i.e. CSAF profile 4 Security Advisories)
2. Reporting on the vulnerability status of a specific product (i.e. NIST SBOM Vulnerability Disclosure Reports)

In scenario 1 a software supplier provides customers with a Security Advisory when a vulnerability is reported/confirmed listing affected products. In scenario 2, the software supplier provides a link to a living Vulnerability Disclosure Report that reports the current vulnerability status for a specific product, which the consumer can check at will, as needed.

[lfrancke]

To me it looks like those are two different angles.

@raboof is looking at it through the eyes of a manufacturer (in the CRA sense)/vendor/supplier/provider
@rjb4standards is looking at it from the consumer perspective

[rjb4standards]

I am definitely looking at it from the software consumer perspective.

The Palo Alto support site shows both a security advisory and product vulnerability disclosure report for real world examples of the two concepts in use by consumers: https://security.paloaltonetworks.com/

View by product to see on demand Vulnerability Disclosure Report (VDR)

There are no VEX examples provided.

[raboof]

I agree we should look at this from both the consumer and the supplier perspective: Our goal as spec writers is for consumers to be safe. The target audience of the spec itself is suppliers. Ideally when suppliers follow this spec, this will lead(/contribute) to the consumers being safe.