Supply chain integration: Sigil attestations + SBOM/AIBOM + Rivet traceability bridge

[avrabe]

Context

Three regulatory deadlines converge in 2026:

• EU AI Act (Aug 2, 2026): AI system documentation, traceability, risk management
• EU Cyber Resilience Act (Sep 11, 2026): Mandatory vulnerability reporting; Dec 2027: machine-readable SBOMs for all digital products in the EU
• IEC 62304 Ed.2 (~2026): AI lifecycle for health software

All require overlapping evidence that currently lives in separate tools:

Evidence Layer	What	Standard	Tool Today
What's in the software	SBOM	CycloneDX / SPDX	Syft, Trivy, etc.
How was it built	SLSA provenance	SLSA v1.1+	Sigil (PulseEngine)
What AI generated it	AIBOM	CycloneDX ML-BOM	Nobody (#104)
Does it meet requirements	Traceability	ISO 26262, ASPICE, etc.	Rivet (PulseEngine)
Is it safe	Safety case + STPA	UL 4600, ISO/PAS 8800	Rivet (PulseEngine)
Is the binary authentic	Signatures	Sigstore, in-toto	Sigil (PulseEngine)

PulseEngine already has layers 2, 4, 5, and 6. This issue connects them and adds 1 and 3.

Design

1. Sigil attestation → Rivet artifact

Each Sigil attestation (DSSE envelope with in-toto predicate) becomes a Rivet artifact:

```yaml

• id: ATT-meld-fuse-001
  type: build-attestation
  title: "meld fuse: vehicle-control.wasm"
  status: verified
  provenance:
  slsa-level: 3
  builder: github-actions
  builder-id: "https://github.com/pulseengine/meld/actions/runs/12345"
  source-repo: "https://github.com/pulseengine/vehicle-control"
  source-digest: "sha256:abc123..."
  output-digest: "sha256:def456..."
  tool: meld
  tool-version: "0.3.2"
  timestamp: "2026-04-01T10:00:00Z"
  sigil-signature: "keyless:fulcio:abc..."
  links:
  verifies: [REQ-042] # This build verifies requirement coverage
  part-of: [REL-001] # Part of release artifact
  ```

2. SBOM integration

New artifact type for tracking software composition:

```yaml

• id: SBOM-vehicle-control-v1
  type: sbom-record
  title: "SBOM for vehicle-control v1.0.0"
  format: cyclonedx # or spdx
  sbom-ref: "sbom/vehicle-control-v1.0.0.cdx.json"
  component-count: 142
  vulnerability-status: assessed
  links:
  documents: [REL-001]
  assessed-by: [SEC-REVIEW-001]
  ```

Import adapter:
```bash

Import CycloneDX SBOM as rivet artifact

rivet import --format cyclonedx sbom/vehicle-control.cdx.json

Import SPDX SBOM

rivet import --format spdx sbom/vehicle-control.spdx.json
```

3. Rivet → SBOM/AIBOM export

```bash

Export AI provenance as CycloneDX ML-BOM extension

rivet export --format cyclonedx-aibom

Export full compliance bundle: SBOM + AIBOM + traceability + safety case

rivet export --format compliance-bundle --schema eu-ai-act,eu-cra
```

4. End-to-end trace: requirement → signed binary

The complete chain:
```
REQ-042 (rivet: requirement)
← satisfies ← DD-043 (rivet: design decision, AI provenance from #104)
← implements ← FEAT-045 (rivet: feature)
← verified-by ← TEST-015 (rivet: verification)
← build-evidence ← ATT-meld-fuse-001 (rivet: sigil attestation)
← signed-by ← Sigil keyless signature (Sigstore/Fulcio)
← sbom-documents ← SBOM-vehicle-control-v1 (rivet: SBOM record)
```

`rivet trace REQ-042 --full` shows this complete chain from requirement to signed binary.

5. Schema additions

New artifact types (in `common.yaml` or a new `schemas/supply-chain.yaml`):

Type	Purpose
`build-attestation`	SLSA provenance attestation from Sigil
`sbom-record`	SBOM metadata (pointer to CycloneDX/SPDX file)
`aibom-record`	AIBOM metadata (pointer to ML-BOM file)
`release-artifact`	A released binary/package with attestation + SBOM links
`vulnerability-assessment`	CVE/vulnerability assessment against SBOM components

Traceability rules:

• Every `release-artifact` must have a `build-attestation` (error)
• Every `release-artifact` must have an `sbom-record` (error for CRA compliance)
• Every `build-attestation` should reference SLSA level (warning)
• AI-generated artifacts should have `aibom-record` linkage (warning)

6. `sigil attest --rivet` integration

In Sigil, add a flag to output attestations directly as Rivet YAML:

```bash

Sign and generate rivet artifact in one step

sigil sign --keyless -i module.wasm -o signed.wasm --rivet-artifact artifacts/attestations/
```

7. EU CRA compliance view

```bash

Check CRA readiness

rivet validate --schema supply-chain,eu-cra

→ SBOM present: ✓

→ Vulnerability assessment: ✓ (last assessed: 2026-03-28)

→ SLSA provenance: Level 3 ✓

→ Vulnerability reporting capability: ✓

→ Missing: update mechanism documentation

```

Phases

Phase 1: Schema + attestation import

• `schemas/supply-chain.yaml` with `build-attestation`, `sbom-record`, `release-artifact`
• `rivet import --format sigil-attestation` adapter
• `rivet import --format cyclonedx` adapter (SBOM metadata extraction)

Phase 2: Traceability rules + CRA compliance

• Rules: release needs attestation, release needs SBOM
• `rivet validate --schema supply-chain` for CRA readiness checking
• `rivet trace REQ-X --full` showing requirement → signed binary chain

Phase 3: AIBOM integration

• Connect to AI code provenance tracking: AIBOM integration and AI-generated artifact audit trail #104 (AI provenance) — AI provenance metadata exported as CycloneDX ML-BOM
• `aibom-record` artifact type
• `rivet export --format cyclonedx-aibom`

Phase 4: Sigil integration

• `sigil sign --rivet-artifact` flag for direct Rivet YAML output
• Shared attestation format between Sigil and Rivet
• `rivet export --format compliance-bundle` with SBOM + AIBOM + traceability + attestations

Regulatory alignment

Regulation	Deadline	What Rivet+Sigil provides
EU AI Act	Aug 2, 2026	Annex IV documentation, AI system traceability, risk management (#99)
EU CRA	Sep 11, 2026 (reporting), Dec 2027 (SBOM)	SBOM generation, vulnerability assessment tracking, SLSA provenance
FDA SBOM	Already required	CycloneDX/SPDX SBOM linked to IEC 62304 traceability (#102)
ISO 26262 Part 8	Ongoing	Tool qualification evidence via SLSA provenance + rivet traceability
ISO/PAS 8800	Published 2024	AI tool qualification + build provenance (#106)

References

• SLSA specification v1.1
• CycloneDX ML-BOM
• OWASP AIBOM
• EU CRA SBOM requirements
• EU CRA timeline
• Supply chain security trifecta: SBOM + SLSA + SSDF
• in-toto attestation framework
• Sigil: `src/lib/src/slsa.rs`, `src/attestation/`, `src/lib/src/intoto.rs`
• Rivet EU AI Act compliance schema (schemas/eu-ai-act.yaml) — high-risk AI system documentation #99 (EU AI Act), AI code provenance tracking: AIBOM integration and AI-generated artifact audit trail #104 (AI provenance/AIBOM), Domain schema packages: IEC 62304, DO-178C, IEC 61508, EN 50128/50716 #102 (domain schemas)

[avrabe]

Triage: this is a four-phase, multi-component initiative (schema additions + adapters + traceability rules + AIBOM export + Sigil integration) and exceeds the "one PR per issue" boundary. There is also no top-level ## Acceptance section.

Recommend decomposing into per-phase or per-component issues, each with explicit acceptance bullets. A reasonable split:

• Sub-issue A (Phase 1, schema only): schemas/supply-chain.yaml with build-attestation, sbom-record, release-artifact, aibom-record, vulnerability-assessment. Acceptance = schema lints, rivet validate clean, tests pass.
• Sub-issue B (Phase 1, importers): rivet import --format sigil-attestation, rivet import --format cyclonedx, rivet import --format spdx. Acceptance = round-trip tests for each.
• Sub-issue C (Phase 2, validation rules): traceability rules (release needs attestation, release needs SBOM); rivet validate --schema supply-chain for CRA readiness. Acceptance = rule tests + reproducer fixture.
• Sub-issue D (Phase 3, AIBOM export): rivet export --format cyclonedx-aibom, depends on AI code provenance tracking: AIBOM integration and AI-generated artifact audit trail #104.
• Sub-issue E (Phase 4, Sigil integration): needs counterpart issue in pulseengine/sigil.

Each sub-issue then gets a ## Acceptance section with testable bullets. Confirm the decomposition and I can file the sub-issues from this hub.

---

Generated by Claude Code

[avrabe]

Triage (issue-triage agent run 2026-05-09): the body lays out a four-phase compliance feature (Sigil attestation import, SBOM import, AIBOM export, Sigil integration) with five new artifact types, four new import/export adapters, and a new --schema supply-chain,eu-cra validate mode. Each phase is multi-day and each phase has soft "should/must" rules but no per-phase bulleted acceptance criteria.

For autonomous pickup this needs to be split into one issue per phase with explicit acceptance bullets. Suggested decomposition matching the body's "Phases" section:

• Supply chain integration: Sigil attestations + SBOM/AIBOM + Rivet traceability bridge #107-Phase-1 — schemas/supply-chain.yaml (build-attestation, sbom-record, release-artifact); rivet import --format sigil-attestation; rivet import --format cyclonedx. Acceptance = schema validates against fixture artifacts; round-trip import → rivet list shows imported attestations and SBOM records.
• Supply chain integration: Sigil attestations + SBOM/AIBOM + Rivet traceability bridge #107-Phase-2 — Traceability rules (release-artifact requires build-attestation and sbom-record); rivet validate --schema supply-chain; rivet trace REQ-X --full. Acceptance = rule violations surface as errors; trace output passes a golden file.
• Supply chain integration: Sigil attestations + SBOM/AIBOM + Rivet traceability bridge #107-Phase-3 — aibom-record artifact type; rivet export --format cyclonedx-aibom. Depends on AI code provenance tracking: AIBOM integration and AI-generated artifact audit trail #104 landing first (open PR feat: provenance lifecycle — mark/apply/clear + Claude hooks #125).
• Supply chain integration: Sigil attestations + SBOM/AIBOM + Rivet traceability bridge #107-Phase-4 — rivet export --format compliance-bundle; sigil-side --rivet-artifact flag (cross-repo, lives in pulseengine/sigil).

Phase 1 is the most tractable single-PR scope — would you like me to split it out as #107-Phase-1 with the acceptance shape above on the next run?

Not implemented this run.

🤖 issue-triage agent run 2026-05-09.

---

Generated by Claude Code

[avrabe]

Triage note — this is a 4-phase design proposal spanning Sigil↔Rivet integration, SBOM/AIBOM imports, traceability rules, and a compliance-bundle export. Each of Phase 1–4 is itself a multi-week feature touching several subsystems (schemas/, rivet-core/src/, rivet-cli/src/, plus Sigil side).

Could you split out Phase 1 (Schema + attestation import) as its own issue with an explicit ## Acceptance checklist of testable bullets (matching the format used in #237, #249, #248)? Something like:

## Acceptance
- [ ] `schemas/supply-chain.yaml` declares `build-attestation`, `sbom-record`, `release-artifact` types
- [ ] `rivet import --format sigil-attestation <path>` parses a DSSE/in-toto envelope into a `build-attestation` artifact
- [ ] `rivet import --format cyclonedx <path>` produces an `sbom-record` referencing the source SBOM
- [ ] Round-trip test fixture: import → validate → list shows the new artifacts
- [ ] `rivet docs schema-supply-chain` topic ships with the new field shape

That would be a focused implementable target. Keeping this open as the cross-cutting design.

---

Generated by Claude Code

[avrabe]

synth side landed: PR pulseengine/synth#129 adds CycloneDX 1.5 build-SBOM emission. synth compile --sbom produces a .cdx.json documenting the compiler version, input WASM hash, output ELF hash + target/backend, and WASM imports as components with a dependency graph. That file is exactly what this issue's sbom-record artifact (format: cyclonedx) points at via sbom-ref — ingestable by rivet import --format cyclonedx. Layer 1 (SBOM) of the evidence table now has a producer on the synth side.

[avrabe]

Triage follow-up (issue-triage agent run 2026-05-23): synth#129 landing on 2026-05-22 changes Phase-1's tractability — there is now a real, in-repo producer of CycloneDX 1.5 build SBOMs (synth-compile output: .cdx.json with compiler version, input/output hashes, WASM imports as components, dependency graph). That's the exact upstream fixture the proposed rivet import --format cyclonedx consumes, so Phase 1 is no longer gated on "we need a real SBOM to import."

Phase 1 is now the most tractable single-PR scope here. Would you split it out as e.g. #107-Phase-1: supply-chain schema + sigil/cyclonedx importers with explicit acceptance bullets? Suggested shape (matching #237 / #249 / #248):

## Acceptance Criteria
- [ ] `schemas/supply-chain.yaml` declares `build-attestation`, `sbom-record`, `release-artifact`
- [ ] `rivet import --format sigil-attestation <path>` parses a DSSE / in-toto envelope into a `build-attestation` artifact (with golden fixture)
- [ ] `rivet import --format cyclonedx <path>` ingests a `synth compile --sbom` output (`synth#129`) as an `sbom-record` and records `sbom-ref` to the source file
- [ ] Round-trip fixture: `rivet import` → `rivet validate` clean → `rivet list --format json` includes the new artifacts
- [ ] `rivet docs schema-supply-chain` ships explaining the field shape
- [ ] Commit trailer: `Implements: REQ-XXX, Refs: #107`

Phases 2–4 still need their own AC blocks before they're agent-tractable; Phase 4 (Sigil --rivet-artifact flag) remains cross-repo and out of this agent's write scope.

Not implemented this run (no AC on body yet, and the task explicitly forbids implementing without it).

🤖 issue-triage agent run 2026-05-23.

---

Generated by Claude Code