Context
PR #364 gave exported SBOMs a stable document identity (shared urn:uuid serial number, versioned tool metadata, primary component). The remaining provenance gap is integrity of the document itself: consumers currently have no way to verify that an SBOM was produced by bomly and has not been modified. Compliance profiles (EU CRA document-integrity expectations; sbom-tools' has_signature provenance check) increasingly expect signed SBOMs, and our release pipeline already signs checksums and publishes SLSA provenance via GoReleaser — the SBOMs bomly produces for users deserve the same story.
Proposal
Two complementary layers, likely phased:
- Detached attestation (recommended first): a
bomly scan ... --sign flow (or documented CI recipe) producing a sigstore/cosign attestation over the generated SBOM file. Format-agnostic — works identically for SPDX and CycloneDX — keyless in CI via OIDC. Possibly ships as documentation + a Guard/CI integration before any CLI flag.
- Embedded CycloneDX signature: JSF
signature support via cyclonedx-go, for consumers that require self-contained signed BOMs. SPDX 2.3 has no embedded-signature equivalent (external attestation covers it), which is worth stating in docs/SBOM.md.
Open questions:
- Key management UX for local (non-CI) runs; keyless vs. provided key.
- Whether signing lives in the CLI at all, or stays a documented cosign recipe until there is demand for
--sign (no new dependencies without discussion — cosign-as-subprocess vs. sigstore-go).
- Interaction with
-o multi-output: one attestation per emitted document.
Acceptance
- A documented, tested path to produce a verifiable signature/attestation for every emitted SBOM in both formats.
- Verification instructions in
docs/SBOM.md (and docs/CI_INTEGRATION.md if the CI recipe route is chosen).
- If embedded JSF signing lands: signed CycloneDX output remains schema-valid and round-trips through
--sbom ingestion.
🤖 Generated with Claude Code
Context
PR #364 gave exported SBOMs a stable document identity (shared urn:uuid serial number, versioned tool metadata, primary component). The remaining provenance gap is integrity of the document itself: consumers currently have no way to verify that an SBOM was produced by bomly and has not been modified. Compliance profiles (EU CRA document-integrity expectations; sbom-tools'
has_signatureprovenance check) increasingly expect signed SBOMs, and our release pipeline already signs checksums and publishes SLSA provenance via GoReleaser — the SBOMs bomly produces for users deserve the same story.Proposal
Two complementary layers, likely phased:
bomly scan ... --signflow (or documented CI recipe) producing a sigstore/cosign attestation over the generated SBOM file. Format-agnostic — works identically for SPDX and CycloneDX — keyless in CI via OIDC. Possibly ships as documentation + a Guard/CI integration before any CLI flag.signaturesupport via cyclonedx-go, for consumers that require self-contained signed BOMs. SPDX 2.3 has no embedded-signature equivalent (external attestation covers it), which is worth stating indocs/SBOM.md.Open questions:
--sign(no new dependencies without discussion — cosign-as-subprocess vs. sigstore-go).-omulti-output: one attestation per emitted document.Acceptance
docs/SBOM.md(anddocs/CI_INTEGRATION.mdif the CI recipe route is chosen).--sbomingestion.🤖 Generated with Claude Code