Add support for DEV_DEPENDENCY_OF Relationship in SPDX 2.2 SBOMs

[nschwerzler]

Description
Summary:
Request to add support for the DEV_DEPENDENCY_OF relationship type in accordance with the SPDX 2.2 specification.

Motivation:
Development dependencies (i.e., those only required for building, testing, or CI and not included in the released product) are already tracked by major package ecosystems (Nuget, NPM, Cargo, etc.) and are surfaced in their SBOM outputs. However, sbom-tool currently does not support emitting the DEV_DEPENDENCY_OF relationship type. As a result, SBOMs generated with sbom-tool do not fully represent the dependency graph and may mischaracterize development-only dependencies as runtime or production dependencies.

Benefits:

Accurate SBOMs: Ensures that SBOMs correctly distinguish between runtime and development dependencies per the SPDX 2.2.2 spec.

Better Security Validation: Allows our SBOM validation services to filter CVEs associated with development dependencies, reducing noise and more accurately highlighting OSS supply chain risks.

Ecosystem Alignment: Brings sbom-tool in line with the output of other major package managers and enables round-trip compatibility for dev dependency metadata.

Specification Reference:
From SPDX v2.2.2, Section 7.1:

"DEV_DEPENDENCY_OF indicates that the element is a development dependency of another element."

Request:

Add support for emitting DEV_DEPENDENCY_OF relationships in all SPDX 2.2 SBOMs generated by sbom-tool.

If possible, provide a way to programmatically flag which dependencies are considered development-only (for example, via config, CLI flag, or integration with package manager metadata).

Update documentation to describe expected output and guidance on use.

Impact:
Adopting this enhancement will help consumers of SBOMs generated by sbom-tool—especially those integrating with automated validation pipelines or vulnerability management—accurately assess the exposure surface for production builds, aligning with SSDF best practices for supply chain risk (PW.4.1, PW.4.4, RV.1.1, RV.1.2) and EO 14028 objectives.

Ref Feature: 2242407

[DaveTryon]

Implementation note: Our current dependencies are based on the AncestralReferrers property of the objects that we receive from component detection. This property is surfaced on the ScannedComponent class, which also has the following property:

public bool? IsDevelopmentDependency { get; set; }

We could theoretically use this proeperty to add the DEV_DEPENDS_ON relationship, as described at https://spdx.github.io/spdx-spec/v2.2.2/relationships-between-SPDX-elements/, while leaving the current DEPENDS_ON relationships as they are. That would allow current consumers (including our internal pipelines) to work unmodified, while also providing a basis for filtering out the dev dependencies. The SBOMs would obviously grow in size with this change.

Caveats:

1. The quality of the data is limited by the quality if the data coming from component detection. If they misclassify a dependency type, so will we.
2. Aggregation would also need to retain this data. We would need to be able to handle cases where the same package is classified differently in different sources and treat them accordingly
3. The SPDX 3.0 relationships (https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Vocabularies/RelationshipType/) does not list a DEV_DEPENDENCY_OF property, although I think the same information can be represented differently. The timetable for moving to SPDX 3.0 might be a factor in deciding to take on this work.

[henrylyons]

SPDX 3.0 supports a LifecycleScopeType attribute, that may be able to be used to represent dev dependencies: ahttps://spdx.github.io/spdx-spec/v3.0.1/model/Core/Vocabularies/LifecycleScopeType/.

There should also be a way to exclude dev dependencies from the SBOM, if the package owner does not want to disclose those. Excluding dev dependencies would be useful for some workflows, like SBOM vulnerability analysis.

[sfoslund]

We have discussed in triage, and we believe this is work that we should do. We have a tracking feature here.