今話題のLinux脆弱性について記載します。 Copy Fail脆弱性とは Linuxで一般ユーザーがroot(管理者)に昇格できる脆弱性です。 2017年以降のほぼすべての主要ディストリビューションで発見されています。（Ubuntu、Amazon Linux等） 重要な点は上記脆弱性に対して攻撃された場合、高確率で攻撃が成功することです。 また、比較的簡単なコードで攻撃が成立してしまう点も問題です。 この脆弱性はLinuxカーネルのAF_ALGとsplice処理の不備により、ページキャッシュ上のデータを書き換えることができます。 特徴的なのはディスク上のファイルには変更を加えず、メモリ上のみを書き換える点でです。 上記特徴により、ハッシュチェックやファイル整合性監視では検知が困難になっています。   攻撃が成立する条件 攻撃が成立する条件は以下の通りです。(あくまで筆者が調べた範囲です) 環境上でコード実行できること 脆弱なカーネルを使っていること（Linux kernel 4.14～6.x） AF_ALG（カーネル暗号API）が使えること よって、この脆弱性単体で外部から攻撃されることは現時点でないと思われます。 （複数個の脆弱性を使用した場合はその限りではない可能性があります）   対策 現時点での対策は以下の通りです。 カーネルを修正済みバージョンへアップデートする AF_ALGを無効化する   実際にやってみた 2026年5月1日9:30ごろにEC2インスタンスを作成して実施してみました。 筆者の環境では攻撃が失敗したため、最新のAmazon Linuxでは修正されている可能性が高いです。 （修正を保証するものではありません） 実行前 一般ユーザーであることとsudoをパスワードなしで使えないことを確認しています。   実行後 sudo -l でパスワードを求められていたり、whoamiやid -uの結果がrootのものになっていないため失敗していることが確認できます。 参考 Copy Fail — CVE-2026-31431 （参照日: 2026-05-01）

