The U.S. government today published the long awaited National Cybersecurity Strategy, which highlights the importance of Software Bill of Materials (SBOM) for identifying and mitigating the risk presented by unsupported software.
In February 2022, the Linux Foundation released a report titled “The State of Software Bill of Materials and Cybersecurity Readiness,” in which the Linux Foundation revealed that 78% of the 412 global organizations that were surveyed intend to adopt SBOMs by 2022.
SBOMs will see increased adoption throughout critical infrastructure and human life, such as energy, utilities, healthcare, manufacturing, telecommunications, and government. The most immediate impact will be in the public sector. This is especially true in U.S. federal departments and agencies, where NIST guidelines require suppliers of software products and services to support SBOMs using standard data formats. Software engineering leaders who adopt and integrate SBOMs throughout the SDLC will reap the benefits of increased visibility, transparency, and security, especially as open-source code use continues to increase.
What is SBOM?
A software bill of materials (SBOM) is an inventory of all components and software dependencies involved in the development and delivery of an application. It has become an increasingly common and critical component of the software development lifecycle (SDLC) and DevSecOps processes.
Modern software applications and services are commonly built with multiple components and dependencies that come from different sources. Those components and dependencies can include open-source software projects, proprietary code, APIs, programming language frameworks, and software libraries. The various sources that help create modern software are part of the software supply chain, serving as the supply sources for enabling applications and services.
An SBOM is the same as the bill of materials (BOM) used in supply chains and the manufacturing industry. However, it has not been common practice In the IT industry. It’s difficult for many of the vendors to accurately detail the constituent code components on which an application is built.
What are the contents of SBOM?
SBOM is an inventory of the source components and dependencies in a specific application or online service. The source components include a listing of the shared dynamic link libraries (DLLs) that an application accesses to operate. SBOM also includes software libraries for different functions. It also includes application-dependent open-source code. Any usage or reliance on software components and programming frameworks on which an application operates. It includes the software components’ names along with the names of suppliers, authors, and version and license details.
An SBOM differs from a list of ingredients or inventory because it should also provide information about where components come from. Modern software development follows that one piece of application code is dependent on another. So, a dependency tree is needed to help provide visibility into the core components of an application.
Why do organizations need SBOM?
- As organizations rely on software to run business operations, it’s essentially important to have an SBOM.
- When software vulnerabilities are discovered, they are often found in components that are dependencies for other software applications. Knowing whether an organization is at risk from a third-party component is a challenge that is commonly referred to as supply chain risk.
- Many organizations face the challenge of understanding whether they are at risk from a specific software vulnerability. For example, The risk in the Log4J open source software vulnerability that was disclosed in December 2021. Even after a source component or library is patched by the original project, it is mandatory for every downstream vendor that relies on the component and every end user to also patch.
What are the benefits of SBOM?
- An SBOM provides visibility into the internal foundations of software to help organizations and users better understand what is being used and where there could be a potential risk.
- In addition to helping with supply chain risk, an SBOM can assist organizations with open-source software license compliance issues. A well-constructed SBOM will not only reveal the underlying open-source software dependencies but also what license restrictions are in place.
- SBOM helps organizations determine if they are susceptible to security vulnerabilities previously identified in internally developed, commercially procured, or open-source software components.
- SBOMs generate and verify information about the origins of code and relationships between components, which helps software engineering teams detect malicious attacks during development and deployment.
For example, a zero-day vulnerability in Apache Log4j was identified in the widely used open-source Java logging library in December 2021. Once the vulnerability was uncovered, security leaders had to quickly work to identify applications using the infected library. Organizations with SBOMs had reduced response times due to their ability to map applications to vulnerable dependencies.
- SBOM also increases efficiency by connecting open-source and third-party software.
What are the challenges of adopting SBOMs?
- Data sharing and data exchange standardization have influenced the success of SBOMs, as they deliver the greatest value when everyone in the supply chain adopts to the same standards. Achieving this may take time due to the volume of software and tools that are already in use.
- Another challenge to consider is the role of adaptability. SBOMs are not static documents. Every new release of a component must include a new SBOM. There is a huge risk in releasing and consuming new components without corresponding SBOM changes. SBOM generation and management tools are critical for adoption, as they help organizations integrate SBOM functionality into software development, packaging, and release activities.
SBOMs: The New Gate to the DevSecOps Pipeline
Requiring an SBOM for all software entering your pipeline has become the best practice these days. You have three options for obtaining SBOMs:
- Gain full cooperation from the software vendor, with the SBOM as part of their delivery.
- Implement software composition analysis tools that require particular expertise.
- Implement a container vulnerability scanning tool that enables you to generate SBOMs for the containers entering your pipeline.
Avoiding software bill of materials generation means moving security left. Depending on your particular business processes, compliance requirements, and pipeline gateway requirements, it’s essential to add a documented or automated process (or a combination of both) that ensures that each software component has an accompanying SBOM before it enters your development environment.
Your development, security, and operations teams have probably put a lot of effort into creating the processes and frameworks to enable your organization to gain the maximum advantage of DevSecOps. Implementing the role of the SBOM into your DevSecOps processes is yet another iteration of your DevSecOps processes.
Kaiburr helps organizations with accelerated maturity and single pane for DevSecOps. You can guarantee close to 100% coverage on application security testing using Kaiburr on SAST, DAST, SCA, Dependency Check, Image Scan, Secrets Scan and SBOM.
You can ensure 100% coverage on SBOM and timely validation and reporting on SBOM per release using Kaiburr. Here is a sample SBOM report from Kaiburr –
Kaiburr also helps organizations to be compliant to various regulations like SOC2, ISO 27k, HIPAA, HITRUST, PCI, FedRAMP, GLBA, GDPR. You can also automate internal controls mapped to standards like NIST 800-53. Here is a sample mapping of SBOM controls to SCF, NIST 800-218 and PCI DSS –
Reach us at contact@kaiburr.com to get started with accelerating DevSecOps maturity and achieving 100% coverage on DevSecOps controls using Kaiburr.