Docker, Inc. to Integrate Free SBOM Generation Tool
Docker, Inc. plans to embed the ability to dynamically generate a software bill of materials (SBOM) using the Docker Build command that developers use to build Docker images from a Dockerfile.
Company CEO Scott Johnston says when it comes to building cloud-native applications, existing SBOM tools can’t keep pace with the rate at which developers are ripping and replacing containers. Docker, Inc. will address the need to provide more visibility into what components are being used to construct an application for no additional cost, he adds.
Docker Inc. recently acquired Atomist, a provider of a container vulnerability scanning tool that will be integrated with Docker Build to enable developers to generate SBOMs that are continuously updated, says Johnston.
While various SBOM creation tools have been available for years, there is now a lot more focus on the need to discover what components make up an application to make it simpler to find and remediate vulnerabilities. The Biden administration is requiring federal agencies to implement SBOMs in the wake of a series of high-profile breaches, and it is expected that many enterprise IT organizations will soon follow suit.
The ultimate goal is to not only collect SBOMs but to also proactively analyze them so organizations can accept or reject applications based on the components being employed. For example, a version of a component that is based on an older release with known vulnerabilities would result in an alert requiring a developer to upgrade that component.
The SBOM capabilities being integrated by Docker Inc. will also make it simpler for development teams to keep track of the components being used. One of the major challenges development teams face today is that even after a vulnerability is remediated, the next time a developer looks to reuse a component downloaded from a repository, they wind up having to fix the same vulnerability again. Development tools that have an integrated SBOM should, at the very least, make it easier to identify those issues earlier in the development life cycle.
One way or another, it’s clear that SBOMs are going to be tightly integrated across the software development life cycle. Today, development teams will spend months looking for every instance of, for example, a Log4j shell vulnerability might exist. Integrating SBOMs into the development life cycle will significantly reduce the time required to remediate what are often thousands of vulnerabilities strewn across an application portfolio.
In the meantime, application security continues to evolve into a team sport as developers assume more responsibility for preventing vulnerabilities from finding their way into production environments. The trouble is that most developers have limited cybersecurity expertise; ideally, the goal should be to provide guardrails that make it simpler to prevent vulnerabilities from finding their way into the software development life cycle in the first place.
Achieving that goal starts, of course, with an SBOM that makes it possible to see the list of ingredients used to construct that application.