こんにちは。プロダクト開発部の森 @jiskanulo です。 2026年4月22日から24日までRubyKaigi 2026 Hakodateが開催されました。 rubykaigi.org 函館アリーナを3日間に渡って貸し切る大規模イベントの運営をしていただきましたスタッフの皆様に感謝を申し上げます。 ファインディ株式会社もPlatinumスポンサーとして協賛しました。 私もブースに立って出展やファインディ各サービスのご案内をさせていただきました。 お話しをしていただいた皆様にも重ねて感謝申し上げます。 ブースに立つ合間にセッションを聞いて自分でやれそうなことに思いを馳せたり、他社様のブースを回ってプロダクトのお話をしたり、昔の同僚や知人と再会したりと個人的にもいい刺激の多い3日間でした。 さて、4月24日、最後のセッションのMatzさんのキーノートにてRubyファイルをネイティブバイナリにコンパイルする Spinel が発表されました。 早速Spinelを使ってみた感想とつかいどころを記します。 Spinelとは 検証環境とセットアップ 動かしてみた Hello, World! eval / requireの挙動：エラーにならず無音で間違う eval は no-op に置き換わる require は文ごと消える 現時点での注意点 Spinelを使ってみる requireなしでJSONを扱う ハマりどころは個別に踏みに行く価値がある Spinelを試すときの判断基準 個人的所感 おまけ: Spinelの由来 おわり Spinelとは SpinelはRubyのAOT (Ahead-Of-Time) コンパイラです。 RubyソースコードをPrismでパースし、全プログラム型推論を行いCのコードに変換してネイティブバイナリを生成します。 パイプラインは次のとおりです。 Ruby → Prism → AST → 全プログラム型推論 → Cコード → ネイティブ実行ファイル リポジトリのREADMEによると、miniruby比で約11.6倍、Conway's Game of Lifeでは86.7倍という性能が示されています。 またバイナリサイズもmrubyを含めずに数十KBに収まるので容量が厳しい環境にも適用できるとのことです。 実体としての ./spinel はPOSIX shell wrapperで、内部で spinel_parse → spinel_codegen → cc を直列に呼び出している、という作りです。 検証環境とセットアップ 検証は手元のmac環境で行いました。 4月24日公開直後にmacで動かそうとしたタイミングでは malloc.h が存在しないなどでエラーになったのでDockerでUbuntuのコンテナを起動して操作しましたが、現在は対応されています。 土日で函館観光しているうちにコントリビュートが進んでいますね。コントリビュートのチャンスですね。 mac build対応 https://github.com/matz/spinel/commit/4593581eb87cea45b59fb28b9dcf2cd75a9bcbab windows対応 https://github.com/matz/spinel/commit/1fe3136aa9bf834b5f37176faca7346503fb1446 環境は次のとおりです。 macOS (arm64) Apple Clang Spinel masterブランチ（2026-04-28時点） ビルドと実行の基本フローはシンプルです。 spinel をmakeし、 spinel にrubyファイルをわたせば実行形式バイナリが出力されます。 make deps # 初回のみ: libprism 取得 make # spinel_parse / spinel_codegen / ランタイムをビルド ./spinel app.rb # Ruby → 実行形式（./app） ./app 動かしてみた Matzのキーノートとも被りますがサンプルコードを動かしてみました。 またキーノートで話があったとおり eval と require はサポートしていないとのことです。 eval, requireを使うと具体的にどうなるのかも試してみました。 Hello, World! 最小の動作確認はそのまま動きます。 # hello_world.rb puts " Hello, World! " ./spinel hello_world.rb ./hello_world # => Hello, World! eval / requireの挙動：エラーにならず無音で間違う 2026年4月28日の現時点では コンパイル時にエラーにならず、warningも出ず、しかし実行すると無音で間違った出力 を返すという挙動です。 具体的に2つのケースを見ていきます。 eval は no-op に置き換わる 次のRubyコードをSpinelでコンパイルして実行します。 # test_eval.rb code = " 1 + 2 " result = eval (code) puts result $ ./spinel ./tmp/jiska/samples/test_eval.rb ./tmp/jiska/samples/test_eval.rb -> test_eval 実行すると結果は 0 です。 $ ./test_eval 0 生成されたCのコードを見ると eval() の呼び出しがno-opに置き換わり、戻り値は型推論で決まったゼロ値（ mrb_int のため 0 ）になります。 const char *lv_code = "1 + 2" ; mrb_int lv_result = 0 ; // mrb_int = int64_t typedef lv_code = "1 + 2" ; lv_result = 0 ; // ← eval() 呼び出し自体が消滅、0 を代入するだけ printf ( " %lld\n " , ( long long )lv_result); mrb_int はmrubyのような」命名に見えますが lib/sp_runtime.h で int64_t のtypedefとして定義されたSpinelランタイムの整数型です。 https://github.com/matz/spinel/blob/64105ec86d08c9edc92c3d17bf059126ceaa15d3/lib/sp_runtime.h#L53 require は文ごと消える 次は require "json" と JSON.generate を使うケースです。 # test_require.rb require " json " puts JSON .generate({ name : " spinel " , year : 2026 }) こちらも実行すると 0 になります！ $ ./spinel ./tmp/jiska/samples/test_require.rb ./tmp/jiska/samples/test_require.rb -> test_require $./test_require 0 require の行は生成されたCのコード上で文ごと消えます。 続く JSON.generate もSpinelから見れば未定義メソッドであり、 eval と同じくゼロ値を返す呼び出しに化けます。 最終的に puts には 0 が渡って表示される、という流れです。 現時点での注意点 現時点では「コンパイルが通った」「実行ファイルができた」「実行できた」の3点だけを見ていると間違った結果を吐いていることに気づけません。 Spinel向けにRubyを書くときは README を都度確認することが重要です。 Spinelを使ってみる 次に実際のユースケースを想定してみます。 実例として、GitHubのPR一覧JSONを入力に取り、各PRの number と author を表示するスクリプトを書いてみました。 入力はARGV、stdinの優先順で受け取ります。 requireなしでJSONを扱う require "json" が使えないので標準の Regexp と String 操作だけで処理を組む必要があります。 なお、ここで示すコードは正しいJSONパーサではありません。 require "json" が使えないSpinelの制約下で、入れ子オブジェクトや }, を含む文字列値が現れない、フラットな配列形式の固定データから number と author をアドホックに取り出す例として読んでください。本格的なJSON処理が必要な場合は、入れ子・エスケープなどで容易に壊れるため、この実装は使えません。 実際のRubyファイルは次のとおりです。 多少トリッキーなところは感じますが、こうした限定的な用途であれば、RegexpとStringの標準機能だけで実装できることがわかりました。 if ARGV .length > 0 input = ARGV [ 0 ] else input = readlines.join end records = input.split( / }, / ) results = [] records.each do |chunk| if chunk =~ / "number" \s* : \s*(\d+)/ num = $1 if chunk =~ / "author" \s* : \s* " ([^ " ]+) " / auth = $1 results << " # #{ num } by #{ auth }" end end end if results.length == 0 $stderr .puts " Error: failed to parse JSON (no matching number/author pairs found) " exit 1 end results.each do |line| puts line end 実行サンプルは次のとおりです。 引数渡し、パイプ、リダイレクトそれぞれに対応しています。 JSONを展開できない場合は標準エラーへエラーメッセージを出して exit 1 します。 SAMPLE='[{"number":1,"author":"Findy"},{"number":2,"author":"jiskanulo"}]' # 1) 引数渡し ./pr_extract "$SAMPLE" # 2) パイプ echo "$SAMPLE" | ./pr_extract # 3) リダイレクト ./pr_extract < sample.json # それぞれの出力: # #1 by Findy # #2 by jiskanulo $ ./pr_extract "not json" Error: failed to parse JSON (no matching number/author pairs found) $ echo $? 1 なお、引数もパイプもなしで ./pr_extract を起動すると readlines がEOF待ちでブロックします。 最初は $stdin.tty? で判定してUsageを表示しようとしましたが、実機で試すとTTYでもパイプでも両方 0 が返ってきました。これも eval / require と同じく、Spinel未対応のメソッドが silent failしている例です。 # test_tty.rb puts $stdin .tty? $ ./test_tty # TTY実行 0 $ echo "" | ./test_tty # パイプ実行 0 Spinelで標準入力を扱うときは $stdin.tty? に頼った分岐ができないため、引数で渡すかパイプ・リダイレクトで明示的に流し込む運用に倒すのが安全です。 ハマりどころは個別に踏みに行く価値がある 実装してみると String#<< でmutable化すると Regexp#scan に渡せない、 Regexp#scan(/(...)/) { |m| ... } のキャプチャは効かない...などとハマりどころがいくつかありました。 ただ、現時点での詳細を解説しても開発が活発に進んでいるのですぐに風化してしまうので詳しくは記しません。 Spinelを試すときの判断基準 ここまで触ってみた感触から、Spinelを触るときの判断基準を次にまとめます。 成功体験を得やすいのは次のようなコードです。 入出力が puts / printf で完結する 標準ライブラリに依存しない 数値計算・文字列処理・正規表現( =~ + $1 )で書ける範囲 逆に、現時点で踏むと詰まる、もしくはsilent failになるのは次のような領域です。 require を前提とするコード（標準ライブラリの利用） eval を含むメタプログラミング 未対応メソッドに依存する処理（呼び出しがゼロ値返却に化ける） 「コンパイルが通ったから動いている」とは限らない、というのが現時点での最も大事な感触です。 CRubyとSpinelの両方で実行して出力をdiffする運用を組むのが安全です。 個人的所感 ローカル環境のlintやチェッカーなど今までワンライナーでやっていたことを置き換えて使ってみたいですね。 コンパイル済みのバイナリを配布できるのであれば環境構築の手間も減るかもしれません。 まだ少し触っただけですが、Spinelに可能性を感じています。また、こういうワクワクするものを提供してくれるMatzさんの凄さをあらためて実感します。 これから機能が拡充されていくのが楽しみです。 自分でもコントリビュートしていきたいですね。 おまけ: Spinelの由来 Rubyと同じく宝石つながりでSpinelなのかなあとはじめ思っていましたが、漫画アニメ『カードキャプターさくら』のスピネル・サン（スッピー）から名前をとっているそうです。 相棒はルビー・ムーンなのでここでもRubyに繋がってきますね。 由来聞いた時はそっちか〜〜！！となりました。かわいい。 おわり ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はい、こんにちはー！クロスイノベーション本部 サイバーセキュリティテクノロジーセンターの福山です。 昨年あたりから、ソフトウェア脆弱性報告件数の増加やサプライチェーン攻撃のニュースが目立つようになりました。 そこで今回は脆弱性管理とソフトウェアサプライチェーンの現状を把握すべく、関連テーマにフォーカスしたセキュリティカンファレンス「VulnCon」にバーチャル参加しましたので、本稿にレポートとしてまとめます。 VulnConとは 1. NIST's National Vulnerability Database Update and the Vulnerability Enrichment Ecosystem 2. Vulnrichment Playground 3. Supply Chains and Malware Campaigns: Is CVE the Right Way to Name the Game? 4. How to Answer "What's Affected?" in Open Source 5. Identifying Exploited and Likely-to-Be-Exploited Vulnerabilities 6. Taming the Scanner Storm: How VEX Brings Context to Vulnerability Data 7. Contextual SBOMs: Unlocking Precise Vulnerability Management with Build-Time Content Intelligence 8. Lessons From NPM's Dark Side: Preventing the Next Shai-Hulud まとめ VulnConとは VulnConとはCVEプログラムやFIRSTが中心となって主催する「脆弱性管理に特化した国際カンファレンス」です。 第1回開催は2024年と比較的新しいカンファレンスであり、今年は米国アリゾナ州スコッツデールで開催されました。 https://www.first.org/conference/vulncon26/ VulnConは、脆弱性管理とサイバーセキュリティ分野の専門家が一堂に会し、意見交換などを行い、具体的な成果の創出を目指す場となっています。 今回、VulnCon 2026（現地時間：2026年4月13日～4月16日開催）をリモートで視聴（参加費用 $100）し、筆者が注目した8つのセッションを紹介します。 本記事では各セッション内容をもとに、脆弱性管理およびサプライチェーンセキュリティの観点から重要なポイントを整理しました。 なお、本記事は講演者の発言内容に基づく書き起こしであり、内容は「TLP:CLEAR」のみです。 1. NIST's National Vulnerability Database Update and the Vulnerability Enrichment Ecosystem 発表：NIST NVD NVDの役割 CVEに対してNVDは追加メタデータ（CPE・CVSS・CWE・参照タグ）を提供する「バウンダリーオブジェクト」として機能 CNAは2016年以降独自公開が可能になり、現在502のCNAが存在 スケールの問題：NVDが直面する現状 CVEの増加数が過去最大レベルに達しており、現行の手動プロセスでは追いつかない CPE割り当てに分析時間の半分以上を消費（LLMプロジェクトやGitHubベースのソフトウェアの急増が負荷を増大） 大規模な未処理バックログが蓄積 NVDの新しい優先度付けアプローチ（リスクベースへの転換） CISA KEVリスト掲載CVE：1営業日以内にエンリッチ（付加情報の付与） 米国連邦政府ソフトウェアに関連するCVE 大統領令14208号で定義されたクリティカルソフトウェアのCVE リクエストベースでの対応も受け付け（対応は可能な範囲で実施） CVSSスコアの方針変更 既にスコアを持つCVEには重複スコアを付与しない（Gap Fillingの正式化） アナリストが矛盾を発見した場合は再評価の可能性あり ※Gap Filling：2025年から暫定導入され、CNAから提出されたCVSSおよびCWEデータを再検証せずに、一時的に受け入れる方針のこと バックログの整理 「deferred」ステータスを「not scheduled」に改名 2026年3月1日以前の古いバックログは原則「not scheduled」に移行 修正されたCVEの再エンリッチは原則行わず（リクエストがあれば対応） 自動化への取り組み LLM/AIを活用した分析自動化を小チームで研究中：完成次第オープンソースとして公開予定 RPAによる反復作業の自動化も並行して検討 CPE管理のフェデレーション化（CNAや作業グループと協議中） 2. Vulnrichment Playground 発表： CISA、Tharros Labs Vulnrichmentとは CISAが連邦政府機関（FCEB）や重要インフラ保護のために行っている脆弱性分析を広く公開する取り組み CVEのADP（Authorized Data Publisher）コンテナとして提供、GitHubリポジトリからも取得可能 毎年約2,000件以上のCVD（協調的脆弱性開示）ケースを処理する中で得た大規模な分析知見が元になっている Vulnrichmentが提供するデータ SSVC（Stakeholder Specific Vulnerability Categorization）：全新規CVEにスコアリング KEVフラグ：既知の脆弱性悪用カタログへの掲載有無 CVSS・CWE：CNA未提供分のバックフィル（CNAが既に提供している場合は上書きしない） 参照タグ：パッチ・アドバイザリ等の分類 2年目の最大の変化：CPEの廃止 当初CPEの付与も実験的に行っていたが、分析時間の2/3をCPE作成に費やしていることが判明 利用者からの「CPEよりSSVC・KEV・CWEのカバレッジを広げてほしい」という声を受けて廃止 CPE廃止によってリソースを再配分し、全新規CVEへの完全エンリッチメントが可能になった 「Playground」の本質：本番環境での実験 KEVは拘束力のある運用指令（BOD）に紐づいており変更コストが高い。Vulnrichmentは低リスクで実験できる場として設計されている 「追加するだけでなく、やめることも重要」という姿勢：CPE廃止がその実践例 Linuxカーネルから「上流カーネル脆弱性のCVSSスコアリングをやめてほしい」という要望（GitHub Issue #262）も公開の場で議論中 Pandoc CVEを使った実践例（CVE記録がどう変化するか） 当初：記述不明確、影響範囲（affected）が「N/A」、誤った参照リンク Vulnrichmentが同日中にCVSS・SSVCを追加 数ヶ月後：参照を修正、SSVCの技術的影響を誤入力→後日修正 実験的介入：CISAが直接Pandocの開発者と議論・検証を行ったうえで書き直す（通常スコープ外） 今後の実験候補：CVE間の関係性の表現 現在は記述文の最終行に「他のCVEとの関連」を自然言語で書くしかない 「CVE同士の関係性を機械可読な形で表現できないか」をVulnrichmentで実験したい（スキーマ変更の前段として） Pandocの例：外部ツールの呼び出し時に別のSSRF脆弱性が発生→関係性が人間にはわかるが機械には処理できない Supplier ADP（SADP）パイロットへの言及 CNA自身が「自社製品でこのCVEは影響なし」というVEX的な情報をADPコンテナとして追記できる仕組みのパイロット 例：Pandocを組み込んだ自社Webアプリが --sandbox など安全な方法でPandocを呼び出しており影響を受けない場合、（提供元がCNAであれば）その旨をADPコンテナとして「影響なし」と追記できる。 参考： https://github.com/CVEProject/sadp-pilot Vulnrichmentのデータ品質・透明性について CVEプログラムのレコード・NVD・Vulnrichmentの3つを信頼性で順位付けするのは難しい 「GitHub上で問題提起→議論→修正」という透明なプロセスが品質の担保 CVSSだけで脆弱性を優先度付けするのは不十分であり、SSVCのようなコンテキスト情報との組み合わせが重要 3. Supply Chains and Malware Campaigns: Is CVE the Right Way to Name the Game? パネルディスカッション： Telos Labs、VulnCheck、HeroDevs、GitHub 議論の前提 CVE CNA Rules 4.1.8 / 4.1.9：一般的な目的で故意に作成された悪意のあるコードはCVE対象外。ただし、トロイの木馬、バックドア、または類似のサプライチェーンの侵害など、悪意のある形に改変された製品は、脆弱性であると判断される可能性がある。 OSVやOpenSSFのmalicious-packagesリポジトリなど代替はあるが、エコシステム全体での標準化や運用の成熟はまだ発展途上 ケース1：XZ Utils（CVE-2024-3094）—バックドア埋め込み Red Hatがバックドアを悪意ある改変済み正規コードとしてCVEを発行 CVEがあったことで、既存の脆弱性管理パイプラインがすぐに対応できた CVEなしでは「どのXZ Utilsの問題か」の識別子がなく、情報伝達が混乱していた可能性 ケース2：tj-actions（CVE-2025-30066）—GitHubアクションの侵害 メンテナーのアカウントがロックアウトされた状態でMITREがCVEを発行 メンテナーが機能停止しても、他のCNA（この例ではMITRE）がCVE発行で通知を前に進められる可能性が示された CVEがあったことで既存ワークフローへの統合が即座に可能 ケース3：Shai-Hulud—npmワームキャンペーン npmのマルウェア削除処理がCVEなしで機能し、GHSAが公開されnpm auditで警告 CVEを使わなくても npm エコシステム（GHSA/npm audit）が機能した ただしCVEシステムにはキャンペーン全体を関連付けるメカニズムが存在しない（記述に書くしかない） ケース4：Trivy侵害（CVE-2026-33634） GitHubがTrivy向けCVEを発行、下流のLightLLMとTelnyxは個別アドバイザリを取得 パッケージマネージャーをまたがる侵害（Go＋PyPI）でのCVE運用の課題を浮き彫りに CVEが最善の方法か？ 「CVEは25年前の設計思想で動いており、今でも機能している。だが完璧ではない」 キャンペーン全体を一つのIDで追跡したい場合と、個別パッケージごとにIDが必要な場合は矛盾する CVEの増発は対応チームの負荷増大を招く（10件のCVEは1件の10倍の事務作業） 「IDが多すぎることは問題ではないが、それらを関連付けられないことが問題」（現行CVEにそのメカニズムなし） 4. How to Answer "What's Affected?" in Open Source 発表： Google CVEプログラムの課題 1999年は321件 → 現在は10分に1件ペース 構造化されていないテキストが多く、自動マッチングが困難 NVDのCPE付与の遅延により手動処理が必要な状況が続いている OSV（Open Source Vulnerability）スキーマの設計思想 機械可読な形式でオープンソースの脆弱性を記述 introduced （脆弱性の混入時点）・ fixed （修正が入った時点）・ last_affected （影響を受ける最終点）イベントで範囲を定義 OSVの設計がCVE5.0スキーマにおけるバージョン範囲導入に影響した バージョン範囲の複雑さ（LTSブランチ問題） 「1.xで導入→2.2.8で修正→3.0で再導入」のような複数ブランチは単純な線形バージョンでは表現しづらい コミットの差分（diff）をハッシュ化した patch-id を使うことで、チェリーピックされた修正を自動検出できる Gitは本質的な順序関係を持つため、エコシステム固有のバージョン比較ロジックに頼らずに済む 「影響あり」判定のルール 導入コミットから現在のコミットへ、修正コミットを経由しないパスが存在する場合に影響あり マージコミットの扱い：修正ブランチ取り込みでも履歴次第で安全性が変わる。判断には“introduced→当該commit”の経路にfixedを含むか、曖昧なら影響あり寄りに倒す。 introduced: 0 （最初のバージョンから脆弱）の際、Gitの複数ルート（subtreeなど）への対処も明示 データソースの種類 エコシステム直接提供（crates.io、GoなどはOSVフォーマットで直接提供、関数レベルの情報も含む） GitHub Security Advisory（GHSA）経由でMaven・npmの情報を補完 CVE/NVDからの変換：バージョンタグとGitコミットを照合して範囲を推定（ただし修正コミットではなくリリースコミットを辿りがちで限界もある） ここから学べること CNAとしてGitコミットハッシュでの脆弱性レポート提供を強く推奨 ツール（VEX・到達可能性解析・静的解析）と組み合わせて「自分のプロジェクトで実際に影響を受けるか」をさらに絞り込める 5. Identifying Exploited and Likely-to-Be-Exploited Vulnerabilities 発表： VulnCheck VulnCheckのCNA活動の3本柱 Report of Vulnerability Service：外部研究者から脆弱性報告を受け付け、CVE発行まで無償でサポート 脆弱性研究・CVD調整：サードパーティとの調整、監査、CVEアサイン Initial Accessチーム：エクスプロイト開発、検知アーティファクト作成（実際に脆弱なコンテナを本番インターネットに公開して攻撃トラフィックを確認） VulnCheck独自KEVの定義と実態 「公開情報として悪用報告があるもの」または「VulnCheckが観測したもの」すべてをKEVとして扱う（CISAより広い定義） 2025年の悪用確認済み脆弱性のうち約28%が開示日当日以前に悪用証拠あり AIの普及によりこのタイムラインがさらに短縮される懸念 CVE未割当の悪用脆弱性の発見：Shadow Serverとの連携 Shadow Serverのシンクホール（悪用検知シグネチャ）を分析→CVEが存在しない状態で長年悪用されていた脆弱性を約50件発見、CVEアサイン 実例：2016年から公開されていたD-LinkのDSLモデムの脆弱性→2025年まで未割当→CVEアサイン後にCISA KEVへ掲載 「CVEがない＝リスクがない」ではなく、単に見えていないだけ Metasploitモジュールの監査 Metasploitに存在するエクスプロイトモジュールとCVEの紐付けを全件監査 数百件のモジュールにCVEが未割当→うち約200件はCNA管轄内でCVEアサインが可能 Moore's Lawの進化版：「カジュアルな攻撃者の能力向上速度≒AIの進化速度」になりつつある BlackHat/Bostonのチャットログ例：脅威アクターがMetasploitをインストールし多数のモジュールを活用 製品セキュリティアドバイザリの活用 Microsoft MSRCのような機械可読フォーマットで悪用インジケータを提供するベンダーが理想 実例：Notepad++が悪用→サプライチェーン侵害→VulnCheckがDIBSプロセスで調整しCVEアサイン→CISA KEVへ掲載 DIBSプロセス：重複CVE発行を防ぐ協調メカニズム CNAが集まり、クリティカルな脆弱性に対して「誰がCVEを発行するか」を短期間で合意する非公式プロセス CVE重複発行リスクを減らしながら、対応速度を確保する リポジトリは公開されており参加可能 研究者コミュニティとの関係構築が重要 Project Discoveryなど、繰り返し脆弱性を報告する研究者コミュニティとの信頼関係を構築→深夜にLinkedIn経由でゼロデイ報告が届く Versa Connectの認証バイパス脆弱性：報告当夜にCVEを発行し、翌日にはShadow ServerおよびSibolが実運用環境での悪用を確認→CISA KEV掲載 脆弱性の悪用に関する初期情報は、研究者コミュニティやフォーラム、Discordなどに常駐する「perpetually online groups」によって最初にサーフェスすることが多く、そうしたシグナルをいかに早くキャッチできるかがカギになる 研究者クレジットの重要性 VulnCheckのInitial Accessチームの研究者（Kale）に加え、外部の脆弱性研究チームであるwatchTowr Labs、Code Whiteが同一の脆弱性をほぼ同時に発見する「researcher collision」が発生 全報告者に適切なクレジットを付与することが信頼を構築するうえで重要 ベンダーはアドバイザリとCVEレコード両方にクレジットを記載すべき AIによる影響（Q&Aより） 高スキル研究者が使えば高品質な脆弱性報告の大量提出が可能に スキルの低い報告者からの「スロップ（雑な報告）」も増加 脅威アクターはまだ古い枯れた脆弱性を多用しており、AIによる新規開発加速の実害はまだ計測困難だが、注視中 6. Taming the Scanner Storm: How VEX Brings Context to Vulnerability Data 発表： NVIDIA 前置き この発表はスキャナーから得られる脆弱性データをどう扱うかという話 今回は特にコンテナイメージにフォーカス 一部のイメージを対象に始めたプロジェクトで、その後すべてのコンテナイメージにVEXを適用できるようになった ※VEXとは： https://www.vuls.biz/blog/articles/20241105a#Vulnerability-Exploitability-eXchange-VEX （上記FutureVuls Blogを参考） 問題：スキャン結果が多すぎて開発者が動けない 34,000のコンテナイメージを毎日スキャン結果を更新→約2,690万件の脆弱性発見、24,536件のユニークなCVE そのうち66%はベンダーパッチが未提供（上流修正はあるがベンダーが未取り込み） スキャナーは「ベンダーが影響なしとしているか」「本当に悪用可能か」「偽陽性か」を判定しない VEX（Vulnerability Exploitability eXchange ※）オーバーレイシステムの設計 2段階パイプライン： Ubuntu（GitHub公開のVEX）とRed Hat（CSAF系VEX）を取り込み、正規化してCycloneDXとしてDBに格納 スキャン完了時にAPIがスキャンレポートにVEX情報を上書きする ルールエンジンでリスク許容度に応じた自動VEX適用ポリシーを設定 VEXアクションの優先順位（ルール） upgrade_suggested → 自動反映しない。修正版があるのでアップグレードを促す vendor_VEX-not_affected → Critical/High含む全深刻度で自動反映可 fix_available → vendor_VEX-not_affected より後順位で適用 vendor_VEX-affected → ベンダーが影響をMedium以下とする等、条件付きで自動反映し、開発者の追加調査の負担を減らす no_vex_or_upgrade_found → 原則は自動で判定せず。ただし最近公開された場合などはトリアージ中として扱う 実績データ 修正しなかったfindingsのうち94%でVEX情報に基づく判定が可能（CVE 2020以降） 中低深刻度1,700万件のうち84%にVEX情報が適用 Critical/Highは修正可能なものが多く積極的に修正指示 -2,600万件→VEX適用後、開発者が真に対応すべき件数を大幅削減 ベンダーが「影響なし」と言っていても顧客スキャナーでは検出されるため、SLAの設計が必要な課題として残る 学んだこと ベンダーごとのVEXフォーマット・更新頻度が異なり正規化が必須 スキャナー側がVEX情報を取り込んでいないケースがあり、業界全体での標準化・取り込みが課題 Alpine等まだ対応していないディストリビューションのVEX情報の取り込みが今後の課題 7. Contextual SBOMs: Unlocking Precise Vulnerability Management with Build-Time Content Intelligence 発表： Red Hat SBOMについて SBOM（Software Bill of Materials）は、ビルド工程で使われ、最終的なソフトウェアコンポーネントに含まれる全アーティファクトを機械可読で棚卸ししたもの 脆弱性管理において重要なのは、ソフトウェア資産全体の中からCVEを迅速に特定でき、修正の優先順位付けにも役立つため 規制（例：EU Cyber Resilience Act）やフレームワーク（例：NIST SSDF）でSBOM要求が増え、SPDX/CycloneDXやツール群で成熟してきた一方、複雑で現実的なコンテナビルドでは「SBOMが約束すること」と「実際に提供できること」にギャップがある 標準SBOM（Analyzed SBOM）の根本的な限界 コンテナイメージは複数のベース・ビルダーイメージからなるマルチステージビルドで構成 標準SBOMはフラットな「contains」リストのみを提供し、「なぜそのアーティファクトがそこにあるか」が不明 「誰が修正責任者か」がわからない状態でCVEが報告されるため、複数チームが無駄な調査・再ビルドに時間を浪費 誤った順序での再ビルドによりCVEが修正されない事態が起こり得る Contextual SBOMのコアコンセプト ビルドステップを精密に監視し、全アーティファクトをビルドアクション・生成イメージにマッピング 使用するSPDXのRelationshipType： CONTAINS ：コンテナイメージ内の標準的な包含関係 DESCENDANT_OF ：ベースイメージとの親子関係（例：アプリイメージ→UBI Python） BUILD_TOOL_OF ：マルチステージビルダーイメージとの関係 具体的な効果（ベースイメージの例） 脆弱なHTTPパッケージ検出時→Contextual SBOMから「UBI Pythonベースイメージに由来」と即座に判定 アプリケーション所有者ではなくベースイメージ所有者に通知 ベースイメージ修正後のCI/CDパイプラインの自動再ビルドを完全自動化 具体的な効果（ビルダーイメージの例） curl が脆弱→GoLang Builderイメージが起点と特定→アプリレイヤーにコピーされていない場合は最終アプリの再ビルド不要と判断可能 ソースコードの依存関係起因のCVE→ベースイメージ所有者・ビルダー所有者には通知不要 Contextual SBOM導入前後の比較 Before After アーティファクトの起源 不明 即座に特定可能 修正担当チーム 関係しそうなチームが巻き込まれ、担当特定に時間 担当チームを最初から特定でき、担当だけが動ける 再ビルド順序 試行錯誤・重複ビルド 最適な順序で自動実行 社内エスカレーション 全体アラートになりがち 「対応不要」と伝えられる 課題と呼びかけ アーティファクトの一意識別子（チェックサム・SPDXのPackage Verification Code）の一貫性が精度の前提 カスタムバイナリファイルなど一意識別子を持たないコンテンツでは起源特定が困難→「不確実状態」でフラグ付け SBOMツールエコシステム全体におけるContextual SBOM対応ツール開発への投資を呼びかけ Contextual SBOMの利用方法 Hermeto（※） 公開プロジェクトとして公開中、CI/CDパイプラインへの組み込み可能 ※Hermeto Project： https://github.com/hermetoproject 8. Lessons From NPM's Dark Side: Preventing the Next Shai-Hulud 発表： OpenSourceMalware.com 「偶発的脆弱性」vs「意図的マルウェア」の違い 偶発的：開発者のミスによるフロー、CVE対象、サードパーティライブラリが動いている場所で悪用、影響期間は長期間のケースがある 意図的：最初に感染するのは開発者PCやCI、影響期間は短命（axiosは3時間未満でレジストリから消えた）、シークレット窃取が主な目的 CVEの対処法（最新バージョンにアップグレード）が、マルウェアでは逆に感染経路になる なぜnpmが標的になるか postinstallなどのライフサイクルスクリプトがデフォルトで実行される（ダウンロード直後に感染） provenance（発行元証明）が必須ではなく、検証の習慣が根付いていない 長期有効トークン（Long-lived Access Token）が存在し、一度奪われると長期間悪用される さらにJavaScriptの推移的依存関係の多さも影響範囲の拡大を加速 2025年主要マルウェアキャンペーン（5件） eslint-config-prettier（7月）： 3800万DL/週。タイポスクワッティングドメインのフィッシングでトークン窃取→Windows開発環境でRCE is（7月）： 280万DL/週。「メンテナーの誤ったアクセス削除」を装うソーシャルエンジニアリング→クリプトウォレット・クラウドクレデンシャル窃取 NX（8月）： GitHubアクションの未発見脆弱性を悪用→AIツール（Claude・Gemini・Amazon Q）の設定を書き換えてマルウェアの共犯者化→370社・20,000ファイル以上流出（第2波で6,700リポジトリ追加公開） Quix（10月）： 26億DL/週。「2FA更新」を装うフィッシング→chalk・debugパッケージ含む28パッケージ侵害→$1,000相当の暗号通貨窃取 Shai-Hulud（9月・11月）： 187パッケージ掌握→TruffleHogを武器化してシークレットをスキャン→感染したパッケージを自動的に再公開するワーム機能→528リポジトリ公開化→第2波で492パッケージ追加侵害（ホームディレクトリ削除機能付き）→26,000リポジトリからクレデンシャル流出 2026年：TeamPCPによるTrivy・axios侵害 Trivy： 長期有効PATを悪用して悪意あるリリースを公開→LightLLMなど下流ツールも汚染 axios： 北朝鮮系脅威アクターによる高度なソーシャルエンジニアリング（偽のSlack連絡・偽のTeamsアップデート誘導によるマルウェア実行） Shai-Hulud第2波の被害を受けた組織の分析 侵害された30,000パッケージについて、どれだけの組織がシークレットをローテーションしたかを調査（Entro Security社による分析） 被害を受けた組織は1,000を超える 一定数の組織で、Shai-Hulud第2波から72時間後も有効なクレデンシャルを保持していた 被害組織は技術系企業だけでなく不動産・医療・保険など幅広い業種に及ぶ 防御策：npmメンテナー向け ハードウェアキー（YubiKeyなど）：ブラウザのオリジン不一致を拒否し、人的認証経路を保護 Trusted Publishing（GitHub OIDC）：CI/CDパイプラインのトークンを保護（採用率：過去ATO被害者で13%、Shai-Hulud被害者でさらに低い10.8%） セッションベーストークン（2025年12月npm導入）：長期トークンを廃止しExposure Window（露出期間）を縮小 防御策：利用者向け 開発者： バージョンピンニング、lockfile管理、自動アップデートの無効化、ライフサイクルスクリプトの無効化 プロダクトセキュリティ： 使用していない依存関係の削除、CIやAI IDE上でのマルウェアスキャン クラウドセキュリティ： シークレットローテーションの自動化・即時実行、異常なクレデンシャル使用の監視 インシデントレスポンス： 脅威インテリジェンスとのフィード統合、サプライチェーンのIRプレイブックの作成 Q & A パッケージ単位ではなく、リポジトリ単位でブロックするという考え方とは？ マルウェアを配布するには、パッケージ単体だけでなく、それを公開するためのインフラ（例：GitHubリポジトリ）が必要になる そのため、個々の悪性パッケージを追いかけるのではなく、以下の対応の方が、運用上効率的でスケールしやすいケースがある 悪性だと判明したGitHubリポジトリ自体をブロックする そのリポジトリから配布される成果物を包括的に遮断する クールダウン期間とは何か？なぜ有効なのか？ 新しいパッケージやバージョンを公開直後にすぐ使わず、一定時間待ってから利用する運用のこと 推奨される待機期間：2〜3日（理由：アカウント乗っ取りなどで公開された 悪性バージョンの多くは、その期間内に削除・検知されている） 攻撃を完全に防げるわけではないが、何もしない場合に比べてリスクを大きく下げられる実用的な防御策とされている クールダウン運用で問題になりがちな点は？ 重大な CVE 対応など、即時アップデートが必要な例外ケースが必ず発生する そのため、クールダウンを前提とする場合は、次が不可欠である 技術的にクールダウンを回避できる仕組み 誰が・どの条件で例外を承認するかという事前合意 実際の運用では、「24時間以内に全社が即時アップデート必須」というケースは稀 理論上の緊急性と、現場で実際に対応できる現実にはギャップがある まとめ VulnCon 2026では、脆弱性管理を取り巻くエコシステムが大きな転換点にあることが示されました。 NVDやCVEといった基盤は引き続き重要である一方、npmパッケージのマルウェアキャンペーンの事例が示すように、サプライチェーン攻撃のスピードと複雑さは増しており、単一の制度や指標だけでは実運用に耐えない場面が増えています。 また脆弱性管理において、VEXやContextual SBOMによる影響範囲の文脈化に加え、VulnCheckの発表が示したような「実際に悪用されている／されやすいか」という視点を組み合わせる重要性が強調されていました。 本記事で紹介したセッションは、これらの変化と課題を理解するうえで特に参考になる内容が多かったと感じました。 ちなみにバーチャル参加の場合、TLP:CLEARかつ2日目以降のセッションしか視聴できませんでした。 ネットワーキングパーティやワークショップへの参加、TLP:GREEN以上のセッションを視聴したい場合は、現地参加をご検討ください。 https://www.first.org/events/calendar/2027#start:2027-03-30 CVE/FIRST VulnCon 2027 & Annual CNA Summit - Save the Date Scottsdale, US March 30, 2027–April 2, 2027 私たちは共に働いていただける仲間を募集しています！ みなさまのご応募、お待ちしています！ 株式会社電通総研 新卒採用サイト 株式会社電通総研 キャリア採用サイト 執筆： @fukuyama.kenta レビュー： @kobayashi.hinami （ Shodo で執筆されました ）