Exploring The Best SBOM/SCA Tools: Docker Scout
SBOMs (software bill of materials) and SCA (software composition analysis) reports are critical for maintaining applications, providing visibility into dependencies, and complying with regulations. However, choosing the best SCA tools for your needs can be challenging, as can managing SCA and SBOM security results.
Docker Scout is an excellent SBOM/SCA tool supported by Docker, that enables teams to detect potential software vulnerabilities in any docker image they rely on—whether it is developed by them, external vendors, or any other source.
While Docker Scout is great for detecting vulnerable packages, as with all SBOM/SCA tools, not all issues identified are real, meaning not all issues are exposed on the attack surface. That’s where solutions like Mayhem come in. By analyzing runtime behavior, Mayhem adds a layer of insight that static SBOM tools can’t match by themselves: identifying which vulnerabilities are definitely reachable and exploitable.
In this post, we’ll explore Docker Scout’s strengths and weaknesses, put it to the test, and combine Docker Scout with Mayhem Dynamic SBOM to automatically identify findings that are observed at runtime.
Why is Docker Scout A Great SBOM Solution?
If you need an SBOM/SCA solution, Docker Scout is a great option, and here's why:
- Tight and simple integration with your container runtime / stack. If you are a Docker user, installing scout is as simple as running a curl command.
- Docker Scout provides SBOM and SCA reports in all standardized formats including SPDX and SARIF along with all vulnerability details and severity level info most security teams need.
- Outstanding ecosystem support like the docker scout GitHub Action workflow, that is highly customizable, with an extremely easy-to-use interface and beautiful reporting that even includes remediation suggestions.
We have found that Docker Scout is a fantastic tool to work with from a UI/UX perspective. The only frustration - as with most SBOM/SCA tools - was that several of the findings were about components not observed at runtime. Can this be improved? This is what we'll look into in the next section with Mayhem Dynamic SBOM.
Mayhem Dynamic SBOM: Building on top of Docker Scout
Mayhem Dynamic SBOM (MDSBOM) is an SBOM/SCA analysis tool that monitors application behavior and automatically identifies all packages and vulnerabilities that are observed at runtime. MDSBOM plugs into any SBOM/SCA tool (including Docker Scout) and enables teams to quickly identify which SBOM/SCA are actually observed.
For example, if you use a debian
image anywhere in production, you may have encountered the infamous CVE-2011-3374 apt vuln:
1$ docker scout cves debian:latest
2 ✓ Image stored for indexing
3 ✓ Indexed 125 packages
4 ✗ Detected 13 vulnerable packages with a total of 24 vulnerabilities
5...
6 0C 0H 0M 1L apt 2.6.1
7pkg:deb/debian/apt@2.6.1?os_distro=bookworm&os_name=debian&os_version=12
8
9 ✗ LOW CVE-2011-3374
10 https://scout.docker.com/v/CVE-2011-3374
11 Affected range : >=2.6.1
12 Fixed version : not fixed
13...
and you may have followed (if you haven't, consider yourself lucky) the thread that Debian is probably not going to fix it, which makes sense given that more than a decade has passed since it was reported. This finding is not unique. Security teams have to deal on a daily basis with images+packages that include 10 year old issues that are "won't fix" and provide reports that show these issues are remediated.
Worse, most likely the application you are developing does not even involve running the package manager with an attacker controlled payload, and the only reason apt
is part of the production image is for packaging purposes (how else can we install our packages?).
What if packages that are not loaded at runtime were automatically identified and prioritized based on reachability? What if Docker Scout could be even better and report only findings that are actually used by the application? Is such a thing possible?
By combining a runtime analysis tool like Mayhem's Dynamic SBOM with Docker Scout, we can:
- Prioritize better. Mayhem’s dynamic SBOM analysis flags all vulnerabilities that are observed at runtime, thus enabling teams to focus on the findings that matter first.
- Reduce false alarms. By focusing on observed findings, teams know that the vulnerabilities they are looking into are reachable, and thus less likely to be false alarms.
- Eliminate dead code. Do you see a package included in your static SBOM but not in your Mayhem DSBOM? That means you have a package that is unused in production. Remove it (if you can!), save on image size and also future SBOM reports. No code is the safest code! :)
Is that combination worth it though? What kind of findings reduction can we expect?
Enough, Show me the Code / Results!
We put the MDSBOM + Docker Scout combo to the test in a GitHub repo to scan images and see what kind of findings reduction we can expect. We used the combo to experiment on 5 of the most popular docker images (redis, nginx, httpd, rabbitmq, memcached) as well as a known vulnerable one (appsecco/dvna). Here's what SCA vulnerability results looked like:
We also used the same pipeline to visualize how many findings were observed vs unobserved according to MDSBOM:
There are two main observations we make from the above:
- dvna (Damn Vulnerable NodeJS Application) is not that bad - according to Docker Scout, findings seem to be on par with some of the most popular images used on the internet today(!) and
- Mayhem DSBOM detects that a significant percentage - ranging from 0% in nginx up to 67% in memcached - of all reported findings were never observed at runtime!
Put another way: using Mayhem, your team knows which 34% of findings are in code that is reachable by your application today and which 66% of findings belongs in potentially unreachable code that you can focus on removing!
Opening one of the SARIF reports for memcached inside Mayhem, we see a familiar finding suppressed as not observed in use at runtime:
1 "message": {
2 "text": " Vulnerability : CVE-2011-3374 \n Severity : LOW \n Package : pkg:deb/debian/apt@2.6.1?os_distro=bookworm&os_name=debian&os_version=12 \n Affected range : >=2.6.1 \n Fixed version : not fixed \n EPSS Score : 0.001640 \n EPSS Percentile : 0.535910 \n"
3 },
4 "ruleId": "CVE-2011-3374",
5 "ruleIndex": 4,
6 "suppressions": [
7 {
8 "justification": "The vulnerable component(s) have not been observed in use at runtime.",
9 "kind": "external",
10 "status": "underReview"
11 }
12 ]
This makes sense, default memcached should not invoke apt
at runtime and Mayhem was able to capture that behavior automatically! Based on that, we may want to remove apt
from the release image and never see this alert again in the future. On the other hand, you may still want a package managed in your production image (every team is different!), but at least Mayhem is pointing out that this package was never observed at runtime.
Conclusion
Docker Scout’s seamless integration with Docker workflows, standardized formats, and outstanding ecosystem support make it a standout choice for improving your container security posture. But why settle for fantastic when you can do even better?
By integrating Mayhem’s Dynamic SBOM, you can cut through the noise and get actionable results focused on the issues that truly matter. Achieving, on average, a 35% reduction in findings means fewer distractions, faster release cycles, leaner images, and more stable deployments.
Improve SBOM Management With Mayhem
Try Mayhem free today and see how runtime analysis can complement SBOM and SCA tools like Docker Scout to triage, prioritize, and reduce security alerts for your team.
All the code used above is available on GitHub - see something off? Send us a PR! Or give Docker Scout and Mayhem Dynamic SBOM a try on your images and let us know how it performed!
Add Mayhem to Your DevSecOps for Free.
Get a full-featured 30 day free trial.