Dependency graph of BOMs generated with Syft is incomplete due to missing root node

[t-k-u]

What happened:
After uploading SBOMs in Dependency Track (v4.11.5), created by syft, we encountered the problem that the dependency graphs could not be displayed.

We tested it with the latest alpine version:

This results in the following SBOM
sbom_diy.json

The logs do not include anything noticeable:

What you expected to happen:
A complete (displayable) Dependency Graph

Steps to reproduce the issue:

1. Create SBOM - run: docker pull alpine:latest

• name: Generate SBOM
  run: |
  ${{ runner.temp }}/syft/syft alpine:latest -o cyclonedx-json=sbom_diy.json
  env:
  PATH: ${{ runner.temp }}/syft:$PATH

2. Upload SBOM to DT using

• name: Upload SBOM to Dependency Track using curl
  run: |
  curl -X "POST" "DTINSTANCELINK/api/v1/bom"
  -H "Content-Type: multipart/form-data"
  -H "X-Api-Key: working API KEY"
  -F "autoCreate=true"
  -F "projectName=DIY_test_image_alpine"
  -F "projectVersion=1"
  -F "bom=@sbom_diy.json"

Anything else we need to know?:
We already created an issue for Dependency Track. It was determined that it is not a problem in DT, but in the SBOM itself, as it has a missing root.

Environment:

• Output of syft version: v1.9.0
• OS (e.g: cat /etc/os-release or similar): -

[willmurphyscode]

Hi @t-k-u thanks for the issue! We'll try to discuss this at an upcoming community meeting. In general, Syft doesn't guarantee that there will always be a root package because Syft doesn't assume that the thing scanned is a single artifact. For example, what is the "root" of alpine:latest? There are a number of packages with their own dependency graphs.

[willmurphyscode]

@t-k-u when scanning alpine:latest as you did here, what would you expect the root of the dependency graph to be?

[t-k-u]

Without any expertise, but my expectation would be that alpine is the root, if alpine as a "package" is the source of the SBOM.

[kzantow]

Hey @t-k-u, we discussed this issue this week on the livestream and we think it would be ok to add an option for Syft to generate these dependencies and add them to CycloneDX output.

As has been discussed elsewhere, we do not believe it is accurate to include dependency relationships in this case, but CycloneDX does not provide any other relationship types that would be more appropriate (such as CONTAINS). However, this is clearly a cause of friction for users, so I think it would be ok to add an option to enable this behavior of adding dependency relationships from the metadata.component to the appropriate top-level package components.

Note for anyone implementing this -- the encoders have configurations that it would be simple to pass options for, see here: https://github.com/anchore/syft/blob/main/syft/format/encoders.go#L36-L53.

Other note: CycloneDX allows for nesting of components. It is possible a better/more accurate solution would be to nest all components in the metadata.component.components, but this has the potential to prevent other tools from properly reading the Syft generated files, too.

[m4nch0t]

Hello,
Any update? It should be a lovely feature for my point of view. Don't really know why there is frictions ¯_(ツ)_/¯

[willmurphyscode]

Hi @m4nch0t - thanks for the ping!

It seems like @kzantow 's comment resolves the remaining friction. This is in our ready column and anyone is welcome to work on it! We just haven't been able to pick it up yet amid other priorities.

Am I right in understanding that this blocks using Dependency Track with Syft-generated CycloneDX JSON? If so I agree that this is fairly high priority. I don't know Dependency Track well. Are there any workarounds you can use in the meantime?

[turing85]

Hi!
No, this does not block the usage of dependency-track. It hinders, however, the user experience. Dependency-track can show the components of an SBOM (i.e. the "installed packages", this is working as far as I can tell). From there, one has a link to this component in the dependency graph. This is currently not working.

This might not sound like much. However, it gets interesting when we merge two SBOMs - say one for the base container, and one for the artifact copied in the container - into a singular SBOM. In this case, it would be nice to know if a component is used by the base container or the artifact (in short: do we need to update the container, or the software component?)