Use of the term vendor does not encompass open source projects effectively

[kestewart]

Please consider broadening the language used to use terms like suppliers (aligning with NTIA), organizations, or be expllicit like MITRE has in the CNA program to say "vendors and projects".

[kestewart]

Consider aligning with NTIA's definiton of Supplier

5.8 Supplier entity that creates, defines, and identifies components and produces associated SBOMs A supplier may also be known as a manufacturer, vendor, developer, integrator, maintainer, or provider. Ideally, all suppliers are also authors of SBOMs for the suppliers’ components. Most suppliers are also consumers. A supplier with no included upstream components is a root entity.

found at: https://www.ntia.gov/files/ntia/publications/framingsbom_20191112.pdf

[tcullum-rh]

I agree that "vendor" is universally defined as "one that sells", "a person or agency that sells", and similar. In a significant number of circumstances/deployments, open source, free, and other software components are not being "sold."

[sthagen]

The TC will of course consider.

But, to provide personal feedback: Didn't we (software engineers) learn for decades, that a vendor in software is the creator and maintainer role? Like we learned to feel bad for not providing reproducible builds ... and in the suggested supplier entry from some NTIA document it already states

"A supplier may also be known as a [...] vendor [...]"

So, we are aligned already, right?

Historically, the CVRF/CSAF standards came into existence driven by the needs of the vulnerability disclosing communities - those that actually issued security advisories. Thus, the CSAF (and prior CVRF) specifications "borrow" the vendor definition from the ISO 29147 standard.

Personally, I like the simplicity of the definition for vendor in "The CERT® Guide to Coordinated Vulnerability Disclosure", Allen D. Householder, Garret Wassermann, Art Manion, and Chris King, August 2017, SPECIAL REPORT CMU/SEI-2017-SR-022 which states:

Vendor – the individual or organization that created or maintains the product that is vulnerable

I would rather avoid glossary entries that divert the reader. Instead suggest to choose a single best-matching term "activating" the reader to work with synonyms (and antonyms) until she understand herself a specific role within the scope of the document. Maybe that is my European background that focuses more on what a sender has to send than what a receiver may receive (Yes, I care, but prefer active readers).

I think that by replacing "vendor" with a chimera like "vendors and projects" there is a danger of losing focus. In the end, it is always individual people that invent, create, break, and repair stuff ...

[tibcodenny]

Everyone has interpretations of the terms "vendor" and "supplier" that are colored by their own personal history. I for instance don't care for the term "supplier" because in my early history this referred to a supply house like Digitkey or Mouser. They didn't actually make things, just redistributed them. I have similar issues with "vendor." And don't even get me started on what "project" means.

My point is that there will be no term that universally fits personal history. The term "vendor" is pretty well accepted at this point. We're identifying a singular entity, so the addition of "and ..." unnecessarily dilutes the term.

[tschmidtb51]

I think there are 4 options the TC should consider:

1. Replace (wherever reasonable) the term vendor with supplier. This would affect at least the following paths in the schema:

   /definitions/branches_t/category
   /definitions/full_product_name_t/product_identification_helper/x_generic_uris (just the descriptions)
   /document/publisher/category
   /document/publisher/vendor_id
   /vulnerabilities[]/involvements[]/party
   /vulnerabilities[]/product_status/recommended (just the description)
   /vulnerabilities[]/remediations[]/category
   /vulnerabilities[]/remediations[]/entitlements[] (just the description)

   and add the definition to the terminology:

   Supplier: entity that creates, defines, and identifies components and produces associated CSAF documents. It may also be known as a manufacturer, vendor, developer, integrator, maintainer, or provider.

2. Add in all places an informative comment that this includes all sorts of suppliers, manufactures, open source projects,...

3. Add the definition given by ISO 29147 standard (or SPECIAL REPORT CMU/SEI-2017-SR-022) to the terminology and add a note why we choose this term over "supplier". (Reasoning: More used in CERT/PSIRT/CSAF community...). Add for the VEX profile a note that their "supplier" term equals our "vendor". I would probably remove the part "that is vulnerable" as we have a product_status called known_not_affected

4. Add a new definition for vendor which explicitly names open source projects:

   Vendor: the individual or organization or open source project that created or maintains a product

Thoughts?

Edit: There is one more option - but I don't think that this one should be consider by the TC:

5. Do nothing.

[sthagen]

I do not think that closed or open source does matter when it comes to security advisories. I also doubt, that the term "open source project" should be added to the specification because of the vagueness of relationship to the product the term introduces.

If option 5 (from @tschmidtb51) is really not the way the TC wants to go , then my personal list (first the most preferred) is:

1. Option 4 from @tschmidtb51 modified to

   Vendor: the community, individual, or organization that created or maintains a product

2. Option 3 from @tschmidtb51

The other options make no sense to me. With differing rationale:

Option 2 from @tschmidtb51 "Add in all places an informative ..." might just become additional noise

Option 1 from @tschmidtb51 "replacing vendor with supplier" I deeply dislike because of the vagueness of the term supplier and the definitions known to me often meandering around to include aspects not relevant for typical relationships important for security advisories.

Please note:

It is not, that I dislike the term supplier. In my daily work and for years the term supplier makes a lot of sense when a vendor delegates to a supplier to satisfy an acquirer (often thousands of suppliers actually ... including 30 direct NPM third-party packages, may lead to pulling in thousands of packages in effect - often even multiple versions of a single package simultaneously in part because of the way these bread and butter package managers walk the dependency trees and in part because of package authors pinning the dependency versions). In that case, the contract partners (vendor and acquirer) will need terms that ensure that the effectivity, efficiency, legitimacy, quality, safety, and security satisfy transitivity assumptions along the complete supply chain.

[mprpic]

Renaming everything to "supplier" would indeed be an invasive change at this point so +1 for option 4 on adjusting the definition of Vendor to explicitly note open source projects.

[sthagen]

I think "open source projects" is not useful but community is, so I suggest to go per:

Vendor: the community, individual, or organization that created or maintains a product

[santosomar]

I suggest the following addition:

Vendor: the community, individual, or organization that created or maintains a product (including open source software and hardware providers)

[santosomar]

This issue t was discussed during the CSAF TC Monthly meeting on May 26th, 2021. The changes suggested above were approved.