Build-Herkunft prüfen

Assured OSS-Pakete werden mit SLSA-Level 2-Compliance erstellt. Die Build-Herkunft wird als Teil der Sicherheitsmetadaten angegeben. Auf dieser Seite wird erläutert, wie Sie die Metadaten zur Build-Herkunft überprü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 überprüfen.

Hinweise

  • Installieren Sie cosign, um die Signatur in der Build-Provenienz 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-Umschlagformat verwendet. Das bedeutet, dass die generierte Signatur die umschlossene Signatur und die Rohdaten enthält.

Tool „aoss-verifier“ verwenden

  1. Um die Herkunft eines Builds zu überprüfen, installieren Sie das Tool aoss-verifier.

  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 ist 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 überprüfen möchten. Verwenden Sie die folgenden Dateinamenerweiterungen:
      • 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, sofern es verwendet wird.

    --temp_downloads_path ist ein optionales Flag, mit dem Sie den Pfad festlegen können, in den Sie die Dateien herunterladen möchten. 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 werden alle heruntergeladenen Dateien bereinigt.

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

Manuelle Bestätigung

So prüfen Sie die Herkunft des Builds:

  1. Build-Herkunft abrufen

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

    Weitere Informationen finden Sie im folgenden Beispiel für Metadaten:

    {
  "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 mit dem Namen 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, dekodieren 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-Provenienz enthält den Verweis auf den Schlüssel, der zum Signieren der Build-Provenienz 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 mit 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:

      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. Signatur der Herkunft überprüfen

    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 im vorherigen Schritt abgerufenen Signatur.

      Nachdem der Befehl erfolgreich ausgeführt wurde, wird die folgende Ausgabe zurückgegeben:

      Verified OK

    2. Wenn Sie auch den mit der Herkunft verknüpften Artefakthash prüfen möchten, verwenden Sie den folgenden Befehl:

      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 im vorherigen Schritt abgerufenen Signatur.
      • ARTIFACT_PATH: Der Pfad zum Artefakt.

      Nachdem der Befehl erfolgreich ausgeführt wurde, wird die folgende Ausgabe zurückgegeben:

      Verified OK

Nächste Schritte