SBOM Security: Top 5 Reasons to Build SBOMs Into Your Pipeline
Read Now >Share: 
In preparation for the June 11th deadline of President Biden’s Executive Order (EO) on Improving the Nation’s Cybersecurity, Deepfactor has focused on educating customers about the importance of accurately and systematically documenting software production, consumption, and operation using Software Bill of Materials (SBOMs). They represent a critical first step in discovering vulnerabilities and weaknesses within your products and the devices you procure from your software supply chain.
Though your software may not be “in-scope” for the rapidly-approaching deadline, organizations merely at or below current regulatory requirements are at a competitive disadvantage, particularly as companies plan for the strategic use of SBOMs, leveraging them for readiness and as a value-added benefit in the software procurement process. Regardless, for many, the race against time has begun to adhere to these mandates.
For those interested in learning more—or just looking for a good recap—continue reading to better understand these requirements, and to learn what Deepfactor has done to help customers prepare!
What SBOM Executive Order mandate?
In 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.” In other words, if your software is sold to, or used by, the US Federal government then you will be expected, for each major version of each software product you supply, to provide the following:
- A self-attestation that the product was built in conformance with NIST’s Secure Software Development Framework (SSDF).
- On request, a Software Bill of Materials (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.
Why SBOMs?
By improving the visibility, transparency, security, and integrity of proprietary and open-source code in software supply chains, this mandate is part of a broader initiative to bolster cybersecurity practices nationwide, emphasizing the importance of understanding and managing software components, recognizing the potential for code compromise, and proactively mitigating risks. For anyone not living inside a log(4j), these requirements shouldn’t be a surprise—they are a direct response to an escalating number of attacks on the software ecosystem.
Example supply chain attacks:
| SolarWinds | Due to a breach in December 2020, roughly 18,000 customers of SolarWinds downloaded trojanized versions of its Orion IT monitoring and management software. The supply chain attack led to the breach of government and high-profile companies after attackers deployed a backdoor dubbed SUNBURST or Solorigate. |
| Octopus Scanner Malware | Octopus Scanner is a type of malware that finds and backdoors open-source NetBeans projects hosted on the GitHub web-based code hosting platform to spread to Windows, Linux, and macOS systems and deploy a Remote Administration Tool (RAT). The malware compromises developers’ computers by infecting NetBeans repositories with malicious payloads within various dependencies, later spreading to downstream development systems. |
| Codecov | Codecov provides tools that help developers measure how much of the source code executes during testing, which can help identify undetected bugs. In April 2021, a threat actor had modified the Codecov Bash Uploader script, exposing sensitive information in customers’ continuous integration (CI) environments. This includes Rapid7, who revealed that some of their source code repositories and credentials were accessed by Codecov attackers. |
By having a comprehensive understanding of the software components that make up an application, organizations can identify, address and/or mitigate potential security 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.
In other words, if you don’t know what software was used to build your software, can you really hope to address critical software vulnerabilities that are finding their way into major projects?
What are SBOMs?
Included in this initiative, the Commerce Department and NTIA were directed to publish the minimum elements necessary to prevent, detect, assess, and remediate cyber incidents with SBOMs. They published a report to identify and define “the essential pieces that support basic SBOM functionality and will serve as the foundation for an evolving approach to software transparency.”
Though the report highlighted (3) minimum elements, automation support remains a leading consideration for organizations evaluating SBOMs products. As we covered in a previous webinar, integrating SBOMs into your SDLC can be challenging, particularly because pipelines require predictable machine and human-readable data formats. Thankfully, multiple interoperable data formats exist in the ecosystem and are being used to generate and consume SBOMs—each one offers a unique set of strengths, weaknesses and target use cases:
| CycloneDX | CycloneDX is a lightweight SBOM standard designed for use in application security contexts and supply chain component analysis. CycloneDX started in the Open Web Application Security Project (OWASP) community, which manages the strategic direction and maintenance of the specification. The CycloneDX GitHub repository includes tools to create and consume SBOMs in various programming languages. |
| Software Package Data Exchange (SPDX) | The SPDX specification was developed by the open source software development community and is supported by a rich ecosystem of open-source tools and commercial providers. SPDX became the internationally recognized standard (ISO/IEC 5962:2021) for SBOMs in September 2021. |
| Software Identification (SWID) | SWID tags were designed to provide a transparent way for organizations to track their software inventory on managed devices. SWID tags contain descriptive information about a specific software release such as the product and version. NIST recommends adoption of the SWID Tag standard by software producers, and multiple standards bodies (e.g. IETF), and is working to incorporate SWID tag data into the National Vulnerability Database (NVD). |
Why does Deepfactor care?
Regardless of the aforementioned standards and guidelines—implementing an organization-wide program to generate, review, and operationalize SBOMs remains challenging. This is particularly true when you consider “7 in 10 DevOps teams (70%) release code continuously” (defined as once a day, or every few days) and, on average, 57% of enterprises are using 11 or more containers per application. Given this pace of releases, SBOMs can have several shortcomings which may limit usefulness for an organization:
| Limited Visibility | SBOMs do not provide a comprehensive view of every component in a software system—such as open ports, running processes, network connections, and privilege escalations. |
| Inaccurate | SBOMs are highly-dependent on the source and the process (i.e. when, where, and how) by which the report is generated. This can lead to missing data and quality issues. |
| Noisy | SBOMs (and SCAs) generate large amounts of data—including a number of false positives—which can overwhelm the developers and security teams responsible for triaging. |
| Inconsistent and Incompatible | SBOMs can produce inconsistent and incompatible reports, particularly when the previously mentioned standards and data formats aren’t strictly observed. |
| Difficult to Integrate | SBOMs are challenging to integrate, particularly in modern pipelines where development and operations are completely automated and happening at-scale. |
What’s next?
To manage these challenges, Deepfactor wants leaders across engineering, security, and operations to have the information necessary to evaluate SBOM platforms for the right combination of features, code coverage, and even instrumentation to ensure developers have the contextual security information necessary to prioritize the resolution of critical security risks. In order to learn more about SBOMs, consider reviewing some the valuable content we’ve authored on the subject, including in-depth conversations with customers and industry-leaders tackling the same problem:
- Download our whitepaper, SBOM Security: Top 5 Reasons to Build SBOMs Into Your Pipeline.
- 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.
Frequently Asked Questions
1. What is the SBOM Executive Order mandate?
Answer: The SBOM Executive Order mandate, issued by the White House Office of Management and Budget (OMB) in September 2022, requires every Federal agency to comply with NIST Guidance when using third-party software. This includes providing a self-attestation of conformance to NIST’s Secure Software Development Framework (SSDF), along with providing a Software Bill of Materials (SBOM) and other artifacts on request.
2. Why are SBOMs important?
Answer: SBOMs improve the visibility, transparency, security, and integrity of software supply chains. By understanding and managing software components, organizations can identify and mitigate potential security risks more effectively, including vulnerabilities, insecure components, and unnecessary dependencies.
3. What are some examples of supply chain attacks that SBOMs aim to prevent?
Answer: Examples include the SolarWinds supply chain attack, Octopus Scanner malware targeting NetBeans projects on GitHub, and the Codecov Bash Uploader script compromise. These attacks highlight the importance of understanding software components to prevent and mitigate security risks.
4. What are the minimum elements necessary for SBOM functionality?
Answer: The Commerce Department and NTIA published a report outlining the minimum elements necessary for SBOM functionality. These include identifying and defining essential pieces to support basic SBOM functionality, serving as the foundation for an evolving approach to software transparency.
On-Demand Webinar
Integrating SBOMs Into Your SDLC By June Executive Order Deadline
Including panelists from Cisco and VMware.
Watch Now >