Creating SBOMs without the F-Bombs: A Simplified Approach to Creating Software Bills of Material
April 10, 2025

Dave Roche
DigiCert

Software engineers are currently caught between a rock and a hard place.

The rock? They're under record pressure to produce and release new software.

The hard place? They're increasingly expected to account for the safety, security and provenance of every single software asset they use in those builds. That's demonstrated in the rise of the Software Bill of Materials (SBOM).

These two clashing requirements are a source of great anxiety for software engineers, who are now forced to learn a new discipline while being simultaneously expected to do their existing jobs faster.

The Rise of the SBOM

SBOMs have risen due to a growing need for transparency in the software development process.

It's easy to understand how this has come about. The supply chain clearly needs greater transparency and continues to be the source of much insecurity and technology failure. In August 2024, for example, a faulty update to the widely used Zoom software caused outages for millions of customers, paralyzing businesses and education institutions alike. In January 2025, another faulty update caused outages for many organizational Slack users who found they couldn't use one of their most fundamental business communication tools.

As the world becomes more tightly locked in the digital realm, we become ever more vulnerable to risks in the supply chain. Furthermore, there's a growing body of regulation — including a variety of presidential Executive Orders and National Institute of Standards and Technologies (NIST) guidelines — which compel organizations to account for those risks or face compliance penalties.

All of this has led to the rise of the SBOM, in which the components and dependencies of a piece of software are cataloged for the inspection of clients, channel partners, regulators and subsequent links in the supply chain.

While this is a broadly positive development, it is also a cause of great worry for software engineers who are now being forced to account for every single component used within their releases.

"That's Not My Job"

It's important to note that software engineers are not security professionals, but in some important ways, they are now being asked to be.

Software engineers pick and choose from various third-party and open source components and libraries. They do so — for the most part — with little analysis of the security of those components. Those components can be — or become — vulnerable in a whole variety of ways: Once-reliable code repositories can become outdated or vulnerable, zero days can emerge in trusted libraries, and malicious actors can — and often do — infect the supply chain. On top of that, risk profiles can change overnight, making what was a well considered design choice into a vulnerable one almost overnight.

Software engineers never before had to consider these things, and yet the arrival of the SBOM is making them do so like never before. Customers can now scrutinize their releases, and then potentially reject or send them back for fixing — resulting in even more work on short notice and piling on pressure. Even if the risk profile of a particular component changes between the creation of an SBOM and a customer reviewing it, then the release might be rejected.

This is understandably the cause of much frustration for software engineers who are often already under great pressure. The structural conditions that are now bearing down on software engineers can't be dismissed, but they can be accommodated while taking the stress off already-stressed development teams.

Assisting Engineers Around the Learning Curve

Principally, software dev teams need to know how the build decisions they make become vulnerable, so they can design with security in mind, and create reliable SBOMs.

That will mean integrating security insight into the development pipelines that software engineers work within. For example, being able to change and track dependencies so that the dev team will immediately know whether a particular choice will create software failures or security vulnerabilities later down the line. It will also let them know whether the components and libraries they once-thought reliable are now vulnerable or outdated.

Threat detection scans can add another layer of insight, offering a look at the source code level and providing a risk profile of both a release's behavior and its dependencies. It's this kind of insight during development that will allow software engineers to climb that steep learning curve that the SBOM presents. It will also furnish those development teams with proof points that they designed a given release securely, even if those releases have since become outdated or vulnerable. That ability to track and catalog changes in the risk profile of components and dependencies must also extend past dates of release, so that engineers can be involved in the continuing security of their creations.

SBOMs are here to stay and rightly so. We've reached a global level of digital complexity in which we have to know what kinds of components and technologies we're dealing with at every stage of the supply chain. A lot of that added responsibility is now falling to software engineers and they need ways to ease the mounting pressure. The SBOM shouldn't be resisted, but it can be accommodated and building SBOM creation tools into the development process can ease that pressure and help engineers adapt to the new reality.

Dave Roche is a Senior Product Manager at DigiCert
Share this

Industry News

April 23, 2025

Kubernetes 1.33 was released today.

Kubernetes 1.33 Release Information

April 23, 2025

Docker announced a major expansion of its AI initiative with the upcoming Docker MCP Catalog and Docker MCP Toolkit.

April 23, 2025

Perforce Software announced the release of its latest platform update for Puppet Enterprise Advanced, designed to streamline DevSecOps practices and fortify enterprise security postures.

April 23, 2025

Azul announced JVM Inventory, a new feature of Azul Intelligence Cloud designed to address the complexity and risk of migrating off Oracle Java.

April 23, 2025

LaunchDarkly announced the acquisition of Highlight, a powerful, open source, full-stack application monitoring platform known for its error monitoring, logging, distributed tracing and session replay capabilities.

April 22, 2025

O’Reilly announced AI Codecon—a groundbreaking virtual conference series dedicated to exploring the rapidly evolving world of AI-assisted software development.

April 22, 2025

Veracode unveiled new capabilities offering proactive risk mitigation and automated security at enterprise scale.

April 22, 2025

Snyk launched Snyk API & Web, delivering a dynamic application security testing (DAST) solution designed to meet the growing demands of modern and increasingly AI-powered software development.

April 21, 2025

Postman announced new releases designed to help organizations build APIs faster, more securely, and with less friction.

April 21, 2025

SnapLogic announced AgentCreator 3.0, an evolution in agentic AI technology that eliminates the complexity of enterprise AI adoption.

April 17, 2025

GitLab announced the general availability of GitLab Duo with Amazon Q.

April 17, 2025

Perforce Software and Liquibase announced a strategic partnership to enhance secure and compliant database change management for DevOps teams.

April 17, 2025

Spacelift announced the launch of Saturnhead AI — an enterprise-grade AI assistant that slashes DevOps troubleshooting time by transforming complex infrastructure logs into clear, actionable explanations.

April 16, 2025

CodeSecure and FOSSA announced a strategic partnership and native product integration that enables organizations to eliminate security blindspots associated with both third party and open source code.