"SBOM-Plus"

[sparrell]

Issue28 proposes we have a place to start defining terms.
Issue29 proposes to define the term "software bill of materials".

The industry has a problem at the moment with whether adding ancillary information (licensing, vulnerability, End-of-live/sales/security/engineering/..., provenance, pedigree, ...) is "part of the SBOM".

The issue is what to call these "SBOM Plus X" documents

I argue the document created with licensing is not an SBOM but a licensing document. Similarly with each of the other 'additions'.
This is analogous to a bill of materials is different from a price list, is different from an assembly drawing, etc.

[hepwori]

To recap the brief discussion in the OSIM TC meeting earlier today, I think we began to see agreement amongst participants that

1. An SBOM (whatever that is, pending the outcome of Define SBOM #29) should contain some minimum set of information; such set to be determined
2. A document which contains that minimum set and some other information is still an SBOM (and may also be other things)

@sparrell, in the meeting you mentioned having seen a CISA document laying out some version of (1). Participants recalled the NTIA "Minimum Elements" document, but not a CISA one — if you could share the CISA one I think that'd be helpful for the group.

fwiw, principle (2) above is in conflict with the position in this issue that a "document created with licensing is not an SBOM" and nor are documents "with each of the other 'additions'". I think that in the meeting you were OK with principle (2) prevailing here; is that correct?

[hepwori]

I should add that in the light of an "SBOM-Plus" in fact being still an SBOM, I'm not convinced that we need the term "SBOM-Plus" at all: that is, an SBOM that contains information beyond the minimum requirements is an SBOM, not an SBOM-Plus.

[sparrell]

Wrt: "I think that in the meeting you were OK with principle (2) prevailing here; is that correct?" Probably but will depend on wording. The devil is in the details. My main concern is so that we can tell the information models apart and don’t encumber ‘SBOM’ with ‘non-SBOM’ stuff. I propose we make actual formal information models (eg in JADN) and you can’t be as wishy washy in them as humans do with English. Wrt: "I'm not convinced that we need the term "SBOM-Plus" at all" I do think we need to somehow distinguish between the information model of 'the thing describing the components' and the other things that describe pricing, availability, vulnerability, exploitability, endofpatching, end of life, etc ad nauseum. I consider the 'core SBOM' (or whatever we will call it - the thing without the extras) to be immutable but the other things may be stochastic. I'm maybe ok depending on what we call things to having the license info model be 'SBOM plus license' WHEN THEY ARE OVERLAPPING. But note you can have a licensing doc without SBOM part, and I am against calling that an SBOM. Another example is a VEX isn’t an SBOM although you can have a VEX that effectively contains an SBOM – but you can have one that doesn’t as well. It is those ‘doesn’t as well’ that I worry about. Related sidenote: A use case I want to handle is on the ‘immutable’ part (ie the ‘core’ or ‘sbom-only’) that is just the components and I want to add other ancillary info like hashes, completeness metrics, quality metrics or providence/pedigree. Note you can do those things on the ‘other’ SBOM-plus elements as well but that is very different once you get into the details of actually doing it and the immutable vs stochasitic aspects. Wrt: "CSIA docs" - I'll have to find. I think I’m munging several: * One I was thinking of was the attestation edict/repository https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form. * Another is the one I thought more appropriate from an edict viewpoint but I guess it never came out yet. The incident reporting gets all the press but there are SBOM requirements in https://www.federalregister.gov/documents/2023/10/03/2023-21328/federal-acquisition-regulation-cyber-threat-and-incident-reporting-and-information-sharing Note it does reference the NTIA but does it as a normative requirement (ie changes NTIA guidance to DOD/GSA/NASA edict) * The NSA put out https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3617462/nsa-releases-recommendations-to-mitigate-software-supply-chain-risks/ * And I swear I thought there was another CISA one that I even did an official Federal Register comment on, but I can’t find it so maybe it’s a hallucination. iPhone, iTypo, iApologize Duncan Sparrell sFractal Consulting, LLC I welcome VSRE emails. Learn more at http://vsre.info/

…

________________________________ From: Isaac Hepworth ***@***.***> Sent: Tuesday, August 6, 2024 8:17:52 PM To: oasis-tcs/osim ***@***.***> Cc: duncan sfractal.com ***@***.***>; Mention ***@***.***> Subject: Re: [oasis-tcs/osim] "SBOM-Plus" (Issue #31) I should add that in the light of an "SBOM-Plus" in fact being still an SBOM, I'm not convinced that we need the term "SBOM-Plus" at all: that is, an SBOM that contains information beyond the minimum requirements is an SBOM, not an SBOM-Plus. — Reply to this email directly, view it on GitHub<#31 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AANEXD2E5N57KX5UBFZIILLZQFRTBAVCNFSM6AAAAABKCLQKAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZSGM4DIOBUGY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[sparrell]

Not the one I was thinking of but note that https://www.cisa.gov/resources-tools/resources/software-acquisition-guide-government-enterprise-consumers-software-assurance-cyber-supply-chain has come out from CISA, CSOC, & ITSCC. It is on an adjacent topic (software assurance - which they use a definition USG has used for awhile and we might want to add to our definitions) but has SBOM requirements, particularly about attestation, that we might want to take into account. I think if we do, the 'stochastic' vs 'immutable' parts become more important to delineate well in the info model.

[sparrell]

Wrt: "A document which contains that minimum set and some other information is still an SBOM (and may also be other things)"

I see there being different aspects to the issues that I am having a hard time articulating. I'm going to use the term 'collection' to be the thing @hepwori is calling an SBOM wrt to the 'and may also be other things'. Ie Collection is the collection of all these other things together that we are calling an SBOM. And I'm going to use 'view' (or maybe 'profile' or hopefully someone has a better word) to be the different 'types'/views/profiles for each of the different needs. IE SBOM is the 'collection' and component/licensing/EoX/vulnerabilities/exploitability/.... are the different 'views'.

Personally I wish SBOM was the name of the 'component view' and some other name was the name of the 'collection'. But if we go with SBOM as the term meaning the collection, then we need to define the name for the 'view' that doesn't have the other stuff and is just the 'classic SBOM, ie the components'. So I'm calling that the component view or component profile.

I would argue that to be an SBOM, you need at least a rudimentary component view (may be just one component) to then attach the other views (eg licensing). But for some use cases and some views, you need a 'better'/'complete'/... component view. Eg for some licensing use cases, you just need the license of the thing you buy and don't need a complete component view (depending on contract T's and C's but assuming seller assumes risk if they sold something with wrong license due to some license issue in a component). But vuln management might need a 'complete' component view to know that CVE whatever doesn't impact the product.

[hepwori]

Yes, I think it makes great to sense to determine what minimum set of information goes into the "base profile" of an SBOM and what other "extended profiles" we'll need.

We might also think about the principles behind an SBOM. For example, I like the idea that SBOMs are descriptors of a software product — and for a given release version of that product are unchanging and immutable. That suggests amongst other things that information about vulnerability exploitability, or even EOL expectations, are a poor fit for SBOMs… since this is information that is liable to change after the SBOM is created and issued.

Of course, there is a ton of complexity hiding here in how we define "software product". See e.g., #29 (comment).