Architect a "Verified Reproducible Build Attestation" Content

[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

Plan for 1Q 25:

• Provide a temurin-build cycloneDX tooling CLI to create CDXA programmatically #4050
• Create a Jenkins job to aid generation and signing of a CDXA json document #4051
• Provide a "template CDXA json" file to allow 3rd party users to simply create from a template, and sign as they feel fit #4052
• Provide a means to "verify" a CDXA json document format, which runs as a github action to verify a contributors PR #4053

[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

[andrew-m-leonard]

Basic CDXA layout:

• Assessor:
  • bom-ref: "assessor-1"
  • thirdParty: true,
  • organization.name: "Acme, Inc."
• Claim:
  • bom-ref: "claim-1"
  • target: "target-1"
  • predicate: "Identical verified reproducible build"
• Target: (identifies the JDK being reproduced)
  • bom-ref: "target-1"
  • component:
    • type: "application"
    • name: "Temurin jdk-21.0.5+11 x64 Linux"
    • externalReferences:
      • type: "distribution"
      • url: "adoptium temurinNN-binaries JDK URL"
      • hashes: [JDK.tar.gz hash...]
• Affirmation:
  • bom-ref: "affirmation-1"
  • statement: "Acme affirms to the identical reproduced build of Temurin jdk-21.0.5+11 on x64Linux"
  • signatories:
    • organization:
      • "name": "Acme, Inc."
    • externalReference:
      • "type": "website",
      • "url": "https://acme.com"

I don't currently see any useful need of "Evidence", as don't see say "Copy of output of diff command..." as being useful.

Trying to mandate JSF json signing for the "signatories" is probably not going to fit all 3rd parties, especially as JSF adoption is poor, and most organizations use detached GPG or Key signatures.

[andrew-m-leonard]

@tellison @smlambert @jiekang My thoughts on what is in the CDXA: #3950 (comment)

[jiekang]

I think the Target->component entry should have the full name of the file (e.g. OpenJDK21U-jdk_x64_linux_hotspot_21.0.5_11.tar.gz)

Though that made me look at the releases page and now wonder what we should plan for staticlibs, debugimage, testimage, and jre artifacts...

[smlambert]

I think the Target->component entry should have the full name of the file (e.g. OpenJDK21U-jdk_x64_linux_hotspot_21.0.5_11.tar.gz)

Not opposed to the suggestion, but want to mention that the full name of the artifact will feature in the url to the binaries repo

[andrew-m-leonard]

Though that made me look at the releases page and now wonder what we should plan for staticlibs, debugimage, testimage, and jre artifacts...

What is the plan for these...? current plan is for only reproducible verification of the JDK.tar.gz

[andrew-m-leonard]

I think the Target->component entry should have the full name of the file (e.g. OpenJDK21U-jdk_x64_linux_hotspot_21.0.5_11.tar.gz)

Not opposed to the suggestion, but want to mention that the full name of the artifact will feature in the url to the binaries repo

yes that was my original thought too

[tellison]

I think the Target->component entry should have the full name of the file (e.g. OpenJDK21U-jdk_x64_linux_hotspot_21.0.5_11.tar.gz)

Not opposed to the suggestion, but want to mention that the full name of the artifact will feature in the url to the binaries repo

yes that was my original thought too

Or preferably, a stable URL link to the asset via the Adoptium API rather than straight to the storage (just to avoid building dependencies on the storage implementation into the CDXA)

e.g. https://api.adoptium.net/v3/binary/version/jdk-21.0.5+11/linux/x64/jdk/hotspot/normal/eclipse

[andrew-m-leonard]

A generated example:

{
  "bomFormat" : "CycloneDX",
  "specVersion" : "1.6",
  "serialNumber" : "urn:uuid:54d03841-be91-4107-8216-0a398920d638",
  "version" : 1,
  "declarations" : {
    "assessors" : [
      {
        "thirdParty" : true,
        "organization" : {
          "name" : "Acme Inc"
        },
        "bom-ref" : "assessor-1"
      }
    ],
    "attestations" : [
      {
        "summary" : "Eclipse Temurin Attestation",
        "assessor" : "assessor-1",
        "map" : [
          {
            "claims" : [
              "claim-1"
            ]
          }
        ]
      }
    ],
    "claims" : [
      {
        "target" : "target-jdk-1",
        "predicate" : "VERIFIED_REPRODUCIBLE_BUILD",
        "bom-ref" : "claim-1"
      }
    ],
    "targets" : {
      "components" : [
        {
          "type" : "application",
          "bom-ref" : "target-jdk-1",
          "name" : "Temurin jdk-21.0.5+11 x64 Linux",
          "externalReferences" : [
            {
              "type" : "distribution",
              "url" : "https://api.adoptium.net/v3/binary/version/jdk-21.0.5+11/linux/x64/jdk/hotspot/normal/eclipse",
              "hashes" : [
                {
                  "alg" : "SHA-256",
                  "content" : "1234567890123456789012345678901234567890123456789012345678901234"
                }
              ]
            }
          ]
        }
      ]
    },
    "affirmation" : {
      "statement" : "Acme confirms a verified reproducible build",
      "signatories" : [
        {
          "organization" : {
            "name" : "Acme Inc"
          },
          "externalReference" : {
            "type" : "website",
            "url" : "https://acme-inc.com"
          }
        }
      ]
    }
  }

[andrew-m-leonard]

And here is the same using XML output:

<?xml version="1.0" encoding="UTF-8"?>
<bom serialNumber="urn:uuid:8d58d54f-e666-4c12-be06-ecfef6a0f0ab" version="1" xmlns="http://cyclonedx.org/schema/bom/1.6">
  <declarations>
    <assessors>
      <assessor bom-ref="assessor-1">
        <thirdParty>true</thirdParty>
        <organization>
          <name>Acme Inc</name>
        </organization>
      </assessor>
    </assessors>
    <attestations>
      <attestation>
        <summary>Eclipse Temurin Attestation</summary>
        <assessor>assessor-1</assessor>
        <map>
          <claims>
            <claim>claim-1</claim>
          </claims>
        </map>
      </attestation>
    </attestations>
    <claims>
      <claim bom-ref="claim-1">
        <target>target-jdk-1</target>
        <predicate>VERIFIED_REPRODUCIBLE_BUILD</predicate>
      </claim>
    </claims>
    <targets>
      <components>
        <component type="application" bom-ref="target-jdk-1">
          <name>Temurin jdk-21.0.5+11 x64 Linux</name>
          <version>jdk-21.0.5+11</version>
          <externalReferences>
            <reference type="distribution">
              <url>https://api.adoptium.net/v3/binary/version/jdk-21.0.5+11/linux/x64/jdk/hotspot/normal/eclipse</url>
              <hashes>
                <hash alg="SHA-256">1234567890123456789012345678901234567890123456789012345678901234</hash>
              </hashes>
            </reference>
          </externalReferences>
          <properties>
               <property name="platform">x64_linux</property>
          </properties>
        </component>
      </components>
    </targets>
    <affirmation>
      <statement>Acme confirms a verified reproducible build</statement>
      <signatories/>
    </affirmation>
  </declarations>
</bom>

[andrew-m-leonard]

For Q1 '25, the above CDXA.xml will be used: #3950 (comment)