When a supply chain attack occurs, companies have to weed through their software to find the bug before bad actors do. But a movement in the security space is trying to make that search easier.
President Biden's May cybersecurity executive order established improvements to software supply chain — it's the government's way of leading by example. Among its recommended enhancements was a requirement for a software bill of materials (SBOMs) for software vendors contracting with the federal government. SBOMs are a written record of the "ingredients" comprising a software product — open source and proprietary code — provided to anyone building software, buying software, and operating software.
SBOMs are theoretically a reasonable security measure, allowing everyone in the supply chain to refer to their ingredients if a vulnerability or update emerges. Yet, like any cybersecurity tool, it's never as easy as one solution.
Keeping track of what software is made of is "really not that difficult," but the issue SBOMs don't and can't address is software development within legacy systems, said Johannes Ullrich, dean of research at the SANS Institute. "It'll never happen for that code … I don't think it's realistic to expect that a 10- to 20-year-old code will ever have a reasonable SBOM."
But the future is more promising for SBOMs, with tools to automate the software audit and standards promoted by the National Institute of Standards and Technology (NIST) through Software Identification (SWID) Tagging, The Linux Foundation's Software Package Data Exchange, and an industry-championed effort through CycloneDX, according to Matt Howard, EVP and CMO at Sonatype.
The National Telecommunications and Information Administration (NTIA) has published standards, or "minimum elements," required within 60 days of the executive order. But Ullrich anticipates more concrete standards from NIST or the Cybersecurity and Infrastructure Security Agency (CISA) eventually as the executive order gave NIST 45 days to define "critical software."
"That definition shall reflect the level of privilege or access required to function, integration and dependencies with other software, direct access to networking and computing resources, performance of a function critical to trust, and potential for harm if compromised," the executive order said.
If SBOM principles extend to all software, beyond what NIST says is critical, companies could be better equipped to spot bugs that impact a supply chain. SBOMs should give security executives some peace of mind by answering these questions in light of a new vulnerability, whether it's in software they built in-house or purchased:
- Do we know whether our production software applications are using a particular version of code that is now vulnerable?
- Where is it?
- How quickly can we patch it?
"Without an SBOM, the timeline for fixing those vulnerabilities can stretch into months or years because security teams have to wait for notification from each supplier," said Sounil Yu, CISO of JupiterOne. But "legacy software without an SBOM is like a can of food from the 1920s without an ingredient label. Consume at your own risk."
Nothing new
While there is a lot of promise in the ability of SBOMs to formalize the artifacts within software builds and launching applications into production, it does not make SBOMs a silver bullet.
That "doesn't mean it's not a good idea," said Howard. "When there's transparency in any situation, I think there's just generally speaking goodness."
Sometimes developers can go rogue, and skirt approved dependencies. Developers can copy and paste code, effectively bypassing source code management. These are both examples of what SBOMs are meant to prevent from happening.
SBOMs create ownership and accountability for software makers because they force suppliers "to be honest with themselves," Ullrich said. Software makers might want to protect the components they use, though disclosing detailed proprietary code is not required in SBOMs.
According to the NTIA, SBOMs typically include:
- Author
- Supplier
- Component name
- Version string
- Component hash
- Unique identifier
- Licensing
Keeping an ingredients list of software is something companies have done internally for years. It's just now that the term "SBOM" has received some recent attention. In the open source community, users are expected to declare certain script dependencies to build software, the difference now is that SBOMs expect more rigor or the security implications it has, according to Ullrich.
SBOMs are the cybersecurity and software space reaching accountability levels other industries hit decades ago. Historically, "there's no such thing as software liability in the industry," said Howard. There are already third-party vendors and engineering teams that practice SBOM principles, but the executive order will not make the entire industry shift to SBOMs.
If a major software vendor has been successful at selling its product, its intellectual property without liability attached, "it's not a bad place to be," Howard said. "Before there was a concept of product liability for the automobile manufacturers, there was no concept of product liability."
Consider the Apache Struts bug that led to the Equifax breach, Howard said. "Instead of a bad airbag, it's an Apache Struts defect, right?"
Challenges to expect
SBOMs will be costly and they will take resources to scale. Software makers know that regularly numerating their dependencies increases maintenance costs, adds more responsibility to "shifting left," and integrates SBOM standards into the development pipeline. If customers are not demanding SBOMs in their contracts, companies may not voluntarily change their transparency efforts, and maintain SBOMs internally.
Even if a software vendor does not share an SBOM with a CISO, its ability to easily produce one "gives me a higher level of confidence that their software development practices are modern or mature enough" to offset vulnerabilities in poorly maintained software, Yu said.
Software vendors can expect to see customers demanding SBOMs in their contracts. It will likely start with large contracts until it becomes a norm across all customers. However, even if every software maker provided SBOMs to every customer, there is still a large portion of the economy "that simply wouldn’t know how to use this information," said John Bambenek, principal threat hunter at Netenrich.
"Many companies struggle to implement best practices we already have. It’s naïve that a new best practice will be implemented universally," he said.
But the SBOM inclusion in the executive order was intentionally meant for government and private industry, though the two sectors see SBOMs in different ways. Government wants SBOMs because they might reduce risk to national security, whereas private industry might see SBOMs as a cost issue.
"If you want to get malicious software into a government agency for use in espionage, a supply chain attack is your best way," Bambenek said.
SBOMs are only one piece of good cyber hygiene — it's another step toward improved security posture across industries, and the public and private sectors. But with code, there is so much of it constantly in production and shared in codebases, keeping track of every piece will be challenging.
"Knowing what software components lie within an application via SBOM is helpful, but this is an extremely low leverage tool," said Mohit Tiwari, co-founder and CEO of Symmetry Systems and associate professor at the University of Texas at Austin.
Legacy code will always be an issue, even if modern software all comes with SBOMs. "Consider that the most high assurance software in the world costs about $10,000 per line of code and software like the SeL4 operating system is only 10,000 lines of code and needs over 200,000 lines of verification code," he said.
