Idea: add SRAC safety-relevance context to SBOM components

[devashridatta-dotcom]

Use case

Organizations using Dependency-Track for safety-relevant products need to know not only that a component has a vulnerability, but also whether an authorized engineering process has classified that component as safety-relevant, what evidence supports the classification, and whether a change-impact analysis is complete.

Would Dependency-Track consider an experimental integration for Safety Relevance Assertion Capability (SRAC) records?

SRAC is a format-neutral, externally authored sidecar associated with SBOM components. It carries safety-relevance metadata, evidence and review state, plus optional change-impact analysis and decisions. The integration would validate, correlate, display, and transport those records; Dependency-Track would not infer a safety classification or approve a safety decision.

Why Dependency-Track is a useful integration point

Dependency-Track already maintains a continuously analyzed component portfolio, consumes CycloneDX SBOM and VEX documents, applies policy, and retains audit information. SRAC could add safety context to the same components without overloading vulnerability severity or introducing non-standard fields into today's SBOM documents.

For example, a team could distinguish:

• a critical vulnerability in a component with an approved safety-related assertion;
• a changed safety-related component whose impact analysis is still incomplete; and
• a component for which safety relevance remains unassigned or the assertion could not be matched.

Proposed minimal experiment

1. Add an optional endpoint or import workflow for an SRAC JSON sidecar associated with a project version.
2. Validate its schema, integrity metadata, and internal references.
3. Correlate assertions deterministically with Dependency-Track components using stable identifiers such as CycloneDX bom-ref, package URL, component version, or artifact digest.
4. Store the original assertion and provenance separately from the imported SBOM and vulnerability-analysis records.
5. Show safety relevance, assertion lifecycle/review state, and change-impact status in component details and API responses.
6. Make those fields usable by portfolio filters and policy conditions.
7. Treat invalid, unmatched, or ambiguous assertions as explicit unknown/error states rather than “not safety-related”.

This could remain a sidecar until a released SBOM specification provides an appropriate native carrier. An exported CycloneDX BOM could optionally retain a resolvable external reference to the integrity-protected assertion.

Suggested acceptance criteria

• An SRAC sidecar can be imported for a specific project version.
• Assertions match components deterministically and do not leak across project versions.
• Invalid, unmatched, ambiguous, and stale assertions are visible.
• Original provenance, digest, author/reviewer fields, and lifecycle state remain auditable.
• Users can filter or define policy based on externally authored safety relevance and review status.
• Vulnerability severity and safety classification remain separate concepts.
• Dependency-Track never creates or changes a safety classification or approval decision.
• A synthetic example and automated tests document the behavior.

Working prototype

The Eclipse S-CORE prototype demonstrates schema validation, SPDX/CycloneDX correlation, integrity checks, enrichment reports, change-impact records, and fail-closed behavior:

• Eclipse proposal/tracking issue: Proposal: Define a minimum SRAC profile for an S-CORE pilot eclipse-score/score#3282

Related work:

• CycloneDX discussion: Proposal: CycloneDX Safety Perspective for SRAC and safety impact workflows CycloneDX/specification#1122
• cdxgen proposal: Proposal: experimental SRAC safety-relevance sidecar integration cdxgen/cdxgen#4392
• Trivy proposal: Idea: correlate Trivy findings with SRAC safety-relevance assertions aquasecurity/trivy#11317

Standards status

The mapping follows current SPDX 3.1-development FunctionalSafety concepts and explores a CycloneDX-compatible external assertion carrier. These are development/proposal references, not claims of released normative support.

Would a project-version sidecar import be compatible with Dependency-Track's architecture, or would maintainers prefer this to enter through CycloneDX before the platform consumes it?

[devashridatta-dotcom]

Proposed architecture: read-only SRAC enrichment for Dependency-Track v5

I suggest a phased architecture that keeps Dependency-Track's existing SBOM ingestion and vulnerability analysis unchanged.

Design principles

• The originating safety system remains the authoritative source.
• Dependency-Track does not determine whether a component is safety-related.
• SRAC transports and preserves externally authored safety assertions.
• Imported assertions are read-only safety context.
• Missing, ambiguous, invalid, and unreviewed assertions remain explicit.
• The original document, provenance, and integrity information are retained.

Proposed flow

Authoritative safety source
        |
        v
Integrity-protected SRAC document
        |
        +---- referenced from SPDX/CycloneDX SBOM
        |
        v
Dependency-Track SRAC ingestion
        |
        +-- schema validation
        +-- integrity verification
        +-- component correlation
        +-- provenance preservation
        |
        v
Read-only safety context in API/UI

Initial ingestion model

For the first implementation, I propose an explicit upload rather than automatically downloading arbitrary external URLs:

POST project-version/{uuid}/external-metadata
Content-Type: application/srac+json

The exact API path should follow Dependency-Track v5 conventions.

The upload process would:

