一般的な資産タイプ

パイプラインにおいて、資産はさまざまな形をとることができる：

• ソースコードのコミット- ビルドおよびテストされるコード
• コンテナイメージ- ビルドによって生成された Docker イメージ
• デプロイメント成果物- Kubernetes マニフェスト、 Helm チャート、または構成ファイル
• パイプラインの実行- パイプラインの実行そのもの

でサポートされている様々なアセットタイプを下図に示します。 DevSecOps:

資産を特定する方法

各資産は、ユニークかつ不変的に識別されなければならない。 これにより、パイプラインが複数回実行されても、アセットに対して収集されたエビデンスが常にまったく同じアーティファクトを参照するようになります。

資産識別フォーマット：

• コミットアセット ：リポジトリとコミットハッシュ

  https://repo.url/org/repo#<COMMIT-SHA>
  

• 画像アセット ： Docker 画像とそのダイジェスト

  docker://registry.URL/name@sha256:<SHA256-DIGEST>
  

• パイプライン・ラン・アセット ：パイプラインとランID

  pipelinerun://<PIPELINE_ID>/<RUN_ID>
  

• その他の資産有資格者 URL 例

  • アセットをファイル名（ヘルムチャートまたは設定ファイル）でコミットします：

    https://repo.url/org/repo#<COMMIT-SHA>/<filename>
    

  • アーティファクト資産：

    <artifactory-url>/artifact.<filetype>
    

エビデンスが常に正確なアーティファクトのバージョンを参照するように、変更可能なラベル（タグ、ブランチ）ではなく、不変の識別子（コミットSHA、イメージダイジェスト）を使用する。

リポジトリ情報の保存

パイプラインがソースコードをチェックアウトしたら、 save_repo コマンドを使って リポジトリの詳細を記録します。 これにより、ビルド成果物は、それらを生成した特定のコミットと関連付けられる。

例:

save_repo app-repo \
  url=<app_url> \
  path=my-app \
  commit=commit1 \
  branch=master \
  buildnumber=1

アーティファクト情報の保存

アーティファクト（イメージ、デプロイメントファイルなど）をビルドしたら、 save_artifact コマンドを 使用してその詳細を記録します。 これはアーティファクトの名前、タイプ、ダイジェスト、出所をキャプチャする。

どのような時に使うのか：

• Docker イメージ構築後
• デプロイメントマニフェストの生成後
• デプロイされるアーティファクトを作成した後

例 Docker 画像の保存

パイプラインがビルドし、 Docker イメージをプッシュした後：

save_artifact app-image \
  name=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561 \
  type=image \
  digest=sha256:sha2561 \
  tags=mytag1 \
  source=<source_url> \
  signature=sign-1 \
  provenance=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561

例配置アーティファクトの保存

Kubernetes マニフェストや Helm チャートなど、画像以外のアーティファクトの場合：

save_artifact artifact-1 \
  name=my-app_IKS_deployment \
  type=deployment \
  signature=sign2 \
  deployment_type=IKS \
  provenance=<url>

在庫パラメータを理解する

以下のパラメータを指定して cocoa inventory add コマンドを使う：

インベントリエントリーの作成

以下の例では、さまざまな資産タイプのインベントリエントリを作成する方法を示します。 パラメータが save_artifact で保存した情報と一致していることに注意。

例 Docker 画像をインベントリに登録する

この例では、先ほど保存した Docker 画像のインベントリエントリーを作成します：

cocoa inventory add \
  --artifact=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561 \
  --name=my-app \
  --app-artifacts='{ "app": "my-app", "tags": "20230828074614-master-commit1" }' \
  --signature=sign1 \
  --provenance=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561 \
  --sha256=sha256:sha2561 \
  --type=image \
  --repository-url=<repo_url> \
  --commit-sha=commit1 \
  --version=commit1 \
  --build-number=1 \
  --pipeline-run-id=pipeline-run-1 \
  --org=Org \
  --repo=my-inventory-20230421184544472 \
  --git-provider=github \
  --git-token-path=./inventory-token \
  --git-api-url=<api_url>

例配置アーティファクトをインベントリに登録する

デプロイメント成果物についても、プロセスは同様ですが、 deployment タイプを使用します：

cocoa inventory add \
  --artifact=my-app_IKS_deployment \
  --name=my-app_IKS_deployment \
  --app-artifacts='{ "app": "my-app", "tags": "20230828074614-master-commit1" }' \
  --signature=sign2 \
  --provenance=<provenance_url> \
  --sha256=sha256:sha2562 \
  --type=deployment \
  --repository-url=<repo_url> \
  --commit-sha=commit1 \
  --version=commit1 \
  --build-number=1 \
  --pipeline-run-id=pipeline-run-1 \
  --org=Org \
  --repo=my-inventory-20230421184544472 \
  --git-provider=github \
  --git-token-path=./inventory-token \
  --git-api-url=<api_url>

資産の証拠収集

を使用する。 collect-evidence コマンドを使用する。 asset-key パラメータは、 save_artifact または save_repo でアセットを保存する際に使用したキーと一致する必要があります。 すべてのパラメータ、サポートされるツール形式、およびCLIの使用方法など、 collect-evidence コマンドの詳細については、 collect-evidenceスクリプトを 参照してください。

例ソースコードに対するテストの証拠収集

ソースコード・リポジトリに対して実行されるテストの場合：

collect-evidence \
  --tool-type "jest" \
  --status "success" \
  --evidence-type "com.ibm.unit_tests" \
  --asset-type "repo" \
  --asset-key "repo-1"

例成果物の単体テストの証拠を収集する

受け入れテストを実施した後、成果物に関する証拠を収集する：

collect-evidence \
  --tool-type "jest" \
  --status "success" \
  --evidence-type "com.ibm.acceptance_tests" \
  --asset-type "artifact" \
  --asset-key "app-image"

受け入れテストを実施した後、複数の成果物について証拠を収集する：

collect-evidence \
  --tool-type "jest" \
  --status "success" \
  --evidence-type "com.ibm.acceptance_tests" \
  --evidence-per-asset \
  --assets "app-image:artifact" \
  --assets "artifact-1:artifact"

不変識別子を使用する

タグやブランチ名ではなく、常にコミットのSHAとイメージダイジェストを使用する。 変更可能な参照は変更される可能性があり、証拠と資産の間のリンクが壊れる。

一貫したネーミングの維持

パイプラインの実行中は、アーティファクト名を固定します。 issueの適切な追跡と自動閉鎖を確実にするため、nameフィールドにタイムスタンプのような動的な値を埋め込むことは避けてください。

アセットタイプに合わせる

cocoa inventory add の type パラメーターが save_artifact で使用されているタイプと一致していることを確認する。 タイプの不一致は証拠収集の失敗の原因となる。

デプロイメントにおける参照実績

CDパイプラインでは、 artifact フィールドではなく、 provenance フィールドを使用して成果物をダウンロードします。 出所 URL は、成果物の完全で不変の場所を提供する。

最適化されたパイプライン実行のための証拠再利用

パイプラインの実行時間とリソース使用量を最適化するには、エビデンスの再利用を有効にします。 この機能により、スキャン対象のアセット（アーティファクトまたはリポジトリ）が前回のスキャン以降に変更されていない場合に、スキャンやテストをスキップすることができます。

再利用の条件、有効期間、高度な設定など、エビデンスの再利用の詳細については、 PRおよびCIパイプライン間でのエビデンスの再利用を 参照してください。

CD パイプラインでは、成果物をダウンロードするために、デプロイメントは成果物ではなく生成フィールドを参照する必要があります。