オープンソース脆弱性スキャンのLLM API連携によるセキュリティ検討時間の短축手法

オープンソースは便利ですが、その分リスクも伴います。2025年のある調査によると、AIがコード生成を肩代わりし始めたことで、バグの発生率が前年比で41%も急増しました。一人で数万行に及ぶ外部ライブラリを検討しなければならないセキュリティ担当者にとって、これは災難以外の何物でもありません。すべてのコードを読み切ることは不可能であるため、AIを味方につける必要があります。Project Glasswingのようにスマートに動作するセキュリティワークフローを、自ら構築する方法をまとめました。

GitHub ActionsへのAIセキュリティエンジンの導入

セキュリティ検討を自動化すれば、毎週10時間以上費やしていた単純な反復作業を排除できます。人間が目視で確認する際に見落としがちなミスを防ぐことも可能です。GitHub Actions環境でLLM APIを呼び出し、プルリクエストが作成されるたびにリアルタイムでスキャンするパイプラインを構築してみましょう。単に質問を投げるのではなく、「識別」と「監査」を分離する戦略が鍵となります。

• APIキーの保護: GitHub Secretsに LLM_API_KEY を登録してください。Libsodium暗号化ストレージに保管することで、キーが外部に漏洩する事故を防ぎます。
• ターゲットディレクトリの設定: すべてのファイルをチェックする必要はありません。YAML設定で path-filter を使用し、src/auth や lib/core のように、トラブルが発生した際に致命的となる機密性の高いディレクトリのみを選択してスキャンしてください。
• クロスバリデーション（交差検証）: 最初のステップでLLMにコード構造を分析させてノートを作成させ、次のステップでそのノートに基づき3回以上の反復スキャンを実行します。AIも時には誤った情報を生成（ハルシネーション）するため、複数回確認して結果を照らし合わせるプロセスが必要です。

この設定を終えるだけで、セキュリティ担当者は数万行のコードの代わりに、AIが要約したセキュリティレポートを確認するだけで済むようになります。

CVSSとEPSSで「真に危険な脅威」を抽出する

AIツールは脆弱性を見つけるのが得意ですが、その分誤検知（偽陽性）も多くなります。100個の脆弱性を見つけたとしても、そのうち15個が誤検知であれば、開発チームの不満は募るばかりです。限られた開発リソースを無駄にしないためには、真の脅威を見極める基準が必要です。CVSS 4.0のスコアと、現在実際に攻撃が発生しているかを示すEPSS指標を組み合わせて優先順位を決定しましょう。

1. 基本スコアの確認: CVSS 4.0ベーススコアで技術的な深刻度をまず確認します。
2. 環境スコアの調整: そのコードが外部インターネットに露出している機能なのか、あるいは内部ネットワークのみで動作する機能なのかによって、スコアを調整してください。
3. 攻撃確率の照合: EPSSデータベースを照会し、該当する脆弱性が現在攻撃者の間で流行しているかを確認します。攻撃確率が50%を超えている場合は、他の作業を差し置いて直ちにパッチを適用すべきです。

9.0点以上の緊急（Critical）レベルに集中するだけでも、セキュリティレベルは飛躍的に向上します。不要な修正依頼を減らすことで、開発チームとの摩擦も自然と解消されます。

サンドボックスでのパッチコード検証とデプロイ

AIが提案した修正案は一見完璧に見えても、時には正常な機能を損なうことがあります。Shopifyのような企業もAIを活用していますが、生成されたコードを鵜呑みにはしません。FirecrackerやgVisorのような隔離された環境で、パッチコードが安全かどうかを自動で確認する手順を設けるべきです。

• 隔離環境の生成: sbx CLI を使用して、現在のサービスと同一のランタイム環境を持つマイクロVMを起動します。
• 攻撃シミュレーション: 攻撃スクリプトで脆弱性が実際に突かれるかを確認した後、AIが提供したパッチを適用し、再度攻撃を行って防御されているかをチェックします。
• 機能テスト: パッチを適用した状態で既存のユニットテストを実行してください。セキュリティは守れても、ログインができなくなっては意味がありません。

このような安全装置を設けることで、AIが作成した「ほぼ正しいが、わずかに誤っている」コードが本番サーバーにデプロイされる事故を防ぐことができます。

オープンソースメンテナが即座に受け入れるレポートの書き方

自社サービスを修正して終わりではありません。利用しているオープンソース自体の欠陥を上流プロジェクトに報告することもセキュリティ担当者の役割です。メンテナは多忙であるため、明確な根拠を提示する必要があります。GitHubのPVRチャネルを活用し、責任を持ってレポートを伝えましょう。

タイトルには脆弱性の種類と場所を明記してください。誰でも再現できる手順（再現パス）とスクリーンショットを添付するのは基本です。最も効果的なのは、先ほどのサンドボックスで検証済みの修正コードを併せて送ることです。検討時間を短縮してあげれば、パッチが採用される確率は飛躍的に高まります。質の高いレポート一つが企業の技術力を証明し、公式なCVE番号の取得という成果にもつながります。