The whole point of an SBOM is lost if you keep it a secret. Here we reveal our secrets of the ideal SBOM exchange. Let us know if we’ve missed anything in RKVST SBOM Hub.
SBOMs are made for sharing and are the gifts that keep on giving, but only if they get to the right place at the right time to drive the right critical decision. The first critical decision, or moment of truth, is whether to buy a vendor’s product. The subsequent moments of truth will all be encountered throughout the useful lifespan of critical software. Those decisions are unlikely to be made by the same teams within an organisation, particularly over the long lifetime of critical systems.
SBOMs must be decoupled and distributable separately from software itself.
Speed, Scale, and Interoperability
SBOMs are snapshots-in-time of software builds. But software continuously changes for many reasons – performance improvement, feature release, bug fixes, and most importantly patching vulnerabilities. Software is only secure until someone discovers it isn’t. A collection of snapshots constructs an auditable history of past events and could be a reliable indication of future performance when buying software. But what’s really needed in the moment of critical operational decisions is a live contextual feed of what’s happening right now. The SBOM must be synchronised with the software in operation. Prevention is better than post-mortem. Speed is your friend.
SBOMs must be delivered at pace to authorized recipients.
Software users will have thousands of software packages from hundreds of suppliers. If each has its own method of discovery and distribution, involving any human interaction, the flow of SBOMs will be constrained. Any human in the loop using spreadsheets, emails, video conferencing, file-sharing, messaging, or any other unstructured data exchange will restrict the ability to scale SBOM data flows. Nobody can afford nor wants to hire an SBOM department.
SBOM discovery and distribution must be automated to achieve scale.
SBOM standard data formats (CycloneDX, SPDX, SWID) offer interoperability at the data layer for both publishers and subscribers. The development toolchains and asset management systems used to create and consume SBOMs will need to integrate connections to SBOM sources. Today’s de-facto method to achieve interoperability of connections is through APIs. Cloud-native identity and access management technology standards protect APIs from unauthorized access.
SBOM distribution must be built on secured Open APIs.
Five dimensions of Trustworthiness
The more trustworthy an SBOM is, the more important and risky jobs we can entrust to it, knowing it won’t let us down.
SBOMs will be a pillar of Zero-Trust architectures – a tool to verify then trust – and inform critical data-driven business decisions that affect operations, productivity, safety, security, and risk.
The corollary to this is that an untrustworthy SBOMs is worse than no SBOM.
SBOM distribution must be trustworthy.
The Industrial Internet Consortium and Digital Twin Consortium model of Trustworthiness take five dimensions: Security, Privacy, Safety, Reliability, and Resilience. SBOMs are in effect, digital twins of software so this model holds true and should be followed.
- Security. The system being protected from unintended or unauthorized access, change, or destruction.
- Privacy. The right of an individual or group to control or influence what information related to them may be collected, processed, and stored and by whom, and to whom that information may be disclosed.
- Safety. The system operating without causing unacceptable risk of physical injury or damage to the health of people, either directly or indirectly, as a result of damage to property or the environment.
- Reliability. The ability of a system or component to perform its required functions under stated conditions for a specified period of time.
- Resilience. The emergent property of a system that behaves in a manner to avoid, absorb, and manage dynamic adversarial conditions while completing the assigned missions, as well as reconstitute the operational capabilities after causalities.
1. Security
The well-known model for information security rests on Confidentiality, Integrity, Availability. Secure SBOM distribution is no different.
Confidentiality – Some software producers will not want to publish their SBOMs freely, and some consumers will not want SBOMs of the software they use to be widely known. For example, an integration team may need to run rigorous checks for breaking changes on inbound software updates. That process may take several months in regulated industries. Therefore, SBOMs should be distributed privately until it is safe to reveal publicly.
SBOM distribution must accommodate the need for private disclosures.
Integrity – A falsified SBOM sent through an encrypted channel is not secure, an SBOM generated by an unauthorized actor should not be trusted.
SBOM distribution must preserve the authenticity of and prevent tampering with evidence.
Availability – When SBOMs inform Zero-trust decisions, the lack of availability could lead to enterprise risk blind spots.
SBOM distribution must have cloud-native levels of availability.
2. Privacy
Creators of SBOMs and consumers of SBOMs have a right to protect their personal identities and that of their organizations. For example, a developer that makes an honest mistake should not be exposed to doxing by an outraged consumer or spear-phishing from motivated attackers. A software supplier should not have to expose its customer list to competitors. A user of software should not have to give away a competitive advantage by revealing its enterprise software stack.
SBOM distribution must protect user and organisation privacy.
3. Safety
Any system that is relied upon for critical decisions must indicate when it is deactivated, inhibited, or requires attention. Car dashboards alert drivers to faulty brakes or intentionally deactivated stability controls. Critical shared data must flow, and it should be obvious if sharing has been switched off.
SBOM distribution must alert users to changes in established sharing policy configuration.
With increasing connectivity of the physical and virtual worlds, critical software is found in operating industrial machinery and civil infrastructure. With public services at stake and moving parts involved, simply stopping or switching off a machine when a software problem is encountered could be catastrophic: more nuanced risk-based decisions must be made based on full context.
SBOMs must contain the right information to make the right decision for every individual place that software is used.
4. Reliability
Assured operation and reliance on SBOMs needs more than security. SBOMs need to get to the right places, users need to identify their sources, and ultimately rely on the data. Three vital attributes are needed: Provenance, Governance, and Immutability.
Provenance – the origin of SBOMs must be identifiable – from the organisation that produced them to the toolchains that automatically built them. Transparency of origin is vital to identify sources of supply chain compromise.
SBOM distribution must use human and machine identity technologies to establish provenance.
Governance – Developers who build software and create SBOMs may have to work with separate compliance teams who decide on distribution rights. It should be easy for developers to put an SBOM in a safe place, then for Governance teams to establish external sharing policies based on contractual arrangements. Some may choose to publish globally, others set fine-grained permissions on specific data.
SBOM distribution must enable collaborative teams to enact Governance-as-Code.
Immutability – A vital reliability and trust-building element is the ability to see a full shared history of events that cannot be tampered with, re-ordered, access withdrawn, or destroyed. It should allow for mistakes to be acknowledged and rectified since that ultimately builds trust and proves reliability. It should make deniability implausible, with historical records for publishers and subscribers. A continuous unbroken fully traceable record can deliver instant audit-less proof of compliance.
SBOM distribution must prove who did what when, and who knew what when.
5. Resilience
A bicycle will not balance upright on its own – a moving bicycle with a rider is a resilient system that can balance indefinitely, avoid hazards, and go places.
Static assurance is no longer fit for purpose in the digital world – dynamic assurance of software with transparency of known vulnerabilities, assured evidence of software status, mitigations, and contextual awareness of threats makes a resilient system that adapts to its environment and is fit for an enterprise journey of digital transformation.
SBOM distribution must be a foundational component of multi-party data exchange with continuous assurance that reduces business risk and boosts trust.
Why RKVST SBOM Hub and RKVST is the right distribution solution.
RKVST SBOM Hub is the first place to find and fetch SBOMs. Extended with RKVST, it meets all requirements of the SBOM distribution manifesto.
- Users can search for publicly discoverable SBOMs and find privately shared SBOMs.
- A private repository enables SBOM producers to easily control distribution.
- Open APIs and SDKs allow easy integration with any tools in less than one day.
- A SaaS platform built on cloud native secure technologies provides high availability
- OpenID connect standards work with your enterprise identity stack.
RKVST extends basic capabilities:
- Governance-as-Code enables highly granular data sharing policy enforcement with permissioned distribution
- Compliance-as-Code enables proactive responses and alerts for continuous assurance
Unlike trying to manually exchange SBOMs, RKVST works with the tools you use today and gets the right data to the right place to drive the right outcomes.
It’s free to access here.
