Never Drop The SBOM, Why A Software Bill Of Materials Pays Off

Caucasian Man Dropping the Mic Sequence – Popular Performance Black and Silver Dynamic Microphone – Hands Only – White Background – Simple Concept

getty

Software needs accountability. This is why the software bill of materials has become an integral element in the modern software application development team’s arsenal of infrastructure services. Positioned by US defense agency CISA as a key building block in software security and software supply chain risk management, the organization defines an SBOM as “a nested inventory [and] list of ingredients that make up software components” in modern technology stacks.

With a cautious eye on system vulnerabilities and security, an SBOM is also used to illustrate the woven fabric of software dependencies (elements of software code that rely on other code, sometimes internal, often also third-party, to perform their function) that might exist inside any given enterprise software codebase. By tracking the version number of components used, an SBOM also helps software teams keep track of licensing requirements, usage guidelines and the possibility of obsolescence.

Thought to date back to somewhere around 2010 in its current formalized definition, it is not unreasonable to suggest that the notion of the SBOM existed long before its official baptism i.e. we’ve always had software projects with multifarious components and interdependent connections, but once upon a time, those lists might have simply been an Excel file.

SBOM, At The Very Minimum

Mike Lieberman, co-founder and CTO at software supply chain security company Kusari thinks that SBOMs are an ecosystem-agnostic way to describe the software that’s inside applications. In fact, CISA released a draft of its updated SBOM “minimum elements” for public comment last month.

“For engineering and platform teams, the proposed updates mean fewer proprietary formats, less guesswork when integrating tools… and a standardized record that can travel across environments and vendors. The addition of new mandatory fields, like Tool Name and License, brings greater clarity. SBOM tools operate differently, so knowing which tool generated an SBOM helps teams assess the reliability of their data, while explicit license information is critical for navigating usage rights in SaaS, distributable products, or mixed environments. This is important as many organizations place restrictions on which licenses can be used in their software,” said Lieberman.

Looking deeper here, SBOMs help answer basic but critical operational questions, such as:

• What software instances, applications and packages are the team running?
• What components does the current stack of applications and services rely on?
• What has changed in the codebase and its connection points between versions?

A Living Operational Document

These are questions that IT teams don’t want to be answering reactively in the middle of a (live deployment) “production” incident or regulatory audit. In working practice, SBOMs also enable software and operations teams to check for newly introduced vulnerabilities in each build, while they also work to enforce policies that prevent critical vulnerabilities from ever reaching production. By treating SBOMs as “living operational documents”, rather than compliance checkboxes, organizations can make updates more efficiently, spot dependency issues earlier and reduce costly surprises in the release cycle.

“The new Component Hash field [basically a digital fingerprint of data input to a software system] strengthens these processes by offering a unique identifier for each dependency across an SBOM,” explained Lieberman. “That matters because packages often share names, but differ in source or build; the hash confirms exactly which component was included. Similarly, the Generation Context field records when and how an SBOM was produced i.e. whether pre-build, during build, or through post-build inspection. Build-time SBOMs are generally most accurate, but in many real-world cases, teams may only have a container image or source code to work with. Capturing this context helps downstream users understand the limits of the data and make more informed decisions,” said Lieberman.

Any SBOM Is Better Than No SBOM

He urges us to further keep in mind that any SBOM is better than no SBOM. His recommendation is that simplicity is the best starting point. Software teams don’t need a complex new system to begin generating and using SBOMs. The Kusari tech lead has said that “lightweight tools” integrated into existing continuous integration and continuous delivery pipelines can provide enough visibility to make informed decisions. Over time, he suggests that richer SBOM practices, such as cross-project dependency analysis and historical tracking, can become powerful enablers of enterprise-scale operations.

The key takeaway for Lieberman is that SBOMs aren’t just about meeting a compliance requirement. They are useful in understanding software composition, managing dependencies… and they ultimately deliver software with greater confidence, speed and control.

Crystal Morin, senior cybersecurity strategist at Sysdig says that while there are still no universal standards, SBOMs have become an increasingly common topic of interest as their value for risk analysis has become clearer.

