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

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

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

Aikido のコンテナイメージスキャンは、イメージを一級のセキュリティ資産として扱うよう設計されています。通常はサイロ化されている 3 つのもの、つまりレジストリ（イメージが置かれる場所）、コード（実際に問題を修正できる場所）、ランタイム（リスクが現実化する場所）をつなぎます。

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

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

コンテナイメージは、アプリケーションコード、OS パッケージ、言語ランタイム、Web サーバー、支援ツールを 1 つの不変アーティファクトにまとめたものです。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 独自のスキャナーでスキャンされたイメージについては、生の Software Bill of Materials をエクスポートできます。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 とソフトウェアサプライチェーンの可視性

コンテナの Software Bill of Materials は、イメージの中に何があり、それがどこから来たのかを具体的に把握するのに役立ちます。イメージがスキャンされた後は、コンテナ詳細ページから生の SBOM をエクスポートできます。このエクスポートは次のことを支援するよう設計されています。

• 確認する fイルシステムの場所s 特定のコンポーネント（およびその脆弱性）が見つかった場所。
• レイヤー全体にわたるインストール済みコンポーネントの出自を追跡する。

SBOM の生成は、Aikido の公開 API を通じて自動化することもできます。API では次のエンドポイントが提供されています。 生成 に設定し、 ダウンロード スキャン済みイメージの SBOM。

ランタイムと EOL リスクの監視

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

監視対象の各ランタイムに対して、Aikido は「古い」「最新」「ほぼ期限切れ」などのステータスを割り当てます。Aikido はまた、特定のパッケージバージョンがベンダーによってサポートされなくなったとき、その非推奨前からフィードにアラートを作成し、日付が近づくほど、また過ぎるほど問題の重大度を引き上げます。

コンテナ向け AI AutoFix

コンテナスキャンは、脆弱性がどこにあるかを特定します。AutoFix for Containers は、最小限の手順でイメージを変更して脆弱性を取り除くのに役立ちます。

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

Aikido がコンテナのベースイメージに脆弱性を見つけると、AutoFix はそのベースイメージを更新する Dockerfile の変更を提案します。これは、複数の更新 विकल्पを提案し、特定のベースイメージに紐づく 3〜5 個の Dockerfile バリアントを生成することで行われます。各バリアントについて、AutoFix はどの脆弱性が修正されるか、また新たに導入されるものがあるかどうかを示します。

Aikido Images

新しい OS リリースやベースイメージへのアップグレードが高コストまたはリスキーな場合、Aikido は Aikido Imagesを提供します。これはコンテナ向けの CVE ゼロのベースイメージのレジストリです。これらは次の特徴があります。

• 保守中および EOL のベースイメージの両方で利用可能
• 既知の CVE を取り除きつつ、互換性を意図したドロップイン代替として提供
• 300 以上のベースイメージとして利用可能で、長期的な代替としても、本格的なアップグレードが可能になるまでの暫定措置としても使用可能

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

コンテナ AutoFix は、前述のリンク手順に依存します。

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

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