Why Docker Scout

Upon the recent release of Docker Scout, a subcommand in the Docker toolchain, I published an article titled "Docker Scout vs Scan", examining the two subcommands in terms of their interfaces, licensing, and features. Following conversations with Amy Bass, Docker product manager, and Christian Dupuis, the lead engineer working on Scout, I realized that my article missed a critical aspect of Scout's functionality. The purpose of this piece is to address this oversight and provide a comprehensive analysis of Docker Scout's capabilities.

Docker Scout is reactive.

To explain what it means, let's look into how Docker Scout works.

CVEs

In the world of software security, it is essential to have a standardized system for identifying and reporting vulnerabilities. This is where the Common Vulnerability and Exposure (CVE) system comes in. A CVE is a unique identifier assigned to a publicly disclosed software security flaw by a CVE Numbering Authority (CNA). The purpose of the CVE system is to provide a common language for identifying and tracking security issues across different software products and organizations. When a CVE is assigned to a vulnerability, it allows security professionals to share information and coordinate their efforts in addressing the issue. By using the CVE system, software vendors, researchers, and users can stay informed about potential security threats and take appropriate measures to protect their systems.

Note. To perform a CVE check on a Docker image using the Scout tool on the Command Line Interface (CLI), execute the following command:

docker scout cves <image-name>

Log4Shell

In the latter half of 2021, the software industry faced a significant security issue with the discovery of Log4Shell (CVE-2021--44228), a vulnerability in the widely used Java logging library, Log4j. As a result of its widespread use across multiple Java projects, the Log4Shell vulnerability quickly became a cause for concern, with the potential to affect a large number of systems worldwide. This vulnerability enabled attackers to execute malicious code remotely, allowing them to take control of a system and carry out further attacks.

In response to this incident, the industry placed renewed emphasis on supply-chain security, recognizing the need to have a comprehensive approach to security that encompasses not only internal practices but also the security of third-party components and dependencies. The Log4Shell vulnerability serves as a stark reminder of the importance of having robust security measures in place, particularly for widely used libraries and components. As such, it has led to increased scrutiny of the security practices and policies surrounding the use of third-party software, and a push for more secure coding practices across the board.

Note. On Docker's Image Vulnerability Database, [dso.docker.com](https://dso.docker.com/), you can search for CVEs, as well as packages and images. Let's search for CVE-2021-44228 under the vulnerability search. It will lead to this page, which has listed all of the affected packages, among others.

SBOMs

A crucial aspect of supply-chain security in software development is the creation of a Software Bill of Materials (SBOM), which is a comprehensive list of all components used in building software, including third-party libraries. In the wake of the Log4Shell incident, SBOMs have gained significant attention in the industry as a valuable tool for identifying and addressing potential security vulnerabilities. By having an SBOM for a software product, it becomes easier to quickly identify any vulnerabilities and take necessary steps to mitigate the risks.

In response to the increasing importance of SBOMs, Docker incorporated SBOM generation into their Command Line Interface (CLI) in April 2022. I remember hosting a Docker Community All Hands watching party in September 2022 and SBOM generation of Docker was the hottest topic.Note. To generate an SBOM from a Docker image, simply execute the following command in your terminal:

docker sbom <image-name>

Note. In Docker Desktop 4.18, an SBOM-generation subcommand for Scout is added:

docker scout sbom <image-name>

Docker Scout

Docker Scout utilizes the Software Bill of Materials (SBOM) generated from a Docker image to match vulnerable packages and dependencies. This process has several implications.

No Point-in-Time Scanning

One significant advantage of using SBOMs is that it eliminates the need for point-in-time scans. Since the SBOM of a Docker image is static and does not change over time, Docker does not need to rescan the image to detect new vulnerabilities.

If a package within a Docker image is found to be vulnerable, Docker Scout will promptly report it reactively, without requiring a rescan.

This critical feature of Docker Scout is most effectively leveraged through Docker Hub, Docker Desktop, and Docker DevSecOps integration to GitHub.

No Rescaning

One can ship a Docker image already bundled with its SBOM. In that case, the Docker image is not indexed at all, and the vulnerabilities are reported just by checking against the CVEs database.

Note. To generate SBOM when creating a Dockerfile, use the following flag:

docker build --sbom ...

Final Words

In conclusion, it is important to note that Docker Scout is still in beta, and its full potential may not have yet been realized.

It is also important to clarify that the views expressed in this article are personal opinions and not sponsored by Docker, although the author is a Docker Captain.

I write a blog post on git and GitOps every week.

• Subscribe to my Medium publishes to get notified when a new Git Weekly issue is published.
• Follow me on Twitter for more updates and articles published on other platforms.