日本語

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

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

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

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

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

コンテナイメージは、アプリケーションコード、OSパッケージ、言語ランタイム、Webサーバー、サポートツールを1つの不変のアーティファクトにまとめたものです。Aikido のコンテナイメージスキャンは、そうしたアーティファクトにおける4つの広範なリスクカテゴリに焦点を当てています。

  1. 既知の脆弱性（CVE） OSパッケージおよびその他のコンポーネント内。
  2. 古い、またはEOL（サポート終了）のランタイム （例: 言語ランタイムやWebサーバー）。
  3. ソフトウェア構成とライセンス、詳細なソフトウェア部品表（SBOM）を通じて。
  4. マルウェア イメージにインストールされているアプリケーションパッケージ内で（npm、PyPI、Maven、NuGet、Go、Cargo、RubyGems、Packagist）。

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 Scannerを使用すると、Aikidoは次を追加します:

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

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

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

ローカルイメージスキャンとゲート

すべてのイメージが継続的インテグレーション環境を離れるわけではありません。そうした場合に備え、Aikidoは自分の環境で実行するローカルイメージスキャナーを提供します。このスキャナーは次のことができます:

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

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

イメージをコードとクラウドのコンテキストに結び付ける

イメージ内の脆弱性は、それを修正できるチームやコードにマッピングできて初めて役立ちます。Aikidoのモデルは、コンテナをリポジトリおよびクラウド資産に結び付けることを明確に前提として構築されています。

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

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

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

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

  • 確認する fファイルシステム上の場所s 特定のコンポーネント（およびその脆弱性）が見つかった場所。
  • レイヤーをまたいでインストール済みコンポーネントの由来を追跡する。

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

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

コンテナにおける多くの重大な問題は、単一のCVEではなく、ベンダーサポート外になったランタイムやWebサーバー上で動作していることに起因します。レジストリを接続すると、AikidoはPythonやNode.jsのランタイム、ApacheやNginxのような一般的なWebサーバーなど、イメージ内の主要ランタイムを監視します。

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

コンテナ向けAI AutoFix

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

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

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

Aikido Images

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

  • 保守中のベースイメージとEOLベースイメージの両方で利用可能
  • 既知の重大（クリティカルおよび高）CVEを排除しつつ、互換性を意図したそのまま置き換え可能な代替として提供されます
  • 2000以上のベースイメージ が利用可能で、長期的な代替としても、完全なアップグレードが可能になるまでの一時的な手段としても使用できます

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

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

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

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