Catalog discovered SBOMs

[wagoodman]

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).

[bureado]

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.

[sambhav]

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

CycloneDX -> #811
SPDX -> #738

[tofay]

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.

[sethmlarson]

This feature would add automatic support for Python virtual environments (according to PEP 770) for installed packages with SBOM(s) stored at package_name.dist-info/sboms/*.