
インテルは、AIと社内リサーチチームによる オープンソースのセキュリティ脅威フィードです。インテルは 、オープンソースパッケージの脆弱性を監視し、 公開される前に発見します。 その多くは決して公開されることはありません。
サイレントパッチが適用されたソフトウェアの脆弱性の67%は公表されなかった
オープンソースソフトウェアは、文字通り世界を動かしている。しかし、オープンソースのセキュリティは、セキュリティ上の大きな懸念事項でもある。オープンソースのツールは、他のものと同様に、セキュリティの脆弱性をもたらす可能性があります。これらは、攻撃者がアプリケーションを悪用するために利用することができます。ソフトウェア・ベンダーは、自らの過失によらず、攻撃される可能性があるのです。そのため、オープンソースのセキュリティは非常に重要なトピックなのです。
私たちは、オープンソースコミュニティにこれらのツールの構築と保守を依存しているだけでなく、既知のセキュリティ脆弱性を修正することも依存しています。重要なことは、脆弱性が 発見されたときに、その脆弱性を公に報告 することです。コミュニティからの脆弱性の公開は、オープンソースのセキュリティの基礎を形成します。
サイレント・パッチ(シャドウ・パッチ)とは、セキュ リティ修正が適用(パッチ適用)されているにもかかわらず、公表されな いパッチのことである。これは、ベンダーがリスクを認識しないまま脆弱なソフトウェアを運用している可能性があることを 意味するため、大きな問題となる。
私たちは、あなたに影響を与える可能性のあるサイレント・パッチが適用されたソフトウェアを影から救い出すために、Aikido Intelを立ち上げます。Aikido インテルによって、開発者に影響を与える可能性のある脆弱性を発見した場合、可能な限り早い段階で警告を与え、オープンソースのセキュリティを向上させることができます。
Aikido インテルとは?
Aikido Intelは、オープンソースのサプライチェーンにおける脆弱性を可能な限り早い段階で発見することで、オープンソースのセキュリティを向上させるためのAI + 社内研究チームによるイニシアチブです。脆弱性データベースで公開される前であっても。これを達成するために、私たちはカスタムトレーニングされたLLMを使ってパッケージの変更をレビューし、セキュリティ問題が修正されたタイミングを特定します。
すべてのソフトウェアがそうであるように、オープンソースも新しいバージョンごとに調整された内容の変更ログを保持している。インテルは、AIを使ってこれらの公開変更ログとリリースノートをすべて読み、セキュリティ問題が修正された例を見つける。そして、5つの脆弱性データベースと照合し、問題が報告されているかどうかを確認します。もし報告されていなければ、セキュリティ・エンジニアが脆弱性を分析・評価し、Aikido 脆弱性番号と深刻度を付与して公表します。 詳しくは後ほど

数字で見るAikido インテル

1月にAikido立ち上げて以来、 インテルは511件の脆弱性を発見した。の脆弱性を発見し、パッチを当てたが公表しなかった。

脆弱性にパッチを当ててから、その問題にCVE番号が割り当てられるまでに時間がかかることがあります。Aikido 毎週、過去の脆弱性の状況を再評価し、CVEが付与されているものがあるかどうかを確認しています。私たちが発見した脆弱性の67%は、どの脆弱性データベースにも公表されていないものでした!


深刻度が低い脆弱性ほど頻繁にサイレント・パッチが適用されるのは驚くことではないが、深刻度が高く重要な脆弱性の50%以上が公表されないというのは衝撃的である。これは、開発者やソフトウェア・ベンダーにとって大きな盲点となる。
さて、皆さんの中には、おそらくこれらはセキュリティ・ポリシーが限定的な、あまり人気のない、小さなオープンソース・プロジェクトなのだろう、と席を立ってもじもじしている人もいるだろうが、実はそれは間違いだ。私たちは、いくつかの非常に大規模なプロジェクトで、公表されていない脆弱性を発見しました。.
Axiosはブラウザとnode.jsのためのプロミス・ベースのHTTPクライアントで、毎週5,600万ダウンロードされ、146,000以上の依存関係がある。 2024年1月、プロトタイプ汚染に関する脆弱性 を修正した。

この脆弱性に関する面白い事実がある: この脆弱性は、実はAikido インテルが最初に発見した脆弱性だった(2023-10001参照)。この脆弱性は現在も公表されていない!
Axiosだけでなく、他にも特別に賞賛に値する名前がいくつかある。アパッチは、公開されていなかったクロスサイト・スクリプティングの脆弱性をエカルツ・ソフトウェアにサイレント・パッチした。

私たちが発見したもうひとつの興味深い例は、9月にパッチが適用されたものの、その脆弱性が公表されなかったチェーンリットのクリティカル・パス・トラバーサル脆弱性である。

