In security media, the Software Bill of Materials - or, SBOM - seems to be having renewed time in the sun. It stands as one of a handful of dominant trending topics, thanks in no small part to recent guidance from the US government, in the form of the Executive Order on Improving the Nation’s Cybersecurity as well as the brand new Security-by-Design and -Default principles from CISA. 

Both of these releases detail the importance of maintaining SBOMs to ensure deeper transparency and managing risk in the software supply chain, ensuring that purchasers can easily access comprehensive information on what is “under the hood” of the software they are using in their organization. 

They are immensely helpful, and there are a plethora of tools - not to mention comprehensive guidance - to assist software vendors in upholding SBOM best practices and meeting increasingly strict compliance requirements. And yet, they remain a pain point for many teams. 

Business leaders need to make room for SBOMs as a priority, especially with so much change in the air for vendors and their ownership of security. However, while we’re at it, perhaps we need to look at how they can be improved going forward. 

As it stands, are they truly a product of an exemplary security program?

Why organizations struggle to maintain SBOMs

With most companies moving through a constantly evolving digital landscape at a cracking pace, keeping up with every single software component and dependency is easier said than done. Without standardization, meticulous record-keeping, and appointed custodians within the business, SBOM maintenance is destined to fall by the wayside. 

SBOM management is an integral part of the contemporary security program, and it’s vital that they are given the attention they deserve. These days, it’s impossible to take on such a task by hand, or as an afterthought, especially at the enterprise level. Development managers should be working with the security team to establish alignment of approach, best practices, and responsibilities, ensuring that this is communicated to all development teams.

There are automated tools that can make the process of tracking every open-source and third-party component, dependency, and license far less burdensome, but it still takes trained personnel with knowledge of the organization’s development and security environment to ensure they’re an ongoing source of truth. This shouldn’t be overly fragmented, or given to individuals who lack the time to take proper ownership of the task.

Essentially, however, it really comes down to poor security culture. Businesses that fail to prioritize security best practices, security awareness initiatives, and role-based upskilling pathways will be far less likely to allocate the necessary resources to maintain them effectively.

They’re not just a list of ingredients

A common pitfall among business leaders is treating SBOMs like a list of ingredients. While that does make up a significant portion of any functional example, it must be far more comprehensive in order to serve its purpose in security.

Vulnerability management is a core component of the modern SBOM, and if this information is outdated or not at all present, it’s a key indicator that an organization has some way to go in this particular function of security maturity. This is made more difficult by the sheer complexity of mapping and tracking vulnerabilities for such a large volume of components, and quite often, automated tools don’t play nicely with SBOM management workflows. 

There is no simple fix, but ensuring that the right SBOM tech stack is implemented and integrative goes a long way to ensuring developers and security personnel tasked with overall custody of the process don’t tear their hair out. They need to be able to stay agile, and flex with curveballs like incomplete vulnerability data, not to mention continuous updates to discovered - and previously addressed - vulnerabilities.

An SBOM fit for a developer-driven security program

It’s apparent that one of the fundamental impediments to a solid SBOM is a lackluster security culture, and this is usually caused by factors like general deprioritization of security across the organization, as well as a lack of continuous role-based skill development, especially among the development cohort.

Highly contextual, relevant, and continuous security education for developers is a potent antidote for common recurring vulnerabilities, and can really help set a positive tone for the overall security culture. Developers need to understand the control they can have over security outcomes, and that they hold the key to instilling best practices from the beginning of the software development lifecycle. With secure software development fast becoming non-negotiable, organizations must take developer enablement seriously, and foster their continuous upskilling.

However, with increased emphasis on the need for training and verified security skills, why is this data not part of the vulnerability management component of an SBOM? The “people factor” in security is notoriously overlooked, yet it remains so incredibly powerful in driving the security outcomes - for better or worse - in every organization. Perhaps if developer training outcomes were recorded as part of the SBOM process, it would be easier to address compliance and knowledge gaps, and ultimately drive better results.