ビルドの来歴を検証する

Assured OSS パッケージは、SLSA レベル 2 のコンプライアンスでビルドされます。ビルドの来歴は、セキュリティ メタデータの一部として提供されます。このページでは、ビルドの来歴メタデータを検証する方法について説明します。

このドキュメントは、無料枠に適用されます。プレミアム ティアのビルドの来歴については、セキュリティ メタデータにアクセスしてパッケージを検証するをご覧ください。

始める前に

  • ビルドの来歴の署名を確認するために cosign をインストールします。

認証を設定する

認証の設定については、認証を設定するをご覧ください。

ビルドの来歴を検証する

ビルドの来歴は、in-toto 証明書を使用して署名されます。この証明書は dsse エンベロープ形式を使用します。つまり、生成された署名には、ラップされた署名と未加工のデータが含まれます。

aoss-verifier ツールを使用する

  1. ビルドの来歴を確認するには、aoss-verifier ツールをインストールします。

  2. $(go env GOPATH)/bin をエクスポートし、--verify_build_provenance フラグを指定して aoss-verifier verify-package コマンドを実行します。

    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]

    次のように置き換えます。

    • LANGUAGE: パッケージの言語。値は小文字にする必要があります。
    • PACKAGE_ID: Java の場合、形式は groupId:artifactId です。Python の場合、形式は packageName です。値は小文字にする必要があります。
    • VERSION: パッケージのバージョン。
    • ARTIFACT_PATH: 検証するローカル ディレクトリ内のデータファイルへのパス。次のファイル名拡張子を使用します。
      • Java パッケージの jar ファイル拡張子
      • Python パッケージの whl ファイル拡張子

    --disable_certificate_verification はオプションのフラグです。使用されている場合、証明書チェーンを介してリーフ証明書とルート証明書の照合をスキップします。

    --temp_downloads_path は、ファイルをダウンロードするパスを設定するオプションのフラグです。TEMP_DOWNLOADS_DIR_PATH を置き換えます。このフラグが設定されていない場合、ファイルは現在のディレクトリの tmp_downloads フォルダにダウンロードされます。

    --disable_deletes は、ダウンロードしたファイルを保持するオプションのフラグです。デフォルトでは、ツールはダウンロードしたすべてのファイルをクリーンアップします。

詳細については、ツールの README ファイルをご覧ください。

手動での確認

ビルドの来歴を確認するには、次の操作を行います。

  1. ビルドの来歴を取得します。

    セキュリティ メタデータへのアクセス方法に応じて、ビルドの来歴へのアクセス方法が異なります。

    詳細については、次のサンプル メタデータ スニペットをご覧ください。

    {
  "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…"
.....

    メタデータ スニペットの例:

    {'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. ビルドの来歴の署名を取得します。

    ビルドの来歴には、Envelope というセクションが含まれており、EnvelopeSignature として署名が含まれています。署名を取得する手順は次のとおりです。

    1. sig データを signature.txt という名前のファイルに保存します。

    2. メタデータ スクリプトを使用してメタデータがダウンロードされているかどうかを確認します。

      メタデータ スクリプトを使用してメタデータをダウンロードした場合は、署名を変更して、signature.sig という別のファイルに保存します。

      署名を変更するには、次のコマンドを実行します。

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

      メタデータ スクリプトを使用してメタデータがダウンロードされていない場合は、署名をデコードして、signature.sig という別のファイルに保存します。

      署名をデコードするには、次のコマンドを使用します。

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

  3. ビルドの来歴の公開鍵を取得します。

    ビルドの来歴の EnvelopeSignature セクションには、ビルドの来歴の署名に使用される鍵への参照が含まれています。鍵は次のいずれかの形式で保存されます。

    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

      ここで、KEY_NAME と KEY_VERSION は Cloud Key Management Service 鍵の名前とバージョンです。

    公開鍵は、Assured OSS が所有する Cloud Storage バケットに保存されます。

    Google Cloud CLI を使用して公開鍵を取得します。次のいずれかのコマンドを使用します。

    • KEY_NAME のみ存在する場合:

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

    • KEY_NAME と KEY_VERSION の両方が存在する場合:

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

    次のように置き換えます。

    • KEY_NAME: Cloud Key Management Service 鍵の名前。
    • KEY_VERSION: Cloud Key Management Service 鍵のバージョン。
    • PATH_TO_LOCAL_STORE は、公開鍵を保存するローカルパスの名前に置き換えます。

  4. 来歴の署名を検証します。

    1. 署名を確認するには、次のコマンドを実行します。

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

      次のように置き換えます。

      • KEY_REF: 前の手順でダウンロードした公開鍵のパス。
      • signature.sig: 前の手順で取得した署名を含むファイル。

      コマンドが正常に実行されると、次の出力が返されます。

      Verified OK

    2. プロベナンスに関連付けられたアーティファクト ハッシュも検証するには、次のコマンドを使用します。

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

      次のように置き換えます。

      • KEY_REF: 前の手順でダウンロードした公開鍵のパス。
      • signature.sig: 前の手順で取得した署名を含むファイル。
      • ARTIFACT_PATH: アーティファクトのパス。

      コマンドが正常に実行されると、次の出力が返されます。

      Verified OK

次のステップ