コンテナイメージスキャンの概要

コンテナレジストリを接続する

スタンドアロンレジストリを接続する

Aikidoのコンテナイメージスキャンは、イメージを主要なセキュリティ資産として扱うよう設計されています。通常は分断されている3つの要素、すなわちレジストリ（イメージが存在する場所）、コード（実際に問題を修正できる場所）、ランタイム（リスクが顕在化する場所）を接続します。

Aikidoは、静的イメージとクラスターにデプロイされたコンテナの両方をスキャンします。詳細はこちら： クラスター内イメージスキャン.

コンテナイメージスキャンの定義

コンテナイメージは、アプリケーションコード、OSパッケージ、言語ランタイム、Webサーバー、サポートツールを単一の不変アーティファクトにまとめたものです。Aikidoのコンテナイメージスキャンは、これらのアーティファクトにおける大きく3つのリスクカテゴリに焦点を当てます。

1. 既知の脆弱性（CVE） OSパッケージやその他のコンポーネントに含まれるもの。
2. 古い、またはサポート終了（EOL）のランタイム （例：言語ランタイムやWebサーバー）。
3. ソフトウェア構成とライセンス（詳細なソフトウェア部品表（SBOM）を通じて）。

AWS ECRなどのレジストリのスキャンを有効にすると、Aikidoはイメージの脆弱性、ライセンス、EOLランタイムを検査し、定期的に再スキャンします。これにより、イメージが最近再ビルドまたはプッシュされていなくても、新しいCVEを検出できます。

Aikidoは、イメージ内で検出された主要なランタイム（Python、Node.js、PHP、Nginxなど）のステータスも追跡し、次のように分類します： 古い, まもなく古くなる, 最新、または 見つかりません。これはベンダーのサポート期限に基づいています。ランタイムがEOLに近づく、またはEOLを過ぎると、Aikidoはアラートを発生させ、非推奨日が近づく、または過ぎるにつれて重大度を引き上げます。これは、すべてが正常に動作しているように見える場合でも、セキュリティ更新が停止することをコンテナ所有者が早期に把握できるようにするためです。

最後に、Aikido独自のスキャナーでスキャンしたイメージについては、生のソフトウェア部品表をエクスポートできます。SBOMには、検出されたコンポーネントのファイルシステム上の場所と、その出所に関する情報が含まれます。脆弱性、ランタイムのステータス、SBOMデータが組み合わさって、Aikidoのコンテナセキュリティモデルの基盤を形成します。

Aikidoがイメージデータを取得する場所

Aikidoは、存在するイメージの信頼できる情報源としてコンテナレジストリ（またはビルドパイプライン）を扱い、さまざまな環境にまたがる検出結果を標準化します。

クラウドレジストリ

ほとんどのクラウドレジストリでは、クラウドプロバイダーのスキャナー（例：AWS ECS向けのAWS Inspector）またはAikidoスキャナーを使用できます。Aikidoスキャナーを使用する場合、Aikidoは次を追加します：

• ライセンスおよびEOLランタイムのスキャン。
• タグレベルの対象指定（つまり、特定のタグに一致するイメージのみをスキャン）
• 最近プッシュされていないイメージも含め、毎日のスケジュールで継続的にスキャンすることで、新たに公開されたCVEを時間の経過とともに検出します。

スタンドアロンレジストリ

Aikidoは、Docker Hubなどのスタンドアロンレジストリにも直接接続します。読み取り専用アクセストークンを提供すると、Aikidoはアクセス可能なリポジトリを列挙し、必要に応じてより良い重複排除のためにコードリポジトリへリンクし、脆弱性をスキャンして結果をAikidoフィードに表示します。

ローカルイメージスキャンとゲーティング

すべてのイメージが継続的インテグレーションシステムの外部に出るわけではありません。このようなイメージ向けに、Aikidoは自身の環境で実行できるローカルイメージスキャナーを提供します。このスキャナーは次のことができます：

• イメージをローカルでスキャンし、問題をAikidoに報告する。
• リリースゲートとして機能し、レジストリへプッシュする前に、選択した重大度以上の問題が存在する場合はパイプラインを失敗させる。
• プルリクエストゲートとして機能し、プルリクエストからビルドされたイメージのセキュリティ態勢をベースコミットと比較し、しきい値を超える新たな問題が導入された場合は失敗させる。

これにより、コンテナセキュリティをデプロイ後の定期チェックだけでなく、ビルドとリリースを守るガードレールとして扱えるようになります。

イメージをコードおよびクラウドコンテキストにリンクする

イメージ内の脆弱性は、それを修正できるチームとコードに対応付けられて初めて有用になります。Aikidoのモデルは、コンテナをリポジトリおよびクラウドアセットにリンクすることを明確に中心として構築されています。

コンテナイメージは、対応するコードリポジトリに手動またはスマートな提案を通じてリンクできます。リンク後：

• コンテナの問題が、関連するリポジトリ内に直接表示される
• Aikidoがイメージに関連付けられたDockerfileを確実に特定できるため、Container AutoFixが利用可能になる（下記参照）

SBOMとソフトウェアサプライチェーンの可視性

コンテナのソフトウェア部品表は、イメージに何が含まれ、それがどこから来たのかを具体的に把握するのに役立ちます。イメージがスキャンされると、コンテナ詳細ページから生のSBOMをエクスポートできます。エクスポートは次をサポートするよう設計されています：

• 確認する ファイルシステム上の場所を 特定のコンポーネント（およびその脆弱性）が検出された場所。
• レイヤーをまたいでインストール済みコンポーネントの出所を追跡する。

SBOMの生成は、次のエンドポイントを公開するAikidoのパブリックAPIを通じて自動化することもできます： 生成 と ダウンロード スキャン済みイメージのSBOM。

ランタイムとサポート終了リスクの監視

コンテナにおける影響の大きい問題の多くは、単一のCVEではなく、ベンダーのサポート対象外となったランタイムやWebサーバー上で実行していることから発生します。レジストリを接続すると、AikidoはPythonやNode.jsのランタイム、ApacheやNginxなどの一般的なWebサーバーを含む、イメージ内の主要なランタイムを監視します。

監視対象の各ランタイムについて、Aikidoは「古い」「最新」「まもなく古くなる」などのステータスを割り当てます。また、特定のパッケージバージョンがベンダーによって保守されなくなる場合、Aikidoはフィードにアラートを作成します。これは非推奨化の前から開始され、日付が近づき、過ぎるにつれて問題の重大度が上がります。

コンテナ向けAI AutoFix

コンテナスキャンは、脆弱性がどこに存在するかを特定します。コンテナ向けAutoFixは、最小限の手動操作で、脆弱性を取り除くためにイメージを変更するのに役立ちます。

ベースイメージ中心の修復

Aikidoがコンテナのベースイメージ内で脆弱性を検出すると、AutoFixはそのベースイメージを更新するDockerfileの変更を提案します。複数の更新オプションを提案し、それぞれ特定のベースイメージに紐付いた3～5種類のDockerfileバリアントを生成します。各バリアントについて、AutoFixは修正される脆弱性と、新たに導入される脆弱性の有無を表示します。

Aikido Images

より新しいOSリリースまたはベースイメージへのアップグレードにコストやリスクが伴う場合、Aikidoは Aikido Imagesを提供します。これは、コンテナ向けのCVEゼロのベースイメージレジストリです。これらは：

• 保守中およびサポート終了済みのベースイメージの両方で利用可能
• 既知のCVEを除去しつつ互換性を維持することを目的とした、置き換え可能な代替品として提供される
• 300種類以上のベースイメージとして利用でき、長期的な置き換えとしても、完全なアップグレードが可能になるまでの暫定措置としても使用可能

リポジトリおよびレジストリとの統合

Container AutoFixは、前述のリンク手順に依存します：

• コンテナをリポジトリにリンクすると、それらのコンテナでAutoFixが有効になり、Dockerfileが正しく特定されることが保証されます
• プライベートベースイメージがAikidoによってスキャンされている限り、AutoFixはパブリックおよびプライベートの両方のベースイメージで機能します。

オプションを選択すると、AutoFixは更新されたDockerfileと関連する変更を含むプルリクエストをソース管理システムに生成します。イメージごとに手動で実行することも、選択したイメージに対して定期的にPRを作成するよう設定することもできます。