Feedback on SPDX 3.1-rc1 — SBOM Lifecycle, Safety, and Governance Enhancements

[devashridatta-dotcom]

<style> </style>

S.No.	Focus Area	Feedback	Rationale	Example	Current Problem / Pain Point
1	SBOM Lifecycle & Context	Add explicit modeling to distinguish build-time vs. deployed SBOMs and track lifecycle states.	Safety and regulated use cases need clarity on which SBOM reflects the live system.	Tag SBOMs with build-time vs deployed labels; include timestamped state transitions.	SBOMs shipped with releases often miss build-time or dynamically introduced components, causing discrepancies discovered by customers, reactive remediation, and reputational risk.
2	Safety & Risk Annotation	Support optional safety/operational criticality metadata for components.	Enables prioritization and safer decision-making for safety-related BOMs.	Add a safety-critical field or operational-risk-score to each component.	Customers cannot easily prioritize remediation or assess risk if criticality metadata is missing.
3	SBOM–VEX–Runtime Linkage	Improve relationship patterns between SBOM components, VEX data, and runtime exposure.	Helps consumers assess real-world exploitability and risk.	Link CVE IDs and VEX statements directly to runtime instances of components.	Without runtime linkage, SBOMs don’t reflect actual exploitable exposures, causing delayed or ineffective risk response.
4	Migration & System Aggregation	Provide clearer 2.3 → 3.x migration guidance and patterns for system-of-systems SBOMs.	Reduces adoption friction and supports complex, safety-critical architectures.	Create migration mapping examples showing aggregated SBOM for a multi-module automotive system.	Organizations struggle to consolidate multiple SBOMs into coherent, system-level views for customer delivery and governance.
5	Lifecycle Semantics	Include non-normative guidance on interpreting lifecycle metadata; consider “Operational Governance Profile” or “Trust Score Metadata.”	Tools may interpret the same SPDX document differently, limiting automation and safety-focused use.	Define TrustScore: High/Medium/Low for supplier components; show ingestion by CI/CD tools.	Inconsistent lifecycle interpretations cause downstream tools to produce conflicting risk assessments or operational decisions.
6	Deterministic Interpretation for Safety	Provide guidance for stable identifiers, field precedence, and behavior when metadata is incomplete.	Determinism ensures repeatable decisions in safety-critical and regulated environments.	Enforce using stable purl identifiers and fallback rules when a digest or version is missing.	Missing or ambiguous identifiers can result in non-deterministic tooling behavior, impacting safety-critical workflows.
7	VEX Operational Expectations	Provide guidance on partial VEX coverage, “under investigation” interpretation, and missing/outdated VEX.	Avoids false positives or unsafe assumptions in automated pipelines consuming VEX data.	Mark a component as vulnerable: under investigation; downstream tooling ignores until resolved.	Lack of guidance leads to unnecessary alerts, incorrect remediation prioritization, or unsafe assumptions.
8	Provenance & Attestation Usage	Include examples clarifying signed vs unsigned SBOMs, assurance levels, and supplier-chained provenance.	Improves trust decisions and reduces inconsistent or overly permissive use of provenance data in governance and safety workflows.	Signed SBOMs from trusted supplier, unsigned from new vendor; tooling flags lower trust.	Ambiguity in interpreting provenance may reduce trust in SBOMs or cause inconsistent governance actions.
9	Cross-Profile Safety BOMs	Provide guidance for interpreting safety-related BOMs spanning multiple profiles (Security, AI, lifecycle).	Reduces fragmentation and misalignment in safety/AI assurance workflows.	AI module with security vulnerabilities and safety-critical status; integrated interpretation across profiles.	Safety-critical and AI components often require combined interpretation, which current guidance does not support.
10	Identifier Normalization & Internal Traceability	Provide guidance for reconciling multiple identifier systems (purl, CPE, SWID, digests) and accepting internal identifiers (build IDs, release IDs) for traceability.	Inconsistent identifier handling causes operational friction and governance complexity; internal IDs enable lifecycle correlation.	Normalize purl pkg:npm/express@4.17.1 with CPE cpe:2.3:a:express:express:4.17.1:::::::*; accept internal BUILD-12345 linking SBOM to release.	Conformance checkers may reject valid SBOMs containing internal identifiers, causing unnecessary remediation or operational delays.
11	SPDX as a Governance Input	Explicitly acknowledge SPDX use as input for governance, safety, and release-authorization decisions.	Helps prevent misuse and improves adoption outcomes.	Use SPDX to automatically approve/reject release if TrustScore < Medium or vulnerabilities exceed threshold.	Without recognizing governance usage, SBOMs may be underutilized or misapplied, reducing their value as a compliance and trust signal.

[devashridatta-dotcom]

@katestewart as requested Here’s my detailed feedback on SPDX 3.1-rc1 from a lifecycle and safety perspective.

[kestewart]

1 - Discussed in call - may need a custom relationship type? Instead of timestamp; use the deployed SBOM timestamp to signify the key information. Need to examine existing relationships (like generates, follows). May want to look at the SBOM types and existing relationships.

2 - Have discussed a bit in safety profile from requirements perspective already, but not sure it was making sense. Complete safety SBOM in form of assessment for specific system, concern about context and how it plays out at system and component level.

Discussion about prioritization proposed by Alexios, Nicole to add comments directly.

3- Is possible already (need to have example spun up to show.)

Pick up feedback review next week