[レポート]99% の企業が見逃す「静かな侵入口」—放置された OSS と進化する攻撃が仕掛ける罠 ～ 巧妙化する攻撃手口と、その温床となる「放置 OSS」の実態 ～ - CODE BLUE 2025 #codeblue_jp #codeblue2025

あしざわです。

本記事はCODE BLUE 2025で行われた以下のセッションのレポートです。

セッション情報

99% の企業が見逃す「静かな侵入口」—放置された OSS と進化する攻撃が仕掛ける罠 ～ 巧妙化する攻撃手口と、その温床となる「放置 OSS」の実態 ～

（第一部）
多層防御をすり抜ける脅威
～突破されるセキュリティ、突破させない企業へ～

【概要】
サイバー攻撃の高度化が進む中、多くの組織では、EDR・NDR・WAFといった強力なセキュリティ製品を導入し、多層的な防御体制を築いています。しかし、そのような環境下においてもセキュリティ事故は後を絶たず、従来の防御策だけでは十分でないことが明らかになっています。 その背景には、攻撃者が「Living off the Land（LotL）」や「ファイルレス攻撃」など、従来の検知を回避する高度な手法を巧みに用いていることがあります。これにより、振る舞い検知や既存の防御網をすり抜けるケースが多く確認されています。 本セミナーでは、こうした高度な攻撃手法の実例を紹介しながら、「なぜ最新のセキュリティ製品を導入していても被害が発生してしまうのか」という疑問に迫ります。また、実際に存在する脆弱性を題材に、迅速なアップデート対応の重要性についても具体的に解説します。本セミナーを通じて、参加者の皆さまが自社のセキュリティ対策を見直すきっかけを得るとともに、最新の攻撃動向を理解し、実効性のあるセキュリティ戦略の構築方法を学んでいただけます。 そして、こうした巧妙な攻撃の最初の突破口となりうる、サプライチェーンに潜む広大なリスクの正体について、第二部でデータと共に明らかにします。

（第二部）
OSSエコシステムの潜在的リスクーー
実稼働2万件のPURL分析が明らかにする、広大な「放置アタックサーフェス」の実態

【概要】
第一部で紹介されたような巧妙な攻撃は、多くの場合、見過ごされてきたソフトウェアの脆弱性を起点とします。 ソフトウェアサプライチェーンのセキュリティは、既知の脆弱性(CVE)管理に焦点が当てられがちですが、我々の足元にはより広範で静かなリスクが 広がっています。それは、公式なEOL(End-of-Life)や、事実上のメンテナンスが停止した「休眠状態」のオープンソースソフトウェア(OSS)コンポー ネントです。これらのコンポーネントは、ひとたび新たな脆弱性が発見されれば、修正パッチが提供されることのない永続的な攻撃経路となりえます。

本講演では、机上の調査ではなく、脆弱性管理クラウドサービス「FutureVuls」を通じて収集した、実稼働環境で実際に利用されている2万件のPURL(Package URL)というユニークなデータセットに基づき、OSSエコシステムの健全性を大規模に分析した結果を報告します。 分析にあたっては、最終リリース日や公式EOL情報といった静的なデータだけでなく、OSSF Scorecardの各種メトリクス、リポジトリのコミット頻度、リリース間隔といった動的な「開発活発度」を示す複数の指標を複合的に評価しました。

その結果、調査対象の約半分が長期間更新されておらず、5～10%が公式にEOLを宣言済みであるという、サプライチェーンの深刻な実態が明らかになりました。本発表は、この定量的なデータを示し、これらの休眠・EOLコンポーネントが攻撃者にとって如何に魅力的なターゲットとなりうるかを考察します。さらに、防御側の視点から、従来の脆弱性スキャンを補完し、潜在的なリスクを可視化・定量化するための実践的なOSSライフサイクル管理フレームワークを提案します。これにより、多くの組織が見逃している真の「静かな侵入口」を塞ぎ、持続可能な防御体制を構築するための具体的な道筋を示します。

Speakers: Masato Watanabe（渡邉 正人）, Kouta Kanbe（神戸 康多）

レポート

前半パート:多層防御をすり抜ける脅威

• 日本をターゲットにする脅威アクター
  • 多い
  • 最近は大手がサイバー攻撃を受けている
  • 攻撃者は自分の身元を隠しながら攻撃する
  • 有名なアクター:APT9
• 近年のセキュリティ対策
  • 過去は境界線防御がメジャーだった
  • 最近は境界線が突破されるようになっているため、多層防御の考え方が重要
  • 一部が突破されても別のところで被害を最小化できる
• 不安要素
  • 色々なセキュリティ製品を導入したが本当に機能するのか？という不安
  • 機能間の連携ができていないとか
  • 守っているつもりだが穴がある場合も
• ペネトレーションテスト
  • Futureでは実際の攻撃者と同様な回避手法を用いて、現実的な攻撃シナリオに沿って検証している
    • 多層防御が機能しているかを確認できる
    • 事前にセキュリティ製品の情報をヒアリングし、その製品が突破できるかを事前検証して高度なテストを実施
    • 攻撃検知時のSOCやCSIRTの動きを確認するTLPTの依頼も増えている
• Future社内のセキュリティ訓練
  • CSIRTとRedTeamに分かれて訓練
  • 双方がコミュニケーションを取りながら進行
  • アラートがインシデントや攻撃のフィードバックとして適切にエスカレーションできているかを確認
  • CSIRTは攻撃の状況をよく理解できて勉強になったそう
