Build-Herkunft prüfen

Assured Open Source Software-Pakete (Assured OSS) entsprechen Supply-chain Levels for Software Artifacts (SLSA) Level 2, was die Build-Herkunft als Teil der Sicherheitsmetadaten erfordert. Um die Integrität des Pakets zu bestätigen, können Sie die Metadaten zur Build-Herkunft prüfen.

Dieses Dokument bezieht sich auf die kostenlose Stufe. Informationen zur Build-Herkunft in der Premium-Stufe finden Sie unter Auf Sicherheitsmetadaten zugreifen und Pakete prüfen.

Hinweis

  • Installieren Sie cosign, um die Signatur in der Build-Herkunft zu prüfen.

Authentifizierung einrichten

Informationen zum Einrichten der Authentifizierung finden Sie unter Authentifizierung einrichten.

Build-Herkunft überprüfen

Die Build-Herkunft wird mit einer in-toto-Attestierung signiert, die wiederum das DSSE-Envelope-Format verwendet. Das bedeutet, dass die generierte Signatur die verpackte Signatur und die Rohdaten enthält.

Tool „aoss-verifier“ verwenden

  1. Installieren Sie das Tool aoss-verifier, um die Build-Herkunft zu prüfen.

  2. Exportieren Sie $(go env GOPATH)/bin und führen Sie den Befehl aoss-verifier verify-package mit dem Flag --verify_build_provenance aus.

    aoss-verifier verify-package \
   --language LANGUAGE \
   --package_id PACKAGE_ID \
   --version VERSION \
   --artifact_path ARTIFACT_PATH \
   --verify_build_provenance \
   [--disable_certificate_verification] \
   [--temp_downloads_path TEMP_DOWNLOADS_DIR_PATH] \
   [--disable_deletes]

    Ersetzen Sie Folgendes:

    • LANGUAGE: Die Sprache des Pakets. Der Wert muss in Kleinbuchstaben geschrieben werden.
    • PACKAGE_ID: Für Java lautet das Format groupId:artifactId. Für Python lautet das Format packageName. Der Wert muss in Kleinbuchstaben geschrieben werden.
    • VERSION: Die Version des Pakets.
    • ARTIFACT_PATH: Der Pfad zur Datendatei in Ihrem lokalen Verzeichnis, die Sie prüfen möchten. Verwenden Sie die folgenden Dateiendungen:
      • jar-Dateiendung für ein Java-Paket
      • whl-Dateiendung für ein Python-Paket

    --disable_certificate_verification ist ein optionales Flag, mit dem der Abgleich des untergeordneten Zertifikats mit dem Root-Zertifikat über die Zertifikatskette übersprungen wird, falls verwendet.

    --temp_downloads_path ist ein optionales Flag, mit dem Sie den Pfad festlegen, in den die Dateien heruntergeladen werden sollen. Ersetzen Sie TEMP_DOWNLOADS_DIR_PATH. Wenn dieses Flag nicht festgelegt ist, werden die Dateien in den Ordner tmp_downloads im aktuellen Verzeichnis heruntergeladen.

    --disable_deletes ist ein optionales Flag, mit dem die heruntergeladenen Dateien beibehalten werden. Standardmäßig bereinigt das Tool alle heruntergeladenen Dateien.

Weitere Informationen finden Sie in der README-Datei des Tools.

Manuelle Bestätigung

