「Intelに出てこない脆弱性」の正体 — Aikido Intel は全CVE台帳ではなく、サプライチェーン脅威の心臓部である

まず、「Aikido Intel」とは何かを押さえておきたい。Intel は intelligence(脅威インテリジェンス)の略で、セキュリティベンダー Aikido が運営する脅威情報フィードの名前だ。npm・PyPI・Maven などオープンソースのパッケージエコシステムや、IDE・ブラウザの拡張を常時監視し、脆弱性や悪性パッケージ(malware)を早い段階で検知して知らせる——いわば、OSSサプライチェーンに迫る脅威の速報窓口である。

週次のCVEレポートを眺めていて、ふと手が止まった。ある週は新規脆弱性が1,900件超、実際に悪用が確認されたものが数件。Dell の端末から Cisco の通信基盤、CLIツールまで横断している。そして思う——「これ、Aikido Intel にはほとんど出てきていないな」と。

ここで多くの人が「Intel は取りこぼしているのか?」と考える。だが、それは問いの立て方が間違っている。Intel と週次CVEレポートは、同じCVEを扱っていても、そもそも別の集合を見ているからだ。本稿では、その関係を整理する。

CVE そのものは、同じものを見ている

まず誤解を解いておく。CVE-2026-XXXXX という識別子と公開脆弱性の基本レコードは CVE.org を起点に共有され、NVD などがそこに CVSS、CPE、影響を受ける製品といった運用上のメタデータを付加している。多くの脆弱性フィードは、この共有された基盤を参照している。つまり「CVEの中身がまったく別物になる」わけではない。

違うのは、CVE の周りだ。具体的には次の3点になる。

Aikido Intel は「全CVE」ではない

ここが本題だ。Aikido Intel は、カバーできるCVEをすべて持ってきているわけではない。理由は2つあり、しかも方向が逆を向いている。

方向①:見ている範囲が限定されている

Aikido Intel が対象とするのは、npm / PyPI / Maven / NuGet / RubyGems / Go / Rust / Packagist といったパッケージエコシステムと、VS Code・JetBrains などのIDE拡張、ブラウザ拡張の世界だ。NVDが日々積み上げるサーバOSやネットワーク機器、エンタープライズDBのCVEは、原則として入ってこない。

しかも Intel は、この範囲のCVEを機械的に全件ミラーするものではない。社内のリサーチチームとAIが「実際の脅威」として検知・検証したものを供給する threat feed であり、NVDの該当エントリをそのまま取り込む網羅型データベースとは性格が異なる。これは弱点というより、目的の違いだ。Intel は世界中のCVEを一覧するための台帳ではなく、開発者のサプライチェーンに関係する脅威を早く見つけるためのフィードだからだ。

方向②:CVEではないものを足している

もう一方の逆向きの動きが、見落とされがちだが本質的に重要だ。Aikido Intel には、CVE番号が付いていない脆弱性も多く含まれている。

Aikido は自前のリサーチで脆弱性を発見しており、同社の公表によれば、ローンチ以降「パッチは当たったが公開開示されなかった」脆弱性を511件発見し、発見した脆弱性の67%はどの脆弱性データベースにも公開開示されていなかったという。パッチとCVE採番の間には時間差があり、そもそも採番されないものも多い。こうした脆弱性には CVE ではなく AIKIDO-2024-XXXXX のような独自IDが振られる。

さらに、npm/PyPI への malware や typosquat、改ざんされたパッケージといった脅威は、そもそもCVEという枠組みに乗らない。これらも Intel の主要な対象だ。

「Intel」と「スキャナ」を混ぜない

ここで役割分担を整理しておきたい。よくある混同が、「Aikido は reachability で脆弱性を絞っている」という言い方だ。これは Intel とプラットフォーム(スキャナ)を一緒くたにしている。

正確には、層が分かれている。Aikido Intel は脅威情報を供給する側で、OSSの脆弱性・malware・悪性パッケージ・IDE/ブラウザ拡張の脅威を検知して流す。一方、実際にその脆弱性が「あなたのコードに効くか」を判定するのはスキャナ側だ。Aikido のプラットフォームが、依存関係・設定・コードからの到達可能性(reachability)を踏まえて、ユーザーにとっての優先度を上下させる。

つまり reachability による優先度付けは、Intel フィードそのものの性質ではなく、Intel を取り込んだスキャナがユーザー環境に対して行う処理だ。この線引きを保つと、「Intel に何が入っているか」と「自分の環境で何を直すべきか」が別の問いだと見えてくる。

集合で書くとこうなる

整理すると、Intel と CVE の関係は「部分集合」でも「上位集合」でもない。

