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 such as:
- A running Linux instance
- System-wide shared libraries like
libcryptandglibc - 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
- JavaScript libraries like jQuery, D3, and React
- Underlying supporting services such as Apache, IIS, and nginx
When any one of these components suffers from a security flaw, the impact extends to all applications using the insecure component, which exposes any accessed or processed data to risk. Threat actors exploit these supply chain vulnerabilities to infiltrate target networks. This is precisely what occurred during the SolarWinds cyberattack.
In December 2020, the American cybersecurity firm SolarWinds experienced a cyberattack that went undetected for months. The attackers planted malicious code in its network management system, Orion.
This software manages the IT resources of hundreds of high-profile organizations worldwide, including many US government agencies. When SolarWinds sent updates to its clients, the malware propagated with this update to infect all organizations running Orion. As a result, attackers and those associated were able to spy on hundreds of clients without detection.
Similarly, there was a vulnerability in Log4j. Commercial and open source software widely use this Java-based logging utility, including the popular Spring framework, so the trickle-down threat was widespread across Java projects of all sizes.
One way to reduce software supply chain vulnerabilities like those affecting SolarWinds and Log4j is to maintain a software bill of materials. To better understand its significance and the best approach toward generating one, it is first necessary to explore just what it is.
What is a Software Bill of Materials?
A Software Bill of Materials (SBOM) is a highly effective strategy for reducing software supply chain cyberattacks. The SBOM lists all components of a software application just as a recipe lists the ingredients necessary to make a favorite meal.
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 shows compliance with major data privacy regulations to ensure all components involved in a software app are transparent and trackable.
Furthermore, the information contained within the SBOM is vital in preventing software supply chain cyberattacks that the United States Department of Commerce has issued various documents about.
The National Telecommunications and Information Administration (NTIA) suggests three main formats for generating the SBOM inventory list that identifies software entities and their associated metadata:
- Software Package Data Exchange (SPDX) — An open standard for creating an SBOM inventory list containing all software components, component licenses, copyrights, and security references
- OWASP CycloneDX — A lightweight SBOM standard for creating a complete inventory of first- and third-party software components for risk analysis. CycloneDX can document different component types including applications, containers, libraries, files, firmware, frameworks, and operating systems.
- Standard for software identification (SWID) — 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. Today, 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, such as Office 365.
The complexity of building modern software apps makes it vital to take inventory of all components used to create each application. This 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) 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 enterprises are following suit.
Ways to Generate an SBOM
An organization or individual can generate an SBOM manually or with automated technology. The manual approach has its advantages for smaller projects, but it may often be the less desirable of the two methods.
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 but is far from ideal for larger projects. According to ZDNet, most GitHub projects have around 700 dependencies. Enterprise-level systems can assuredly exceed this number. Attempting to manually generate an SBOM inventory for a project with thousands of direct and transitive dependencies is hardly an option.
Furthermore, this method is quite prone to human error. It is all too easy to update a dependency and forget to update the SBOM accordingly.
The Automated Method
By and large, automating your SBOM is the best approach. In doing so, 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 accordingly.
Additionally, most SBOM generation tools integrate nicely with CI/CD tooling like CircleCI. These tools automatically scan your software projects, listing both proprietary and open-source software components and related attributes, such as licenses and any dependencies on third-party libraries.
Summary
An SBOM offers numerous benefits to organizations for compliance, security, and managing the various components of each application’s license agreements. Automating this SBOM helps ensure complete coverage and current information.
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 integrating your SBOM generation tools with CircleCI to boost your software security.
If you’re interested in developing expert technical content that performs, let’s have a conversation today.
