Intelは、AIと社内研究チームによって提供されるオープンソースセキュリティ脅威フィードです。Intelは、オープンソースパッケージの脆弱性が公開される前に監視し、発見します。多くの場合、それらは決して公開されません。
密かにパッチが適用されたソフトウェア脆弱性の67%は、決して公開されませんでした。
オープンソースソフトウェアは、文字通り世界を動かしています。しかし、オープンソースのセキュリティは、大きなセキュリティ上の懸念事項でもあります。オープンソースツールは、他のすべてと同様に、セキュリティ脆弱性を導入する可能性があります。これらは攻撃者によってアプリケーションをエクスプロイトするために使用される可能性があります。ソフトウェアベンダーが自らの過失なく攻撃にさらされることになります。このため、オープンソースのセキュリティは非常に重要なトピックです。
これらのツールを構築・維持するためにオープンソースコミュニティに依存しているだけでなく、既知のセキュリティ脆弱性を修正するためにも彼らに依存しています。重要なのは、脆弱性が発見された際に、これらのメンテナーが脆弱性を公に報告することにも依存している点です。コミュニティによる脆弱性の公開は、オープンソースセキュリティの基盤を形成します。
サイレントパッチ、またはシャドウパッチとは、セキュリティ修正が適用（パッチ適用）されたものの、決して公開されない状態を指します。これは大きな問題であり、ベンダーがリスクを認識せずに脆弱なソフトウェアを実行している可能性があることを意味します。
影響を及ぼす可能性のあるサイレントパッチ適用済みソフトウェアを明るみに出すため、Aikido Intelを立ち上げます。Aikido Intelにより、開発者に影響を及ぼす可能性のある脆弱性を発見した場合、可能な限り早期に警告を発し、オープンソースのセキュリティを向上させることができます。
Aikido Intelとは何ですか？
Aikido Intelは、AIと社内研究チームによる取り組みであり、オープンソースサプライチェーンにおける脆弱性を可能な限り早期に、脆弱性データベースで公開されるよりもさらに前に発見することで、オープンソースのセキュリティを向上させることを目指しています。これを達成するために、カスタムトレーニングされたLLMを使用してパッケージの変更をレビューし、セキュリティ問題がいつ修正されたかを特定します。
すべてのソフトウェアと同様に、オープンソースは新しいバージョンごとに変更された内容の変更ログを保持しています。IntelはAIを使用して、これらの公開されている変更ログとリリースノートをすべて読み込み、セキュリティ問題がパッチ適用された例を特定します。その後、その問題が報告されているかどうかを確認するために、5つの脆弱性データベースと照合されます。報告されていない場合、セキュリティエンジニアがその脆弱性を分析・評価し、Aikido Vulnerability番号と深刻度を割り当て、影響を受けるかどうかをユーザーが把握できるよう公開発表します。詳細については後ほどご確認ください
数字で見るAikido Intel
1月にAikidoを立ち上げて以来、Intelは511の脆弱性を発見しました。これらはパッチが適用されたものの、公には開示されておらず、これらのパッケージを使用するすべての人に現実の脅威をもたらしています。
脆弱性にパッチを適用してから、その問題にCVE番号が割り当てられるまでに時間がかかる場合があります。Aikidoは毎週、以前の脆弱性のステータスを再評価し、CVEが割り当てられているかを確認しています。私たちが発見した脆弱性の67%は、どの脆弱性データベースにも公開されたことがないことを開示できます。
深刻度の低い脆弱性がより頻繁に密かにパッチ適用されることは驚くことではありませんが、深刻度の高い脆弱性や緊急性の高い脆弱性の50%以上が一度も開示されていないことは依然として衝撃的です。これは、開発者やソフトウェアベンダーにとって大きな盲点となります。
これらは、セキュリティポリシーが限定された、あまり人気のない小規模なオープンソースプロジェクトではないかと、お考えの方もいらっしゃるかもしれません。しかし、それは間違いです。実際には、非常に大規模なプロジェクトでも未公開の脆弱性をいくつか発見しています。
ブラウザおよびnode.js向けのプロミスベースHTTPクライアントであるAxiosは、週に5,600万回ダウンロードされ、146,000以上の依存関係を持つにもかかわらず、2024年1月にプロトタイプ汚染の脆弱性を修正しましたが、これはこれまで公には開示されていませんでした。
この脆弱性に関する豆知識: これは実際にAikido Intelが発見した最初の脆弱性でした（番号2023-10001を参照）。今日に至るまで未公開のままです！
ここでAxiosだけを取り上げるのは本意ではありませんが、他にも特筆すべき名前がいくつかあります。Apacheは、echartsソフトウェアにおけるクロスサイトスクリプティングの脆弱性を、公表することなく密かにパッチ適用しました。
我々が発見したもう一つの興味深い例は、Chainlitにおける深刻なパストラバーサル脆弱性でした。これは9月にパッチが適用されましたが、この脆弱性は公には開示されませんでした。
最も一般的な脆弱性
クロスサイトスクリプティングは、機密情報の漏洩（12.3%）に次いで、未公開の脆弱性の中で最も多く、14.8%を占めました。全体として、90種類の脆弱性を検出し、結果のロングテールを生み出しており、以下に最も一般的なものをいくつか示します。
発見された最も一般的な脆弱性
クリティカルおよび高レベルの脆弱性のみを見ると、リモートコード実行がリストの1位を占めるという、わずかに異なる状況が見られます
発見された最も一般的な脆弱性 - 重大度「Critical」および「High」のみ
情報開示までの時間
本稿執筆時点では、パッケージの67%が脆弱性を開示していませんでしたが、31%はメンテナーまたはセキュリティ研究者によって開示されました（彼らに敬意を表します）。脆弱性を開示したパッケージのうち、パッチがリリースされてからCVEが割り当てられるまで平均27日かかりました。観測された最短期間はわずか1日でしたが、最長期間は9ヶ月でした！
インテリジェンスの仕組み（詳細）
新しいAIに関する誇大広告にはうんざりしていることと存じますが、IntelはAikidoのセキュリティ研究チームとAikidoのAIチームによる取り組みであり、Human in The LoopとAIを組み合わせることで、オープンソースセキュリティを向上させるための公開脅威フィードを提供しています。
Intelは、公開されているすべての変更履歴とリリースノートを読み込み、セキュリティ修正が適用されたものの公開されていないかどうかを理解することで機能します。これを実現するため、2つのLLMモデルが使用されます。1つはデータをフィルタリングし、不要なコンテキストをすべて削除して、2つ目のLLMが脆弱性分析に集中できるようにします。その後、人間のセキュリティエンジニアがLLMの発見をレビューし、その結果を検証し、脆弱性が確認された際にIntelをリリースします。
これは、これらのシステムすべてを脆弱性のためにスキャンしようとするよりも、計算能力を著しく少なく消費するため、非常に効果的な方法です。それでも、1年以上にわたり多くの真の結果を見つけることが証明されています。
チェンジログはAikido Intelによってどのように見られますか？
チェンジログは、オープンソースプロジェクトで管理されているドキュメントであり、更新、バグ修正、機能追加、パッチを記録します。例としては、以下が挙げられます。 CHANGELOG.md ファイル、コミットメッセージ、GitHubリリースノート。
Intel LLMは、セキュリティ関連の変更を示唆するエントリを以下を探すことで特定します。
- キーワード：「脆弱性」、「セキュリティ」、「修正」、「エクスプロイト」、「入力検証」など
- 文脈上の手がかり: 「重大なバグを修正」、「バッファオーバーフローをパッチ適用」、「認証の問題を解決」。
LLMによってフラグ付けされたエントリ例：- ログインハンドラーにおける入力サニタイズの問題を修正しました。
- サービス拒否攻撃につながる可能性のあるメモリリークを解決しました。
- ファイルアップロード機能におけるパス横断脆弱性に対処しました。
オープンソースセキュリティ、脆弱性の適切な開示方法
前述の通り、公開開示はオープンソースセキュリティの重要な要素です。ソフトウェアに脆弱性が存在する時期を開示するために、いくつかの異なるデータベースが使用されます。主要なデータベースは、米国政府が管理するNational Vulnerability Database (NVD)です。このデータベースは、企業がサプライチェーンをチェックするために使用されるだけでなく、このデータベースや他のデータベースに対してプロジェクトをチェックするセキュリティソフトウェア（SCAソフトウェア）によっても使用されます。MitreのCommon Vulnerabilities and Exposuresデータベース（CVE）、GitHub Advisory Databaseなど、他にも多数のデータベースがあり、合計でAikidoは5つの異なるデータベースに対してチェックを行います。しかし、これらのデータベースのほとんどに共通しているのは、通常、修正がリリースされた後に脆弱性が公開開示されることを要求している点です。
なぜ脆弱性は開示されないのでしょうか？
これは良い質問であり、まず、脆弱性を開示しない正当な理由はないと言いたいと思います。おそらく最も一般的なのは、ソフトウェアが安全でないと見なされるという評判リスクですが、開示しないことによる損失は、開示することによる損失よりもはるかに大きいと私は主張します。
シャドウパッチがオープンソースセキュリティにとって問題となる理由
ソフトウェアの脆弱性を公開しないことは、ユーザーにとって大きなリスクを生み出します。ことわざにもあるように、壊れていなければ直すな、これはソフトウェアにもしばしば当てはまります。
ソフトウェアのコンポーネントを更新すると、パフォーマンスやユーザビリティに問題が生じたり、アプリケーションが単に壊れたりすることがよくあります。このため、新しいバージョンが利用可能になったときにすぐにパッケージを更新することは、常に一般的な慣行ではありません。
しかし、コンポーネントにセキュリティ上の問題がある場合、オープンソースおよびサードパーティのコンポーネントを更新する緊急性が変わるため、それを知ることは重要です。この情報を開示しないと、ユーザーは更新する可能性が低くなり、知らないうちにツールにセキュリティ上の欠陥を抱えることになります。これがシャドウパッチが問題となる理由です。
