Buildroot can generate a CycloneDX SBOM from its show-info output, and make pkg-stats reports whether known CVEs affect packages in your current configuration. Together they give an embedded Linux team a component list and a first vulnerability view, without a separate scanner, for everything Buildroot itself builds.
The three tools in the manual
The Buildroot manual describes these pieces.
- make pkg-stats produces HTML and JSON details about packages. The details include whether known CVEs affect the packages in your current configuration, and whether a newer upstream version exists.
- make show-info prints a JSON description of the enabled packages with dependencies and licenses. The show-info-all variant covers every package regardless of configuration, which the manual points to for jobs such as a full-tree SBOM.
- CycloneDX SBOM generation builds on show-info output. The manual says the SBOM can be enriched with vulnerability analysis from the NVD database using the support/scripts/cve-check script.
A practical flow
- Finish a clean build of your release configuration.
- Run show-info and keep the JSON as a build artifact.
- Generate the CycloneDX SBOM from it and store it with the firmware image and its version.
- Run pkg-stats and review which packages have CVEs and which have newer releases.
- Triage. Record which findings apply, which are patched in your tree, and which do not affect your configuration.
What it does not see
The tooling knows what Buildroot builds. Anything outside that is invisible to it: a vendor binary blob copied into the root filesystem, a library dropped into an overlay directory, or application code your team wrote that embeds third-party sources. Add those to your inventory by hand, with a name, version and source, so the SBOM stays honest.
| Component type | Covered by Buildroot output |
|---|---|
| Packages built by Buildroot | Yes |
| Files copied by overlays or post-build scripts | No |
| Vendor SDK libraries and blobs | No, add manually |
Keep it with the release
Store the SBOM with the exact firmware version. Months later, when a customer asks whether a new CVE affects the unit in the field, you need the list for that build, not today's configuration.
Where Safeguard fits
If you want an inventory your reviewers can query, Safeguard offers SBOM and dependency scanning with policies and gates on pull requests. It works from the source and manifests it supports. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Look at how a component list is organized by name, version and source, then think about which of your own entries would be missing from a Buildroot export.
Click through it at your own pace, or open it full screen.
Quick check
Is the Buildroot CVE report the final word?
No. It is a first pass based on NVD data. Someone still has to decide whether each finding applies to your configuration and record the decision.
Which SBOM format does Buildroot produce?
The manual describes CycloneDX output generated from the show-info data.
Sources
Last reviewed: 19 October 2026.
