Why It’s Time for SBOMs
Each headline of another third-party vulnerability is the latest reminder of how interconnected everything is across our industry.
Last year was notable for its many cybersecurity failures. However, sometimes, failure and crisis spur moments of self-reflection and self-improvement. This time, the self-reflection may require a Software Bill of Material (SBOM) from all vendors, discusses Augusto Barros, security evangelist & former Gartner analyst, Securonix.
After SolarWinds, there were murmurs that we needed to start looking at developing SBOMs. With Log4j, the latest high-profile incident, those murmurs have become shouts as highly regulated industries like automotive and healthcare want to know precisely what is in their software purchases.
Each headline of another third-party vulnerability is the latest reminder of how interconnected everything is across our industry. People tend to think of software development as discreet bits, but software development today is closer to building with Lego blocks than actually writing code with people snapping pieces into play as they need them. Yet, like the game Jenga, an enterprise’s security defense is interconnected. One faulty block can compromise the entire structure, shutting down an enterprise’s operations as they scramble in fear, wondering what damage has been done.
While people may be clamoring for SBOMs, what’s lacking in that conversation is an actual discussion of what an SBOM is and how it can protect an enterprise.
What Are SBOMs?
In more established and highly regulated industries like airlines and pharmaceuticals, bills of material are expected and relatively standardized. While SBOMs are not expected in the software industry, there is a working definition of what they should be. According to the federal government, “A Software Bill of Materials (SBOM) is a nested inventory for software, a list of ingredients that make up software components.”
It’s essentially a standardized way of knowing what components, libraries and dependencies you have in your applications, so when a known vulnerability arises, you can quickly move to remediate it.
SMOBs don’t only help people who purchase software, and they also help companies that build software. Many software vendors use open-source code when building their applications. SBOMs can help software developers detect vulnerabilities within their environment, putting them in a better position to protect their downstream customers.
SBOMs are not perfect. The transparency that SBOMs provide gets murky when you’re using software-as-a-service. In that case, you’re buying software from a third-party vendor who may also be consuming software-as-a-service and running it on a cloud vendor. It’s almost impossible to keep track of that complex web of network dependences.
See More: Can IGA Solve Business Security Challenges?
Benefits of SBOMs
SBOMs help anyone who makes software, buys software, or operates it. There are a lot of interdependencies within the supply chain, and the SBOM helps companies understand some of their risks, providing transparency into all the dependencies of a software package. It’s a form of reassurance that someone is tracking everything they put into their software, and they’re going to continue to update that SBOM accordingly. An SBOM helps with patching and vulnerability management. If there’s a problem, an enterprise can look through its SBOMs and quickly identify whether or not it has that vulnerability.
It’s not only open-source coding that’s insecure. The software industry uses commercial libraries, and if they become vulnerable, you need to know if you have them in your stack to protect the enterprise.
SBOMs and Known Vulnerabilities
SBOMs can also help enterprises with a known vulnerability without an available patch. Suppose an enterprise has a known vulnerability within its stack and a patch is not yet available. In that case, the company can start monitoring and looking for traces of those attacks using that vulnerability until the enterprise or its vendor can patch it. An SBOM would help an enterprise mitigate that vulnerability.
It’s Time to Prepare Better
Given the rise of third-party attacks and the interconnectedness of the modern enterprise, it’s not a surprise that people who build, buy, and operate software want to know what’s in it. The likelihood of a Log4j event happening again is high. The Lego approach to software building is simply the way things are done. This building block approach is cheap and insecure.
The truth is that it’s past time for the software industry to join its more established brethren in creating a bill of materials that outlines everything that goes into a software application. Developers have been lax about tracking what goes in their software, and we’ve seen the results spread across headlines and through multi-million dollar ransomware payouts. It’s time to make sure that in 2022 and beyond, we don’t repeat history.
How do you see SBOMs changing enterprise protection in the recent future? Share with us on LinkedIn, Twitter, or Facebook. We’d love to know!
MORE ON CYBERSECURITY:
