As a result, the White House Executive Order from May 2021 tasked the National Institute of Standards and Technology (NIST) to come up with a set of best practices to improve software security. Those practices have now been codified in two extensive documents (SSDF and SSCSG), but the TLDR for Independent Software Vendors (ISVs) is:
- U.S. agencies are required to obtain a self-attestation from the software producer.
- U.S. agencies will be required to obtain from their software producers SBOMs and documented processes to validate code integrity.
Recall that an SBOM:
- Lists all the software components that comprise an application, service, API, or runtime environment.
- Contains detailed information about each software component.
- Is a machine-readable official record of all proprietary and third-party integrations within the software.
All of which enables better software composition tracking since ISVs (and their customers) can monitor the security of their application post-deployment, and identify the potential impact of any new vulnerabilities.
While the directive is squarely aimed at ISVs that sell into the US Government, standards that begin in the public sector tend to be quickly adopted by the commercial sector, as well. In fact, according to Gartner, more than 60% of organizations will have adopted SBOMs by 2025, representing a 20% increase from 2022.
The Open Source Supply Chain is Under Attack
Open source software is the foundation of the digital world. According to the 2022 Open Source Security and Risk Analysis Report, open source software accounts for 75% of codebases, on average. While open source libraries are essential to software development, particularly in terms of fostering innovation and reusability, they pose a threat to software security. Hackers can insert malware directly into open source dependencies, thereby infiltrating the entire software supply chain.
The increased frequency of software supply chain attacks like those against SolarWinds in 2020 and Kaseya in 2021 have confirmed the fact that:
- ISVs are now the front line of defense for their customers.
- Bad actors have discovered economies of scale: infecting a single ISV can potentially compromise thousands or even tens of thousands of their customers who unsuspectingly install software upgrades and patches from their trusted vendor.
SBOMs, a formal record for maintaining visibility into the software supply chain, represent one of the key regulatory mechanisms for ISVs looking to secure their software supply chain. In this post, we will examine the role of SBOMs in reducing software security risks.
Benefits of SBOMs in Managing Software Supply Risks
While SBOMs cannot be used to directly solve software attacks, the information they provide is extremely useful for identifying and mitigating potential vectors of attack, such as vulnerabilities. Additionally, SBOMs can help with:
- Achieving regulatory compliance:
- Identify components that are disallowed within a compliance framework like PCI-DSS, SOX, HIPAA, etc.
- Providing compatibility between old software packages and OSS updates:
- Compare and contrast SBOMs before and after a package update to identify transient dependencies that may have shifted.
- Protecting customers in the event of a software supply chain attack:
- Readily identify whether a compromised component/version of the component targeted by a supply chain attack is also present in your software application.
- Ensuring that security protections are in place throughout the software:
- Check the components/versions of components against vulnerability databases (such as the NVD) to ensure no impactful vulnerabilities exist.
- Licensing management/compliance:
- Check the open source software licenses listed in the SBOM to ensure that none are prohibited by your corporate guidelines.
While manual verification is possible, SBOMs are intended to be machine readable and should be presented in a programmatically consumable way, typically as JSON, CSV, SPDX or other standard format.
Types of SBOM Standards
To provide a common format and structure for describing software composition, SBOM standards act as schema designs. With an SBOM standard, the schema design is inherited and used to provide for integration with other tools, such as vulnerability scanners.
The US Government (based on NIST recommendations) currently accepts only the three most popular SBOM standards as valid, namely:
- CycloneDX – a lightweight SBOM standard from OWASP that’s useful in application security contexts and supply chain component analysis. It aims to provide guiding principles on how to reinforce a risk-based approach to standard development. The CycloneDX SBOM specification provides:
- Support for XML, JSON, and Protocol Buffers.
- A large collection of official and community-supported tools that create or interoperate with the standard.
- Software Identification (SWID) tag – contains information about a particular software product version. SWID tags are supported by both the Trusted Computing Group (TCG) and the Internet Engineering Task Force (IETF). The SWID tag is an established standard for maintaining the security posture of software composition through:
- Information management
- Identification of vulnerabilities
- Compliance support
- Ensuring secure configurations for computing services
- Software Package Data Exchange® (SPDX) – provides a format for communicating the components, licenses, and copyrights of software packages. Originally a grassroots open source project hosted by the Linux Foundation, it is now driven by a consortium of vendors, system integrators, and other foundations. The SPDX SBOM is available in a variety of formats, including RDF, XLS, SPDX, YAML, and JSON.
How to Generate an SBOM
The ActiveState Platform’s SBOM provides a comprehensive view into the runtime environment that software applications are built with, specifically the open source components provided by Python, Ruby, and Perl. It can identify components at multiple levels, including the packages themselves, transitive dependencies, and OS-level (Windows, Linux, and macOS) dependencies, as well.
Separately, the ActiveState Platform can be used to track Common Vulnerabilities and Exposures (CVEs) for each open source component in your software project. It also keeps an audit trail of all vulnerability remediations, and highlights possible ramifications and potential cascading effects on other components before you commit changes.
In the images below, you can see a sample SBOM generated by the ActiveState Platform in SPDX format, starting with the configuration of a runtime environment:
- You can configure a Python, Perl or (in this case) Ruby runtime environment by clicking on the New Project button on the dashboard of your ActiveState Platform account. Just follow the wizard to create a runtime for your OS, and then add the gems required for your project either one at a time, or else altogether by importing a gemfile. The ActiveState Platform will determine all the dependencies for you:
Figure 1 – Configure the Runtime
- The ActiveState Platform will save a version of your runtime under the History tab, and then automatically build the entire runtime in a few minutes. Clicking on the History tab will display the UUID associated with the saved configuration, which you will need to copy:
Figure 2 – Obtain the Commit ID
- You can now go to the ActiveState Platform’s Build Graph and plug in:
- Your org name (in my case, danac)
- The name of your project (in this case, Ruby-3)
- The Commit UUID from step 2
- Clicking on the arrow button will immediately create a complete SBOM for your runtime environment:
Figure 3 – Sample SBOM in SPDX Format
The ActiveState Platform generates a comprehensive SBOM that includes:
- Supplier: the name of the software vendor/author
- Version: the published version of the component
- Name: the name of the component
- Relationship: which component is dependent upon other component(s)
- License: the high-level license of the component
Unlike alternative SBOM solutions, the ActiveState Platform streamlines the risk mitigation procedure, saving developers time that would otherwise be spent dealing with packages, dependencies, and vulnerabilities related to open source language packages. It achieves this by:
- Keeping track of transitory dependencies and related libraries.
- Identifying and examining the relationships between the dependencies.
- Calculating changes to the dependency tree before committing to any update.
Conclusions – Automate SBOM Generation
The increasing frequency of software supply chain attacks has brought SBOMs to the attention of the US Government. SBOMs have an important role to play in securing software supply chains by providing end-to-end visibility into open source software components, which are at once the most likely point of compromise in any application and the majority of the code in modern software.
The unique strengths of open source software have resulted in ISVs over-investing in its use and under-investing in supply chain security. To solve the resulting unique challenge will require a robust set of tools and practices to be implemented as standards across all major ISVs. It’s only through standardization that these challenges can be solved.
A good first step toward enhancing open source supply chain security is to obtain automated SBOM-generating technology. Using the ActiveState Platform, you can integrate your current development workflow and set up dependency monitoring for Perl, Python, and Ruby environments. ActiveState’s automatically-generated SBOM will then enable you to quickly identify any security and compliance issues within your tech stack, as well as providing you with improved vulnerability tracking for your open source libraries.
Read similar stories
