Architect a "Verified Reproducible Build Attestation"

[andrew-m-leonard]

Architect a "Verified Reproducible Build Attestation".

Some useful links:

• https://www.cisa.gov/sites/default/files/2024-03/CISA_RSAA_User_Guide_18_March_2024.pdf
• https://cyclonedx.org/capabilities/attestations/
• https://github.com/CycloneDX/specification/blob/master/tools/src/test/resources/1.6/valid-attestation-1.6.json
• https://github.com/in-toto/attestation/blob/main/README.md
• https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form (and related DB for attestations and artifacts)
  • TODO, check if similar exists for EU
• https://www.cisa.gov/sites/default/files/2024-04/Self_Attestation_Common_Form_FINAL_508c.pdf
  • TODO, look at fields/requirements of the form and see if all are also valid for verification builds / as opposed to official published build)
• https://www.activestate.com/blog/everything-developers-need-to-know-about-attestations/
• https://cyclonedx.org/docs/1.6/json/#declarations_attestations
  • https://docs.google.com/presentation/d/13QP5Z5MRL-XtxEwTQ-JYy8x5_X884BmdEVkYLHt5PDk/edit#slide=id.g9d2ff71b8c_0_0

[andrew-m-leonard]

@tellison @smlambert fyi

[smlambert]

Also:

• https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form (and related DB for attestations and artifacts)
  • TODO, check if similar exists for EU
• https://www.cisa.gov/sites/default/files/2024-04/Self_Attestation_Common_Form_FINAL_508c.pdf
  • TODO, look at fields/requirements of the form and see if all are also valid for verification builds / as opposed to official published build)
• https://www.activestate.com/blog/everything-developers-need-to-know-about-attestations/
• https://cyclonedx.org/docs/1.6/json/#declarations_attestations

[tellison]

Sigstore seems to be a center of gravity in the secure supply chain processes.
We should seriously consider using the formats supported by Rekor to be able to use that infrastructure downstream.

[andrew-m-leonard]

Sigstore seems to be a center of gravity in the secure supply chain processes. We should seriously consider using the formats supported by Rekor to be able to use that infrastructure downstream.

An interesting read, this is what I understand from reading their various docs:

• CoSign's primary aim is in providing signing of "containers" stored in an OCI Registry.
• CoSign signing process is usually interactive involving opening of a Browser window for Identity verification during the signing
• CoSign keyless signing uses Rekor attestation ledger allowing "Signature" to be "verified" against the Rekor ledger entry identity and timestamp, hence does not require a "key"
• Rekor provides a append only transparency log, for things like attestations
• Rekor provide a public server: https://rekor.sigstore.dev

I take from that we could maybe:

• Using CoSign seems to be specific to keyless "Identity" based Signatures, it's usage for generic blob/artifact signing is not its main aim
• Rekor transparency log provides various pluggable formats including in-toto-attestations : https://github.com/sigstore/rekor/tree/main/pkg/types#currently-supported-types
  • Rekor also support generic types: https://docs.sigstore.dev/logging/sign-upload/
• Using Rekor transparency log, possibly the public one, could be a means for 3rd party reproducible attestation uploading. The public instance is limited to 100Kb attestation blobs

[smlambert]

in-toto/attestation#82
in-toto/attestation#129

[andrew-m-leonard]

in-toto/attestation#82 in-toto/attestation#129

Thanks Shelley, I am going to follow up with some questions to in-toto in their Slack (https://cloud-native.slack.com/archives/CM46K2VT2/p1727340094818479)

[andrew-m-leonard]

Further research, and references:

• in-toto attestation's are primarily targeted at automated policy engines, like in-toto-verify (and the associated in-toto-run'type interfaces) or Google Binary-Authorization engine, which capture "attestations at the time of execution" : ref: https://github.com/in-toto/attestation/blob/main/spec/README.md#in-toto-attestation-framework-spec
• CycloneDX 1.6 attestations provide a full metadata declaration for attestations in the CDXA format : https://cyclonedx.org/capabilities/attestations/

[andrew-m-leonard]

Option 1:

I am currently thinking of this outline architecture:

1. Temurin build (temurin-build) constructs a CycloneDX CDXA "provenance" attestation document at the end of the build along side the existing SBOM document, and links the SBOM->CDXA. The "Adoptium signed" CDXA will state the "provenance" of the built JDK tarball from an Adoptium "Producer" perspective, ie. something along the lines of a statement with evidence of "reproducible build", eg. binary hashes, and a "re-build" reproducible build evidence log?? Both SBOM and CDXA are published at release time.
2. A 3rd party performs a successful "Reproducible Verification Build", and creates their own "3rd party signed" consumer CDXA "provenance" attestation document, which documents their statement of evidence of "reproducible build" for the given Temurin release JDK tarball. The 3rd party then publishes this CDXA attestation document to the Adoptium marketplace: https://adoptium.net/marketplace/.
3. The last step by the Adoptium community as a consequence of a 3rd party publishing a "consumer" CDXA, is to run a "Verify" step, which compares the "producer" CDXA with the "consumer" CDXA, comparing the references and evidence, and upon success then lists the given 3rd party as "attesting" to the reproducibility of the given Temurin JDK release. This last step could also update a "reference", maybe a "bom-link" in the Temurin SBOM, to reference the "verified" consumer CDXA, the "version" number of the SBOM would be incremented by 1, as with accordance to the "CycloneDX Authorative Guide to SBOMs".

Future:

• Add capability of 3rd party uploading a CycloneDX CDXA document to the public Sigstore Rekor instance, and allowing the step(3) "Verify" stage to reference the Rekor transparency log entry. The "bom-link" would then reference the Rekor entry.
• Leverage in-toto producer policy auditing in the Adoptium CI build&test pipelines to sign the various stage completions eg.checkout, compile, smokeTest, aqaTest,..., package...

[andrew-m-leonard]

From talking to members of the in-toto community, their suggestion points to looking at https://github.com/in-toto/witness
Which from the front cover looks a possibility.

[andrew-m-leonard]

Option 2:

• Temurin ci.adoptium.net pipeline produces an in-toto attestation of reproducible-build provenance using the in-toto-witness tooling
• 3rd party performs a Temurin re-build, and produces their own in-toto attestation using in-toto-witness
• Eclipse Adoptium runs an in-toto-policy verification using in-toto-witness that verifies the Adoptium attestation and the 3rd party attestation evidence matches, to attest the claim of an independent Verified Reproducible Build