So prüfen Sie die Build-Herkunft:

  1. Build-Herkunft abrufen

    Je nachdem, wie Sie auf Sicherheitsmetadaten zugreifen, wird die Build-Herkunft unterschiedlich abgerufen.

    Weitere Informationen finden Sie im folgenden Beispiel-Metadaten-Snippet:

    {
  "creationTime": "2023-03-25T05:32:23Z",
  "buildDetails": [
   {
     "packageFileName": "jackson-databind-2.13.3.jar",
     "envelope": {
     "payload": "eyJfdHlwZSI6Imh0d……………",
     "payloadType": "application/vnd.in-toto+json",
     "signatures": [
        "sig": "eyJwYXlsb2FkVHlwZSI6Im……",
        "keyid": "gcpkms://projects/cloud-aoss/locations/global/keyRings/cloud-aoss-ring/cryptoKeys/tekton-chains"
       }
     ]
   },
  "buildProvenance": "{\"_type\":\"https://in-toto.io/Statement/v0.1…"
.....

    Beispiel für ein Metadaten-Snippet:

    {'BuildOccurrence': name: "projects/cloud-aoss/occurrences/06c514bb-1069-4cde-8d68-b1306f19535a"
resource_uri: "jackson-databind-2.13.3.jar@sha256:4c01a14673bc1cd4a2df337a3b4e695af0a6ed8ac6be19c9e4077377fb8adf92"
note_name: "projects/cloud-aoss/notes/tekton-cloudbuild-intoto"
kind: BUILD
create_time {
  seconds: 1665556616
  nanos: 891004000
}
……
……
}
envelope {
  payload: "{\"_type\":\"https://in-toto.io/Statement/v0.1\", ….."
  payload_type: "application/vnd.in-toto+json"
  signatures {
    sig: "{\"payloadType\":\"application/vnd.in-toto+json\",....."
    keyid: "gcpkms://projects/cloud-aoss/locations/global/keyRings/cloud-aoss-ring/cryptoKeys/tekton-chains"
  }
}
,
…

  2. Rufen Sie die Signatur der Build-Herkunft ab.

    Die Build-Herkunft enthält einen Abschnitt namens Envelope, der Signaturen als EnvelopeSignature enthält. So rufen Sie die Signatur ab:

    1. Speichern Sie die sig-Daten in einer Datei mit dem Namen signature.txt.

    2. Prüfen Sie, ob die Metadaten mit dem Metadatenskript heruntergeladen werden.

      Wenn die Metadaten mit dem Metadatenskript heruntergeladen werden, ändern Sie die Signatur und speichern Sie sie in einer anderen Datei mit dem Namen signature.sig.

      Führen Sie den folgenden Befehl aus, um die Signatur zu ändern:

      cat signature.txt | sed -e 's/\\"/"/g' > signature.sig

      Wenn die Metadaten nicht mit dem Metadatenskript heruntergeladen werden, decodieren Sie die Signatur und speichern Sie sie in einer anderen Datei mit dem Namen signature.sig.

      Verwenden Sie den folgenden Befehl, um die Signatur zu decodieren:

      cat signature.txt | tr '\-_' '+/' | base64 -d > signature.sig

  3. Rufen Sie den öffentlichen Schlüssel für die Build-Herkunft ab.

    Der Abschnitt EnvelopeSignature in der Build-Herkunft enthält den Verweis auf den Schlüssel, der zum Signieren der Build-Herkunft verwendet wird. Der Schlüssel wird in einem der folgenden Formate gespeichert:

    1. gcpkms://projects/cloud-aoss/locations/global/keyRings/cloud-aoss-ring/cryptoKeys/KEY_NAME

    2. gcpkms://projects/cloud-aoss/locations/global/keyRings/cloud-aoss-ring/cryptoKeys/KEY_NAME/cryptoKeyVersions/KEY_VERSION

      Dabei sind KEY_NAME und KEY_VERSION der Name und die Version des Cloud Key Management Service-Schlüssels.

    Der öffentliche Schlüssel wird in einem Cloud Storage-Bucket gespeichert, der Assured OSS gehört.

    Rufen Sie den öffentlichen Schlüssel mithilfe der Google Cloud CLI ab. Verwenden Sie einen der folgenden Befehle:

    • Wenn nur KEY_NAME vorhanden ist:

      gcloud storage cp gs://cloud-aoss/keys/KEY_NAME-public.pem PATH_TO_LOCAL_STORE

    • Wenn sowohl KEY_NAME als auch KEY_VERSION vorhanden sind, gilt Folgendes:

      gcloud storage cp gs://cloud-aoss/keys/KEY_NAME-KEY_VERSION-public.pem PATH_TO_LOCAL_STORE

    Ersetzen Sie Folgendes :

    • KEY_NAME durch den Namen des Cloud Key Management Service-Schlüssels.
    • KEY_VERSION durch die Version des Cloud Key Management Service-Schlüssels.
    • PATH_TO_LOCAL_STORE durch den Namen des lokalen Pfads zum Speichern des öffentlichen Schlüssels.

  4. Überprüfen Sie die Herkunftssignatur.

    1. Führen Sie den folgenden Befehl aus, um die Signatur zu prüfen:

      cosign verify-blob-attestation --insecure-ignore-tlog --key KEY_REF --signature signature.sig --type slsaprovenance --check-claims=false /dev/null

      Ersetzen Sie Folgendes:

      • KEY_REF: Der Pfad zum öffentlichen Schlüssel, den Sie im vorherigen Schritt heruntergeladen haben.
      • signature.sig: Die Datei mit der Signatur, die im vorherigen Schritt abgerufen wurde.

      Nach erfolgreicher Ausführung des Befehls wird die folgende Ausgabe zurückgegeben:

      Verified OK

    2. Verwenden Sie den folgenden Befehl, um auch den mit der Herkunft verknüpften Artefakt-Hash zu prüfen:

      cosign verify-blob-attestation --insecure-ignore-tlog --key KEY_REF --signature signature.sig --type slsaprovenance --check-claims=true ARTIFACT_PATH

      Ersetzen Sie Folgendes:

      • KEY_REF: Der Pfad zum öffentlichen Schlüssel, den Sie im vorherigen Schritt heruntergeladen haben.
      • signature.sig: Die Datei mit der Signatur, die im vorherigen Schritt abgerufen wurde.
      • ARTIFACT_PATH: Der Pfad zum Artefakt.

      Nach erfolgreicher Ausführung des Befehls wird die folgende Ausgabe zurückgegeben:

      Verified OK

Nächste Schritte