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

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

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

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 に近づく、または到達すると、Aikido はアラートを発し、非推奨日が近づくか過ぎるにつれて重大度を引き上げます。これにより、すべてがまだ動作しているように見えても、コンテナ所有者はセキュリティ更新が停止することを早期に把握できます。

最後に、Aikido 独自のスキャナーでスキャンされたイメージについては、未加工の Software Bill of Materials をエクスポートできます。SBOM には、検出されたコンポーネントのファイルシステム上の場所と、その由来に関する情報が含まれます。脆弱性、ランタイムの状態、SBOM データを合わせて、Aikido のコンテナセキュリティモデルの基盤を形成します。

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

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

クラウドレジストリ

ほとんどのクラウドレジストリでは、クラウドプロバイダーのスキャナー（例：AWS ECS の AWS Inspector）または Aikido スキャナーのどちらかを使用できます。Aikido Scanner を使用すると、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。

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

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

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

コンテナ向け AI AutoFix

コンテナスキャンは、脆弱性がどこにあるかを特定します。Container AutoFix は、最小限の手作業でイメージを変更し、脆弱性を取り除くのを支援します。

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

Aikido がコンテナのベースイメージで脆弱性を見つけると、AutoFix はそのベースイメージを更新する Dockerfile の変更を提案します。これは、複数の更新オプションを提示し、特定のベースイメージに結び付いた 3〜5 個の Dockerfile 変種を生成することで行われます。各変種について、AutoFix はどの脆弱性が修正され、どの新しい脆弱性が導入されるかを示します。

Aikido Images

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

• メンテナンス中のベースイメージと EOL ベースイメージの両方で利用可能
• 既知の重大な（critical および high）CVE を除去しつつ互換性を意図した、差し替え可能な代替品として提供される
• 2000 を超えるベースイメージ が利用可能で、長期的な代替としても、完全なアップグレードが可能になるまでの一時的な手段としても使えます

リポジトリとレジストリとの統合

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

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

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