Require CNA organization type, at least when type == vendor

[zmanion]

CNAs can have multiple organization types (expand 'Program Roles / Organization Types' on the Partners page).

It's important to know when a CNA is acting as a Vendor, i.e., the first-party developer/supplier/maintainer of the software in question for the CVE. The other organization types are less important, but an option could be to require the CNA to specify which organization type they are operating under on a per record basis. A simpler option would be to specify type == vendor when that is true.

Using Palo Alto as an example, after a quick search it seems like they assign primarily or exclusively as "vendor" and rarely or never as "researcher," but they could assign for a vulnerability "...discovered by Palo Alto Networks that are not in another CNA’s scope." I'd like to know when they act as "vendor" without having to (manually) read a description, affected elements, or other record information.

[ccoffin]

I agree that this would be useful at the CVE Record container level for some CVE consumers. One thing we need to discuss, maybe in the next QWG, is the criteria to be used for determining whether we add something like this as a tag or as a custom property. This data probably wouldn't change after it has been written, which might suggest using a new Boolean (vendor) property.

[jayjacobs]

Could this be generalized to basically specify if the CNA is an "authority" on the vulnerable platform? Meaning for a CNA that just aggregates found or stray vulnerabilities (vuldb), they would generally always not be an "authority" on that product. (maybe "authority" isn't a good concept, maybe "responsible" or some other concept meaning they have some skin in the game)

What's the use case? Just guessing, but if you are looking at some of the enriched data, you may put more confidence in data that stems from the authority/responsible party and less from those without authority/responsibility? The assumption being that the authority/responsible party has access to more information to generate a CVSS or CWE or whatever about the vulnerability? Or another use case?

[pete2160]

This: assumption being that the authority/responsible party* has access to more information to generate a CVSS or CWE or whatever* about the vulnerability.

…

On Thu, Sep 19, 2024 at 1:30 PM jayjacobs ***@***.***> wrote: Could this be generalized to basically specify if the CNA is an "authority" on the vulnerable platform? Meaning for a CNA that just aggregates found or stray vulnerabilities (vuldb), they would generally always *not* be an "authority" on that product. (maybe "authority" isn't a good concept, maybe "responsible" or some other concept meaning they have some skin in the game) What's the use case? Just guessing, but if you are looking at some of the enriched data, you may put more confidence in data that stems from the authority/responsible party and less from those without authority/responsibility? The assumption being that the authority/responsible party has access to more information to generate a CVSS or CWE or whatever about the vulnerability? Or another use case? — Reply to this email directly, view it on GitHub <#340 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLITHH7Y45U4V6UPCC545LZXMC3VAVCNFSM6AAAAABOJZ5AQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRRG44TEMJUGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[zmanion]

A use case: As a (possibly bulk) consumer and analyzer of CVE data, I want to be able to quickly decide if the author/CNA is first party, because I'll likely choose to "trust" their content, while I may trust content from a non-first-party less (and perform further analysis/verification).

I think it should be simple enough to require a CNA to assert their first-party/vendor role for a record. The CNA must have a vendor type and on a per-record basis can assert their "first-party supplier" label.

[zmanion]

An option would be to require and assert that every supplier CNA has scope for their products and only assigns for that scope. There would be no need for a per-record flag or assertion, every record from that CNA is 1st party for the affected products (using "products" very broadly here).

For organizations that have other roles, they'd need separate CNAs with different scope. Continuing the example, Palo Alto Unit 42 the research organization would be a separate CNA from Palo Alto the supplier.

My original idea was to add a field or tag to a record, which might be quicker to implement but not as robust in the long term.