Go: list vendored modules in show-info and the SBOM

The SBOM only listed Go packages as a whole, the modules vendored into them were invisible to CVE scanners. Read them from the build info the Go toolchain embeds in each binary, so the list matches what ships.

Signed-off-by Mattias Walström <[email protected]>

---
 package/pkg-golang.mk           |  8 ++++
 package/pkg-utils.mk            |  7 ++++
 support/scripts/go-modules-info | 67 +++++++++++++++++++++++++++++++++
 3 files changed, 82 insertions(+)
 create mode 100755 support/scripts/go-modules-info

package/pkg-golang.mk +8 -0

index cf12dd56b0..043efc94bd 100644
@@ -206,6 +206,14 @@ define $(2)_INSTALL_CMDS
 endef
 endif
 
+# Record the Go modules linked into the built binaries, for show-info
+define $(2)_GO_MODULES_INFO
+	$$(Q)$$(TOPDIR)/support/scripts/go-modules-info --go $$(GO_BIN) \
+		-o $$(@D)/$$(PKG_VENDORED_DEPS_FILE) \
+		$$$$(find $$(@D)/bin -maxdepth 1 -type f 2>/dev/null)
+endef
+$(2)_POST_BUILD_HOOKS += $(2)_GO_MODULES_INFO
+
 # Call the generic package infrastructure to generate the necessary make
 # targets
 $(call inner-generic-package,$(1),$(2),$(3),$(4))

package/pkg-utils.mk +7 -0

index 17b0aa1760..21b434c6bd 100644
@@ -111,6 +111,10 @@ define json-info
 	}
 endef
 
+# File in a package build directory listing the dependencies vendored into
+# it, as a JSON list of {name, version, purl}, added to show-info when present
+PKG_VENDORED_DEPS_FILE = .br_vendored_dependencies.json
+
 # _json-info-pkg, _json-info-pkg-details, _json-info-fs: private helpers
 # for json-info, above
 define _json-info-pkg

@@ -210,6 +214,9 @@ define _json-info-pkg-details
 			$(call mk-json-str,$(patsubst $(CONFIG_DIR)/%,%,$(patch)))$(comma) \
 		)
 	],
