A new Presidential Executive Order was just signed highlighting the need to enhance the software supply chain as one of the measures for improving the nation’s cybersecurity. With too many critical vulnerabilities being found in software packages, it is now essential to know the components (i.e. third-party binary and open source code) and vulnerabilities in the entire software supply chain.
This Executive Order solidifies a previous announcement about what companies must disclose to the government when a data breach occurs. Like the rules already in place in the state of California, these new rules will shield software developers from legal liabilities associated with a breach disclosure. However, due diligence is required on behalf of software companies, which includes evidence collected and shared with federal law enforcement. A significant part of the disclosure is a software bill of materials – a comprehensive inventory of all included software components, both internally developed, third-party and open source.
What is a SBOM?
A software bill of materials (SBOM) is a list of all software components used in a software product. The increasing use of third-party and open-source code means that most software released today is comprised of software developed internally and externally from the company releasing it. Any quality and security issues in these reused components live on in the new product and as such pose a risk that remains hidden to the end customer. In fact, software developers may themselves be unaware of the vulnerabilities in dependencies buried in the code they reuse.
The SBOM is more than just list of software components, it’s a continuously updated catalog of software, versions and known vulnerabilities in the detected components including any dependencies. Software Composition Analysis (SCA) tools like GrammaTech CodeSentry continuously identify these components in binary code and track known 0-day and N-day vulnerabilities throughout the software lifecycle. The SBOM can be embedded along with each application making audit requests more reliable.
Supply Chain Attacks
A software supply chain is like any other supply chain – the entirety of the components needed to build your product. In the case of software, it’s all of the components (could be source or binary) that are bought, copied or reused in your software, including open-source, commercial and any other third-party product. The software supply chain isn’t a new topic but has become top-of-mind due to increasing reliance on third-party and open-source software, and related, high profile data breaches and attacks.
So, why all these concerns about SBOMs, disclosure and the software supply chain? Vulnerabilities in reused software (i.e. SolarWinds) is a high risk and easily exploitable attack surface for software products. Vulnerabilities, often in older versions, are public knowledge as are the exploits. Software developers often have these vulnerable components in existing (and new) products some of which may have been in the marketplace for years. As new vulnerabilities emerge, the associated risk is present in all the places the software is used.
A recent example of this is the URGENT 11 and Amnesia 33 collection of vulnerabilities in embedded network stacks. For example, URGENT 11 vulnerabilities are linked to embedded RTOSes like Wind River VxWorks and GreenHills Integrity, but the vulnerabilities lie within a third-party TCP/IP network stack from InterPeak commonly used by embedded OS vendors. End users of products using Integrity or VxWorks are at risk of attack if using older versions of the OS due to a dependency in the RTOS itself (i.e., the risk is transferred from InterPeak -> Wind River -> manufacturer.) The supply chain attack is widespread and critical in this case because of the number of products using these well-known commercial operating systems.
Creating a SBOM from binary code using CodeSentry
CodeSentry uses deep, scalable binary analysis to create a detailed SBOM and lists known vulnerabilities (cross referenced with the National Vulnerabilities Database – NVD) in the detected components, including any dependencies. This type of analysis yields high precision and recall meaning less missed vulnerabilities and less false positives. CodeSentry continuously tracks these vulnerabilities during development and is designed to be integrated into a continuous integration/continuous delivery (CI/CD) pipeline to keep the SBOM updated. The following is a sample Software Bill of Materials:
Integrating SCA and SBOM in a DevSecOps Pipeline
SCA tools are usually introduced during the build phase of a typical CI/CD pipeline, although scans are recommended to set baselines for existing software products. Despite the relatively static nature of third-party dependencies, the potential for new vulnerabilities remains.
CodeSentry is ideal for keeping on top of this by maintaining an up-to-date SBOM and monitoring for changes in vulnerability exposure in software dependencies.
The release phase consists of packaging verified and digitally-signed binaries to be deployed for operation. Presumably, part of this packaging includes a SBOM which is generated as part of the release process. It’s critical that deployed packages include not only a SBOM of included components in the release but also a complete list of dependencies on open-source and other third-party libraries. The following diagram illustrates the integration points of SCA in a CI/CD and DevSecOps pipeline:
Summary
It’s clear that new Executive Order and government regulations at the state and federal level are moving towards more due diligence in the software supply chain. Privacy breach disclosures requirements are just one part of the push for improved privacy and security in software. A critical part of this due diligence is a software bill of materials (SBOM) which catalogs all of the software components and their dependencies included in a shipping software product.
Creating and maintaining a SBOM via automation and integrating the process into a DevSecOps pipeline is the best approach. The nature of third-party and open-source dependencies are changing constantly as is the vulnerability landscape. It is critical software development organizations maintain visibility into and the manage the risk of their software supply chain.
Want to know the SBOM and what is vulnerable in your software or applications that you are evaluating? GrammaTech can run a complimentary binary analysis for you today.
{{cta(‘45359179-2455-4cbc-b268-8569a739a752’)}}
