User Story:
As an OSCAL content consumer, I need release artifacts to include cryptographic provenance verification for all releases moving forward, so that downstream tooling can establish proof of origin before ingesting framework data.
Goals:
The SHA-256 checksums on the v1.5.0 release page verify download integrity but do not provide cryptographic proof of origin. Adding signed releases would allow downstream consumers to verify that artifacts were built and published by the OSCAL team's CI pipeline and have not been modified after publication.
Dr. Iorga suggested opening this issue to gather community preferences on the signing mechanism. Three options to consider:
Option 1: GitHub Attestations (recommended)
Uses actions/attest-build-provenance to produce SLSA v1.0 provenance attestations tied to the GitHub Actions workflow identity. There are no key generation, storage, or rotation required and consumers verify with gh attestation verify. This aligns with NIST supply chain integrity guidance (SSDF, SP 800-218).
Option 2: Sigstore cosign (keyless)
Uses OIDC-based ephemeral certificates via Fulcio with signatures logged in Rekor. There are no key management burden and consumers verify with cosign verify-blob. And this is widely adopted in the container and artifact signing ecosystem.
Option 3: GPG detached signatures
Publishes .sig files alongside release artifacts. Consumers verify with gpg --verify, it is well-understood but requires key generation, secure storage, rotation, and public key distribution.
Dependencies:
No prior issues required. The release workflow would need a new step to generate and upload the signature or attestation alongside existing artifacts.
Acceptance Criteria
User Story:
As an OSCAL content consumer, I need release artifacts to include cryptographic provenance verification for all releases moving forward, so that downstream tooling can establish proof of origin before ingesting framework data.
Goals:
The SHA-256 checksums on the v1.5.0 release page verify download integrity but do not provide cryptographic proof of origin. Adding signed releases would allow downstream consumers to verify that artifacts were built and published by the OSCAL team's CI pipeline and have not been modified after publication.
Dr. Iorga suggested opening this issue to gather community preferences on the signing mechanism. Three options to consider:
Option 1: GitHub Attestations (recommended)
Uses
actions/attest-build-provenanceto produce SLSA v1.0 provenance attestations tied to the GitHub Actions workflow identity. There are no key generation, storage, or rotation required and consumers verify withgh attestation verify. This aligns with NIST supply chain integrity guidance (SSDF, SP 800-218).Option 2: Sigstore cosign (keyless)
Uses OIDC-based ephemeral certificates via Fulcio with signatures logged in Rekor. There are no key management burden and consumers verify with
cosign verify-blob. And this is widely adopted in the container and artifact signing ecosystem.Option 3: GPG detached signatures
Publishes
.sigfiles alongside release artifacts. Consumers verify withgpg --verify, it is well-understood but requires key generation, secure storage, rotation, and public key distribution.Dependencies:
No prior issues required. The release workflow would need a new step to generate and upload the signature or attestation alongside existing artifacts.
Acceptance Criteria