Skip to main content
SBOM Audit Trail for Hardening Cybersecurity

SBOM Audit Trail for Hardening Cybersecurity

By 07/15/2022August 23rd, 2023Supply Chain and Cybersecurity

An SBOM Audit Trail with Ortelius and the XRP Ledger

Imagine a centralized open-source software SBOM audit trail of immutable Software Bill of Material data (SBOM), Common Vulnerabilities and Exposures (CVE), and other critical usage information. Now go one step further and add this information to a private data store that combines the open-source data with all of your internal package information in one place.

For each change registered to the open-source data, your internal applications are given new ‘versions’ with newly generated SBOM and CVE information. The mission of the Ortelius open source project is to make this a reality, creating a central SBOM audit trail of shared data using the XRP Ledger(XRPL) with sidechains.

Ortelius is an open-source project incubating at the Continuous Delivery Foundation under the umbrella of the Linux Foundation. For more information on Ortelius, visit Ortelius.io. 

  

Why SBOMs are Critical

Software Bill of Materials (SBOMs) are the answer to hardening cybersecurity. SBOM insights can facilitate ‘zero trust’ policies and expose vulnerabilities. SBOMs also track the licensing and provenance of software raw materials related to a specific software solution or application release.

“…with ripples felt by the global technology sector at large, was the Biden Administration’s Executive Order on improving the Nation’s Cybersecurity. This bellwether indicator put Software Bill of Material at the forefront of software procurement practices.

…SBOMs will play an essential role in building more trust and transparency in how all software is created, distributed, and consumed throughout the supply chains.” Jim Zemlin, Executive Director Linux Foundation, Software Bill of Materials and Cybersecurity Readiness

The Contents of an SBOM

SBOMs contain key provenance information which exposes your software’s composition, including:

  • Supplier  – who created the component.
  • Version – Identifier for the change in the component
  • License – What license the component uses
  • Dependencies (packages) – the relationship that the upstream component X is included in software Y. 

The most critical data in the SBOM is the dependency information. Your software dependencies produce the Common Vulnerabilities and Exposures (CVEs). It is this information that allows you to address security concerns proactively. 

SBOMs Themselves Have Issues

SBOM gaps make SBOMs an imperfect solution.  First, they are not immutable, and no SBOM audit trail exists. SBOMs are text files generated as part of the components build process. SBOMs can be edited to remove packages with known vulnerabilities. In addition, each component update creates a new version of the SBOM. The result is many SBOMs with no audit trail. If SBOMs are the first line of defense in supply chain management, we need a method of centralizing the SBOM data with an audit trail. We also need to make SBOMs more accessible so they are used, not just generated. 

Ortelius Snapshot and SBOM Audits

Ortelius is a governance catalog that tracks changes in components over time. The Ortelius ‘snapshot’ produces an audit trail that shows what changed. The ‘snapshot’ captures key attributes, including: 

  • key-value pairs
  • inventory across clusters
  • Swagger Input
  • Container registry
  • Git Commit
  • Git SHA
  • Git User
  • Blast Radius (consuming applications)
  • The number of lines changed
  • SBOM and CVEs
  • Component package dependencies
  • License consumption across all transitive dependencies

In addition, Ortelius tracks the users of components. Users can quickly see how they are impacted when a component is updated at the application level. The component-to-user relationship allows Ortelius to easily track application-level SBOMs in complex microservice architectures. Aggregating lower-level dependency SBOMs to the higher application level is essential in producing the data needed by development teams to determine if their software is safe for consumption.  

Ortelius and the XRP Ledger as an SBOM Audit

To create both an immutable and sustainable SBOM audit trail, the Ortelius snapshot versioning process will be enhanced using the XRP Ledger. 

There are four main uses cases for this Blockchain SBOM Ledger:

  1. Enforce ‘zero-trust’ by interrogating the signed provenance of microservices.
  2. Auditing of microservice ‘drift’ between clusters can be reported and automatically used to correct the drift. The desired state exists in the blockchain and can be used to correct a ‘threat’ when an incorrect ‘version’ is detected across clusters. 
  3. Provide a notification model with immediate feedback to all consumers impacted by a threat. For example, a single location to track all users of Log4J, and notify them immediately of the required actions.
  4. Use events to build policies for required changes. For example, a fix to a CVE can trigger events across the DevOps pipeline to automatically address the vulnerability.
  5. The blockchain data can be used with OPA to determine the DevOps pipeline path for microservices based on a ‘risk factor’ defined by OPA.

As we move into more complex cloud-native systems, a level of microservice governance is required to manage the ‘consuming’ application-level data. The Ortelius SBOM Ledger approach is the beginning of a new disruptive approach to tracking all changes for SBOM reporting, with the ability for application teams to know and act on threats immediately.

The Collection of SBOM Data

In complex cloud-native systems, a new version of a microservice creates a new version of every ‘logical’ application that consumes that service. A ‘logical’ application is an immutable representation of the digital service delivered to the end-user. Each time a microservice is updated, the end-user is accessing a new version of that ‘logical’ application.

Similarly, each time an open-source package is updated, a new version of that same logical application becomes available. The problem is knowing when the underlying dependencies have changed and when a new ‘release candidate’ at the application level has been created.

Applications are a collection of Components. Components are comprised of the following relationships:

A) The logical application depends upon 1 > n Component Versions.

B) Component Version depends upon 0 > n Component Versions.

C) Component Version depends upon 1 > n Component Packages.

D) Component Package depends upon 0 > n Component Packages.

E) Component Package depends upon 0 > n Software Licenses. 

F) Component Package depends upon 0 > n CVEs (Common Vulnerabilities and Exposures).

G) Component Package depends upon a Creator Signatures.

Software Bill of Material (SBOM) consists of data from D, E, F, and G. These SBOMs are generated from the Component Software Build Lifecycle.

Items A, B, and C are generated by Ortelius. 

SBOM Audit

Relationship Complexity in Shared Components

 

Ortelius Blockchain SBOM Audit

The transactions captured by the blockchain ledger include the creation of the component version NFT, the creation of the application-level SBOM version, and the consumption of a logical application SBOM version when it is deployed into a runtime environment such as a Kubernetes cluster.

XRP Ledger sidechains reference transactions on blockchains maintained outside the public XRPL network. This scenario occurs when a company’s logical application-level SBOM includes private microservice versions, private package signatures, and public open-source package signatures.

Conclusion: SBOM Audit Trail 

SBOMs are a critical tool in hardening cybersecurity. Even so, SBOM data is not centralized, accessible, or immutable. In addition, in a cloud-native microservices architecture, SBOMs need to be aggregated to the ‘logical’ application level for every release candidate.

The Ortelius SBOM Blockchain will provide a centralized location for accessing SBOM data across open-source packages, their versions, and the applications that consume them, creating an audit trail of SBOM data that can be used publicly and privately.  

The Ortelius open-source project will leverage the XRP ledger to create the audit trail, providing a centralized location to explore SBOMs everywhere. 

Further Reading on Supply Chain Security:

Get Started – Give DeployHub a Try: 

Close Menu