The Presidential Executive Order made it clear that the status quo, where the hidden vulnerabilities in cyber supply chains left doors wide open to attackers, can no longer be allowed to persist. It correctly identified transparency as the key principle to build trust and Software Bills of Material as a critical first step of the solution. But while much of the current debate is focused on how to build SBOMs, further and deeper thinking is needed on how to share them. After all, having an SBOM in itself is only a foundational solution; without effective, controlled and timely sharing, SBOMs are of limited use. Simple to implement, low-to-no-code automation of SBOM sharing can lay the foundations for high fidelity enhanced records that ensure all participants in cyber supply chains always know who did what when to their critical software assets.
Do the Math
Simple math makes the complexity of SBOM sharing clear. CISA has identified 11 categories of critical software – everything from browsers and operating systems to identity management. This will encompass thousands of products from hundreds of suppliers. Meanwhile, different approaches and formats for SBOM creation are emerging and the list of requirements will grow from a minimal compliance threshold toward high fidelity attributes. The recent ‘SBOM playbook’ emerging from NTIA shines a light on the growing list of requirements to implement SBOMs effectively. A cursory read shows that even as the format is standardized, the way SBOMs need to be used will vary enormously. Both publishers and subscribers must start to think through how they will share and consume SBOMs in their organisations, and who will be responsible for them.
Open Source Just One Approach
Much of the debate so far has been driven toward the principles espoused by the open-source community; ‘information wants to be free’. Open-source code is now thought to be present in 98% of enterprise applications and does indeed represent a critical aspect of cyber risk. However, most vendors of the software that falls into the 11 categories identified, offer proprietary solutions. Yes, they integrate open source, but they won’t want to reveal sensitive operations to the world. This is where the open-source approach of ‘be open and publish for all to see’ runs out of road. That will work for some, but vendors of critical software must have the means to share their SBOMs with precisely those who need to know and no further. Protecting intellectual property whilst enhancing security in a zero-trust world with transparent disclosure is not impossible. But it does need careful thought.
Everything in the open not always acceptable
Responsible disclosure is another conundrum for developers to consider. Just because a vulnerability is found, does not mean that everyone should be told immediately. If all software could be updated instantaneously then widespread, rapid disclosure makes sense, but the world does not work that way: in most settings it takes time to assess, approve, and deploy updates and balance small local improvements with system-wide stability. Critical service providers must balance the risk of a vulnerability against the business continuity cost and disruption needed to plug it. Everyone doing everything in the open all the time is not the right approach. Disclosure needs to be carefully managed to reach exactly the right people at the right time to minimise the potential exposure.
SBOM Consumption Headaches
On the consumption side of the equation things are no less complicated. Currently, the Executive Order applies only to federal agencies as customers. Yet a big department, say defence or health, will have multiple applications in most if not all the 11 critical software categories. These will often be bespoke and contain code from multiple different vendors. How will they manage thousands of SBOMs across all the services, servers, and devices they operate?
For basic compliance it may be enough to simply archive the SBOM record alongside other critical assets relating to the software. But even this minimalist approach requires thinking through. Where will they be stored, who should have access, how will they find them, who is responsible for updating or terminating them with each supplier?
Others will integrate and automate SBOM assurance into business and development processes and pipelines. But who should be responsible? The users of each individual piece of software, already stretched internal DevOps, governance risk and compliance teams? Each has their own reason to be involved, and their own skillsets – but none has the complete overview.
As SolarWinds is sued by its shareholders, an additional question emerges. How can you prove that you have done enough to secure your cyber supply chain as a producer or consumer? Knowing what is shipped in software packages and how they were built is much like food allergy labelling and kitchen hygiene rating. Proving they are up-to-date, accurate and fully implemented is just as important as having the label. This puts the issue firmly in GRC if not the C-suite territory. How can you adequately demonstrate that you’ve effectively shared SBOMs?
No One Wants an SBOM Department
It’s a complex and multi-disciplinary job to manage SBOM sharing but no one is suggesting or wants dedicated SBOM teams and new layers of bureaucracy to handle this. Instead, automation is the answer. Continuous assurance as a service, as provided by RKVST, represents the low-code solution to automating the distribution of SBOMs. Using simple APIs to seamlessly integrate an immutable ledger of all the SBOMs you publish or consume, RKVST gives you precise control of permissions as to who can see what when. Developers can use RKVST as a private repository to store SBOMs as they work on code, before deciding whether to publish openly, or distribute them confidentially to specific customers. In all cases full provenance and governance is ensured through an immutable record of exactly who did what when to each asset within the SBOM.
SBOMs have a crucial role to play in establishing zero-trust environments that enhance the security of cyber supply chains. Best practices for managing them in ways that do not create unnecessary or onerous bureaucracy are emerging and SBOMs are the first step but MUST be automated now to avoid death by a thousand cuts with minimal check-box compliance. RKVST proves that automation, low-code integration and creation of shared, permission-based collaboration around SBOMs is effective. SBOMs are here to stay, and, when combined with automated continuous assurance will significantly improve cyber resilience without adding to the burden of developers, DevSecOps teams or those charged with managing governance risk and compliance. Visit https://www.rkvst.com/share-sboms/ to find out more.
