Closed captn3m0 closed 1 year ago
@captn3m0 for python and busybox detection try running the power-user
command provided by syft. This will execute the classifier
path and should give you detection for things like python
go
and busybox
.
Example: syft power-user library/python:3-slim
The results should be under classifications
.
I'll take a look at the other reports from this issue as well.
The power-user
command is helpful, but since the data is missing in the SBOM, every other tool now needs to build in custom tooling. Anything relying on the standard SBOM formats will miss out on these critical dependencies.
Perhaps classifiers should provide a template alongside that can be included in the BOM?
For eg, "python-binary","3.10.7"
from the classification could translate down to pkg:generic/python@3.10.7
I re-ran the images against the power-user
command, and the results are slightly better. There's some incorrect detections for python binaries, but that's expected with heuristic matching. Doesn't look like it picked up anything extra beyond Python, Go and Busybox however - since that's all the classifiers detect today
Here's the output from the important ones:
Scanning python:3-slim
"cpython-source","3.10.7"
"python-binary","3.10.7"
Scanning python:3-alpine
"busybox-binary","1.35.0"
"cpython-source","3.10.7"
"python-binary","3.10.7"
Scanning python:2
"cpython-source","2.7.18"
"python-binary","2.7.16"
"python-binary","2.7.18"
"python-binary","3.7.3"
Scanning python:3
"cpython-source","3.10.7"
"python-binary","3.10.7"
"python-binary","3.9.2"
Scanning busybox:1.35-musl
"busybox-binary","1.35.0"
Scanning busybox:1.35-musl
"busybox-binary","1.35.0"
Scanning busybox:stable
"busybox-binary","1.34.1"
Scanning golang:alpine
"busybox-binary","1.35.0"
"go-binary","1.1"
"go-binary-hint","1.19.1"
Scanning golang:buster
"go-binary","1.1"
"go-binary-hint","1.19.1"
"python-binary","2.7.16"
FWIW, both of those Python versions that "work" are picking up the distro build of Python, not the Python that's first in the path / intentionally provided by the image (instances of https://github.com/docker-library/python/issues/744, essentially) -- because they're the non-slim "batteries included" images, some of the "batteries" in their base layer use Python so it gets included via the distro (and that's somewhat dangerous for us to override/remove) :disappointed:
Hi @captn3m0, I'm looking at some old issues and I have spot-checked a few of these with the latest version of Syft, and I believe we have solved most of these problems. I'll close this issue but if you run into any other missing packages, please go ahead and open a new issue and we can look into it. Thank you!
Double checked all of the above, and filed #1963.
What happened:
Docker official images are highly used across the ecosystem, but since these images involve a lot of custom source-installed software, instead of package managers, a lot of these components are undetected by Syft. These are critical foundational dependencies that are getting missed.
What you expected to happen: Syft should detect foundational packages via other means.
How to reproduce it (as minimally and precisely as possible): Run some scans on docker official images and validate whether the primary dependency is picked up. Examples:
Python
None of these detects the version of Python installed:
python:3-slim ❌
python:3-alpine ❌
python:2 ✔️
This one does work (Partial output)
python:3 ✔️
Busybox ❌
None of these discovers busybox as installed:
Redis ❌
None of the following picks up Redis:
Nodejs ❌
None of the following picks up Nodejs
Traefik ❌
Picks up incorrect version
httpd ❌
Neither of these picks up httpd/apache:
memcached ❌
None of these picks up memcached
Golang ❌
Consul ❌
It does report some versions, but all are incorrect
Correct version is 1.13:
Nextcloud ❌
Influxdb ❌✔️
Detected in the debian version, not in the alpine one.
Wordpress ❌
Not detected.
Ruby ❌
None of the Ruby images detect ruby
Haproxy ❌
PHP ❌
Bash ❌
Vault ❌
Detects wrong version.
Anything else we need to know?: I picked the first 30 or so images from https://hub.docker.com/search?image_filter=official&q= for the survey. The ones that get detected are either using a package manager properly (mariadb, mysql) or built as java archives which are detected easily outside the package managers (such as tomcat or sonarqube).
Python/PHP/Ruby/Node/Golang are arguably the most depended upon base images, and
syft
should detect the primary dependency in these images.Usage Context
This request comes via the endoflife.date project, where we are working towards detecting EOL products by scanning SBOMs. The plan is to "leave the detection the existing SBOM ecosystem" (ie, products like syft), while we can provide feeds/PURLs/scanners to actually find EOL products in existing SBOMs.
Unfortunately, the most common usecase for eol checks (Programming Language EOL) is not met by syft, hence this issue.