feat(supply-chain): ingest SPDX/CycloneDX and build queryable software lineage

[tcconnally]

Context

The Kessel Run DevSecOps CSO is an active umbrella vehicle for Software and DevSecOps offerings, with focused Areas of Interest and submission instructions released as specific requirements arise:

• SAM.gov: https://sam.gov/workspace/contract/opp/2dbc9f187ca543398f9f1c6e7601fde9/view
• CISA SBOM overview: https://www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom
• CISA 2025 SBOM minimum-elements guidance: https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom

This issue is a research/roadmap item inspired by an internal Kessel Run DevSecOps AoI hypothesis review. It is not a claim of Kessel Run endorsement or a replacement for existing scanners.

Gap

Perseus has code/context and provenance-oriented surfaces, and the repositories publish their own software SBOM/security documentation. That is different from consuming SBOMs produced by an existing customer pipeline.

The product-facing gap is a normalized, queryable lineage model that can answer a question such as:

Which deployed artifacts contain this vulnerable component, through which dependency/build path, and what evidence supports that answer?

A parser alone is insufficient. The system must preserve source metadata and digests, handle identifier/version variance, represent incomplete lineage, and connect component data to builds, artifacts, deployments, vulnerability/VEX records, and optional signing/attestation references.

CISA identifies SBOMs as a key software-supply-chain risk-management building block and emphasizes machine-processable formats that support scalable integration with broader cybersecurity practices.

Proposed scope

Add an explicit ingestion and lineage contract for SPDX and CycloneDX, initially with representative JSON/XML fixtures and a bounded local query surface. The implementation may use Vault for durable graph storage and Ledger for hash-only evidence receipts, but the user-facing contract should remain clear in Perseus.

Acceptance criteria

• Ingest representative SPDX and CycloneDX JSON/XML fixtures with format/version validation.
• Normalize components while preserving original document digest, source, timestamp, supplier, version, identifiers, and relationship metadata.
• Correlate source -> dependency -> build -> artifact -> deployment with explicit confidence/coverage and unknown states.
• Support an impacted-artifact query using a synthetic Log4j-style vulnerable component.
• Preserve VEX, vulnerability, signature, and attestation references when supplied; do not invent them when absent.
• Return an auditable explanation of the query path and the evidence supporting each edge.
• Demonstrate integration with existing scanner/pipeline outputs without requiring replacement of those tools.
• Add offline deterministic fixtures and tests; no cloud service is required for the core path.

Non-goals

• Replacing SBOM generators, vulnerability scanners, CI/CD systems, or deployment platforms.
• Claiming SLSA/in-toto signing or attestation parity before it is implemented and verified.
• Treating an incomplete SBOM or missing relationship as proof that an artifact is unaffected.

Related implementation surfaces

• docs/SBOM.md
• docs/federal-buyers.md
• docs/SECURITY-MILESTONES.md
• Code-map/context and Vault provenance integration surfaces

[tcconnally]

Resolved by PR #1000, squash-merged as 233314a944892fbd2b269df8b24fdafc1ce21bc5 on 2026-08-20. The final reviewed candidate 761ca6e78607a3fcf88a656bd3c999c3545ea3f1 passed the exact-tree security review, build parity, the SBOM lineage suite (141 passed), and the full suite (2758 passed, 6 skipped).