つまり Aikido Intel は「カバーできるCVEを全部持ってくるフィード」ではなく、**「自社のリサーチチームとAIが検知・検証した脅威を、CVEの有無に関係なく供給するフィード」**だと言える。CVEはその一部の表現形式にすぎない。

では、Aikido Intel の何が強いのか

ここまで整理すると、Intel の強みも見えてくる。それは「全CVEを網羅していること」ではない——むしろ逆で、全CVEを追わず、開発者のサプライチェーンに効く脅威へ焦点を絞り切っていることにある。強さは、次の3つに集約される。

ひとつめは、CVE採番を待たない早さだ。脆弱性は、CVE番号が付いた瞬間に生まれるわけではない。コード上の問題が見つかり、修正され、パッチが出て、ようやくCVEとして整理される——その順序が普通だ。攻撃者は、むしろその時間差を狙う。Intel は採番前の段階で脅威を捕捉し、独自IDで扱える。「公開DBに載るのを待つ」設計とは、見えるタイミングが一段早い。

ふたつめは、CVEに乗らない脅威まで拾う広さだ。npm や PyPI に投下される malware、typosquat、改ざんされたパッケージ、怪しいIDE/ブラウザ拡張は、そもそもCVEとして登録されるとは限らない。だが開発者やCI/CDにとっては、登録の有無より「いま手元にあるか」の方が問題で、こちらの方が即死に近いことすらある。CVE台帳だけを見ているチームには、この層がまるごと欠けて見える。Intel は最初からそこを見に行っている。

みっつめは、スキャナと接続したとき、修正判断に変わる実戦性だ。Intel は読み物としてのニュースフィードではない。Aikido のプラットフォームに取り込まれることで、自分の依存関係・コード・設定・reachability と突き合わさり、「世の中で危ないもの」が「自分が今すぐ直すべきもの」へと翻訳される。情報が、そのまま運用上の意思決定になる。

早さ、広さ、実戦性。いずれもCVEの件数では測れない指標だ。網羅型レポートが「世界に何件あるか」を数える台帳だとすれば、Intel が答えているのは「あなたのサプライチェーンに、いま何が迫っていて、どれを先に潰すべきか」という、まったく別の問いである。

運用上、これが意味すること

この構造を理解すると、フィードの使い分けが見えてくる。

エンタープライズ機器やインフラ層まで含めた網羅監視が必要なら、Intel だけを見ていては不十分で、NVD なり網羅型のCVEレポートを別建てで併読する必要がある。「Intel に出ていない=世の中に脆弱性がない」ではない。

逆に、OSSサプライチェーンの脅威を、CVE採番を待たずに早く・静かに掴みたいなら、網羅型レポートよりIntelの方が向いている。採番前の脆弱性も、CVEにならない malware も、ここで先に見えるからだ。そのうえで「自分の環境に実際に効くか」は、Intelを取り込んだスキャナ側の判定に委ねる——情報の供給と、優先度の判定を、別の層として使い分けるのが筋がいい。

Aikido の心臓は、UI ではなく Intel database

ここまでの整理は、実はもっと本質的なことを指している。

セキュリティスキャナは、突き詰めれば「既知のパターンとの照合」だ。SAST はコード上の危険なパターンを照らし合わせ、SCA は依存パッケージを既知の脆弱性・malware のデータベースと突き合わせる。だから、スキャナ同士の差は、画面の見やすさやアラートの出し方だけでは決まらない。むしろ、その前段で「何を既知として持っているか」に決定的な差が出る。とすれば、本当の課題は照合する仕組みの側ではない。照合する相手——脅威のパターンやデータベースを、いかに広く集め、いかに早く更新し続けるかにある。スキャナは、自分が知らない脅威を検知できないからだ。どれだけUIが洗練されていても、データベースの更新が遅ければ、採番前の脆弱性も新しい malware も画面には出てこない。

そして OSS サプライチェーンにおいて、その「集めて、更新し続ける」役割の中心にあるのが Intel database だ。だからこそ「Intel に何が出て、何が出ないのか」を理解することは、そのまま Aikido という製品の本質を理解することでもある。

こうして三層に分けると、全体像が見える。

「Intel に出てこない脆弱性」は、取りこぼしではない。それは、Intel と網羅型フィードが異なる集合を、異なる目的で見ていることの当然の帰結である。そして、その「目的」を担っているデータベースの質と更新速度こそが、SCA やサプライチェーン防御、ひいてはセキュリティスキャナ全体の競争力を決める。スキャナのUIは、その上に乗っている一番見えやすい表層にすぎない。見えない差は、裏側でどれだけ早く、どれだけ広く、どれだけ正確に脅威を知っているかにある。