Feature Proposal: Make it possible to correlate package/component dependencies

[cookiengineer]

Currently, components can only be listed without their correlations to each other. For a lot of scenarios though, it would be better to have a structured relationship and dependency that needs to be analyzed.

The problem I'm talking about are package managers on *nix systems that don't have a strict consumer/provider concept (like pacman has) but offer a more complex alternative to the dependency that's required.

For example, Debian and Ubuntu's dpkg-based package managers offer a format like this:

Name: package-example
Depends: library3 | library-component (<< 3), library:any

The issue with this is that the logical condition cannot be reflected in the SBOM, and it is necessary to figure out potential pitfalls in automated update scenarios. The above example implies that there needs to be the following logical condition of the example package's dependencies:

• depend either on library3 or library-component before version 3
• depend on library (any version)

This scenario implies that the upstream library decided to include the library-component starting from version 3 in their set of core packages. I'm picking this specific example, because it happens a lot of time in the python ecosystem, and it's necessary to have the logical relationships between the packages and the actually required components in order to figure out an educated mitigation strategy if the component is affected by a vulnerability.

Additionally, this would help clear up all the pitfalls that are currently happening when an SBOM is generated that contains virtual packages or strictly virtual packages in the Debian ecosystem. Those packages are offered not by the package identifiers themselves, but as a separate identifier.

For example, the dbus package also has Provides: default-dbus-system-bus, dbus-system-dbus fields which a lot of other packages rely on as their dependencies. This scenario is currently also impossible to mitigate with the current SBOM structure of the components.

What are your thoughts on this?

[jkowalleck]

my thoughts:

[...] it's necessary to have the logical relationships between the packages and the actually required components in order to figure out an educated mitigation strategy if the component is affected by a vulnerability.

My understanding: Since an SBOM is about facts (what is there?) and not about replacing an ecosystem's own manifest and resolution process (what could be there?), I don't see much value in reflecting ALL possibilities a ecosystem COULD resolve the dependency tree. It you need to (like for evidence reasons), you still can do this with ecosystem-specific properties ala https://github.com/CycloneDX/cyclonedx-property-taxonomy If you need to mitigate this, you should consult the actual ecosystem that does the resolution, not an SBOM.

re: components correlations

Currently, components can only be listed without their correlations to each other. For a lot of scenarios though, it would be better to have a structured relationship and dependency that needs to be analyzed.

Did you mean a dependency graph? Like https://cyclonedx.org/use-cases/#dependency-graph? If you turn this "consumer/provider" around, so it becomes a fact-based system, rather than a optortunity-based system, then a dependency graph could work for you.

re: Provides

For example, the dbus package also has Provides: default-dbus-system-bus, dbus-system-dbus fields which a lot of other packages rely on as their dependencies. This scenario is currently also impossible to mitigate with the current SBOM structure of the components.

I would suggest to have the "provides" as a property ala https://github.com/CycloneDX/cyclonedx-property-taxonomy, because its internal meaning, usage and so on are owned by each individual ecosystem. (for example php's composer knows that concept, too, but it might implement it similar but different)

conclusion:

That all said, it appeared to me, that there are already structures in CycloneDX that can be used to model your needs. The following could be an SBOM that is already with today's specification:

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.4">
    <metadata>
        <component type="operating-system" bom-ref="my-sys">
            <name>my OS</name>
        </component>
    </metadata>
    <components>
        <component type="application" bom-ref="package-example">
            <name>package-example</name>
        </component>
        <component type="library" bom-ref="library-component">
            <name>library3</name>
            <version>2.1.0</version>
        </component>
        <component type="library" bom-ref="library">
            <name>library</name>
        </component>
        <component type="library" bom-ref="dbus-system-dbus">
            <name>dbus-system-dbus</name>
            <properties>
                <property name="myNS:pacman:package:virtual">true</property>
            </properties>
        </component>
        <component type="application" bom-ref="dbus">
            <name>dbus</name>
            <properties>
                <property name="myNS:pacman:package:provides">default-dbus-system-bus</property>
                <property name="myNS:pacman:package:provides">dbus-system-dbus</property>
            </properties>
        </component>
    </components>
    <dependencies>
        <dependency ref="my-sys">
            <dependency ref="package-example"/>
        </dependency>
        <dependency ref="package-example">
            <dependency ref="library-component"/>
            <dependency ref="library"/>
        </dependency>
        <dependency ref="library-component"/>
        <dependency ref="library">
            <dependency ref="dbus-system-dbus"/>
        </dependency>
        <dependency ref="dbus-system-dbus">
            <dependency ref="dbus" />
        </dependency>
        <dependency ref="dbus"/>
    </dependencies>
</bom>