Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Catalog discovered SBOMs #737

Open
wagoodman opened this issue Jan 6, 2022 · 3 comments
Open

Catalog discovered SBOMs #737

wagoodman opened this issue Jan 6, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@wagoodman
Copy link
Contributor

What would you like to be added:
If a container image (or directory) being scanned contains an SBOM it would be interesting to consider taking additional actions based on detecting that it's an SBOM. These actions might be:

  • merge the discovered SBOM with the current SBOM being created
  • additionally output the discovered SBOM and create a relationship between the two
  • summarize the SBOM in a subsection of the SBOM being created
  • another option?

This would give syft a more intelligent avenue for SBOM data discovered other than reporting it as "another file" discovered within the scanned source.

Why is this needed:
This could play into #31 , but that is not clear yet.

Additional context:
If a "merge" of the discovered SBOM and the current SBOM is selected, it is important to be transparent about which packages were not directly detected by a package cataloger and which were (and specifically, which SBOM file each package came from). Additionally, if the merge path is detected this has certain implications about the ID-system for packages (there may be overlap in IDs used, which can get complicated fast).

@wagoodman wagoodman added the enhancement New feature or request label Jan 6, 2022
@bureado
Copy link
Contributor

bureado commented Jan 8, 2022

Built-Using comes to mind as a readily available attribute that indicates a software component of interest that is unlikely to be present at the time of scanning a binary artifact and that might be in the user's best interest to see in the resulting SBOM, see #572 (comment). That's for "system" components. Clearly this has an even wider applicability for application components, e.g., a build system that outputted a binary and an SBOM for said binary and placed both in the image that syft will scan; in such a scenario it might be safer to assume that the user wants the resulting SBOM to collate the results. As discussed in #31 and other places, the big question is what are the input formats of those hints, because in general the build systems and tooling that output such SBOMs aren't doing so in SPDX or Cyclone (although that's rapidly changing and in general we should expect that to be the norm soon) I'm talking particularly about https://reproducible-builds.org/docs/recording/ and for example the output of tools such as TestifySec's witness or basically any CI/build system-attached recorders that might output supply chain-relevant information.

@samj1912
Copy link
Contributor

Dependent upon implementation of decoders for all the SBOM formats the syft supports.

CycloneDX -> #811
SPDX -> #738

@tofay
Copy link
Contributor

tofay commented Jun 9, 2022

a build system that outputted a binary and an SBOM for said binary and placed both in the image that syft will scan; in such a scenario it might be safer to assume that the user wants the resulting SBOM to collate the results

Yes, I'd like syft to support cataloguing SBOMs for this reason. Go binaries have a solution here via the Go binary cataloguer. But for other languages like Rust/C++ dependency information isn't inspectable from the binaries. For containerized Rust applications I want to drop an SBOM into the container image and have syft detect the Rust dependencies from that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: No status
Development

No branches or pull requests

4 participants