+	$(if $(wildcard $($(1)_DIR)/$(PKG_VENDORED_DEPS_FILE)), \
+		"vendored_dependencies": $(shell cat $($(1)_DIR)/$(PKG_VENDORED_DEPS_FILE))$(comma) \
+	)
 	$(if $($(1)_PROVIDES), \
 		"provides": [ \
 			$(foreach provide, \

support/scripts/go-modules-info new file +67 -0

new file mode 100755
index 0000000000..476a4de333
@@ -0,0 +1,67 @@
+#!/usr/bin/env python3
+"""List the Go modules linked into a set of Go binaries.
+
+Reads the build info that the Go toolchain embeds in every binary
+(go version -m -json) and writes the third-party modules, deduplicated
+across binaries, as a compact JSON list. Modules replaced by a local
+directory are part of the package source and are left out.
+
+Each entry has the name, version and purl of the module that was built.
+When a replace directive swapped in another module, the original is
+recorded under "replaces".
+"""
+
+import argparse
+import json
+import subprocess
+import sys
+import urllib.parse
+
+
+def purl(path, version):
+    segments = [urllib.parse.quote(s, safe="") for s in path.split("/")]
+    return f"pkg:golang/{'/'.join(segments)}@{urllib.parse.quote(version, safe='')}"
+
+
+def is_local(path):
+    return path.startswith(("./", "../", "/"))
+
+
+def module(path, version):
+    return {"name": path, "version": version, "purl": purl(path, version)}
+
+
+def binary_deps(go, binary):
+    out = subprocess.run([go, "version", "-m", "-json", binary],
+                         check=True, capture_output=True, text=True).stdout
+    return json.loads(out).get("Deps") or []
+
+
+def main():
+    parser = argparse.ArgumentParser(description=__doc__,
+                                     formatter_class=argparse.RawDescriptionHelpFormatter)
+    parser.add_argument("--go", required=True, help="Path to the go tool")
+    parser.add_argument("-o", "--output", required=True, help="Output JSON file")
+    parser.add_argument("binaries", nargs="*", help="Go binaries to inspect")
+    args = parser.parse_args()
+
+    modules = {}
+    for binary in args.binaries:
+        for dep in binary_deps(args.go, binary):
+            repl = dep.get("Replace")
+            if repl:
+                if is_local(repl["Path"]):
+                    continue
+                entry = module(repl["Path"], repl["Version"])
+                entry["replaces"] = module(dep["Path"], dep["Version"])
+            else:
+                entry = module(dep["Path"], dep["Version"])
+            modules[entry["purl"]] = entry
+
+    with open(args.output, "w") as f:
+        json.dump([modules[k] for k in sorted(modules)], f, separators=(",", ":"))
+        f.write("\n")
+
+
+if __name__ == "__main__":
+    sys.exit(main())

Signature · 6 lines

2.43.0

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

Hi Mattias,

I haven't totally check the series yet but during the ELCE2026 Buildroot dev meeting we have discussed this issue. Go is not the only case this would be
required: Rust, the kernel, potentially NPM packages and other standalone packages that support generating an SBOM (such as wolfssl, brotli, ...) would also benefit from a proper SBOM generation support.

The idea was to add a "<pkg>_SBOM" step to the generic package infrastructure so we can both have something shared per infra such as Go and individual package implementing their own procedure.

There are still some missing links before we move forward this way:

- How do we support the variety of SBOM format (CycloneDX, SPDX, compilation database)
- Do we include in the CycloneDX SBOM or just reference it ?

Some question for you for the Go case:

- Would it make sense to use the utility CycloneDX maintain for Go instead [1] ? If we go with the "<pkg>_SBOM" step I described it's something we could add to the dependencies. And Rust packages could also use the CycloneDX utility for Rust.
- Can you compare the output of this utility to the one you propose so we can better assess the pros and cons ?

[1] https://github.com/CycloneDX/cyclonedx-gomod

Quoted 7 lines · Thomas Perale via buildroot

Hi Mattias,

I haven't totally check the series yet but during the ELCE2026 Buildroot dev meeting we have discussed this issue. Go is not the only case this would be
required: Rust, the kernel, potentially NPM packages and other standalone packages that support generating an SBOM (such as wolfssl, brotli, ...) would also benefit from a proper SBOM generation support.

Hi Thomas,

Thanks for the context from the dev meeting, I wasn't aware of the discussion. A generic SBOM step sounds like the right place for this, and I'm happy to rework the series in whatever direction you settle on.

Quoted 3 lines

The idea was to add a "<pkg>_SBOM" step to the generic package infrastructure so we can both have something shared per infra such as Go and individual package implementing their own procedure.

If it helps, the series is already split along those lines: a post-build hook in pkg-golang.mk writes the module list to the build directory, and generate-cyclonedx only reads a generic "vendored_dependencies" field from show-info. Turning the hook into a $(2)_SBOM_CMDS step in pkg-generic with pkg-golang providing the default should be straightforward, and other infras could fill the same field.

Quoted 5 lines

There are still some missing links before we move forward this way:

- How do we support the variety of SBOM format (CycloneDX, SPDX, compilation database)
- Do we include in the CycloneDX SBOM or just reference it ?

I don't have a strong opinion. What the series does is record facts (name, version, purl) in show-info and leave the format to the generator, which keeps SPDX possible later. For packages that produce a complete SBOM themselves (wolfssl, brotli), referencing it from the package component seems simpler than merging, but I haven't tried.

Quoted 8 lines

Some question for you for the Go case:

- Would it make sense to use the utility CycloneDX maintain for Go instead [1] ? If we go with the "<pkg>_SBOM" step I described it's something we could add to the dependencies. And Rust packages could also use the CycloneDX utility for Rust.
- Can you compare the output of this utility to the one you propose so we can better assess the pros and cons ?

I hadn't looked at cyclonedx-gomod before, so I tried it. I ran "cyclonedx-gomod bin" (v1.12.0) on the Go binaries of an Infix [2] build (x86_64) and compared it with what this series records for the same packages:

package binaries cyclonedx-gomod this series
podman 3 164 164

  cni-plugins      17          14              14
  yangerd           2          11              10
  webui             1           3               2
  netbrowse         1           0               0

Both read the build info Go embeds in the binary (go version -m), so the module lists come out the same. The differences I found:

- podman: "+incompatible" versions. The series percent-encodes the "+" in the purl, cyclonedx-gomod leaves it as is.
- yangerd, webui: cyclonedx-gomod emits "pkg:golang/../features@(devel)" for a "replace ... => ../features" directive. The series skips local replacements since that code is part of the package source. I may be wrong that skipping is the right call.
- webui: the series records github.com/openconfig/goyang as pedigree.ancestors of the github.com/kernelkit/goyang fork that replaces it. cyclonedx-gomod reports only the fork.

Things cyclonedx-gomod can do that the series cannot: module hashes and license detection. The hashes were empty in all 181 components here, as Go doesn't record them for -mod=vendor builds. License detection needs every module in the module cache; in our case the cache is only filled when go-post-process runs on the same machine, so with a populated DL_DIR or a mirror it would need to download the modules again at SBOM time. I don't record licenses either, so neither approach gives us that today.

Practical differences: cyclonedx-gomod produces one document per binary, so we would need to merge and deduplicate per package ourselves (cni-plugins has 95 components for 14 modules), and it would be a new host package that follows the latest Go release. The series is a small Python script using the host go we already build, and it stores the result in show-info rather than in CycloneDX directly. On the other hand cyclonedx-gomod is maintained by the CycloneDX project, and if Rust and others end up using the CycloneDX tools as well, consistency may matter more than the points above.

Let me know what you'd like to see in a v2.

Quoted 1 line

[1] https://github.com/CycloneDX/cyclonedx-gomod

[2] https://github.com/kernelkit/infix

Best regards,
Mattias
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot