Docker · Kubernetes · Trivy · CISA KEV · EPSS
コンテナイメージの脆弱性スキャン・通知・修正
KestreLynxは、Docker・Kubernetesで稼働中のコンテナが使うイメージをTrivyで定期的にスキャンするOSSです。前回からの変化と、深刻度・CISA KEV・EPSSに基づく優先度をSlackやWebhookへ通知します。Docker・Compose向けには、修正計画と修正PR（実験的）を備え、同じ条件での再スキャン結果の比較とGitHubへのPR作成を通じて修正を支援します（既定で無効）。
オープンソース · AGPL-3.0
🛡️ KestreLynx [prod-vps] — 2026-06-28 09:00のスキャン結果
イメージ12件をスキャン、1件に影響あり
前回のスキャンからの変化
🆕 前回のスキャンからの新規検出 (1件)
イメージ: nginx:1.25.3
◆ libnghttp2-14
現在: 1.52.0-1
修正版: 1.52.0-1+deb12u1
更新の注意度: 🟢 ディストリのセキュリティパッチ
検出件数: CRITICAL 0 / HIGH 2
代表CVE: CVE-2023-44487 · HIGH · EPSS >99% (このパッケージにほか +1件のCVE)
悪用情報: CISA KEV (実際の攻撃で悪用あり)
参照: アドバイザリ · ベンダーのアドバイザリ · 💬 HN (166 pts)
📌 現在の未解決: 🚨 今すぐ対応1件
diffモード、notify.language: jaでの通知のサンプルです。値は説明用で、実環境のスキャン結果ではありません。- 新規検出 「前回のスキャンからの新規検出」でイメージとパッケージを確認
- 修正版の有無 「現在」と「修正版」で使用中のバージョンと修正版を確認
- 優先度 「現在の未解決」で優先度別の件数、KEVとEPSSで判断材料を確認
前回からの変化を追う
差分通知で、新規検出、CVEの追加、修正版の提供開始、優先度の上昇、監視範囲から消えた検出を確認できます。未解消の検出があれば変化のない日も短い通知が届き、既定では月曜の通知に全件レポートが加わります。
KEVとEPSSを確認の優先順位に
深刻度にCISA KEVとEPSSの情報を組み合わせ、「今すぐ対応」「要監視」「低優先度」に分類します。確認する順番の判断材料であり、その環境で悪用できるかを確定するものではありません。
Trivyの結果に修正版と更新の注記を添える
Trivyでスキャンし、既定では修正版のないものも含めてHIGH・CRITICALの脆弱性を報告します。パッケージごとに修正版があればそのバージョンと更新リスクの目安を示しますが、互換性は保証しません。
修正計画と修正PR（実験的）
Docker・Compose向けに、次の3種類のソースの変更を提案できます。
- Composeファイルの配布イメージのタグ
- Dockerfileのベースイメージのタグ
- npm・pnpm・pip・uvで管理する言語パッケージの依存
修正計画と修正PRは、どちらも既定で無効です。計画は候補の選定、スキャン結果の比較、 通知を行い、GitHubへの書き込みや作業用コンテナの起動は行いません。 PRを別途有効にすると、GitHubへの変更と、言語パッケージ更新用のDockerの作業用コンテナを使います。
候補やPRがあることは、稼働イメージが修正済みであることを意味しません。 比較した範囲を確認し、マージ前にCIを実行してください。再ビルドとデプロイは別途必要です。
設定、通知、権限は修正計画と修正PR（実験的）に記載しています。
用途・対応範囲・必要な権限
セルフホストしているサービスについて、稼働中のコンテナが使うイメージの脆弱性を継続して確認する用途に向いています。
- Docker
- ホストごとに1インスタンスを配置し、複数のComposeプロジェクトと単独コンテナをまとめて対象にする
- Kubernetes
- クラスタ内のDeploymentから、読み取り専用のAPI権限を持つServiceAccountで全namespaceまたは指定namespaceの稼働中コンテナを発見する
- Kubernetesの検証範囲
- linux/amd64の単一ノードK3s＋containerdのみ検証済みで、複数ノード、arm64、マネージドKubernetes、認証付きプライベートレジストリは未検証 検証の記録
- 発見の範囲
- 発見時に稼働中のコンテナが対象で、Kubernetesのネイティブsidecarを含み、通常のinit containerとephemeral containerは対象外
- Docker socketの権限
- コンテナ情報やイメージの読み取りに加え、修正PR有効時は言語パッケージ更新用の作業用コンテナの作成・起動・削除にも使い、
:roはDocker APIの権限を制限せず:rwへの変更も不要なため、接続先のイメージを信頼できることが前提
セットアップ
Docker Composeでの手順です。Docker Composeが使えるDockerホストと、通知先が1つ以上必要です。通知先はSlack Incoming Webhook、Slack Botとチャンネル、汎用Webhookから選べます。Kubernetesでの手順はセットアップを参照してください。
-
リポジトリを取得してディレクトリへ移動する
-
設定ファイルを作る
設定例を
config.ymlにコピーし、通知先とnotify.language: jaを設定する -
タイムゾーンを確認して起動する
スキャン時刻は
docker-compose.ymlのTZに従うため、既定のUTCを確認し、日本時間ならAsia/Tokyoに変更する -
ログで起動とスキャンを確認する
設定例では起動時に1回スキャンし、以後は毎日09:00に実行する
差分通知や初回検出日の履歴を保つため、コンテナを作り直すときもkestrelynx-stateボリュームは削除しない