“Businesses are beginning to demand SBOMs as part of their software procurement processes, too. Pursuant to U.S. Executive Order (EO) 14028, the National Institute of Standards and Technology (NIST) and National Telecommunications and Information Administration (NTIA) have both published SBOMs recommendations which are mandated for federal entities and their software suppliers,” explained Morin. “While the lack of standardized SBOM practices has been a challenge for universal implementation, CISA’s August update has the potential to deliver greater clarity and simplify the barrier for adoption. To date, we’ve seen a stark disconnect between how leadership and practitioners view the success of their organizations’ adoption of SBOMs.”

A Sonatype survey from 2023 found that 92% of large enterprises had planned or already implemented an SBOM, according to their IT directors, while a more recent survey found that nearly half of security professionals believed their organizations were behind in adopting EO 14028 and CRA.

A Tablestakes Bet, Soon

“As for developers, SBOMs ultimately serve as a stamp of quality on their work. They are evidence of diligence, disciplined security, accountability and transparency,” said Morin. “Gone are the days of manually creating SBOMs. Their generation, formatting and maintenance can now be automated and integrated directly into developer workflows. Beyond compliance, SBOMs are also valuable for faster vulnerability remediation, third-party risk management and can even support the ‘shift-left’ secure development mentality. SBOMs will increasingly become tablestakes over the next few years, so organizations working to get their supply chain security in order now are setting themselves up for future success.”

Dustin Kirkland, SVP of engineering at Chainguard balances the argument by saying that SBOMs are certainly important, but he thinks they’re far from the full solution.

“Think of them like the ingredients label on a box of food – they sort of show what’s in your groceries, but they details nothing about the quality of those ingredients or whether someone tampered with them along the way. The latest guide from CISA adds some useful details, but it doesn’t solve that bigger problem. To really secure the software supply chain, we need proof that software was built the right way from the start. That means tying SBOMs to verifiable records of the build process, so they’re always accurate, up to date, and ready to be trusted,” noted Kirkland, during a media briefing this week.

“There are several key decisions that organizations must get right in order to get the most benefit from an SBOM,” said Scott McKinnon, CSO of UK&I at Palo Alto Networks. “First, they should consider the challenges of retroactively applying such a standard to existing software assets. All software should be included in the SBOM’s scope, including product lines, legacy code and acquisitions. This is no small undertaking.”

He explains that another critical area is assessing how effective an SBOM will be in a rapid, cloud-native environment where many daily updates are rolled out. It’s important to ensure that IT operations aren’t slowed down significantly so that teams throughout the business can continue to operate efficiently. Understanding how consumers of SBOMs operationalize their artefacts should also be considered.

“For example, if a customer has 50 software vendors making continuous updates and providing SBOMs then they need to be swiftly verified via an established process otherwise operations will again be hindered,” said McKinnon. “If an organization can effectively produce an SBOM then that’s indicative of a strong process which is clearly a positive. However, the true scale of the task can be underestimated, which prevents SBOMs from delivering their full value.”

A Mixed Market Of Vendors

Key players in the SBOM market include GitLab, GitHub, Snyk, Anchore, (Black Duck acquired Synopsys in 2017), Sonatype, Aqua, Veracode, and the above-referenced Chainguard, Synopsys, Sysdig… and Palo Alto Networks for its Prisma Cloud service. While some of these names are pure-play security vendors at heart, others straddle the intersection of standards and software tools management. Technology vendors with the widest grasp in this space tend to be market leaders because they have embedded SBOM services into their code repository services, the application dependency mapping graphs that they offer… and the continuous CI/CD pipeline services that they deliver as their bread-and-butter core competencies.

Technology procurement buyers (working developers and the C-suite selection pack of CIO, CTOs and CISOs) tend to buy based on a SBOM specialist’s ability to offer standards support, how well the SBOM exports, the degree of vulnerability-mapping and policy automation that features, how far their governance services stretch and what level of “developer ergonomics” they can provide in terms a) the amount of negative operational friction an SBOM causes in a team and b) whether there are pre-scripted and pre-architected elements on offer to make the whole affair as plug-and-play as possible.

Perhaps best of all, the SBOM is pronounced S-bomb, so it works for engineers who need to handle it and for the business suits that might enjoy saying it in board meetings. Most advocates in this space agree that we need this technology and we shouldn’t drop it… even if it’s hot.