Along with the increasing sophistication of cyberattacks today, modern software applications have become increasingly complex and reliant on third-party components.
Rarely are software applications built from scratch; instead, they are assembled from dozens—if not hundreds—of open-source software libraries, third-party modules, and commercial components.
Critical vulnerabilities often lie deep within these layers of dependencies, some of which may not even be known to the developers.
The Software Bill of Materials (SBOM) has emerged as a necessity for modern cybersecurity. Yet SBOMs are often seen as optional or neglected altogether.
For CISOs and technology leaders, the opacity of the software supply chain has become a blind spot. It is not wise to implement applications without knowing what they contain.
A comprehensive SBOM is no longer a best practice; it’s a baseline requirement. And that must be continuous—not a one-time snapshot.
The CISO’s Dilemma: Known Risk, Invisible Dependencies
Each element introduced into an application risks exposing potential vulnerabilities within the environment. The problem lies in the limited visibility into what is actually in the software that’s deployed.
The infamous Log4Shell vulnerability (CVE-2021-44228) in 2021 was a critical zero-day vulnerability. It affected Apache Log4j, which was a widely used logging library embedded in many enterprise applications.
The vulnerability allowed attackers to execute arbitrary code remotely on affected systems. It stemmed from improper input validation in Log4j’s Java Naming and Directory Interface (JNDI) lookup functionality.
Once it was discovered, organizations spent weeks, and in some cases even months, trying to determine where and how they had been exposed. In certain situations, the SEC required public companies to report on the impact in short timeframes. In other words, an SBOM had to be rapidly created.
For the largest enterprises, this was nearly an impossible task! The difficulty could have been avoided had they had a SBOM to provide this information, enabling organizations to identify and mitigate exposure within hours instead of weeks.
What Is a SBOM and Why Does It Matter?
A SBOM is a comprehensive list of all components, including libraries, frameworks, and modules, contained within a software application and contained in the “stack” of software necessary to operate the application. This can include operating systems, device drivers, firmware, etc. It’s the digital equivalent of a nutrition label for code.
When done right, a SBOM gives security teams:
– Complete visibility into direct and transitive (embedded) dependencies.
– The ability to quickly assess exposure to known vulnerabilities.
– A foundation for continuous risk monitoring and compliance.
In short, it gives us the same level of visibility in our software hierarchy we enjoy on our endpoints, servers and virtual machines from asset management tools and EDR/MDRs.
However, the unfortunate situation today is that software vendors either provide incomplete SBOMs or don’t even offer them at all. Another issue is that internal development teams may lack the tooling or discipline to generate and maintain them.
The Case for Ongoing Visibility
A SBOM must be treated as a living document, updated with every code change, new release, or patch. Threat actors won’t conveniently wait for your next quarterly review cycle to exploit an “invisible” vulnerability. As soon as a new CVE is published, that is the moment to act.
The SolarWinds attack in 2020 is a classic example of today’s complex software chains. Hackers exploited the build environment of a trusted software vendor, injecting malicious code into a routine update.
Even organizations that religiously followed patching best practices fell victim when this backdoor was opened into their networks. If SolarWinds had the SBOM discipline, exposure could have been identified earlier.
Best Practices for SBOM Adoption
For organizations looking to build a resilient software supply chain, here are key recommendations:
Mandate SBOMs from all vendors: Require comprehensive, machine-readable SBOMs as part of your procurement and vendor risk assessment process.
Mandate SBOMs from all internal development teams: Require comprehensive, machine-readable SBOMs as part of your software architecture, design, and development teams. Know your entire pipeline from top to bottom, inside and out.
IT Operations teams should maintain constant visibility through the use of modern-day observability tools such as Dynatrace.
Integrate SBOM tools into your development lifecycle: Leverage automated tools like Snyk, Endor Labs, or Scribe Security to generate SBOMs during build time and track changes over time.
Establish governance for SBOM maintenance: Write clear policies to define ownership, update cadence, and integrate with vulnerability management workflows. Stand up a visible, consistent, and well-run exception management program.
It is often the case that software component vulnerabilities are discovered with the aforementioned tools that are difficult, costly, or inconvenient to remediate.
In these cases, we may choose to “tolerate” the existence of the vulnerability, but this should be managed through the exception governance process and, where possible, maintain a set of compensating controls.
Use SBOMs for proactive vulnerability scanning: Cross-reference your SBOM inventory with databases like the National Vulnerability Database (NVD) for real-time risk insights. Do this as constantly as you do for your endpoints (real-time, all the time).
Train your teams: Ensure that developers, DevOps, and security teams understand how to read, use, and maintain SBOMs effectively. Most importantly, instill the same discipline in our development teams that we’ve come to employ in our endpoint vulnerability management efforts.
Know your environment: It’s no longer acceptable to ignore these security gaps. Tools and information are available to close these gaps. It requires an unrelenting commitment from your software development leaders.
Visibility Is Non-Negotiable
Running software without an SBOM is like offering an open invitation to threat actors. Without a SBOM, you don’t know what you’re running, and as long as you do this, you risk becoming the next threat actor front door into your systems, or your customers’ systems. The cost of inaction may not just be financial—it could easily be reputational and regulatory.
You’ve likely heard that cybersecurity is only as strong as its weakest link. And if that link is a dependency buried several layers deep, you’ll need a SBOM even to be aware of it. Cybersecurity problems can be addressed. The frameworks exist. What’s often lacking is cultural commitment, policy development, exception management, and enforcement.
CISOs and software development leaders must take the initiative. Comprehensive SBOMs are a necessity; a defensive tool no organization can be without.
The time is now to get them embedded into your risk frameworks, development pipelines, and vendor contracts. The longer you wait, the longer you leave yourselves exposed to preventable threats.
We feature the best patch management software.
This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro
