Recently, Docker added a new command to Docker CLI.
docker sbom. We can use this command to create a Software Bill of Materials (SBOM) for any container image. Another great capability when it comes to shift-left security.
This post explains why you should want to have SBOMs for all the container images of your application. How to get them and which actions you can take based on SBOMs to improve the overall security of your containerized workloads.
- What is Software Bill Of Materials (SBOM)
- Generating SBOM with Docker Desktop on Docker CLI
- Integration with vulnerability scanners
- What we have covered in this post
What is Software Bill Of Materials (SBOM)
Let’s do a quick refresher for those of you that have never heard the term Software Bill Of Materials (SBOM)
Why do you want to have SBOMs
Now that you know what an SBOM actually is, you may ask yourself why you should care about it and what you can do. From a developers perspective, you can achieve the following:
- Identify all runtime dependencies of your container images
- Minimize supply chain attack surface by removing unnecessary or forbidden (due to regularity compliance) dependencies from your container images
- Harden your supply chain by replacing specific software packages with alternatives
- Start your inner-loop security process as part of shift-left security by handing over SBOM to vulnerability scanners
- Detect issues due to licenses applied to upstream components
- Implement security, quality, and compliance gates that use SBOM to prevent usage of particular software packages or as safeguard to prevent infiltration
On top of that, your customers may also ask you to provide an SBOM for all your deliverables. See the following paragraph explaining why more and more enterprises request SBOMs.
Why do customers request SBOMs
I see more and more customers asking for SBOMs these days. Typically they want to
- Know about dependencies finding their way into secured environments
- Harden their supply chain and learn about potential attack surfaces
- Prevent deployment of specific packages due to regulatory compliance
- **Verify licenses **used by third-party software vendors
Obviously, there are more reasons why your customers may ask you for an SBOM. However, those were the ones that I hear most often.
Generating SBOM with Docker Desktop on Docker CLI
With version 4.7.0, Docker CLI (part of Docker Desktop) comes with the new
docker sbom command, which allows us to create an SBOM for any Docker image. Under the covers,
docker sbom is currently using the open-source project
Syft from Anchore to create the SBOM.
All we need to do is provide the image name and the desired tag as an argument to
docker sbom. The following snippet shows how to create an SBOM for the latest NGINX image (based on Alpine Linux):
docker sbom nginx:alpine Syft v0.43.0 ✔ Loaded image ✔ Parsed image ✔ Cataloged packages [42 packages] NAME VERSION TYPE alpine-baselayout 3.2.0-r18 apk alpine-keys 2.4-r1 apk apk-tools 2.12.7-r3 apk brotli-libs 1.0.9-r5 apk busybox 1.34.1-r5 apk ca-certificates 20211220-r0 apk ca-certificates-bundle 20211220-r0 apk curl 7.80.0-r0 apk freetype 2.11.1-r0 apk geoip 1.6.12-r2 apk libbz2 1.0.8-r1 apk libc-utils 0.7.2-r3 apk libcrypto1.1 1.1.1n-r0 apk libcurl 7.80.0-r0 apk libedit 20210910.3.1-r0 apk libgcrypt 1.9.4-r0 apk libgd 2.3.2-r1 apk libgpg-error 1.42-r1 apk libintl 0.21-r0 apk libjpeg-turbo 2.1.2-r0 apk libpng 1.6.37-r1 apk libretls 3.3.4-r3 apk libssl1.1 1.1.1n-r0 apk libwebp 1.2.2-r0 apk libxml2 2.9.13-r0 apk libxslt 1.1.35-r0 apk musl 1.2.2-r7 apk musl-utils 1.2.2-r7 apk ncurses-libs 6.3_p20211120-r0 apk ncurses-terminfo-base 6.3_p20211120-r0 apk nghttp2-libs 1.46.0-r0 apk nginx 1.21.6-r1 apk nginx-module-geoip 1.21.6-r1 apk nginx-module-image-filter 1.21.6-r1 apk nginx-module-njs 184.108.40.206.7.2-r1 apk nginx-module-xslt 1.21.6-r1 apk pcre2 10.39-r0 apk scanelf 1.3.3-r0 apk ssl_client 1.34.1-r5 apk tzdata 2022a-r0 apk xz-libs 5.2.5-r0 apk zlib 1.2.12-r0 apk
SBOM file formats and their capabilities
Having detailed information about all software components part of your Docker image is mission-critical. But to move on from here, we must integrate SBOM with other tools like vulnerability scanners and others. The underlying open source Syft is able to produce the SBOM in different formats, that we can use for integration with upstream tooling:
- SPDX: Either JSON or tag-value report that is SPDX 2.2 spec conform
- CycloneDX: Either XML or JSON report that is CycloneDX 1.4 spec conform
- Syft-JSON: Most detailed report that contains all information Syft can collect
- Text: a row based report (easy to read for humans, yet good to process for machines / tools)
- Table: a column-based summary (default output format)
Both SPDX and CycloneDX are standards that we use for further investigations like vulnerability scanning.
Integration with vulnerability scanners
Although vulnerability scanners can scan Docker images, it’s often faster to use the SBOM as a data source instead of the actual Docker image. There are many vulnerability scanning solutions available that we can use to scan our Docker images. For the sake of this article, we will use Grype (also created by the awesome folks at Anchore) to scan for vulnerabilities using SBOM:
# Create SBOM docker sbom nginx:alpine --format syft-json -o sbom.json Syft v0.43.0 ✔ Loaded image ✔ Parsed image ✔ Cataloged packages [42 packages] # Scan for vulnerabilities grype sbom:./sbom.json ✔ Vulnerability DB [updated] ✔ Scanned image [16 vulnerabilities] NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY curl 7.80.0-r0 7.80.0-r1 apk CVE-2022-22576 Unknown curl 7.80.0-r0 7.80.0-r1 apk CVE-2022-27774 Unknown curl 7.80.0-r0 7.80.0-r1 apk CVE-2022-27775 Unknown curl 7.80.0-r0 7.80.0-r1 apk CVE-2022-27776 Unknown libcurl 7.80.0-r0 7.80.0-r1 apk CVE-2022-27774 Unknown libcurl 7.80.0-r0 7.80.0-r1 apk CVE-2022-27775 Unknown libcurl 7.80.0-r0 7.80.0-r1 apk CVE-2022-22576 Unknown libcurl 7.80.0-r0 7.80.0-r1 apk CVE-2022-27776 Unknown libgd 2.3.2-r1 apk CVE-2021-40812 Medium libgd 2.3.2-r1 apk CVE-2021-38115 Medium libgd 2.3.2-r1 apk CVE-2021-40145 High xz-libs 5.2.5-r0 5.2.5-r1 apk CVE-2022-1271 Unknown
Handing over the SBOM to a vulnerability scanner like Grype, we can speed up the process of vulnerability scanning and can take further actions like upgrading vulnerable dependencies from here.
What we have covered in this post
- 💡 Learned what Software Bill of Materials (SBOM) is
- 🖇 Recognized why we as developers and our customers may want to have an SBOM
- ⚙️ Created an SBOM from a Docker Image
- 🦠 Used an SBOM as data source for a vulnerability scanner
Generating and providing detailed Software Bill of Materials (SBOM) for Docker images has never been easier. The integration of open-source Syft as a first-class citizen command is a vast simplification and addition to inner-loop tooling.
Identifying dependencies and eliminating potential vulnerabilities is a core principle for building rock-solid Docker images. We, as developers, must take responsibility for the Docker images we created to distribute our applications. As part of this responsibility, we must care about the security of our Docker images. In this context,
docker sbom acts as the entrance into shift-left-security, which helps us to create secure and trustworthy Docker images.