RFC: cargo-sbom by arlosi · Pull Request #3553 · rust-lang/rfcs (original) (raw)

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

arlosi added the T-cargo

Relevant to the Cargo team, which will review and decide on the RFC.

label

Jan 4, 2024

arlosi changed the titleAdd new RFC cargo-sbom RFC: cargo-sbom

Jan 4, 2024

Comment on lines 47 to 49

Comment on lines 63 to 66

Comment on lines 48 to 51

Comment on lines 25 to 30

epage mentioned this pull request

Jan 13, 2024

Comment on lines 25 to 30

epage mentioned this pull request

Apr 29, 2024

This comment was marked as duplicate.

Comment on lines +66 to +67

epage mentioned this pull request

May 21, 2024

This was referenced

Jul 20, 2024

tmpfs mentioned this pull request

Jul 30, 2024

cho-m mentioned this pull request

Sep 22, 2024

1 task

github-merge-queue bot pushed a commit to rust-lang/cargo that referenced this pull request

Feb 26, 2025

What does this PR try to resolve?

This PR is an implementation of RFC 3553 to add support to generate pre-cursor SBOM files for compiled artifacts in Cargo.

How should we test and review this PR?

The RFC 3553 adds a new option to Cargo to emit SBOM pre-cursor files. A project can be configured either by the new Cargo config field sbom.

# .cargo/config.toml
[build]
sbom = true

or using the environment variable CARGO_BUILD_SBOM=true. The sbom option is an unstable feature and requires the -Zsbom flag to enable it.

Check out this branch & compile Cargo. Pick a Cargo project to test it on, then run:

CARGO_BUILD_SBOM=true <path/to/compiled/cargo>/target/debug/cargo build -Zsbom

All generated *.cargo-sbom.json files are located in the target folder alongside their artifacts. To list all generated files use:

find ./target -name "*.cargo-sbom.json"

then check their content. To see the current output format, see these examples.

What does the PR not solve?

The PR leaves a task(s) open that are either out of scope or should be done in a follow-up PRs.

• does not address #6313 (see [comment](#13709 (comment)))

Additional information

There are a few things that I would like to get feedback on, in particular the generated JSON format is not final. Currently it holds the information listed in the RFC 3553, but it could be further enriched with information only available during builds.

During the implementation a number of questions arose:

• Should the graph be packages or crates?
• The unit graph that the SBOM is based on is units. The current SBOM graph is identical to the unit graph, with the run build script nodes merged with building build scripts.
  • Artifact dependencies may impact this
• Which outputs should get SBOMs files?
• Currently: executables (including examples and tests), dylib, cdylib, staticlib
• How do we refer to "normal" dependencies? #13709 (comment)
• What case should we use? #13709 (comment)
• Should this be build.sbom or profile.*.sbom
• Is sbom the right name for this?

Thanks @arlosi, @RobJellinghaus and @lfrancke for initial guidance & feedback.

• RFC: #rust-lang/rfcs/pull/3553