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


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

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

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

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

OSパッケージやその他のコンポーネントにおける既知の脆弱性（CVE）
古くなった、またはサポート終了（EOL）のランタイム（言語ランタイムやWebサーバーなど）
詳細なソフトウェア部品表（SBOM）によるソフトウェア構成とライセンス

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

Aikidoはまた、イメージ内で検出された主要なランタイム（Python、Node.js、PHP、Nginxなど）のステータスを追跡し、ベンダーのサポート期限に基づいてOutdated、Almost Out-of-Date、Up-to-Date、Not Foundに分類します。ランタイムがEOLに近づく、または過ぎると、Aikidoはアラートを発し、非推奨日が近づき、また経過するにつれて深刻度をエスカレーションします。これにより、見た目には正常に動作していても、セキュリティアップデートが停止することをコンテナ所有者が早期に把握できます。

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

Aikidoがイメージデータを取得する仕組み

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

クラウドレジストリ

ほとんどのクラウドレジストリでは、クラウドプロバイダーのスキャナー（AWS ECSの場合はAWS Inspectorなど）またはAikidoスキャナーのいずれかを使用できます。Aikido Scannerを使用する場合、Aikidoは以下を追加します。

ライセンスとEOLランタイムのスキャン
タグ単位でのターゲティング（特定のタグに一致するイメージのみをスキャン）
最近プッシュされていないイメージも含めた、毎日のスケジュールによる継続的スキャン。これにより、新たに公開されたCVEを時間をかけて捕捉します

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

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

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

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

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

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

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

イメージ内の脆弱性は、それを修正できるチームとコードに紐付けられて初めて有用になります。Aikidoのモデルは、コンテナをリポジトリおよびクラウド資産にリンクすることを前提に明確に設計されています。

コンテナイメージは、対応するコードリポジトリに手動で、またはスマート提案によってリンクできます。リンクされると、以下が可能になります。

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

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

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

特定のコンポーネント（およびその脆弱性）が発見されたファイルシステム上の場所の確認
レイヤー間でのインストール済みコンポーネントの出所の追跡

SBOMの生成は、Aikidoの公開APIを通じて自動化することもできます。APIには、スキャン済みイメージのSBOMを生成およびダウンロードするためのエンドポイントが用意されています。

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

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

監視対象の各ランタイムに対して、Aikidoは「Out of date」「Up to date」「Almost out of date」といったステータスを割り当てます。また、特定のパッケージバージョンがベンダーによって保守されなくなった場合、非推奨化の前からフィードにアラートを作成し、期日が近づき、また経過するにつれてIssueの深刻度を高めていきます。

コンテナ向けAI AutoFix

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

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

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

Aikido Images

新しいOSリリースやベースイメージへのアップグレードがコスト面やリスク面で見合わない場合、Aikidoはコンテナ向けのゼロCVEベースイメージのレジストリであるAikido Imagesを提供しています。これらは次のような特徴を持ちます。

保守されているベースイメージ、EOLのベースイメージの両方に対応
既知のCVEを取り除きながら互換性を保つことを意図した、そのまま置き換え可能な代替イメージとして提供
300を超えるベースイメージが利用可能で、長期的な置き換えとしても、完全なアップグレードが可能になるまでの暫定策としても使用可能

リポジトリおよびレジストリとの連携

Container AutoFixは、前述のリンク作業に依存しています。

コンテナをリポジトリにリンクすることで、そのコンテナに対するAutoFixが有効になり、Dockerfileが正しく特定されるようになります
AutoFixは、プライベートなベースイメージがAikidoによってスキャンされている限り、パブリック・プライベート両方のベースイメージに対応できます

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