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.

[jayjacobs]

this looks like this may be a duplicate (though more succinctly stated) with Issue #78

[zmanion]

I'd say they overlap, but #78 might go further into the "supply chain" problem (how does supplier A convey status for a vulnerability in an upstream component from supplier B).

[zmanion]

We have roles and types in the current Partners data, but I don't think either of these fields will work.

To restate: A CVE consumer needs to know if the CNA is speaking first-hand, authoritatively, about the vulnerability (e.g., CVSS, CWE, CPE), because some (many?) consumers may treat authoritative information with different (greater?) confidence than non-authoritative data.

This may particularly impact the use of CPE (or other software identifiers), if, for example, the supplier is providing software IDs used in the record, those IDs may be treated as "the correct names."

[jayjacobs]

One thing that may help is to have a clear name and definition for the criteria when this would true versus false. For example, it's probably clear when it's a commercial product, the vendor has authority over that product, but what about open source projects? Would CNAs have a clear list of products they are an authority for? or would some CNAs always be true or false?

[Chris-Turner-NIST]

I'm reading/hearing a lot of interest for this across many different data-type trust use cases.
How do we ensure appropriate context is clear for the data types a data provider is self-asserting confidence?
(Maintainer of Product vs Specification Authority vs Research Organization vs Agent etc.)

Problem Statement Refactor Attempt:
Some CVE records contain conflicting information from different sources. As a downstream consumer, I want to know which organizational information is most authoritative or appropriate to prioritize in my vulnerability management processes.

[MrMegaZone]

There was a lot of discussion on today's QWG call - we used 45 minutes of the meeting on this issue. A lot of different views.

I believe we need a clear statement of 'why' - what is the problem this will solve, and for whom. Art indicated he may work on providing that.

There were different thoughts on the form this would take.

• A 'True/False' binary flag - is this my code or not. Is the entity publishing the container the same entity that developed the product/code.
• A 1-10 scale of how responsible the entity is.
• A 'Type' or 'Role' for the entity, as indicated in 'Organization Types' in https://www.cve.org/PartnerInformation/ListofPartners
• Some simplified list of roles such as 'Author', 'Agent', or 'CNA'.

And then there is the issue of making this a required field or not, which is a significant decision.

Personally I feel I need to better understand the problem being solved to get a feeling for the right course. Based on today's discussion I'm leaning toward the simplified list concept. The Author would be the entity who created the code, an Agent would be someone acting on behalf of the creator, such as a bug bounty program, and then CNA would be someone just acting as a CNA with no direct ownership or authority for the code itself.

I would need some convincing to make it a required field, if only because we've kept the barrier to creating records low by limiting the number of required fields, and if we're going to start adding more required fields there are fields that are probably more widely useful I'd see added first, like CVSS and CWE.

Even if not required it may be useful as those who are authorities would have reason to declare as much. If I'm the 'Author' and speak with authority, why wouldn't I make that known?

Since there were a number of different views after the extended discussion those who thoughts on this issue were encouraged to bring them here, so hopefully we'll see more of those captured.