> For the complete documentation index, see [llms.txt](https://help.aikido.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.aikido.dev/docs/docs-ja/kontenaimjisukyan/container-image-scanning-overview.md).

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

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><a href="/pages/02dcac33b4672cefd400c511b0edae1e19f3b4f1"><strong>コンテナレジストリを接続</strong></a></td><td></td><td><a href="/pages/02dcac33b4672cefd400c511b0edae1e19f3b4f1">/pages/02dcac33b4672cefd400c511b0edae1e19f3b4f1</a></td></tr><tr><td><a href="/pages/1a016dceeeda839a32e29a474c5b2318a3ed4bd4"><strong>スタンドアロンのレジストリを接続</strong></a></td><td></td><td><a href="/pages/1a016dceeeda839a32e29a474c5b2318a3ed4bd4">/pages/1a016dceeeda839a32e29a474c5b2318a3ed4bd4</a></td></tr></tbody></table>

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

{% hint style="info" %}
Aikido は、静的イメージとクラスターにデプロイされたコンテナの両方をスキャンします。詳細はこちら: [クラスター内イメージスキャン](https://help.aikido.dev/cloud-scanning/kubernetes-cluster-scanning/kubernetes-in-cluster-image-scanning).
{% endhint %}

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

コンテナイメージは、アプリケーションコード、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 には次のためのエンドポイントがあります: [生成](https://apidocs.aikido.dev/reference/generatecontainersbom) に設定し、 [ダウンロード](https://apidocs.aikido.dev/reference/exportcontainerrepolicenses) スキャン済みイメージの 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**](/docs/docs-ja/autofix-to/scope/autofix-for-containers-using-aikido-images.md)、コンテナ向けの CVE ゼロのベースイメージのレジストリを提供します。これらは次のとおりです:

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

#### リポジトリとレジストリとの連携

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

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

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.aikido.dev/docs/docs-ja/kontenaimjisukyan/container-image-scanning-overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
