A Presidential Executive Order was signed on 12th May 2021, mandating improvements to US Govt. Cybersecurity. Much of the Order focuses on risks arising from the increasingly digital supply chain, and a key provision of the Executive Order is the introduction of a mandatory and standardised Software Bill of Materials (SBOM) to be provided by Federal Software Vendors to attribute and record what components they include in their software.
While this momentum and focus is new, the concept of an SBOM has been discussed for some time in industry and there are already several different standards available to describe a piece of Software, its components and its authors.
Whichever standard(s) for SBOMs ultimately win market acceptance, they all need a trusted sharing mechanism which protects the interests of all parties: vendors retain control of their proprietary information and release processes while customers have assured and reliable visibility into their digital supply chain risks.
RKVST Data Assurance Hub offers a solution to this sharing and distribution problem. Built for robust data assurance and exchange mechanism with granular attribute sharing allowing for comprehensive and well-governed supply chains; built to address both Public and Private SBOM sharing. Backed by a robust tamper-proof blockchain platform the provenance Suppliers and Consumers can demonstrate with their Software will stand up to any audit when tracing the constituent Software Components and Authors throughout their lifecycle.
When combined with initiatives such as Vex Vulnerability Disclosure, software supply chain management with RKVST becomes richer and answers many significant concerns about software estates, IT practices and more, ensuring that data produced by known vulnerable systems can be quarantined long before making compromised operational decisions.
Assuring SBOM traceability with RKVST
The Executive Order states that a recommendation for a single standard is to be decided by the National Telecommunications and Information Administration (NTIA) within 60 Days of signing. The NTIA has extensive history dealing with SBOMs, investigating standards and consulting on potential solutions for specific Industries that need to meet these new requirements.
These base attributes support most use cases. RKVST’s flexible custom attributes handling means that it can also support more advanced use cases as they arise.
Data Friendly Implementations
The core information above describes necessary information in an SBOM but not how an SBOM may be automated or shared in a data-friendly way. The NTIA’s SBOM Proof of Concept identifies the need for strong community management and data sharing mechanisms but does not describe how to achieve them.
Individual standards and their merits will not be discussed in detail here, though there are useful concepts and definitions that can be used interchangeably which will help to flesh out a fully realised RKVST Solution.
The NTIA mentions three machine-readable standards which can be used for describing an SBOM:
CycloneDX - A commercially designed standard for OWASP Dependency Track with extensive tooling built around it
SPDX - The Linux Foundation Defined SBOM standard (now an ISO itself)
SWID - Described by NIST IR 8060 and standard ISO/IEC 19770
While not described by the NTIA, Google’s SLSA Standard is also an emerging contender for SBOM that is worth considering.
Whichever of these is chosen (or indeed a mix, in the case of a software suite), RKVST can facilitate the distribution and coordination of SBOM updates.
These different data-friendly standards are primarily concerned with describing the SBOM of a particular piece of Software at any given time. They are not, however, concerned with providing details about the Provenance, Governance and Immutability of a given software, identifying the lifecycle of a specific deployment or an easy way to share known and pertinent vulnerabilities.
The executive order in this case makes it clear that not only is the need for an SBOM important but consideration should be shown for the management and deployment of an SBOM during the Software Lifecycle.
RKVST’s value lies in its ability to build a history of provenance, integrity and transparency into the distribution and governance of an SBOM for a specific piece of Software. As an SBOM gets updated RKVST could be used to trace the decisions a consumer acted upon with a new release, a vulnerability disclosure or even if they chose to rollback a specific version to account for a regression, with justifications assigned for each.
As noted by the NTIA:
Sharing SBOM data across the supply chain will involve a combination of technical platforms, predictable data formats, and operational processes. Due to the diverse needs of the software ecosystem, there is no one-size-fits-all solution; however, modeling SBOM processes on existing approaches and methods will enable interoperability between vendors, dampen variance, minimize the need for new tools, and thereby simplify processes required for better supply chain management.
The RKVST solution focuses on the lifecycle of an SBOM as a description of a piece of Software; the rich lifecycle events, provenance, integrity, transparency and governance. This means simultaneously meeting the needs of each standard while also not providing an obstacle to the adoption of SBOMs.
To address the concerns of the NTIA, the core baseline attributes should be recorded and maintained as attributes of the Software Package, then further details should be kept to the format by which the Producer wishes to provide to its consumers and the standard in which they provides it to them.
RKVST should also provide a basic template that can be adapted by Producers to describe the lifecycle of their product for easy adoption by their consumers and any end customers in the supply chain from there.
When considering the relationship between Suppliers, Consumers and a specific Software Package in a Supply Chain there is a need to consider the different roles and types of Software in place.
In almost all cases, Suppliers provide a Software Package which is then either repackaged as a component of another Software Package to be subsequently supplied, or is deployed directly to be consumed by end customers across different environments, such as a customer facing Production environment or perhaps a high-level testing environment like UAT (User Acceptance Testing).
Supplied Software Packages may be maintained at various versions across multiple customers and deployments, which means consumer software lifecycle management is not typically under the control of a Supplier except in the case of a SaaS or Platform solution provided by a Supplier.
However, using this broad abstraction we can identify two main types of Assets that can encapsulate a full Software Package Supply Chain:
Software Package - Captures the supply of a Software Package to consumers, can be both an internal baseline/architecture or an external supply of software, maintained by Suppliers
Software Deployment - Captures a live deployment of a Software Package and Product in Production, PreProd or UAT (preferably per device/fleet/cluster where appropriate), usually maintained by a Consumer but can be maintained by a Supplier in the case of a platform
These two types of Asset have different needs and special interactions that may help with planning a comprehensive Software Supply Chain Lifecycle.
To find out more about the Software Package and it's lifecycle, please refer to the Reference SBOM Implementation for Software Packages.
To find out more about the Software Deployment and its' lifecycle, please refer to the Reference SBOM Implementation for Software Deployments.