• 攻撃者が利用する検知回避手法
  • 複数技術を使って、防御側の検知の盲点をつく
  • 攻撃者は痕跡を残さないように、検知しないようにしている
    • 監視プロセスの無効化など
• EDR検知回避手法
  • いくつかあるが2点に絞って説明
  • DLL Side Loading
    • 概要
      • 署名された正規のEXEファイルから不正なDLLをロードする手法
      • 未署名のEXEファイルはEDRで検知される
      • DLLファイルは署名されていなくても検知されない（これが重要）
      • 署名された正規EXEからロードされるDLLは不審スコアが低い
      • 攻撃者はDLLファイルにプログラムを乗せて実行する
    • 仕組み
      • 正規のEXEが読み込むDLLに脆弱な読み込みがあるとファイルのすり替えが可能
      • 悪性DLLのファイル名を正規のDLLと同名にして、正規EXEと同じフォルダに配置する
      • 正規のEXEが悪性DLLを読み込んで��まう
  • Sleep Mask(スリープマスク)
    • 一言:Sleep中に自身を暗号化して身を隠すこと
    • マルウェアはC2サーバーにアクセスする(大体10分に1回、15分に1回)
      • その間は何も動いていないのでSleepしている
    • Sleep時にメモリスキャンが実施されると検知されてしまう
      • Sleep中に暗号化することで検知を回避
      • メモリスキャンがかかっても検知されない
• 検知回避される前提での対策
  • 脆弱性の管理も大切
  • 情報セキュリティの10大脅威にも脆弱性対策が多い
• 最新のセキュリティ製品は高機能だが、サイバー攻撃の対策は基本的な対策が重要

後半パート:OSSエコシステムの潜在的リスク

• ツールの宣伝ではなく、データからわかった不都合な真実を伝えるパート
• 脆弱性管理の戦い
  • フェーズが変わった
  • CVEへの対応
    • 自動化、効率化が進んでいる
  • サプライチェーン全体のリスク管理
    • 法的義務、EU CRAなどによる強制力
    • 最も致命的なリスクがEOL
• なぜ今、EOLなのか
  • EU CRAの義務:製品サポート5年
  • OSSサポート:3年
    • 2年のギャップがある
    • これは努力で埋められるものではない
    • 法的義務とサポートが致命的に噛み合っていない
• 調査
  • 2万種類のOSSの健全性調査
    • 企業の裏側で実際に動いているもの
  • 結果
    • 活発に活動:40%
    • 安定版:10%
    • 明示的なEOL:10%
    • 実質的なEOL:5%
    • 開発停滞:35%
  • ここで言いたいこと
    • 半分が健全、もう半分が安全ではない
• ケース
  • AngularJS
  • 2022/1:EOL
    • 移行したくても移行できない件が続出
    • 現在も120万サイトが稼働中
    • EOL後に合計12件のCVEが公開された
      • 2024/2にはCVSS 7.5のものも
    • EOLなので公式パッチは出ない
• 攻撃者視点
  • 企業はセキュリティへの多額の投資で兵士を雇っている
  • 攻撃者は効率を重視して手薄なところを狙っている
    • 壊れた城壁を狙っている
• 二つの壁
  • EOLに気付けない:発見の壁
    • ライブラリの依存関係の奥深くにEOLのOSSが潜んでいる
  • EOLに気付いても直せない:対応の壁
    • 選択肢
      • FIX:社内のエンジニアが脆弱性を解析してパッチを当てる
      • Fork:OSSをフォークして保守する
      • Forgo:諦めて他に乗り換える
      • Pay:商用サポートに入る
    • これらは莫大な予算や工数が必要になる
      • 事実上の詰み状態になる
• 発想の転換
  • 発見の壁
    • これまで:人手のスナップショット管理
      • 年1回の棚卸しでは破綻する
    • これから:継続的な分析
      • SBOM:すべての依存関係を可視化
      • 高度な分析
  • 対応の壁
    • これまで:場当たり的な対応
      • 破綻する
    • これから:プロアクティブな管理
      • EOL予測:1年後にEOLを迎えるものを事前に把握する
      • 管理:技術的負債として管理する
      • 予算と計画:緊急対応ではなく、次年度予算のロードマップに組織として組み込む
• Future Vulsの例
  • これらが先週のリリースで追加された
• EOL判定ロジック
  • 公式EOL判定の自動判定
    • PURLを入力
    • GitHubのURLに変換
      • READMEからEOL関連の強いワードを抽出
      • コミット日付、リリース日付も活用
    • パッケージマネージャーの情報も活用
      • npmのレジストリーの「deprecated」フラグなど
    • 情報をクロールしてLLMに判断させる
      • LLMは嘘をつくこともあるので人間がチェックして硬いカタログを作成
  • 実質EOL判定
    • メンテナンスされていない、人間のコミットがない、パッチが当たっていない脆弱性がたくさんある
    • Dockerと連携させてコンテナ内のOSSライブラリ(PURL)を解析し健全性をチェックするツールを作成
• まとめ
  • EOLはアタックサーフェス
  • 法規制が技術負債を法的負債に変えた
  • 発見とガバナンスの自動化が二重苦を突破する鍵

感想

OSSのうち安全だと言えるものは半分しかないという調査結果に驚かされました。

前半でEDR検知回避手法の具体例が紹介され、後半で近年の脆弱性対応におけるEOL対応の重要性やリスクを示されたことから、基本的なセキュリティ対策が極めて重要だと再認識しました。