Docker launches CLI command to pull a Software Bill of Materials
New CLI command generates a software bill of materials instantly...
Containerisation heavyweight Docker has added a new CLI command to generate a Software Bill of Materials (SBOM) from a Docker image that lists system packages and language libraries installed -- in a welcome move that organisations can use to get visibility into the packages that exist across their infrastructure.
The command will be included in Docker's Linux packages in future too, said Docker CTO Justin Cormack, adding that the functionality was developed as an open source collaboration with supply chain security specialist Anchore using their Syft project -- which lets users generate SBOMs from container images and filesystems.
Developers incorporate a significant amount of open source software (OSS) in the containerised applications they build and supply chain integrity attacks -- unauthorised modifications to software packages -- have been rising dramatically in recent years as reliable attack vectors that can open the doors to large numbers of organisations.
(Attacks on the software supply chain surged 650% in a year, according to a late 2021 eport by Sonatype that tracked 12,000 software supply chain attacks over the past year, compared to just 929 in 2019-2020.)
See: Hackers breach PHP Git repo, add backdoor, troll Zerodium
Cormack wrote on April 8: "We believe that the best time to determine and record what is in a container image is when you are putting the image together with docker build. To enable this, we are working on making it easy for partners and the community to add SBOM functionality to docker build using BuildKit’s extensibility.
"As this information is generated at build time, we believe that it should be included as part of the image artifact. This means that if you move images between registries (or even into air gapped environments), you should still be able to read the SBOM and other image build metadata off of the image" he added in a blog.
As one security engineer, Square's Kinneard McQuaid noted on Twitter: "It is a pain in the ass to determine which packages and which images are deployed across your ecosystem. We saw this in the Log4j incident * You can `docker pull` -> `docker sbom` -> parse, then report... great job by the Docker team for pushing this feature.
He added: "Software Supply Chain Security's had a lot of innovation recently - between the SLSA framework, increased awareness of abusing CI/CD, increased usage & awareness of SBOMs, and more.
"If you're looking for a way to differentiate yourself in AppSec, these are good skills to learn!"
Both the Log4J and recent Spring Framework vulnerabilities have driven home the importance of having a software bill of materials in place to act as a "list of ingredients" you are using across your software applications.
Provision of a software bill-of-materials (SBOM) is also a key part of President Biden’s executive order on improving national cybersecurity, yet as a recent survey by Anchore showed, fewer than a third of organisations are following SBOM best practices, with only 18% of respondents having a complete SBOM for all applications.
As David A. Wheeler, Director of Open Source Supply Chain Security, Linux Foundation, recently noted to The Stack apropos the Spring4Shell vulnerability: " [SBOMs] enable organizations to understand which third-party components are in their applications, so that they can quickly identify any risks and reduce the potential impact of any vulnerabilities in their supply chains. Organizations must set their houses in order..."
"The obvious approach [to generating a SBOM]" he added, "is to adopt the ISO standard, the Software Package Data Exchange (SPDX), an open standard for communicating software bill of materials information, which enables companies to respond more rapidly following vulnerabilities such as the one impacting Spring Framework. Organizations’ application development processes should also have a variety of tools in their continuous integration (CI) pipeline that look for vulnerabilities, including known vulnerabilities in dependencies.
Other software companies may also want to consider taking Docker's lead and seeing what they can do to help ensure customers can easily access a clear SBOM in the event of (or prior to) an upstream incident.