1. Retain the original SRAC document.
2. Validate it against the supported SRAC schema version.
3. Verify its declared SHA-256 digest.
4. Correlate each assertion with a component in the applicable project version.
5. Record matched, unmatched, ambiguous, and invalid results.
6. Expose the results through a read-only API.

Automatic retrieval from an SBOM external reference could be considered later, with URL allowlisting and SSRF protections.

Deterministic component correlation

The proposed matching order is:

1. BOM reference within the same uploaded BOM and project version.
2. Package URL plus version.
3. Cryptographic component digest.

There should be no fuzzy name-only matching. Multiple matches must be reported as ambiguous, not selected automatically.

Persistence model

Dependency-Track would retain:

• Original SRAC document and schema version.
• Document digest and optional signature information.
• Source URI and creation timestamp.
• Applicable project version or BOM.
• Component-correlation results.
• Safety relevance, classification, assertion status, and review status.
• Evidence links and impact-analysis references.

The normalized fields would be an indexed projection for discovery and display. They would not replace the original assertion or become a second safety source of truth.

Initial UI

A component could display a read-only Safety context section containing:

• Safety relevance.
• Classification or integrity level, where asserted.
• Assertion lifecycle status.
• Reviewer and review state.
• Evidence and requirement references.
• Impact-analysis status.
• Source, schema version, and digest-verification result.

The project view could show counts for matched, unmatched, ambiguous, invalid, and unreviewed assertions.

MVP scope

The first increment would contain only:

• Explicit SRAC upload.
• Schema and integrity validation.
• Deterministic component correlation.
• Read-only API results.
• Correlation report and automated tests.

The MVP would not include:

• Automatic safety classification.
• Modification of vulnerability severity.
• Automatic remote-document retrieval.
• Policy enforcement.
• Editing safety assertions inside Dependency-Track.

Those capabilities can be evaluated after the ingestion and correlation model has been validated.

Standards evolution

The sidecar enables this workflow with current SPDX and CycloneDX documents through an integrity-protected external reference. When equivalent safety semantics are available natively in an adopted SBOM version, the same ingestion projection could accept those native fields without changing the Dependency-Track UI model.

Future native CycloneDX integration

The external-reference approach is intended as a compatibility and migration path, not as permanent coupling to a separate transport.

CycloneDX safety support is currently under public RFC in CycloneDX/specification#1120, targeting the 2.0-dev specification. The proposal includes safety-integrity and change-impact concepts, but it is not yet a released CycloneDX standard. The Dependency-Track MVP should therefore not depend on its current draft shape.

The ingestion architecture can nevertheless define an adapter boundary now:

SRAC external-reference adapter --+
                                  +--> Common Safety Context projection --> API/UI
CycloneDX native-safety adapter ---+

This supports a phased path:

1. Current compatibility path: CycloneDX 1.6/1.7 carries an integrity-protected external reference to the SRAC document.
2. Future native path: after the applicable CycloneDX safety specification is released and supported, a native CycloneDX adapter maps its safety fields into the same internal projection.
3. Migration: producers may transition transport without requiring a redesign of the Dependency-Track API or Safety Context UI.

Expected behavior would be:

• External reference only: validate and import the SRAC document.
• Native CycloneDX safety data only: import the supported native fields.
• Both present and consistent: retain both provenance paths and present one Safety Context projection.
• Both present but conflicting: report an explicit conflict and do not silently select a value.
• Unsupported future version: retain the source document without inferring safety semantics.

The originating safety lifecycle system remains authoritative in every path. Dependency-Track consumes and presents the supplied context; it does not create or approve the safety decision.

Requested guidance

Would this read-only, explicit-upload MVP be an acceptable starting point for Dependency-Track v5?

If the concept is acceptable, I can prepare:

• A synthetic CycloneDX SBOM.
• A corresponding SRAC document.
• Matched, unmatched, ambiguous, and invalid test cases.
• A reproducible container-based demonstration.
• An Architecture Decision Record before native implementation.

[devashridatta-dotcom]

I have consolidated the cross-project feedback into an overall
safety-relevance architecture:

• Architecture explanation and diagram

For Dependency-Track, the proposed receiving path is:

SBOM external reference -> SRAC discovery -> schema and digest verification -> component correlation -> read-only Safety Context API/UI

The expected outcomes are component-level safety visibility and
safety-informed vulnerability prioritization. Safety relevance changes the
priority and required response; it does not alter the VEX exploitability status
by itself.

The receiver must preserve provenance and expose matched, unmatched,
ambiguous, invalid, and stale states. It must not autonomously issue a safety
decision. Dependency-Track could separately act as a human-controlled authoring
workbench when operated under the responsible manufacturer's authority, but
that is distinct from this read-only ingestion proposal.

Feedback on whether this ingestion/API boundary fits the existing component
and vulnerability-analysis model would be appreciated.

[stevespringett]

