共有脅威インテリジェンスを活用せよ、ISACに参加せよ、コミュニティフィードを自社のパイプラインに組み込め――こうしたアドバイスはよく聞かれますし、私自身もその通りだと思います。しかし誰も教えてくれないのが「運用マニュアル」です。なぜなら、アクセスすることは決して難しい部分ではなかったからです。脅威フィードとは、要するに他人のデータベースです。それは他人のプロセスによって構築され、他人の判断によって形作られ、他人の「最悪の火曜日」がそこに座ったまま、自動化がそれをもとに動き出すのを待っているのです。
私はGitHubでDependabotを運営するチームを率いています。Dependabotは2026年現在、3,000万以上のリポジトリを監視し、脆弱性のある依存関係や悪意のある依存関係を検出しています。今年、私たちはOpenSSFのmalicious-packagesリポジトリからコミュニティインテリジェンスを取り込むことで、悪意あるパッケージに関するアドバイザリの対象範囲を、3月から悪意あるパッケージの検出を行っていたnpmから、8つのパッケージエコシステムへと拡大しました。マルウェアアラートは、フィードの取り込みにとって過酷なテストケースです。通常の脆弱性であればアップグレードで解決できますが、悪意あるパッケージの場合はそうはいきません。パッケージを完全に取り除いた上で、ビルドが触れたすべての認証情報をローテーションする必要があります。しかも、その量が止まることはありません。2026年5月までの1年間で、私たちは1日あたり約18件の新たな悪意あるnpmパッケージをカタログ化しました。
実運用を経て残った教訓は5つあります。そして、それはパッケージのマルウェア報告を取り込んでいようと、OSVのレコードを扱っていようと、ISACの指標を処理していようと関係ありません。コミュニティのデータがあなたの自動化を支えているのであれば、これらの教訓はあなたにも当てはまります。
来歴情報は「取り消しボタン」である
まず問うべきなのは、居心地の悪い質問です。それは「レコードがどのようにパイプラインに入ってくるか」ではなく、「どのようにそこから出ていくか」です。上流のソースは間違いを公開することがあります。報告が誤ったパッケージ名に紐づくこともあれば、研究者が発見内容を撤回することもあります。深夜2時の一括インポートがうまくいかないこともあるでしょう。これは「もし」ではなく「いつ」の問題ですから、取り込むすべてのレコードには、それを生み出した上流の変更まで遡れる経路が必要ですし、インポートは一括で、一度の操作で、数分のうちに取り消せなければなりません。
来歴情報は、フィーチャーフラグやロールバックと同じ棚に置かれるべきものです。単なる記録ではなく、運用上の制御機能なのです。疑わしいレコードが浮上したとき、すべては「それを持ち込んだ正確な上流の変更まで追跡できるかどうか」にかかっています。「その変更に由来するものをすべて取り消す」のであれば迅速な是正で済みますが、「データベースを検索して、うまくいくことを祈る」ようでは最悪の一週間になってしまいます。
自分自身の水を飲むことになる
もしあなたの組織がコミュニティインテリジェンスに情報提供もし、それを消費もしているのであれば、遅かれ早かれ、自分たちの調査結果が他人のタイムスタンプをまとって戻ってくることになります。コミュニティのリポジトリは多くの貢献者からの報告を集約しますが、その集約の過程で「誰が最初に発見したか」というコンテキストが失われてしまいます。これを無警戒に取り込んでしまうと、自分たちの報告が独立した裏付けであるかのように装ってパイプラインに再び入り込むエコーチェンバーを作り出したり、元の報告と衝突して同一パッケージに対する重複アラートを発生させたりすることになります。
解決策は地味なものです。自分たちが提供した情報にフィンガープリントを付け、受信するすべてのレコードをそのフィンガープリントと照合し、自分たちのエコーを入口で除外することです。あるレコードを裏付けとして扱う前に、消費者は「これは自分たちから始まったものか」という一つの問いに答えられなければなりません。それに答えられないチームは、自分自身の声を測定しているだけなのに、それをコンセンサスと呼んでいるのです。
予算の大半は正規化に費やされる
脅威データそのものは華やかな部分です。しかし本当の作業は、各エコシステムが何一つ足並みを揃えていないという現実への対処にあります。あるレジストリはパッケージ名を大文字小文字を区別するものとして扱う一方、別のレジストリはそうしません。影響を受けるバージョンは、あるフォーマットでは正確なピン留めとして届き、別のフォーマットでは境界の意味論が微妙に、しかし厄介なほど異なる範囲指定として届きます。深刻度の語彙も一致しません。そして、これらの問題は決して派手に失敗しません。バージョン範囲のマッピングを一つ誤るだけで、影響を受けなかった何千人ものユーザーにアラートが飛んだり、逆に影響を受けたユーザーには何も通知されなかったりします。しかも、そのどちらの失敗も、内部から見れば正常に動作しているシステムのように見えてしまうのです。
ですから、これに対して予算を確保してください。マッピングと検証のレイヤーが、私たちのエンジニアリングコストの大半を占め、正確性に関するリスクのほぼすべてを抱えています。もし統合作業の見積もりが主に転送とストレージに関するものであるなら、その見積もりは誤っています。
自動化に必要なのは「レビュアー」ではなく「被害範囲の限定」
8つのエコシステムにわたって1日あたり数十件のレコードという規模では、レコードごとの人間によるレビューは形だけのものにすぎません。スケールしませんし、それが可能であるかのように装うことは、疲弊をユーザーから社内のキューへと静かに移し替えているだけで、そこにいずれ滞留が生まれます。私たちのマルウェアアドバイザリは自動的に公開されます。誰もそれを一つひとつ読んでいるわけではありません。これは意図した設計上の判断であり、私はそれを擁護します。
それを擁護できる理由は、信頼ではなくエンジニアリングにあります。1回のインポート実行で作成できるアドバイザリの数には上限が設けられているため、破損した上流のバッチが、人が気づく前に大量のアラートを氾濫させることはありません。すべてのバッチは一つの単位として取り消すことができます。通常の一日と比べて量や形状に異常があれば、それがフラグ立てされます。あらゆる自動化パイプラインにとって適切な問いは、「誰が各レコードを承認するか」ではありません。「人が気づく前に、このシステムが犯しうる最大の間違いは何か、そして、それをどれだけ早く取り消せるか」なのです。
静かに修復するのではなく、大きな音を立てて失敗せよ
フィードの取り込みにおいて最も魅力的に見える判断は、静かに修正することです。上流のレコードに不正な形式のバージョン範囲が含まれているとき、パーサーはその意図を推測できるかもしれませんし、その推測はおそらく正しいでしょう。しかし、それに抗ってください。静かな修復は、他人の誤りを自分の負債に変えてしまいます。その推測はあなたの名前のもとで世に出て、下流の消費者はそれを引き継ぎ、上流のソースは自分たちのレコードが壊れていたことを永遠に知らないままになります。
無効なレコードは隔離(クアランティン)に送られ、上流にレポートを生成すべきです。時間はかかりますが、正しいやり方です。また、それはあなたを共有財産のより良い一員にもします。共有インテリジェンスは、消費者が品質に関するシグナルを内々で回避するのではなく、上流に押し戻すことによってのみ向上するからです。
公開する前に
次のフィード統合に向けた簡単な自己チェックです。あなたは、あるレコードをその上流の発生源まで追跡できますか。インポートのバッチを一度の操作で取り消せますか。自分たちの貢献したデータが巡り巡って戻ってきたとき、それだと気づけますか。正規化は、あなたの見積もりにおいて、それが現実で占めるのと同じくらいの比重を占めていますか。そして、上流のデータが壊れているとき、あなたのパイプラインはそれに異議を唱えますか、それとも推測してしまいますか。
共有された脅威インテリジェンスは、この業界が合意している数少ないアイデアの一つであり、その合意にふさわしい価値を持っています。そして、それを支えるコミュニティのソースには、より少なくではなく、より多くの消費者が必要です。しかし、フィードとはニュースレターの購読とは違います。それは、自動化された結果が組み込まれた、他人のデータベースのライブレプリカなのです。それに見合った真剣さをもって運用すれば、ユーザーをより安全にすることができます。単なるチェックボックスとして扱ってしまえば、遅かれ早かれ、他人の最悪の一日を自分自身の中で自動化してしまうことになるでしょう。
翻訳元: https://www.helpnetsecurity.com/2026/09/03/github-threat-intelligence-feed-ingestion/
