hepwori
commented
3 months ago I suspect that we'll be able to reach agreement relatively easily on the idea of an SBOM being a list of the constituent components of a product.
I think the really hard work will be to define "product" and "constituent components".
An example: Microsoft Teams is considered by many to be a product. How might one unambiguously determine its horizontal and vertical boundaries—particularly those of the hosted portions—to figure out what components are "a part of it"? For packaged software products this is a fairly straightforward question to answer. For SaaS software products, particularly large complex ones, it's anything but.
I'd be interested in others' view on this aspect.
aj-stein-nist
Issue #28 proposes we have a place to start defining terms. I propose one term that needs an official standard definition is SBOM, or more appropriately Software Bill of Materials, the term for which SBOM is an acronym.
Hopefully we can easily agree SBOM needs defining. Maybe not quite as easily but hopefully still easy, we can agree with the definition in EO 14028 - either in its entirety or trimmed down/editied/whatever.
a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.Some might argue it's already defined - but the White House is not a recognized SDO. NIST is - if someone can find their definition the we could use it by reference