Description
Today, when generating an SBOM for a container image, you get something like the following.
$ bom generate \
-a \
--format json \
--scan-images \
-i registry.k8s.io/kube-apiserver:v1.28.2 \
-o kapi.spdx.json
$ bom document outline kapi.spdx.json
_
___ _ __ __| |_ __
/ __| '_ \ / _` \ \/ /
\__ \ |_) | (_| |> <
|___/ .__/ \__,_/_/\_\
|_|
📂 SPDX Document SBOM-SPDX-79a7e3e3-88ca-4e11-8d0b-45d6bc0f55ad
│
│ 📦 DESCRIBES 1 Packages
│
├ registry.k8s.io/kube-apiserver@sha256:6beea2e5531a0606613594fd3ed92d71bbdcef99dd3237522049a0b32cad736c
│ │ 🔗 4 Relationships
│ ├ CONTAINS PACKAGE registry.k8s.io/kube-apiserver@sha256:07ec0f29e172784b9fda870d63430a84befade590a2220c1fcce52f17cd24631
│ │ │ 🔗 12 Relationships
│ │ ├ CONTAINS PACKAGE sha256:a7ca0d9ba68fdce7e15bc0952d3e898e970548ca24d57698725836c039086639
│ │ ├ CONTAINS PACKAGE sha256:fe5ca62666f04366c8e7f605aa82997d71320183e99962fa76b3209fdfbb8b58
│ │ ├ CONTAINS PACKAGE sha256:b02a7525f878e61fc1ef8a7405a2cc17f866e8de222c1c98fd6681aff6e509db
│ │ ├ CONTAINS PACKAGE sha256:fcb6f6d2c9986d9cd6a2ea3cc2936e5fc613e09f1af9042329011e43057f3265
│ │ ├ CONTAINS PACKAGE sha256:e8c73c638ae9ec5ad70c49df7e484040d889cca6b4a9af056579c3d058ea93f0
│ │ ├ CONTAINS PACKAGE sha256:1e3d9b7d145208fa8fa3ee1c9612d0adaac7255f1bbc9ddea7e461e0b317805c
│ │ ├ CONTAINS PACKAGE sha256:4aa0ea1413d37a58615488592a0b827ea4b2e48fa5a77cf707d0e35f025e613f
│ │ ├ CONTAINS PACKAGE sha256:7c881f9ab25e0d86562a123b5fb56aebf8aa0ddd7d48ef602faf8d1e7cf43d8c
│ │ ├ CONTAINS PACKAGE sha256:5627a970d25e752d971a501ec7e35d0d6fdcd4a3ce9e958715a686853024794a
│ │ ├ CONTAINS PACKAGE [email protected]
│ │ ├ CONTAINS PACKAGE sha256:6021ef4e32c708f4759a7292b12fa3bb2999cedadbfad2e5c75ed0e08f471f9a
│ │ │ │ 🔗 3 Relationships
│ │ │ ├ CONTAINS PACKAGE [email protected]+deb11u7
│ │ │ ├ CONTAINS PACKAGE [email protected]
│ │ │ └ CONTAINS PACKAGE tzdata@2021a-1+deb11u10
│ │ │
│ │ └ VARIANT_OF PACKAGE registry.k8s.io/kube-apiserver@sha256:6beea2e5531a0606613594fd3ed92d71bbdcef99dd3237522049a0b32cad736c
│ │
Note that only the OS package database is analyzed, even though there are Go binaries go-runner
and /usr/local/bin/kube-apiserver
with their own dependencies.
When running go version -m
, go will analyze module information baked into the binary. This functionality is facilitated by debug/buildinfo.ReadFile()
in the standard library which returns a *runtime/debug.BuildInfo{}
.
What would you like to be added:
While it would not be as complete as the current go.mod
analyzer, it'd be nice to be able to analyze local files or files within an image specified like bom generate -i $IMAGE --scan-images -f /go-runner -f /usr/local/bin/kube-apiserver
to check if they're go binaries and get the module information.
Why is this needed:
If I'm a user scanning an image with a Go binary that has module information, I'd like to know the module version information in my SBOM