With a constant threat of dangerous cyberattacks looming, a software bill of materials (SBOM) is an effective and still emerging tool that enterprise IT leaders should add to their IT security arsenals to help protect their companies from disruptive and costly digital attacks by cybercriminals.
A detailed and comprehensive SBOM can help enterprises more closely monitor every business-critical application they are running every day to keep their business operations, revenue, and services operating smoothly.
Vincent Danen, the vice president of product security for open source software leader Red Hat, is on a constant mission to talk about the need for SBOMs and other security tools with customers and IT leaders as part of his job, where he regularly shares his knowledge and insights about application security and open source with business leaders and developers.
I caught up with Danen this spring at The Linux Foundation’s Open Source Summit North America in Vancouver, Canada, and SBOMs were weighing heavily on his mind for good reason.
What Is a Software Bill of Materials?
An SBOM is a detailed, nested inventory of the application code that is built into an important software application. The idea is that if enterprises use a mission-critical application, they should know what code components are built within it so they can quickly react and fix them if future security vulnerabilities are discovered within the software. This is hugely important because it is not always readily apparent if potentially bad code is contained somewhere within any application. Often code from an application that is found to have vulnerabilities is deeply buried inside other code snippets, hiding its origins and making it much harder to know if the vulnerability-affected code is present or not. These problems lurk across the software supply chain ecosystem and must continuously be addressed.
That is exactly the kind of conundrum faced by enterprise IT security leaders in December 2021, when a critical remote code execution (RCE) flaw was found in the popular open source Apache Log4J Java logging application. The security vulnerability in Log4J, which is widely used within enterprise applications and cloud services, allowed attackers to remotely execute arbitrary Java code to take control of a server that was being targeted, throwing chaos into the operations of many enterprises and other organizations.
Ironically, the need for SBOMs was mapped out just 7 months earlier in 2021 when the Biden administration issued its Executive Order on Improving the Nation’s Cybersecurity in May, which included recommendations for the federal government and private sector businesses to dramatically clamp down to improve their cybersecurity efforts.
One of those recommendations was to work to enhance the security of the software supply chain by carefully tracking, labeling, and listing what code – that bill of materials for the included code – goes into applications used by the federal government and its suppliers by providing a detailed SBOM to the purchaser of every software application to empower users in the event of cyberattacks. It is like having a list of the ingredients used in a favorite recipe. Tracking this information is so important and I think it is mindboggling that we are only attacking this problem more seriously today.
SBOMs have been around for more than a decade, said Danen, but their importance really took off after the destructive and debilitating Log4J attacks and following their mention in Biden’s Executive Order.
The huge SolarWinds cyberattack in 2020 also led to the issuance of the Biden Executive Order because that massive attack affected the US government, its suppliers and a broad range of businesses around the world. The attack took advantage of security vulnerabilities in SolarWinds’ Orion IT performance monitoring system. The attacks were successful because SolarWinds Orion had privileged access to IT systems for log and system performance data, making it a lucrative target for the attackers, according to a report by TechTarget. That attack was one of the largest cyberattacks in history after being inadvertently delivered as backdoor malware by SolarWinds to thousands of its customers when SolarWinds issued an Orion software update.
Had SBOMs been in use at the time, perhaps they could have helped find issues in the patch before it was issued. Perhaps an SBOM could have uncovered other concerns about other dependencies and code. I believe that SBOMs could have made a difference had they been used at the time.
How Can a Software Bill of Materials Help?
The biggest benefit of SBOMs is that they dissect critical applications to their core code and components and then keep a list of all those components, letting users see the integral dependencies and code snippets that are almost impossible to find upon a cursory glance in the event of a chaotic cyberattack.
When the Log4J attacks occurred, many IT security pros did not see Log4J among the names of the applications their operations were using, but it was the deep-down dependencies where Log4J was being used – but not clearly listed – that got them ensnarled in the mess.
To me, these are important lessons learned from the Log4J vulnerability and other cyberattacks. I believe that these attacks showed that enterprise users have the best chance of minimizing or avoiding or minimizing the damage if they have a clear, detailed, and concise inventory of what code and code snippets are inside the applications they are using.
Enterprise IT professionals must know what they have, what they are using, and which dependencies are likely buried below to have a better chance of protecting their operations.
Open source code can bring great value and flexibility to enterprises, but like proprietary code it also must be carefully monitored, patched, catalogued, and overseen to use it safely across an enterprise’s critical business operations.
Critics of open source in its long history have often pointed to what they say are security concerns about open source because the code is open. But as I look at open source and its robustness, creativity, quality, and capabilities, I say that is part of the same old FUD (Fear, Uncertainty, and Doubt) that naysayers have been using to throw a bad light on open source since the first day that proprietary software vendors started realizing that they might have some real competition in the marketplace.
Software Bill of Materials: What To Do?
I believe that for our nation to effectively battle cyberattacks, SBOMs are among the most important tools that can be more widely enacted. Will SBOMs eradicate cyberattacks? Certainly not, but they provide powerful insights and oversight for enterprises so they can react more swiftly in the event of fast-moving and dangerous global cyberattacks that can happen at any moment.
As Danen told me at the Open Source Summit, it is the “unknown unknowns” that can get enterprises in the event of a cyberattack. I absolutely agree. If enterprises have no way to see what software, code snippets, and dependencies they are using, then they cannot know what to look for in the event of an emergency. If they know what is there, they can patch it or remove it.
And the thing is, once a company has an SBOM, it is not a stagnant, one-and-done document. It will need constant updates as software evolves, as patches and changes are made, as new pieces are installed and run. SBOMs show enterprises details that automated vulnerability scanners can miss.
That means that just having SBOMs is not enough. Just ticking the check box is not enough. Enterprise IT security leaders and workers must adopt and embrace SBOMs and then follow them up with their due diligence so they can be effective over the long term.
I believe this critical topic must be higher on the agendas and value chains of already-busy enterprise IT leaders, especially when it comes to maintaining vigilance over IT security. I think it is time for a deep talk about SBOMs inside your enterprise IT operations.
Ultimately, having SBOMs does not preclude you from ever being hit head-on by software security vulnerabilities, but they can help lessen the blow and could give you much more information to find a speedy resolution.
As Red Hat’s Danen told me and as every IT security pro already knows, IT security means putting out fires all the time. But using SBOMs can be like having a fire guard, as if you are bulldozing a fire line through the brush around an attack to stop it in its tracks. That way, he said, maybe it will not burn your enterprise down.
And that, I believe, is sound advice to follow to try to keep your enterprise out of the cyberattack fray as much as possible.