We've discussed some of this previously. Several capabilities aren't in DT today and must be in place before we consider implementing safety information. IMO, the right approach is to break down the discrete features needed to support safety and create individual ADRs for each.

Strategically, we are very interested in supporting features that support leading indicators of risk.

Off the top of my head, I think the following would likely be good ADR candidates:

• Expanded support for external references (CycloneDX 1.x and higher)
• Support for commercial licensing (CycloneDX 1.x and higher - yes, this can have a safety impact)
• Support for evidence (identify and license for 1.x and vulnerabilities, behaviors for 2.0)
• Support for bad things not originating from vulnerabilities
  • Threats
  • Weaknesses
  • Risks
  • Controls
  • Impacts (safety is one of many)
• Support for Pedigree (CycloneDX 1.x and higher)
• Updated dashboards, views, scoring mechanisms (will likely need UX expertise)

Some of these items already have tickets. However, since the result is a major visual change, we will also want to update our version of Vue before any of this work starts. I believe there's also a ticket for that.

So, we need to address a few prerequisites first. If we want to support safety information in DT, we need to get the data model right, and an MVP specific only to safety likely isn't a good path forward. We'll likely want to take inspiration from the model CycloneDX created so that, when 2.0 is eventually supported in DT, the implementation is fairly straightforward. That path, while taking a bit longer, will not result in a complicated migration for users from the MVP data model to a CycloneDX-aligned data model, and it supports our strategic vision of moving from a BOM consumption and analysis platform to a Supply Chain Posture Management platform.

[devashridatta-dotcom]

Thanks, Steve. I reviewed the existing Dependency-Track trackers to map the prerequisites you identified. My initial inventory is:

External references

• #4277 — retrieve additional dependencies through externalReferences
• #4743 — preserve external references during SBOM upload
• #3283 — preserve available information during BOM export

Commercial licensing

• #2843 — support CycloneDX commercial licensing
• #170 — support multiple licenses

Evidence

• #1241 and #3290 — license evidence ingestion defects

These appear narrower than the generalized CycloneDX evidence capability you described. I did not find an umbrella ticket covering identity, license, vulnerability, and future behavior evidence.

Pedigree

• #4119 — ingest and represent component pedigree
• #919 — use pedigree patches during vulnerability analysis

Threats, risks, and controls

• #2479 — threat-intelligence import
• #5518 — custom vulnerability risk scores from VEX
• #1972 — compensating controls and residual risk

These provide useful prior work, but they remain largely vulnerability-centric. I did not find an existing umbrella issue for a generalized CycloneDX-aligned model of threats, weaknesses, risks, controls, and impacts where safety is one possible impact dimension.

Frontend prerequisite

• frontend #445 — upgrade CoreUI
• frontend #446 — upgrade to Vue 3 after Bump lib.lucene.version from 7.7.2 to 8.2.0 #445

Related future transport

• #1746 — SPDX 3 support

Based on this inventory, I see the likely ADR gaps as:

1. the complete external-reference lifecycle—ingestion, persistence, integrity verification, API exposure, and re-export;
2. generalized evidence and provenance;
3. a CycloneDX-aligned model for threats, weaknesses, risks, controls, and impacts;
4. dashboard and scoring behavior after the frontend prerequisite is completed.

Would you confirm whether this is the correct prerequisite map? If so, I can draft the first ADR around expanded external-reference support, using safety-relevance metadata as one motivating example without creating a safety-specific data model.

[devashridatta-dotcom]

A few additional cross-cutting concerns occurred to me while considering the ADR decomposition. These may fit within the ADRs you already listed rather than requiring a separate ADR for each:

• Trust and provenance: preserve the original source, issuer identity and validation result; support digests now and signatures or attestations where available. Integrity alone does not establish who issued or approved information.
• Deterministic subject correlation: define how imported evidence maps to a project version and component using stable identifiers such as BOM reference, pURL/version and artifact digest. Name-only matching should not be used, and unmatched or ambiguous results should remain explicit.
• Lifecycle and conflict handling: represent superseded, withdrawn, expired, stale, duplicate and conflicting assertions or evidence from multiple sources.
• Secure external retrieval: if Dependency-Track follows external references, define URL allowlisting, SSRF protection, authentication, redirects, size limits, timeouts and caching.
• Auditability and round-trip preservation: retain the original artifact and validation history and avoid silently losing supported information during re-export.
• Policy and automation integration: after the underlying model is established, expose these leading indicators through APIs, portfolio filters, policy conditions and notifications.

I would also suggest preserving three boundaries in the model:

1. exploitability status and impact remain separate;
2. externally supplied facts remain distinguishable from Dependency-Track-computed scores or conclusions; and
3. ingestion and correlation do not constitute approval by the originating authority.

These capabilities would support safety relevance, but they are also reusable for licensing, operational risk, compliance evidence and other Supply Chain Posture Management use cases.