Yael Citro
2020 was the year that our lives were turned upside down, but it also hosted another memorable event: the SolarWinds software supply chain attack.
It was a cataclysmic event that affected over 18,000 customers, including nine federal agencies. Worst of all, it was not an isolated incident – the number of software supply chain attacks grew by more than 300% in 2021 compared to the previous year. If the world’s most recognizable software companies are vulnerable to cyber-attacks, what does this mean for SMEs and businesses that rely on tech giants as their third-party vendors?
Thankfully, one good thing came out of the chaos. This attack prompted the Biden administration to release Executive Order 14028 in May 2021 on Improving the Nation’s Cybersecurity.
The comprehensive EO 14028 is one of the first times that an official paper has recognized the importance of the software bill of materials (SBOM). While it seems like the SBOM Executive Order is relevant only to companies that do business with the US government, in reality, its reach is far greater.
Thankfully, we’re saving you the effort of reading all 8,000 words in the EO by focusing on Section 4: Enhancing Software Supply Chain Security. In this article, we’re breaking down the SBOM Executive Order and what it means for software companies.
What is a Software Bill of Materials, and What Does it Include?
A software bill of materials is a list of all the components comprising a software product. The more information an SBOM includes, the better it is as a tool for increasing transparency. The NTIA (the National Telecommunications and Information Administration) published a guide on the minimum requirements for an SBOM document in July 2021, which include:
- Supplier name – The name of an entity that creates, defines, and identifies components.
- Component name – The designation assigned to a unit of software, defined by the original supplier.
- The version of the component – An identifier used by the supplier to specify a change in software from a previously identified version.
- Other unique identifiers – These could serve as a look-up key for relevant databases.
- Dependency relationship – Characterizing the relationship that an upstream component X is included in software Y.
- Author of SBOM data – The name of the entity that creates the SBOM data for this component.
- Timestamp – A record of the date and time of the SBOM data assembly.
An SBOM may include hash values of files in addition to their name, version, and path as a way to uniquely identify those files. There are 3 major SBOM standards:
- CycloneDX (by OWASP)
- SPDX (by the Linux Foundation)
- SWID (by NIST along with ISO and IEC)
Of the three standards, CycloneDX and SPDX are the most common, with some applications even offering the option to choose the format of the SBOM. But a new standard has emerged that is providing dev stakeholders with a greater level of visibility over their software supply chain attack surface – the PBOM.
Whereas an SBOM comprises a static list of the stages that a piece of software goes through, a pipeline bill of materials (PBOM) provides a real-time list of software lineage. Essentially, everything that’s ever been done to the software. A PBOM is much more in-depth than an SBOM as it also includes CI/CD integrity, a development process review, static code analysis, and more. Crucially, it differs from an SBOM because it continuously monitors changes that impact security so you can keep an eye on your security drift.
What are the Benefits of a Software Bill of Materials?
Now that we know more about what an SBOM is, what can you actually do with one? Here’s a short list of some of the more common uses for SBOMs:
Gain Visibility into Transient Dependencies
An SBOM is one of the most efficient ways to see all the open source packages added to your software, whether or not you have added them directly.
Avoid License Poisoning
Open-source packages have a multitude of different license types. Even if you can scrutinize the license types of all packages you choose to include, the dependencies and their dependencies are often a black box. Avoiding the loss of IP is a critical use case in favor of an SBOM.
Exploit Remediation
Having an SBOM significantly shortens search and remediation time for active exploits.
CVE Mapping
Just like exploits, CVEs are constantly updated. Having a complete map of all the components in your software is very helpful when you need to figure out quickly which CVEs are affecting it.
What is the SBOM Executive Order (EO 14028)?
Executive Order 14028 on Improving the Nation’s Cybersecurity is a comprehensive document meant to overhaul the federal cybersecurity standards to try and, hopefully, avoid another incident like SolarWinds.
Section 4, Enhancing Software Supply Chain Security, outlines a clear timeline and concrete steps required to fortify the security of the software supply chain, including:
- Using administratively separate build environments
- Establishing multi-factor, risk-based authentication
- Documenting dependencies
- Employing encryption for data
- Generating and providing artifacts that demonstrate code integrity (including open-source), vulnerability scanning, and other tests
- Providing a software bill of materials (SBOM) for each product. Or ideally, you can identify best practices and ensure build integrity by creating a pipeline bill of materials (PBOM). This also means you can mark each artifact and verify that every version of your software is safe for customers, so you can guarantee the level of traceability that the US government expects
Any company that wants to do business with the US government must adhere to the EO requirements and the SSDF. As this impacts new and existing contracts, the EO has made compliance a business issue, not just a software one, meaning that software companies have a far greater chance of this regulation being adopted en masse.
But the regulations don’t stop with this new order. The EO also instructed other agencies to do follow-up work to further advance software supply chain security guidelines. This resulted in the NIST’s creation of the Secure Software Development Framework and the developer guide on securing the software supply chain, which was a collaboration between the NSA, CISA, and ODNI.
The Message is Clear
Whether or not your company has government contracts, the message is clear – with the EO, the US government is sending a clear message: increase visibility with evidence as quickly as you can. In a way, it’s reminiscent of an ISO accreditation process. Since the White House expects compliance to be fully established by 2024, you might fall behind if you do not yet have a tool to create, manage, and share an SBOM for each of your software products and pipelines.
Since mobilizing your organization and changing entrenched procedures is time-consuming, it’s highly advisable to get a leg up on the process and start implementing as soon as possible. Ox Security’s PBOM standard can help you build a more secure and transparent pipeline that includes a traditional SBOM but enables greater visibility. It also means you can get started immediately on market requirements that follow the SBOM Executive Order without committing extra manual labor and time.
Book a demo or start free today for the right tool to help secure your software supply chain.
