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 パッケージの脆弱性に加え、言語パッケージの依存にも対応する（対応言語は拡張されてきている）
• コンテナイメージは、直近 30 日以内にプルされている間は新しい脆弱性情報で継続評価される。30 日を超えると古い状態（stale）、90 日を超えるとアーカイブ状態になり、継続評価の対象外となる
• コンテナ外の言語パッケージを対象にするパッケージスキャンは、Artifact Registry のリポジトリごとに明示的に有効化する。既定では無効で、同じパッケージを複数リポジトリへ置いても重複排除されない
• 結果は Container Analysis のメタデータ（ノート/オカレンス） として保存され、API・gcloud・コンソールから取得できる
• オンデマンドスキャンは、レジストリ保存前のイメージにも使え、CI のゲートとして組み込める
• 自動スキャンには Container Scanning API、オンデマンドスキャンには On-Demand 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 の未有効化と、継続再評価の有効期間切れによる古いイメージの未反映

コスト

自動スキャンは一意なダイジェストの初回、オンデマンドスキャンは実行ごとに 1 件 0.26 米ドルです。同じコンテナダイジェストの再評価やタグ変更には再課金されません。コンテナ外パッケージは複数リポジトリへ同じ内容を置いても重複排除されないため、配置ごとに課金されます。

セキュリティ

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

関連サービス・比較

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

ハンズオン / CLI例

# 自動スキャン用とオンデマンドスキャン用の API を有効化
gcloud services enable \
  containerscanning.googleapis.com \
  ondemandscanning.googleapis.com

# Artifact Registry にある既存イメージをオンデマンドスキャン
gcloud artifacts docker images scan \
  asia-northeast1-docker.pkg.dev/PROJECT_ID/my-repo/web:latest \
  --remote \
  --location=asia

# 上の同期実行で返る完全なスキャン名を指定して脆弱性一覧を取得
gcloud artifacts docker images list-vulnerabilities \
  projects/PROJECT_ID/locations/asia/scans/SCAN_ID

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