On-Demand Webinar: Integrating SBOMs Into Your SDLC By June Executive Order Deadline
Including panelists from Cisco and VMware.
Watch Now >Share:
Modern applications rely on open source and third-party software for a majority of their code base. Many of those software building blocks come with vulnerabilities and license risks that organizations must manage to avoid supply chain security incidents that can result in data breaches. Software Bill of Materials (SBOMs) improve supply chain security by maintaining inventories of software components and dependencies used to build and deliver applications.
1) What is an SBOM?
According to the U.S. National Institute of Standards and Technology (NIST), an SBOM is “a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product.”
2) Primary driver for SBOMs: White House Executive Order
This is the primary driver behind President Biden’s Executive Order (EO) on Improving the Nation’s Cybersecurity, which mandates accurate and in-depth reporting of software supply chains. By June 11th, 2023, all organizations that sell software to the U.S. federal government are required to provide a Software Bill of Materials (SBOM) as part of enhancing supply chain security.
Keep on reading to better understand these requirements, and to learn what Deepfactor is doing to help customers address them!
3) Timeline leading to June 2023 deadline
| May 2021 | President Biden’s White House published Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity, recognizing “persistent and increasingly sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people’s security and privacy”.
The Executive Order directed the US Secretary of Commerce, acting through the Director of NIST, to “issue guidance identifying practices that enhance the security of the software supply chain”. |
| July 2021 | The Department of Commerce and NTIA (National Telecommunications and Information Administration) published a report, Minimum Elements for an SBOM, to help identify and define “the essential pieces that support basic SBOM functionality” that “will serve as the foundation for an evolving approach to software transparency.” |
| February 2022 | In accordance with with EO, NIST issued two documents with further standards, now collectively known as the “NIST Guidance”: |
| September 2022 | The White House Office of Management and Budget (OMB) issued a memorandum requiring every Federal agency to comply with NIST Guidance, “when using third-party software on the agency’s information systems or otherwise affecting the agency’s information.” |
4) What does this mean for my business?
If your software is sold to, or used by, the U.S. Federal government, starting next year you will be expected to provide the following for each major version of each software product you supply:
- A self-attestation that the product was built in conformance with NIST’s Secure Software Development Framework (SSDF).
- On request, a SBOM for the product. The NTIA report Minimum Elements of an SBOM is a useful starting point for understanding what’s required.
- On request, other artifacts substantiating SSDF conformance, e.g., output of vulnerability scanners, software provenance metadata, etc.
- On request, evidence of participation in a Vulnerability Disclosure Program.
Though your software may not be in scope today, you might nonetheless find your customers asking for the same things before long, as the new U.S. Federal Government standards raise the bar across the industry. The European Union and many private companies are following suit, requiring SBOMs as part of their software procurement process.
5) Steps you can take now to build SBOMs into your pipeline
Given these requirements, organizations are increasingly responsible for verifying and securing software supply chains. However, engineering leaders across development, security, and compliance need help managing the balance between mitigating product security and supply chain risk as directed by Biden’s EO, while shortening time-to-market, automating incident and remediation response, and assisting with compliance requirements.
SBOMs represent a critical first step in discovering vulnerabilities and weaknesses within your products and the devices you procure from your software supply chain. SBOMs improve the visibility, transparency, security, and integrity of proprietary and open-source code in software supply chains. In other words, SBOMs enable organizations to expose and manage the risk inherent in the vast amounts of code they create, consume, and operate.
In order to learn more about SBOMs, consider downloading SBOM Security: Top 5 Reasons to Build SBOMs Into Your Pipeline. The objective of this whitepaper is to help engineering teams understand and identify the core components and capabilities of SBOMs responsible for addressing the many challenges introduced by the increased adoption of OSS across digital transformation and application modernization initiatives. In doing so, enterprises should be prepared to meet regulatory demands for in-depth reporting and analysis of their software supply chain.
SBOMs represent a critical first step in discovering vulnerabilities and weaknesses within your products and the devices you procure from your software supply chain. SBOMs improve the visibility, transparency, security, and integrity of proprietary and open-source code in software supply chains. In other words, SBOMs enable organizations to expose and manage the risk inherent in the vast amounts of code they create, consume and operate.
The following items are the top reasons organizations should consider implementing a SBOM:
| 1 | Maintain Compliance | Many industries and government agencies have regulations (e.g. President Biden’s Executive Order) in place requiring organizations to maintain a certain level of transparency and security in software supply chains. SBOMs can help developers meet compliance requirements by providing a clear and accurate record of the software components and dependencies used within an application. This can include information on the origins and versions of those components, as well as licensing and end-of-life information. |
| 2 | Improve Security | By having a comprehensive understanding of the software components that make up an application, organizations can identify, address and/or mitigate potential security vulnerabilities and risks more effectively. This can include identifying and patching vulnerabilities, replacing insecure components with more secure alternatives, or removing unnecessary components that increase the attack surface of an application unnecessarily. |
| 3 | Address Customer Requirements | Driven in part by a legislation to help secure open-source software, there’s a growing demand for increased supply chain transparency and disclosure by customers. By addressing these requirements, organizations can ensure competitiveness with other software vendors offering SBOMs. Gartner reports in Innovation Insights for SBOMs by analysts Manjunath Bhat, Dale Gardner, Mark Horvath, ”By 2025, 60% of organizations procuring mission-critical software solutions will mandate SBOM disclosures in their license and support agreements, up from less than 5% in 2022.” |
| 4 | Minimize Financial Consequences | Insecure software supply chains greatly increase the chance and/or impact of security incidents such as data breaches, zero-day vulnerabilities, and privacy violations. With the average data breach costing businesses in the United States $9.05 Million, SBOMs ensure organizations can identify and eliminate unnecessary “risks” in the software supply chain, helping to avoid expensive consequences in the future. |
| 5 | Enhance Communication & Collaboration | SBOMs can be shared amongst various personas (e.g. AppSec, Developers, Compliance Officers, etc.) providing a common understanding of the software components and dependencies being used across the engineering organization. SBOMs are a key component of the vulnerability scanning process, providing the information necessary to quickly remediate and/or mitigate application security risks, improving the ROI and time-savings promised through DevSecOps. |
Additional resources to help you
Watch the on-demand webinar Integrating SBOMs Into Your SDLC by the Biden Executive Order June Deadline, with Rose Judge, Sr. Open Source Engineer, VMware; Chocks Ramiah, Principal Architect, Cisco; and Kiran Kamity, Founder & CEO of Deepfactor. This webinar panel focuses on steps you can take now to integrate the production of SBOMs into the software development life cycle (SDLC) to both meet the requirements of the Executive Order and better manage the risks of the software supply chain and vulnerabilities in both open-source and third-party software components. The panel also discusses the practical and operational aspects of gathering, using, and handling SBOMs. Panelists include experts and practitioners with deep expertise in implementing SBOMs and supply chain security best practices at their organizations. Watch it here.
Frequently Asked Questions
1. What is a Software Bill of Materials (SBOM)?
Answer: An SBOM is a formal record that details the components and supply chain relationships of various elements used in building software. It enumerates the open source and commercial software components in a product, helping developers and vendors maintain an inventory of these elements.
2. Why are SBOMs important for supply chain security?
Answer: SBOMs improve supply chain security by providing transparency and visibility into the software components used in applications. This enables organizations to discover vulnerabilities and weaknesses, manage risks, and ensure the security and integrity of both proprietary and open-source code in their software supply chains.
3. What are the top reasons for implementing a SBOM in an organization?
Answer: The top reasons include maintaining compliance with regulations (e.g., President Biden’s Executive Order), improving security by identifying and mitigating potential vulnerabilities, addressing customer requirements for supply chain transparency, minimizing financial consequences of insecure software supply chains, and enhancing communication and collaboration among different stakeholders in the engineering organization.