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 go-runner@v2.3.1
│ │ ├ CONTAINS PACKAGE sha256:6021ef4e32c708f4759a7292b12fa3bb2999cedadbfad2e5c75ed0e08f471f9a
│ │ │ │ 🔗 3 Relationships
│ │ │ ├ CONTAINS PACKAGE base-files@11.1+deb11u7
│ │ │ ├ CONTAINS PACKAGE netbase@6.3
│ │ │ └ 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
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 go-runner@v2.3.1 │ │ ├ CONTAINS PACKAGE sha256:6021ef4e32c708f4759a7292b12fa3bb2999cedadbfad2e5c75ed0e08f471f9a │ │ │ │ 🔗 3 Relationships │ │ │ ├ CONTAINS PACKAGE base-files@11.1+deb11u7 │ │ │ ├ CONTAINS PACKAGE netbase@6.3 │ │ │ └ 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-runnerand/usr/local/bin/kube-apiserverwith their own dependencies.When running
go version -m, go will analyze module information baked into the binary. This functionality is facilitated bydebug/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.modanalyzer, it'd be nice to be able to analyze local files or files within an image specified likebom generate -i $IMAGE --scan-images -f /go-runner -f /usr/local/bin/kube-apiserverto 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