最も一般的な脆弱性
クロスサイト・スクリプティングは、最も一般的な未公開の脆弱性で、14.8%を占め、次に機密情報の漏洩が12.3%でした。全体として90種類の脆弱性が検出され、ロングテールの結果となりました。
発見された最も一般的な脆弱性

キューティクルと高度の脆弱性だけを見てみると、リモート・コード実行がリストの1位を占めており、少し違った様相を呈している。
発見された最も一般的な脆弱性 - クリティカルとハイのみ

開示までの時間
この記事を書いている時点では、67%のパッケージが脆弱性を公表していないが、 31%は公表している。脆弱性を公開したパッケージのうち、パッチがリリースされてから CVE が割り当てられるまでにかかった日数は平均 27 日でした。私たちが観測した最短時間はわずか1日で、最長時間は9ヶ月だった!

インテルの仕組み(詳細)
しかし、IntelはAikidoセキュリティ・リサーチ・チームのイニシアチブであり、AikidoAIチームは、オープンソースのセキュリティを向上させるために公開脅威フィードを提供するために、ループ内の人間とAIを活用している。
インテルは、公開されているすべての変更履歴とリリース・ノートに目を通し、セキュリティ修正が行われたにもかかわらず公開されていないかどうかを把握する。 これを実現するために、2つのLLMモデルが使用されます。1つはデータをフィルタリングし、不要なコンテキストをすべて削除するためのもので、2つ目のLLMは脆弱性分析に集中することができます。そして、人間のセキュリティ・エンジニアが LLM の発見をレビューし、発見を検証し、脆弱性が確認されたときに Intel をリリースする。
これは、脆弱性のためにこれらすべてのシステムをスキャンしようとするよりも著しく少ない計算能力を消費するため、このように効果的な方法である。とはいえ、1年以上かけて多くの真の結果を見つけることが証明されている。
Aikido インテルによる変更履歴の見方
チェンジログとは、オープンソースプロジェクトにおいて更新、バグ修正、機能追加、パッチを記録するために維持されるドキュメントである。例として以下が挙げられる。 CHANGELOG.md
ファイル、コミットメッセージ、GitHubのリリースノート。
インテル® LLM は、セキュリティ関連の変更を示唆するエントリーを特定するために、以下の項目を検索する:
- キーワード「脆弱性」、「セキュリティ」、「修正」、「エクスプロイト」、「入力検証」など。
- 文脈上の合図:「重大なバグを修正した」、「バッファオーバーフローを修正した」、「認証の問題を解決した」。
LLMがフラグを立てたエントリー例:-
- サービス拒否攻撃につながる可能性のあるメモリリークを解決しました。
- ファイルアップロード機能におけるパストラバーサルの脆弱性に対処しました。
オープンソースのセキュリティ、脆弱性の適切な開示方法
先に述べたように、公開はオープンソースのセキュリティの大きな要素である。ソフトウェアに脆弱性があることを公表するために、いくつかの異なるデータベースが使用されている。主なデータベースは 国家脆弱性データベース(NVD)である。このデータベースは、企業が自社のサプライチェーンをチェックするために使われるだけでなく、プロジェクトをこのデータベースや他のデータベースと照合してチェックするセキュリティ・ソフトウェア(SCAソフトウェア)にも使われている。その他にも、Mitreの 共通脆弱性・暴露データベース(CVE)やGitHub Advisory Databaseなど、他にも多くのデータベースがあり、Aikido 合計で5つの異なるデータベースと照合している。しかし、これらのデータベースのほとんどに共通するのは、脆弱性が一般に公開されること、通常は修正がリリースされた後であることです。
なぜ脆弱性が公表されないのか?
これは良い質問であり、脆弱性を開示しない正当な理由はないということから始めたい。おそらく最も一般的なのは、あなたのソフトウェアが安全でないとみなされるかもしれないという風評リスクでしょうが、私は、開示することよりも開示しないことで失うものの方がはるかに大きいと主張します。
シャドーパッチがオープンソースのセキュリティにとって問題である理由
ソフトウェアの脆弱性を公表しないことは、ユーザーにとって大きなリスクとなる。 壊れていないなら直すな 」ということわざがあるように 、これはソフトウェアにもよく当てはまります。
ソフトウェアのコンポーネントをアップデートすると、パフォーマンスやユーザビリティに問題が生じたり、単にアプリケーションが壊れたりすることがよくあります。このようなことを念頭に置いて、新しいバージョンが利用可能になったらすぐにパッケージをアップデートするというのは、必ずしも一般的なやり方ではありません。
しかし、コンポーネントにセキュリティ上の問題がある場合、オープンソースやサードパーティのコンポーネントをアップデートする緊急性が変わるため、それを知ることは重要です。この情報が開示されないということは、ユーザーがアップデートをする可能性が低いということであり、つまり、ユーザーが知らないうちにツールにセキュリティ上の欠陥があるということである。