Most organizations that make software — from small startups to multi-billion-dollar behemoths — use third-party libraries and tools to develop their applications. Modern apps depend on many external components to build and deliver software to customers. These libraries and tools are collectively called the software supply chain.
A software supply chain for a typical web app may include components like these:
- A running Linux instance
- System-wide shared libraries like libcrypt and glibc
- Open source frameworks and libraries installed via package repositories like npm, NuGet, and Maven
- Chunks of source code copied from other applications (or Stack Overflow)
- Supporting applications like databases and in-memory caches
- Underlying supporting services such as Apache, IIS, and nginx
When any of these components presents a security flaw, the impact extends to all applications using the compromised component. That exposes any accessed or processed data to risk. Threat actors exploit these supply chain vulnerabilities to infiltrate target networks. Two well-known examples of supply chain exploits are the 2020 SolarWinds hack and the 2021 Log4j vulnerability.
One way to reduce software supply chain vulnerabilities is to maintain a software bill of materials.
What is a software bill of materials?
Using a software bill of materials (SBOM) is a highly effective strategy for reducing software supply chain cyberattacks. Just as a recipe lists the ingredients necessary to make a favorite meal, the SBOM lists all components of a software application.
An SBOM includes all libraries, code packages, and other third-party components used to create a particular software application. The SBOM list also contains:
- Each component’s license type (shared, open source, or commercial)
- Component version
- Patch status
- The dependencies between these components in the software supply chain
The importance of the SBOM extends well beyond security. It also demonstrates compliance with major data privacy regulations, ensuring all components involved in a software app are transparent and trackable.
The information contained within the SBOM is so vital in preventing software supply chain cyberattacks that the United States Department of Commerce has issued various documents on the topic.
The National Telecommunications and Information Administration (NTIA) suggests three formats for generating the SBOM inventory list that identifies software entities and their associated metadata:
- The Software Package Data Exchange (SPDX) is an open standard for creating an SBOM inventory list containing all software components, component licenses, copyrights, and security references.
- The OWASP CycloneDX is a lightweight SBOM standard for creating a complete inventory of first- and third-party software components for risk analysis. CycloneDX can document component types including applications, containers, libraries, files, firmware, frameworks, and operating systems.
- The Standard for software identification (SWID) was developed by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). SWID is an XML file containing a list of software components and their licenses, patch statuses, and installation bundles.
Why the SBOM is important
The software supply chain — every tool, framework, or library used to write, build, or run applications — has become a leading source of software vulnerabilities and breaches. Software developers and organizations are increasingly reusing code, software packages, and libraries between many applications. Many third-party vendors also sell commercial code packages ready to be incorporated with widely-used productivity applications like Office 365.
The complexity of building software apps makes it vital to take inventory of all components used to create each application. Cataloging enables organizations to detect and resolve security vulnerabilities before malicious actors can gain unauthorized access to sensitive resources.
The use of SBOMs is also beneficial because it:
- Avoids reusing vulnerable components in software projects
- Helps discover vulnerable parts in current applications
- Better manages the software supply chain risk through knowledge of all components (and their dependencies) being used in software applications
- Helps organizations better comply with various data protection regulations by providing a list of all application components and their relevant characteristics
- Helps organizations select preferred software vendors who provide their applications’ SBOMs
- Helps organizations maintain an inventory of all software apps in their IT environment
- Conserves organizations’ time and resources by detecting vulnerable parts in the early design phases of the software development life cycle (SDLC)
- Calls necessary attention to the security risks associated with the software supply chain
The U.S. government issued an executive order directing federal agencies to generate plans that will improve software supply chain security. As a result, many commercial enterprises are following suit.
How to generate an SBOM
An organization or individual can generate an SBOM manually or with automated technology. The manual approach may be right for smaller projects, but it can be less desirable for others.
The manual method
Developers can manually list all software components in a spreadsheet or similar file, with each component’s version, license, dependencies, and any additional relevant information.
This method is suitable for small projects with few components. It is far from ideal for larger projects, though. According to ZDNet, most GitHub projects have around 700 dependencies. Enterprise-level systems are sure to exceed this number. Attempting to manually generate an SBOM inventory for a project with thousands of direct and transitive dependencies is just not realistic.
The manual method is also prone to human error. It is all too easy to update a dependency and then forget to update the SBOM.
The automated method
For most projects, automating the SBOM is the best approach. Automation lets you maintain an updated list of all components, including languages, libraries, and Docker images.
You can incorporate automated tools into your continuous integration and continuous delivery (CI/CD) pipeline to scan all of your software projects and update their associated components as needed. Popular dependency scanners include Snyk and Anchore.
Most SBOM generation tools also integrate nicely with CI/CD tooling. These tools automatically scan your software projects, listing both proprietary and open-source software components and related attributes like licenses and dependencies on third-party libraries.
An SBOM offers many benefits for compliance, security, and managing the various components of each application’s license agreements. Automating this SBOM helps ensure complete coverage and current information for your organization.
Organizations that use SBOM and link their component inventory with cyber threat intelligence feeds can better track zero-day vulnerabilities in their applications. Then, they can fix them before incurring significant damage to their software integrity.
Learn more about how you can integrate dependency scans and SBOM generation tools in your CI/CD pipeline to strengthen your software security.