概要：なぜコンテナレジストリの侵害が増えているのか
コンテナイメージはアプリケーションの配布単位として幅広く使われるため、攻撃者にとっては「一度汚染すれば多くを侵す」魅力的な攻撃面です。公開レジストリ（Docker Hub 等）では、メタデータ改竄や正規パブリッシャーの認証情報窃取を経てマルウェア入りイメージや情報窃取コードが流通する事例が確認されています。最近の大規模事例としては、2026年3月にTrivyのDockerイメージが改竄され、CI/CDシークレットやクラウド認証情報が流出した可能性が報告され、同年4月にはCheckmarxのKICS用イメージに不正なイメージがプッシュされた事例も公開されています。これらは“正規の公開フロー”が攻撃経路になった典型例です。
（参照：Trivy／Docker Hubインシデント（2026年3月19–23日）、Checkmarx KICS イメージ改竄（2026年4月22日）など）。
代表的な最新事例（短いタイムライン）
- Trivy イメージの供給連鎖侵害（2026年3月19–23日）：Trivyの特定タグ（例：0.69.4～0.69.6およびlatest）が改竄され、CI/CDシークレットやSSH鍵、Docker設定が漏えいした可能性があると報告されています。被害対象はこれらイメージをCIで自動取得していたユーザーです。
- Checkmarx/KICS リポジトリの不正公開（2026年4月22日）：正規のパブリッシャー資格情報を用いて悪性イメージが公開され、多数の利用組織に影響を与えうる状況が確認されました。攻撃はIDE拡張やサードパーティ経路からの資格情報窃取が発端であったと考えられています。
- Docker Hub上の“imageless”／悪意あるメタデータキャンペーン（2024年4月発見）：JFrog等の研究で、コンテンツが無いリポジトリに悪意あるリンクやメタデータを埋める大規模キャンペーンが確認されており、ユーザ誘導やtyposquatting的攻撃に悪用されています。
加えて学術調査では、公開イメージ内に秘密情報（APIキー・秘密鍵等）が含まれる割合が一定程度存在することも示されており、〈イメージ自体に機密が埋め込まれる〉リスクも無視できません。
企業が今日から実行すべき防御チェックリスト（優先度順）
署名と検証をパイプラインの必須にする（高）
ビルド完了時に必ずコンテナイメージを署名し、実行前に検証する仕組みを導入します。Sigstore／cosign を用いた署名と、Kubernetesでは Sigstore policy-controller 等のAdmission Controllerで“署名済みかつ信頼できる発行元”のみを許可する設定を必須化します。これにより、レジストリ上での不正プッシュやタグのすり替えがあっても、署名が無ければ展開を阻止できます。
CI/CD とレジストリの資格情報ハードニング（高）
CIのトークンは最小権限・短寿命（fine‑grained token／期限付き）で発行し、秘密はVaultなどの専用シークレットストアで管理します。ビルド環境やIDE拡張の侵害でパイプライン権限が盗まれないよう、トークン回転・監査ログ・異常使用のアラートを設定します。OCIレジストリ側でも可能ならOIDCベースの短期トークンを使用してください。
SBOM と SLSA（供給連鎖保証）の実装（中〜高）
各イメージにSBOM（CycloneDX/SPDX）を付与し、SLSA の原則（ビルドの再現性、複数承認など）を段階的に導入します。SBOMは脆弱性の可視化と、どのビルドがどのアーティファクトを作ったかの追跡に役立ちます。
イメージの自動スキャンとメタデータ監査（中）
レジストリにプッシュされたイメージは自動でVulnerability/Static解析と秘密情報スキャンを実行し、疑わしいメタデータ（README／説明文の悪性リンク等）を検出するルールを設けます。ツールとしてはTrivy/Grype/Snyk/Syft等を組み合わせます（ただしTrivy自体が供給連鎖侵害の対象となった例もあるため、ツールの出所と署名を確認してください）。
ランタイムの最小権限化とホスト保護（中）
Pod／コンテナは非rootで実行し、readOnlyRootFilesystem を有効、Linux capabilities を drop: ["ALL"] して必要分だけ付与する等のCIS推奨設定を徹底します。これにより、万一イメージに悪性コードが含まれても被害拡大を抑えられます。
レジストリ・CIのモニタリングとアラート（中）
プッシュ／タグ付け／トークン発行といったイベントを監査ログに出力・外部保管し、異常なパブリッシュ、短時間での大量プッシュ、正規と齟齬のあるリリース（タグとGitHubリリースが一致しない等）を検出するSIEMルールを整備します。
サプライヤ／OSS使用ポリシーとブラックリスト（低〜中）
第三者イメージの利用は原則禁止か、認定済みプロバイダのみを使用するルールを策定します。Docker社等が公開する“hardened images”カタログのような信頼済み配布を活用すると導入コストを下げられます。
事故対応（IR）プレイブック準備（高）
イメージ改竄が疑われる場合の手順を定義します：影響範囲（digestでの検索）、CIビルド履歴の保存、関連トークンの即時無効化、K8s上の該当Podの隔離とスナップショット取得、法務／ベンダ連絡テンプレの準備などです。Dockerやレジストリベンダーの通知チャネルを事前に登録しておきます。
実務的な導入例（短い実装ガイド）
以下は実務チームが取り組みやすい導入スコープ例です。
| 短期（1–2週） | 中期（1–3ヶ月） | 長期（3–12ヶ月） |
|---|---|---|
| 署名ポリシー設計、重要リポジトリの署名必須化 | CIでのSBOM生成と自動スキャン導入 | SLSA適合（ビルドの再現性・マルチ承認）と完全自動化 |
| トークンの即時最小権限化と回転方針 | Admission Controllerで署名検証を強制 | 全社イメージの署名・SBOM・VEX連携による完全追跡 |
| 署名されていないイメージのデプロイ禁止ルール | レジストリ監査ログのSIEM連携 | サプライヤ評価と契約上のセキュリティ要件化 |
これらの実装はツール選定や既存CIとの相性で手順が異なります。まずは最も影響が大きい“署名と検証”の自動化から着手することを推奨します。
まとめと次の一手
公開コンテナレジストリを狙う攻撃は増加傾向にあり、攻撃手法は「資格情報窃取」「正規フロー悪用」「メタデータ悪用」など多様です。最も効果的な初動は“署名の導入と展開前の検証”です。加えて、CIトークンの最小権限化、SBOMの付与と管理、ランタイムの最小権限化を組み合わせた多層防御でリスクを低減してください。
この記事で引用した公式調査・企業アナウンス（Docker公式、JFrog報告、学術調査、Sigstoreドキュメント等）を基に、まずは署名+Admission ControllerのPoCを実施することを強く推奨します。