On April 2023 DHS, CISA, DOE, and CESER released a report titled ‘Software Bill of Materials (SBOM) Sharing Lifecycle Report’. The purpose of the report was to examine the current ways in which people are sharing SBOMs as well as outline, in general terms, how this sharing could be done better, with greater sophistication to enable better transparency into software.
The report brakes the SBOM sharing lifecycle into 3 phases: Discovery, Access, and Transport. Discovery is how a user or consumer can become aware of the existence of a new SBOM from an author or provider. Access is how a user or consumer can access this SBOM and all relevant data that accompanies it (SBOM enrichment). Transport is how a consumer can receive the SBOM. In all cases the more automated the process is, the better it will be for all parties involved.
Although the report doesn’t specifically mention any tools it does include various examples and lists of attributes such desired tools would include.
We were thrilled to discover here at Scribe that our platform, which enables the sharing of SBOM information as part of its core use, gets very high marks when checked against the list of requirements published.
In this article, we’ll go over the 3 parts of the SBOM sharing lifecycle as specified in the report and examine the most sophisticated solution as seen by CISA. We’ll conclude by describing how Scribe’s platform answers these requirements.
SBOM Sharing Lifecycle Sophistication
Discovery is the initial phase of the lifecycle and it involves how a consumer becomes aware of the existence of an SBOM from an author or provider. This could be as simple as placing a new SBOM in a standardized placement within a vendor website or location within a software repository. It should be clear enough to the consumer how to gain or at least request access to this SBOM data so they can later access it and download it for their use. Sometimes the consumer will need to keep in touch with the provider and ask for updates on his SBOM. Alternatively, automated continuous updates could be made available.
A high-sophistication approach, as stated in the report, places more of the onus of discovery on the provider in order to make the consumer’s life easier. Ideally, there may be a well-known and well-documented process that is ideal for automation and has little that needs to be done manually. As an illustration, a provider might develop a publish/subscribe service that will automatically update users with information on new SBOMs as well as updated versions of existing SBOMs and a mechanism for locating them. Additionally, more sophisticated levels should be more precise in directing customers toward requested information while hiding irrelevant information.
Access is the next step and it details how to obtain access to the data. The emphasis of this stage is on the access restrictions put on the SBOM and how a user will obtain permission to move on to the Transport stage. The easiest way is to make the SBOM fully accessible to the public and there might not even be a requirement to put access controls in place. But, realistically, a provider might demand that SBOMs be kept in a repository where access to them needs to be manually approved or role-defined before being granted to a specific recipient. Additionally, SBOMs might need specific access control granularity to guarantee that customers can only view particular SBOM versions linked to a product or access particular parts of the data.
In a high-sophistication approach a consumer may request access to view an SBOM and a restricted account may be created automatically. If a consumer can show proof that they have purchased a device or piece of software that is relevant to the SBOM in question, such as a software key, access to SBOMs may be automatically granted. With roles or organization-level access controls, there is a high level of permission granularity. This feature requires a high level of sophistication due to the requirement of analyzing and comprehending the permissions of each desired activity as well as tracking the data required to automatically validate customer purchases. Using a system like Public Key Infrastructure delegation using certificate signing, a provider may be able to delegate authentication and access control requests to another organization for an even higher level of sophistication.
Transport is the final step and it details the method by which a consumer receives the SBOM. SBOMs may be transported using various methods from one location to another or from one location to a number of locations. This process is more effectively facilitated by some methods than others. A copy stored on a hard drive and sent from the author to the consumer may be sufficient if the SBOM transport only involves the movement of a single SBOM. A method that enables customers to safely retrieve the SBOM should be made available if a large consumer base needs it. This stage is necessary for the consumer to use the data. Bear in mind that most practical SBOM uses require a machine-readable format so transport needs to take that into account.
Using established protocols, the Transport phase process should be thoroughly documented to enable as much transport automation as possible. An application programming interface (API) ought to be accessible, repeatable, and consistent. It would be sufficient to classify an OpenAPI interface as high-sophistication if it offers documentation for a Representational State Transfer (REST) or RESTful API. 13 Other API standards, like Simple Object Access Protocol (SOAP) or Graph Query Language (GraphQL), can also be considered sufficient. REST is just one popular example of a standardized interface. In fact, any interfaces that offer a comparable level of integration ease are sufficient to be categorized as high sophistication.
How Does the Scribe Platform Answer the Requirements
Scribe developed a platform that enables an automatic publish/subscribe service. A software producer can link their CI pipelines to the platform so that each time they run a build a corresponding SBOM is created. These SBOMs are then enriched with additional information and can be accessed based on the specific project, build pipeline, date, and time. The producer can add subscribers to each project so that once they decide to publish a new software version. All subscribers are notified and immediately have full access, not only to the new SBOM but also to all other security information that accompanies it. The subscribers can access the SBOMs they have access to at their leisure and they can download them whenever they want to.
Once the build pipeline link is done and a subscriber approves they are interested in the data, the entire stream of information is automated and requires little to no manual intervention. The security data is encrypted and secured by Scribe and only the producer and approved subscribers have access. Discovery is automatic, Access is determined by the producer and Transport is at the whim of the subscriber.
The Future of SBOM Sharing
These days SBOM sharing is as likely to be done by email than by an automated system but this approach is not scalable. To enable greater sharing more tools and platforms like Scribe’s need to become available, easy to use, and approachable. A variety of sharing solutions designed for diverse stakeholders’ needs would be advantageous for the SBOM sharing ecosystem. These conditions exist because a given supplier may be requested to use various transport methods by their clients, and a client may be provided with SBOM data using various methods by their upstream partners. We need more solutions that can deal with the identified special situations while attempting, when practical, to do away with manual processes and avoid actions that hinder interoperability. The aim of the industry should be to prevent the emergence of numerous SBOM sharing solutions that are incompatible with one another in a larger supply chain as that would only exacerbate the existing problems.
Since the Scribe platform is free to use for up to 100 builds a month I encourage you to give it a try and see how many of your security and regulatory needs the platform meets. We still have a long way to go for a truly universal platform that meets our vision but it’s a good starting point that we’re eager to share with the world.