> 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 自身のスキャナーでスキャンされたイメージについては、元のソフトウェア部品表をエクスポートできます。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 とソフトウェアサプライチェーンの可視化

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

* の **f**ァイルシステム上の場所を調べること**s** 特定のコンポーネント（およびその脆弱性）が見つかった場所。
* レイヤーをまたいでインストールされたコンポーネントの由来を追跡すること。

SBOM の生成は、Aikido の公開 API 経由でも自動化できます。この API は次のエンドポイントを提供します: [生成](https://apidocs.aikido.dev/reference/generatecontainersbom) および [ダウンロード](https://apidocs.aikido.dev/reference/exportcontainerrepolicenses) スキャンされたイメージの SBOM。

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

コンテナで影響の大きい問題の多くは、単一の 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 ゼロのベースイメージのレジストリです。これらは次の特徴を持ちます:

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

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

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

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

オプションを選択すると、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.
