I'll try to make issues/PR's etc but I want to hitchhike on some of the discussion last meeting.

We didn't discuss 'types' of SBOMs – where type is as used in the CISA workgroups. Let me digress and say the work "type" is my fault in that context as since the beginning I would bring up SBOMs of source code are a different 'type' of SBOM than build artifacts then an SBOM made by an executable scanners. The word stuck even though everybody hates it (just like they hate VEX as a word). We have the opportunity to correct these misnomers and the more I think about it, the more I think we need to address the information model of the provenance and pedigree of both the software that is the subject of the SBOM, and of the SBOM itself. I say this because the 'type' (ie what process used to create it) is just Pedigree/ Provenance "information".

This implies we need to define Pedigree and Provenance in our context. The NTIA SBOM use case doc (from 2019) has the following text along with related text on 'integrity' which we will also need to define:

Provenance

The Provenance of an SBOM is the term of art for having information about the chain of custody of the software and all of the constituent components that comprise that software, capturing information about the authors and locations from where the components were obtained. Whether a component comes directly from the supplier's distribution site or some other location can be a concern for some organizations. Similarly, understanding the exact identity of the supplier can help an organization establish where to go for updates or to communicate about bugs or enhancements. Finally, access to authorship allows organizations to correlate their experience with components to the creators and rank their internal preferences through reputation-like scoring of providers of software.

Pedigree

The Pedigree of an SBOM is the term of art for having information on all of the components that have come together to make a piece of software and process under which they came together. This can include details beyond components, such as compiler options. For example, understanding whether compilation options invoking ASLR were used or not used indicates that the resultant piece of deployable code is hardened against certain types of attacks. Understanding of the process used in taking the source code and incorporated components and libraries to formulate the resultant executable is an important source of insight for those who need to know what selection of options were used in creating the executable software.

Integrity

The Integrity of the SBOM refers to the use of cryptographic techniques to indicate that the SBOM hasn't been altered since written by its author or if there was a modification it indicates that alteration by some subsequent SBOM author. Being able to determine the SBOM's integrity can help, for example, in situations where there is concern about whether an adversary may be purposefully trying to alter the SBOM to mislead those using them for analysis of vulnerabilities. If someone edits the SBOM to indicate it has a later, non-vulnerable version of a component, the organization will be left susceptible to attacks against that vulnerability even though the altered SBOM indicates they are using a non-vulnerable version. Similarly, alteration of the authorship or source information would undermine the Provenance of the SBOM or alteration of the details of the formulation choices would undermine the Pedigree of the SBOM.

Does this make sense (ie the concept that 'type' is really just pedigree/provenance)? If so, I'll make into PR's. If not, let's discuss.

Hi Duncan,

I usually say that during the lifecycle activities of a piece of software there are different points where SBOMs usually have value and may be created.

One is while you are doing design, one is while you are working with source code, one is when you create a deployable item from the software, one is when you have installed/deployed the software into use, and one is when you are using the software.

These map to the Design, Source, Build, Deployed, and Runtime "types" that CISA's community document captured. The other "type" is Analyzed, which is for when you don't have anything but the running code and have to try to intuit what you can by analyzing it to create the SBOM.

Bob

Hi Duncan, I usually say that during the lifecycle activities of a piece of software there are different points where SBOMs usually have value... -posted to the "OASIS Open Supplychain Information Modeling (OSIM) TC" community

Open Supplychain Information Modeling TC Post New Message Re: Pedigree and Provenance might play bigger role SBOM information Reply to Group Reply to Sender via Email Sep 5, 2024 12:29 PM Robert Martin Hi Duncan, I usually say that during the lifecycle activities of a piece of software there are different points where SBOMs usually have value and may be created.   One is while you are doing design, one is while you are working with source code, one is when you create a deployable item from the software, one is when you have installed/deployed the software into use, and one is when you are using the software.   These map to the Design, Source, Build, Deployed, and Runtime "types" that CISA's community document captured. The other "type" is Analyzed, which is for when you don't have anything but the running code and have to try to intuit what you can by analyzing it to create the SBOM.   Bob     Reply to Group via Email   Reply to Sender via Email   View Thread   Recommend   Forward   Original Message Original Message: Sent: 9/5/2024 12:14:00 PM You are subscribed to "Open Supplychain Information Modeling TC" as isaach@google.com. To change your subscriptions, go to My Subscriptions. To unsubscribe from this community discussion, go to Unsubscribe.

Hi Duncan,

I usually say that during the lifecycle activities of a piece of software there are different points where SBOMs usually have value and may be created.

One is while you are doing design, one is while you are working with source code, one is when you create a deployable item from the software, one is when you have installed/deployed the software into use, and one is when you are using the software.

These map to the Design, Source, Build, Deployed, and Runtime "types" that CISA's community document captured. The other "type" is Analyzed, which is for when you don't have anything but the running code and have to try to intuit what you can by analyzing it to create the SBOM.

Bob

To the definitions part – I'll defer to Bob Martin who I consider the provenance/pedigree SME.

To how they relate – use the simple case of SBOM-A was made at build by the build system. SBOM-B was made by code scanning the executable. They are different 'types' in CISA Working Group docs but are really just different pedigree/provenance/lineage from the core information viewpoint (ie information about components derived by different means).