The software bill of materials (SBOM) is gaining renewed attention and notoriety post-SolarWinds. More companies and government agencies seek deeper transparency into the software components entering their software supply chain.

While there are critics out there that believe that the SBOM is a misguided concept for DevSecOps, the continuing evolution of DevSecOps, much less the automation it brings to development teams today, now makes SBOMs a foundational aspect of the DevSecOps process.

SBOMs: The New Gate to the DevSecOps Pipeline

It’s time to treat the software BOM as a barrier to entry for software components entering your DevSecOps, not just your container repository. Requiring an SBOM for all software entering your pipeline has become a common-sense best practice in this day and age. You have three options for obtaining SBOMs:

  • Gain full cooperation from the software vendor, despite whether they’re a partner of your organization, with the SBOM as part of their delivery 
  • Implement software composition analysis tools that require particular expertise 
  • Implement a container vulnerability scanning tool that enables you to generate SBOMs for the containers entering your pipeline 

Moving software bill of materials generation to the left is just another step in moving security left. Depending on your particular business processes, compliance requirements, and pipeline gateway requirements, it’s essential to add a documented or automated process (or better yet, a combination of the two) that ensures that each software component has an accompanying SBOM before it enters your development environment As an example, let’s say your developers are taking advantage of an open source software (OSS) component in a cloud-native application built for one of your most important customers. OSS projects don’t have the resources or staff to generate an SBOM. It’s not something they do. Nothing stops your teams, however, from creating an OSS onboarding process and putting in the right tool to generate the SBOM for the OSS themselves before the software even hits your development environment and software repositories.

SBOM, Say What?

There are some details from industry surveys and various industry mutterings that project that less than half of the companies out there are creating SBOMs for their software. It’s not about the SBOM being a misguided concept for DevSecOps either. Currently, organizations just do not build SBOM creation into their DevSecOps processes. You control the gates at all phases of your DevSecOps toolchain. It’s up to you to put in the tools and processes upfront (“to the left”) to ensure that all software from your in-house teams, contractors, partners, vendors, and OSS enter your DevSecOps toolchain, much less your enterprise software supply chain.

Accountability for the SBOM is a New Priority

Accountability for SBOMs seems to get lost in the rush to deliver new software. It’s time for that to change.

Beyond putting in the tools and processes to capture an SBOM at contract time or have your team generate an SBOM for OSS, here are some examples of how you can build in SBOM accountability inside your organization:

  • Include SBOM as a requirement for contractual deliverables from your vendors and partners, making it part of new software development, updates, and patches they deliver as part of a project.
  • Establish the SBOM as a method for cross-functional team collaboration early in the project lifecycle because your contracts, finance, development, and cybersecurity teams all benefit from a well-formed SBOM to help them accomplish critical project-related tasks.
  • Deputize a developer or development team to “own” or shepherd OSS components through your DevSecOps toolchain, giving them the responsibility of generating an SBOM for each component.
  • Elevate the role of your cybersecurity team in the SBOM discussion by mandating that the SBOM serves as the basis for vulnerability scans.

Final Thoughts

Your development, security, and operations teams have probably already put a lot of work into creating the culture, processes, and frameworks to enable your organization to leverage DevSecOps. Factoring in the role of the SBOM into your DevSecOps processes is yet another iteration of your DevSecOps processes. 

Do you want to generate SBOMs on the OSS in your development projects? Download Syft, our open source command-line interface (CLI) tool, and Go library for developing a Software Bill of Materials (SBOM) from container images and filesystems.