Artifact Analysis

解決する課題

ビルドして保管したコンテナイメージやパッケージには、後から発覚する OS パッケージや言語ライブラリの脆弱性が潜みます。これを人手で追跡するのは現実的でなく、古いイメージほど見落とされがちです。Artifact Analysis は、レジストリ内のアーティファクトを自動でスキャンして既知の脆弱性を可視化し、デプロイ前の関門と組み合わせてサプライチェーンを守ります。

• レジストリへプッシュしたイメージを自動でスキャンし、既知の脆弱性を早期に把握したい
• 一度スキャンしたイメージも、新しい脆弱性情報が出たら継続的に再評価してほしい
• OS パッケージだけでなく 言語パッケージ（Go・Java・Python など）の依存も含めて検査したい
• 脆弱性の有無や署名などの情報をメタデータとして一元管理し、CI/CD や監査から参照したい
• 危険なイメージが本番へ流れないよう、スキャン結果を根拠にデプロイを止めたい

主要概念と用語

• スキャン（scanning）: イメージやパッケージを解析し、含まれるコンポーネントと既知の脆弱性を突き合わせる処理
• 自動スキャン（automatic / on-push scanning）: レジストリへのプッシュを契機に自動で走るスキャン。新たな脆弱性情報が出ると既存イメージも継続的に再評価される
• オンデマンドスキャン（on-demand scanning）: ローカルのイメージや CI 内のイメージを、レジストリへ保存する前に明示的に実行するスキャン
• 脆弱性（vulnerability）: 検出された既知の問題。CVE 識別子と深刻度（Critical/High など）を持つ
• ノート（note）: 脆弱性の定義など「種類」を表すメタデータの親。脆弱性データソース側が保持する
• オカレンス（occurrence）: 特定のアーティファクトにそのノートが現れた「実例」。あるイメージに対する個々の検出結果がこれにあたる
• 来歴・証明（provenance / attestation）: そのイメージがどう作られ、誰が検証したかを示す署名付きメタデータ。Binary Authorization の判断材料になる
• Container Scanning API / Container Analysis API: スキャン実行とメタデータ参照を担う API 群。Artifact Analysis はこれらを束ねた呼称

仕様・制限・クォータ

• 自動スキャンは Artifact Registry に保存されたアーティファクトを対象とする（旧 Container Registry も一部対象）
• 検出対象は OS パッケージの脆弱性に加え、言語パッケージの依存にも対応する（対応言語は拡張されてきている）
• 自動スキャンには、新たな脆弱性情報の公開に追従してプッシュ済みイメージを継続的に再評価する仕組みがある
• 継続的な再評価には、最後にプル/操作されてから一定の有効期間があり、長く触れられないイメージは再評価対象から外れることがある
• 結果は Container Analysis のメタデータ（ノート/オカレンス） として保存され、API・gcloud・コンソールから取得できる
• オンデマンドスキャンは、レジストリ保存前のイメージにも使え、CI のゲートとして組み込める
• 機能の有効化は Container Scanning API の有効化で行い、深刻度の定義や対応範囲は更新されうる

内部の仕組み

Artifact Analysis は、レジストリ内のアーティファクトを解析して含まれるコンポーネント一覧（パッケージとバージョン）を抽出し、それを脆弱性データソースと突き合わせて検出結果を生成します。検出結果は「種類」を表すノートと、特定イメージへの「実例」を表すオカレンスという2階層のメタデータとして保存され、API から横断的に照会できます。

• プッシュを契機に自動スキャンが走り、抽出したコンポーネントを既知の脆弱性情報と照合する
• 脆弱性データベースが更新されると、過去にスキャン済みのイメージも再評価され、新たに該当した脆弱性がオカレンスとして追加される
• スキャン結果のほか、ビルドの来歴やデプロイ可否の判断に使う証明（attestation） も同じメタデータ基盤に集約できる
• 蓄積したメタデータは Binary Authorization が参照し、ポリシーに反するイメージのデプロイをブロックできる

AWS でいえば、Amazon Inspector のコンテナイメージスキャン（Amazon ECR と連携した自動・継続スキャン）が役割として近く、結果メタデータを基にデプロイ関門と連携させる発想も共通します。

設計パターン / ベストプラクティス

• プッシュ時の自動スキャンを有効化し、レジストリに入った時点で脆弱性を可視化する
• CI ではオンデマンドスキャンをビルド直後に実行し、危険なイメージはレジストリへ保存する前に弾く
• スキャン結果を Binary Authorization のポリシーと組み合わせ、一定深刻度以上の脆弱性を含むイメージはデプロイさせない
• イメージはダイジェスト（sha256）で参照し、どのイメージのスキャン結果かを一意に追跡する
• 古い脆弱なイメージを残さないよう、Artifact Registry のクリーンアップポリシーで世代管理する
• 継続再評価を活かすため、稼働中イメージは定期的にプル/再デプロイして有効期間内に保つ

運用・監視

• スキャン結果はコンソールの Artifact Registry / Artifact Analysis 画面で深刻度別に確認できる
• 脆弱性の検出は Pub/Sub への通知として受け取り、Slack 連携や自動チケット起票など後続処理につなげられる
• 新規/更新されたオカレンスを起点に、該当イメージの棚卸しやパッチ適用済みイメージの再ビルドを運用フローに組み込む
• 検出メタデータは gcloud / API から取得でき、ダッシュボードや定期レポートに集約できる
• よくあるつまずきは Container Scanning API の未有効化と、継続再評価の有効期間切れによる古いイメージの未反映

コスト

課金は主に「スキャンしたアーティファクトの量」に基づきます。自動スキャンは初回のスキャンに対して、オンデマンドスキャンは実行ごとに費用が発生する形が中心で、継続的な再評価分の扱いは料金体系に従います。Artifact Registry の保管費用とは別枠であり、脆弱性メタデータの参照自体は API 呼び出しのコスト感で捉えます。

セキュリティ

• スキャン結果や証明などのメタデータへのアクセスは IAM ロールで制御し、参照と書き込みを分離する
• Binary Authorization と連携し、検証・署名済みで脆弱性基準を満たすイメージだけをデプロイ可能にする
• 検出された脆弱性は深刻度に応じて対応の優先度付けを行い、Critical/High を優先してパッチする
• スキャンはあくまで既知の脆弱性が対象であり、未知の問題や設定不備は別の対策（コードレビューやランタイム保護）で補う
• イメージはダイジェスト固定で扱い、タグの差し替えによる検証回避を防ぐ

関連サービス・比較

Artifact Analysis は Artifact Registry に保存したアーティファクトをスキャン対象とし、検出結果を Binary Authorization がデプロイ可否の判断に使います。レジストリが「保管」、Artifact Analysis が「検査とメタデータ化」、Binary Authorization が「関門」という役割分担です。

ハンズオン / CLI例

# Container Scanning API を有効化（自動スキャンの前提）
gcloud services enable containerscanning.googleapis.com

# レジストリへ保存する前にローカルイメージをオンデマンドスキャン
gcloud artifacts docker images scan \
  asia-northeast1-docker.pkg.dev/PROJECT_ID/my-repo/web:latest

# 特定イメージの脆弱性オカレンス一覧を取得
gcloud artifacts docker images list-vulnerabilities \
  asia-northeast1-docker.pkg.dev/PROJECT_ID/my-repo/web:latest

# メタデータ（オカレンス）を直接照会
gcloud artifacts docker images describe \
  asia-northeast1-docker.pkg.dev/PROJECT_ID/my-repo/web:latest \
  --show-package-vulnerability