It has been nearly a year since the President Biden’s Executive Order 14028 catapulted Software Bills of Materials (SBOMs) from niche topic to the forefront of efforts to improve security of cyber supply chains. Since then not only have federal agencies including NIST and CISA delivered significant amounts of guidance and insight, but SBOMs have been the subject of intense debate across developer communities and beyond. However, we must all recognise that the use of SBOMs is still in its fledgling state. The focus to date, rightly, has been on how to generate these vital ‘ingredient lists’ so that federal customers are aware of exactly what’s in the software they are buying. But creating an SBOM is just the tip of the iceberg. Far more lies beneath the surface as both publishers and consumers begin to tackle the complexities of implementing SBOMs as part of a zero trust approach to cyber risk. The subsequent steps of storing and distributing SBOMs are equally critical and need urgent attention.
Step One: Generate an SBOM
Generating an SBOM for new or existing software is the essential first step, and it is non-trivial in itself. Identifying every constituent element of a piece of software, understanding its provenance, assuring its integrity and tracking all its dependencies is a significant task even for relatively basic applications. Fortunately, there are many tools and vendors emerging that can automate and help streamline these processes. Then there is the issue of creating your SBOM in a format that meets the requirements outlined by NIST and can integrate with a wide range of tools required to transform an SBOM from a static list of components into a machine-readable file that can play its intended role at the heart of proactive and dynamic cyber risk mitigation. Here again, standards are emerging, and an ecosystem of tool vendors are beginning to establish the foundations for automation.
Step Two: make it Secure but accessible
But the current focus on generation has obscured the need for more work on what happens next. Once an SBOM is created it must be stored somewhere. As security ‘shifts left’ it becomes the daily routine of developers. They will need almost continuous access to the most up-to-date SBOMs for any code they are working with. They will need continuous assurance that they can trust the SBOM they are referencing is accurate, complete and current. We are already hearing anecdotal evidence of developers maintaining 2 or 3 repositories for SBOMs, one for those being built, one for internal use and one for published ‘public’ SBOMs. The management overhead, and the potential for errors are already high. As SBOMs multiply and are ingested and exported between participants of complex software supply chains, simply knowing where to find the SBOMs you need will become a significant challenge. And don’t think that you can have just one SBOM that you overwrite every time and put in a well-known location: customers are likely to be using many different versions of software and need the SBOM for the software they’re actually using, not some pristine ‘latest’.
Step Three: Share it with the right people
To be any use, an SBOM must be shared. Consumers of the software to which it pertains must be able to access and integrate the information at the point of need. Sometimes this will be during an initial due diligence process as part of a software purchase cycle. But once software is part of the customer organisation’s stack governance risk and compliance teams, as well as security and internal development teams, will all need to access current SBOMs on an ongoing basis. Publishers will need to ensure that the most up-to-date SBOMs for their software are easily available to those that need them in a timely fashion, as well as SBOMs for previously released versions for real-world customers who can’t patch every day.
Definitions of who needs to know what will change between applications, customers, and roles. Whilst it may be acceptable to publicly share SBOMs for open-source code for all to inspect, most commercial software publishers will not want to share details of proprietary code with everyone, and when sensitive customers are involved who have long patch cycles and can’t change configurations quickly, the idea of responsible disclosure starts to become very strained. That requires implementation of governance and granular permissions that ensure only those with authorisation are able to see specifics of individual SBOMs. These permissions will vary not only with every piece of software and every customer, but even with individual elements of a software package and roles within an organisation.
No need for an SBOM department
Some commentators have already pointed out that the management overhead needed to successfully implement an SBOM-focused cyber risk mitigation strategy dooms it to failure from the outset. However, we disagree. No one wants to hire an SBOM department just to manage the storing and sharing of potentially thousands of SBOMs, but automated, easy to implement solutions already exist.
RKVST provides a blockchain-based cloud service that provides an immutable record of who did what when to any asset. Applying this zero-trust fabric to SBOMs means that multiple parties can establish the provenance of an SBOM, set up and enforce granular governance for distribution, and leverage a flexible yet secure storage repository.
RKVST SBOM Hub is already tracking thousands of publicly available SBOMs making it the perfect place to find and fetch the SBOMs you need. Any software company can share SBOMs for its products on the RKVST SBOM Hub in CycloneDX and SPDX formats. It can also use an RKVST private repository to store those SBOMs it is working on or does not yet want to share. The private permissioned blockchain technology at the heart of RKVST allows users to share SBOMs only with accredited participants. Publishers can not only share with specific parties at specific times, but thanks to the immutable ledger, can prove what was shared with whom and when. All of this can be implemented through a simple API so that publishers or consumers can easily onboard their supply chain partners to the RKVST platform without requiring expensive and hard to find blockchain developers.
SBOMs will certainly play a significant role in the zero trust fabrics of almost every organisation. Ensuring that they can not only be generated but stored and shared without creating massive bureaucratic overheads will accelerate their deployment and the enhanced security of cyber supply chains we all desire. RKVST tackles the subsurface mass of the SBOM iceberg in an effective, efficient and easy to implement way. Check it out here.
