Industry insights

Your next security bug won’t even be in the software that you wrote

January 17, 2022 by Danny Bradbury

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

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. 

Sources 

Posted: January 17, 2022
Author
Danny Bradbury
View Profile

Danny Bradbury is a print journalist, editor, documentary filmmaker and podcast presenter. He has edited several magazines on a freelance basis covering software development and IT security. His freelance clients include the National Post (Canada), TechRepublic, the Australian Fairfax media syndicate (including the Sydney Morning Herald), The Independent Newspaper, The Guardian (London), SC Magazine, Computer Weekly, Investment Executive, the Financial Times, specialist cryptocurrency web site Coindesk.com, IT Pro, The Economist Intelligence Unit and Microscope. For the past few years, he has been a winner at BT's Infosecurity Journalism awards. His documentary film Epicentre, about the cultural history of the nuclear arms race, was entirely self-funded, researched, filmed and produced. It has been successful on the festival circuit.

Leave a Reply

Your email address will not be published.