Your next security bug won’t even be in the software that you wrote
Your in-house developers spend time and effort checking their software for security flaws, but the next shop-stopping bug might not come from them at all. Instead, it might come from your digital supply chain. What is the tech industry doing to help?
Today’s software products and services comprise multiple components from different third parties. The growing popularity of open-source libraries has exacerbated the problem. It lightens the workload for developers who can quickly assemble components sourced from elsewhere, but also creates more risk. This composable software trend means that few organizations fully understand the provenance of all their software’s components.
In May, the White House move to address this issue by publishing Executive Order 14028, Improving the Nation’s Cybersecurity. This called for federal agencies to provide guidance on better cybersecurity practices for their vendors.
This requested guidance includes the provision of a software bill of materials (SBOM) that would help federal buyers understand what was in their software and where it came from. This helps to identify potential software vulnerabilities. The Executive Order likened it to an ingredients list on food packaging.
“A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration,” the document added. “The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems.”
The Executive Order tasked the National Telecommunications and Information Administration (NTIA) to come up with the minimum elements of an SBOM format. The organization was ahead of the game; its Software Component Transparency Framing Working Group started work on a standard for digitally stored SBOM data in 2018.
Three main SBOM formats
This year, the NTIA published guidelines detailing minimum requirements for an SBOM format while leaving the exact choice of protocol open for adopters. It has published mappings between three well-used formats: Software Package Data Exchange (SPDX), CycloneDX and Software Identification (SWID) tags.
Software Package Data Exchange (SPDX)
SPDX is a Linux Foundation project that lets organizations communicate information on the open-source software components they’re using, along with any known security vulnerabilities.
CycloneDX is an XML-based format designed for extensibility, which also supports SPDX data elements. It comes from the Open Web Application Security Project (OWASP), and its supporters include Lockheed Martin.
Software Identification (SWID) tags
SWID is an ISO standard that uses XML tags to define software components upon installation. There is also a draft IETF standard called Concise SWID (CoSWID), which is a smaller representation of SWID tags substituting hexadecimal code for human-readable XML. Its designers created it for small-footprint environments including IoT equipment.
The NTIA has identified several tools that can help companies to translate between SBOM formats. These include SwiftBOM, DecoderRing and an SPDX tool for uploading and converting SPDX files. The Linux Foundation has also created a free online training course for SPDX adopters.
Other SBOM-related projects
In addition to these suggested protocols, there are also other projects that might be useful as part of the SBOM ecosystem. Some of them focus on provenance and security. In-toto is a widely used framework to cryptographically secure SBOM information to ensure that no one tampers with it, ensuring that the right person performed specific steps.
Other projects include Package-URL (PURL), which is a protocol for listing software component data in URL form. SWID supports this. Grafeas is an API format that allows people to query metadata on software components. It stores the metadata in notes that link to occurrences, which represent affected software components.
Tackling third-party bugs
We’ll need more than just file formats to solve the cyber supply chain security problem, which has surfaced some egregious breaches, including last year’s SolarWinds software hack. Best practices will also play a major part, and these should also be enforceable in software.
In June this year, Google has also announced its Supply chain Levels for Software Artifacts (SLSA). This work stems from Binary Authorization for Borg, its internal system of controls for governing software integrity. Rather than an SBOM, this is a set of security guidelines that implements four levels of security checks. The company is working on turning this into an enforceable system that automatically creates metadata for auditors to use when enforcing software development best practices across multiple parties.
Our software development culture not only relies on reusing others’ libraries; it actively promotes it. While that brings huge benefits and avoids developers reinventing the wheel, it’s time to codify our response to this emerging problem. Thanks to efforts by technology groups across the industry, we’re getting more tools and techniques to address the issue, but for many organizations, the work is just beginning.
- Executive Order 14028
- NTIA Presentation on SBOM formats and tooling
- NTIA: Framing Software Component Transparency
- NTIA: Survey of Existing SBOM Formats and Standards
- SPDX upload and conversion portal
- SLSA announcement
- SWID (ISO/IEC 19770-2:2015)
- SwiftBOM SBOM generator tool