SBOM Dependency Tree is lost when importing and exporting

[christian.georg_5533]

Hi There,
I am currently evaluating ProGet for SBOM management and one of the things I have noticed is that proget is not creating a dependency tree showing which dependencies are direct dependencies and which dependencies are only transitive dependencies. When importing an SBOM including the dependencies and then exporting it again the dependency information is lost.

Am I doing something wrong here or is there no way to preserve the dependency information in the SBOM

Thanks
Chris

[Dan_Woolf]

Hi @christian-georg_5533,

Would you be able to provide us with an example SBOM file that we can test with?

Thanks,
Dan

[christian.georg_5533]

Hi Dan,
thanks for following this up. I cannot provide you with one of our internal SBOMs but I can replicate the same behaviour with external examples, likte the sbom postet here:
https://github.com/CycloneDX/bom-examples/blob/master/SBOM/keycloak-10.0.2/bom.json

This original SBOM has a dependencies secion showing the hierarchie of the packages and thus allowing us to distringuish between direct dependencies and transitive dependencies which cannot always be controlled in the way we would like to.

"dependencies": [
    {"ref": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.62?type=jar"},
    {"ref": "pkg:maven/org.bouncycastle/bcpkix-jdk15on@1.62?type=jar"},
    {"ref": "pkg:maven/org.jboss.logging/jboss-logging@3.4.1.Final?type=jar"},
    {"ref": "pkg:maven/com.sun.activation/jakarta.activation@1.2.1?type=jar"},
    {
      "ref": "pkg:maven/org.keycloak/keycloak-common@10.0.2?type=jar",
      "dependsOn": ["pkg:maven/com.sun.activation/jakarta.activation@1.2.1?type=jar"]
    },
    {"ref": "pkg:maven/com.fasterxml.jackson.core/jackson-core@2.10.1?type=jar"},
    {
      "ref": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.10.1?type=jar",
      "dependsOn": ["pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.10.1?type=jar"]
    },
...
]

When importing this section and exporting it from proget 2025.25 build 11 the complete dependencies section is missing and therefore any information on the dependency hierarchie.

Best regards

Chris

[atripp]

Hi @christian-georg_5533 ,

Thanks for sharing this; this behavior is expected.

ProGet is not a "SBOM Document Repository" (e.g. like Dependency Track), but instead models Projects & Builds for Software Composition Analysis (SCA). A Build is comprised of Packages (which should be stored in Feeds in ProGet), and "importing an SBOM document" is one way to create a build/package dataset.

Note that a build in ProGet will often be comprised of multiple SBOM documents, especially for web applications where like npm + .NET is used.

ProGet can "export" a build as an SBOM, and some of the information from the imported document will be used. However, our SCA model does not model a dependency tree, so it's not possible for this kind of information to be output or preserved.

That could be something we consider as a feature request, but we'd need to start with the "SCA model" (i.e. Builds + Packages) first, and try to understand why modeling a dependency tree relationship is beneficial.

The main idea I can think of is to "reduce noise from vulnerabilities", but that's a core feature of ProGet 2026 (upcoming!) so I'd check that out first, and see if it makes sense still.

Thanks,
Alana

[christian.georg_5533]

Hi Alana,
thanks for your response. The main beenfit of the depenency tree is to understand what needs to be done to get ridd of a certain component. If there is a component in your supply chain that you would like to get ridd of, then there is a big diference if this is a direct dependency that you included and that could possible be solved quite easily or if this is a component that is part of another direct dependecy (or even multiple other dependencies) where you would neet do remove the direct dependencie(s).

I do however understand from your response that keeping the dependency tree is not planned in the near future and that using ProGet as a central SBOM Repository to enable further workflows which need the dependency tree is not the way to go as the focus of Proget is the management of the feeds and providing validated and approved packages
Best regards
Chris

[atripp]

Hi @christian-georg_5533 ,

Thanks for sharing the additional context, that makes sense.

You are correct -- ProGet is a package repository with SCA as a value-added feature. Most of our users create SBOM because they are required to due to regulations, and but don't find much use outside of that :)

Of course we're always interested in expanding features but we aren't really striving for the "central SBOM Repository" use case now. We'll see if there's more demand down the line, feel free to share more information (other products, tools) sinc eit's always good to think about future versions of the product!

Cheers,
Alana