Software Bill Of Materials (SBOMs) have become extremely popular of late, mainly due to two factors:

• It’s a key requirement for US government software vendors.
• Many SCA vendors (and there are a lot of them) have recently introduced SBOM functionality.

To anyone paying attention, it seems like there’s an SBOM full court press underway, which lines up favorably with the US government’s upcoming June 11 deadline for key software vendors to get onboard with securing their software supply chain.

The problem is Software Bill Of Materials won’t secure your software supply chain.

Recall that SBOMs:

• List all the software components that comprise an application, service, API, and/or runtime environment. 
• Contain detailed information about each software component.
• Are machine-readable official records of all proprietary and third-party integrations within the software.

In other words, SBOMs can tell us what’s in the box, but they provide little information to judge the risk of those contents. While the inclusion of hashes and external links to known vulnerability information are a step in the right direction, none of the current SBOM standard formats provide information about how a component is sourced or built. An SBOM is simply a snapshot in time of a moving target given how often vulnerabilities are discovered in open source libraries, which comprise up to 80% of any modern application. 

Currently, the primary use case for SBOMs involves enabling the ability to quickly identify the impact of a new open source package vulnerability across all the applications deployed by an organization. Having worked at an organization that forced each division to manually enter all the components in their applications into a central database on a per release basis, SBOMs represent a far better solution to the problem. But securing the software supply chain requires more than just tracking vulnerabilities.  

The Importance of Software Attestations

A software attestation is a trust mechanism that allows a verifier (i.e., a customer) to independently validate the integrity of something asserted by the provider (i.e., the software vendor). For example, an attestation can verify that an application is not compromised by malicious code. In other words, attestations make it easier for users of third party code to trust that code.

But attestations come in many different flavors. Two of the principal ones that can genuinely help organizations assess the security risk of the applications that want to run include:

• Software Attestation – this is the most common version of an attestation that is used to specify how an application was created. For example, the software was indeed built by the vendor who used GitHub Actions to build the components of a linked repository branch.
  • This kind of information is key to understanding whether the software was built on a developer’s desktop, or whether it was built using a secure build service. 
• Provenance Attestations – these are used to identify the origin of the proprietary source code, but more importantly, the origin of all open source dependencies/ transitive dependencies.
  • This kind of information is key to understanding (for example) whether open source dependencies included in the software were built securely from source code, or whether they were imported as prebuilt binaries. 

Obviously, software built on a desktop should be assessed as higher risk, but hot fixes and patches may use this method for expediency’s sake. Unfortunately, developer desktops are rarely locked down and secured with the result that it’s not unusual for builds to differ from one day to the next. These kinds of non-reproducible builds make it difficult to verify the security and integrity of the software produced. 

Similarly, open source dependencies that are imported as prebuilt binaries, rather than built securely from source code, should also be treated as suspect since public repositories offer no guarantees as to the security and integrity of the packages they offer. The risk becomes exponentially higher when importing prebuilt binary packages (i.e., packages that include C code/ native libraries) since they can more easily disguise a malware payload. 

Fortunately, the latest version (v2.3) of the SPDX SBOM specification adds new reference categories to support linking to security documents, such as attestations. It’s these kinds of improvements that are needed if SBOMs are to become key in helping organizations secure their software supply chain.

Conclusions: Software Bill Of Materials + Attestations = Security

I’ve discussed previously in my “How Software Bill Of Materials (SBOMs) Support Secure Development” blog post how software vendors can potentially incorporate SBOMs into their software development process in order to enhance supply chain security. 

Incorporating attestations within an SBOM will provide even greater reason for making SBOMs the centerpiece of an organization’s security by providing information to allow organizations to make an accurate risk assessment of the software they intend to work with. 

While the ActiveState Platform programmatically generates an SPDX SBOM on demand for your runtime environment, the SBOM is created based on the SPDX 2.1 specification, and therefore does not currently incorporate attestations. 

Instead, attestations are generated separately in order to verify:

• The software (in this case, a Python, Perl or Ruby runtime environment) was created securely using the ActiveState Platform’s secure build service. 
• Each component within the runtime environment was not only sourced securely, but also built securely from source code, including packages that incorporate C libraries. 

The key here is that not only do the attestations attest to the fact that your software was created securely from source code, but also that each component – including binary components – were also generated securely from vetted source code. This can provide software vendors with a competitive edge when selling to security-conscious organizations.

Read Similar Stories