対象：自分で運用するサイトやサービスの脆弱性情報を、人が見張らなくても拾える状態にしたい人。何を拾い、何と照合し、どこまでAIに任せるかに絞ります。
何があったか：3回続けて、人のほうが先に知った
当サイトの運営者が関わるサイトで、1週間のうちに次の3つが起きました。どれも、運営者はSNSかメールで先に知り、自動の監視はその時点で何も出していませんでした。
1件目
PHPの脆弱性。運営者が先に知った。自動監視は未検知。2件目
Pythonパッケージへの悪意あるコードの混入。運営者が先に知った。自動監視は未検知。3件目
コンテナのベースイメージの問題。運営者が先に知った。自動監視は未検知。
最初に疑ったのは「情報源が足りない」ことでした。原因は1つに絞れず、公式情報が「話題になる」より遅れること（後述）に加えて、「うちの構成に関係がある」と判定する材料が足りないことも原因の1つでした。「PHP」「Python」のような技術名の言葉は、記事やニュースの本文には出ても、自分が使っているパッケージ名とは別のものだからです。
作り直した監視の仕組み
①集める
公式アドバイザリ／GitHubのアドバイザリ／悪意あるパッケージの一覧／KEV／ニュース／SNS
↓
一覧A：使っている技術の言葉
広く拾う
一覧B：実際の部品名
ロックファイル＋OSパッケージから生成
↓
②ルールで拾う（AIなしで動く）
↓
③安価なAIが一次判定
緊急度を上げることだけできる。下げることはできない。
- 集める範囲：公式アドバイザリ、GitHubのアドバイザリ、悪意あるパッケージの一覧、CISAのKEV、ニュース、SNS。
- 2本の一覧で照合する：「使っている技術の言葉」で広く拾い、「実際に使っている部品の名前」で確度の高い一致を取る。部品の一覧は、すべてのリポジトリのロックファイルとOSパッケージから作る。
- イメージ全体を走査する：アプリの依存だけでなく、ベースイメージを含むイメージ全体を調べる。
- ランタイムの古さを測る：Node、PHP、データベースなどが、最新の版からどれだけ遅れているかを確認する。
- AIの一次判定：安価なAIモデルが「うちに影響するか」を最初に判定する。AIは緊急度を上げる方向にだけ働く。
実測で分かったこと（予想と違った点を含む）
最初の仮定：公式情報だけで足りる
公式アドバイザリとKEVを見ていれば、重要なものは拾えると考えた。しかし実際には、「話題になる」ほうが「公式の告知が出る」より先に起きることがあった。公式情報だけでは、この競争に負ける。
実測後：SNSも入口に加える
SNSを入口に加えると、公式情報より早く気づけるようになった。ただしSNSの情報は、公式の確認が取れるまで事実として扱わない。入口は広く、判断は慎重にする。
- 見落としの検証：別の目的（記事の候補探し）で10日間に集めた重大な脆弱性、約100件を、この監視の結果と突き合わせました。運営者のサイトに影響するものの見落としは0件でした。
- AIの利用枠切れ：月の利用枠を使い切り、AIの一次判定が約6日止まりました。AIを使わないルール照合は、その間も動き続けました。設計としては「停止期間の終わりの日をあらかじめ決めておき、その日から自動で再開する」形にしています。
- 新しいサーバーの抜け：新しく追加したサーバーのOSパッケージが、部品の一覧に入っていませんでした。月に一度の一覧の作り直しで見つかりました。一覧は作って終わりではなく、定期的に作り直して初めて信頼できます。
自分の環境で作る手順
部品の一覧（SBOM）を機械的に作る
各リポジトリのロックファイルと、サーバーやコンテナのOSパッケージの両方から作ります。CISAはSBOMを「ソフトウェアを構成する部品の入れ子の一覧」と説明しています。SBOM生成ツールには、コンテナイメージやファイルシステムからOSパッケージと主要言語の依存を読み、CycloneDXやSPDX形式で出力できるオープンソースのSyftなどがあります。
一覧に対して既知の脆弱性を照合する
依存パッケージの照合には、ロックファイルやコンテナを読むオープンソースのosv-scannerが使えます。導入とCIへの組み込みは osv-scannerの導入と使い方 にまとめています。
優先度は KEV と EPSS で付ける
件数が多いと、すべてを同じ重さでは直せません。実際に悪用が確認されたもの（KEV）と、悪用される確率が高いもの（EPSS）から直します。使い分けは CVSS・EPSS・KEVの使い分け に書きました。
AIを使うなら、上げる方向だけに使う
AIの判定が「影響なし」でも、ルールが拾った項目を消さないようにします。AIは誤って「関係ない」と言うことがあり、見落としの被害は誤警報の手間より大きいからです。
AIが使えない日の動きを決めておく
利用枠の切れ、障害、サービスの停止は起こり得ます。AIなしのルールだけで最低限の通知が出ること、再開日を設定して自動で戻ることを、運用の前に決めておきます。
一覧を定期的に作り直す
サーバーやリポジトリを追加したのに一覧へ反映されていない、という抜けは起きます。月に一度は作り直し、増えたものが入っているかを確認します。
SNSの情報は、公式の確認が取れるまで事実として扱わない
SNSは早い反面、誤情報や、公式がまだ確認していない推測が混じります。入口としては有用でも、対応を決める根拠は、ベンダーの公式アドバイザリやKEVなど、確認できる一次情報に置いてください。
当サイトの視点：技術名は広く拾い、部品名で絞る
当サイトの運営者の経験では、実際の部品名での照合に切り替えると、ヒットと見落としが減りました。ただし部品名の一覧が古いと、見落としに直結します。広く拾う網と、正確に絞る一覧の両方が要ります。なお本記事で説明したのは、運営者が関わるサイトのために作った監視の話です。
出典（一次情報・公式資料）
- CISA — Known Exploited Vulnerabilities Catalog（実際に悪用が確認された脆弱性の一覧）
- CISA — Software Bill of Materials (SBOM)（SBOMの定義）
- FIRST — EPSS（悪用される確率の予測）
- OpenSSF — malicious-packages（悪意あるパッケージの報告をOSV形式で集めたリポジトリ）
- Anchore — Syft（コンテナイメージ・ファイルシステムからSBOMを生成。CycloneDX・SPDX出力、OSパッケージと主要言語に対応）