In security media, the Software Bill of Materials (SBOM) is 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 new security-by-design and default principles from CISA.
Both of these releases detail the importance of maintaining SBOMs to ensure deeper transparency and manage risk in the software supply chain, ensuring that purchasers can easily access comprehensive information on what is “under the hood” of the software they use 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, we need to look at how they can be improved going forward.
Why Organizations Struggle to Maintain SBOMs
With most companies moving through a constantly evolving digital landscape at a cracking pace, keeping up with every 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 must be given the attention it deserves. 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 work with the security team to align approaches, best practices and responsibilities, ensuring this is communicated to all development teams.
There are automated tools that can make tracking every open-source and third-party component, dependency and license far less burdensome. However, 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 comes down to poor security culture. Businesses that fail to prioritize security best practices, 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 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 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, which is usually caused by factors like general deprioritization of security across the organization and 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 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 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.