VulnCon 2026 セッションレポート（脆弱性管理とソフトウェアサプライチェーンの変化）

はい、こんにちはー！クロスイノベーション本部 サイバーセキュリティテクノロジーセンターの福山です。
昨年あたりから、ソフトウェア脆弱性報告件数の増加やサプライチェーン攻撃のニュースが目立つようになりました。
そこで今回は脆弱性管理とソフトウェアサプライチェーンの現状を把握すべく、関連テーマにフォーカスしたセキュリティカンファレンス「VulnCon」にバーチャル参加しましたので、本稿にレポートとしてまとめます。

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本柱

  1. Report of Vulnerability Service：外部研究者から脆弱性報告を受け付け、CVE発行まで無償でサポート
  2. 脆弱性研究・CVD調整：サードパーティとの調整、監査、CVEアサイン
  3. 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アクションの優先順位（ルール）

  1. upgrade_suggested → 自動反映しない。修正版があるのでアップグレードを促す
  2. vendor_VEX-not_affected → Critical/High含む全深刻度で自動反映可
  3. fix_available → vendor_VEX-not_affected より後順位で適用
  4. vendor_VEX-affected → ベンダーが影響をMedium以下とする等、条件付きで自動反映し、開発者の追加調査の負担を減らす
  5. 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が標的になるか

  1. postinstallなどのライフサイクルスクリプトがデフォルトで実行される（ダウンロード直後に感染）
  2. provenance（発行元証明）が必須ではなく、検証の習慣が根付いていない

  3. 長期有効トークン（Long-lived Access Token）が存在し、一度奪われると長期間悪用される

  4. さらに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メンテナー向け

  1. ハードウェアキー（YubiKeyなど）：ブラウザのオリジン不一致を拒否し、人的認証経路を保護
  2. Trusted Publishing（GitHub OIDC）：CI/CDパイプラインのトークンを保護（採用率：過去ATO被害者で13%、Shai-Hulud被害者でさらに低い10.8%）
  3. セッションベーストークン（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で執筆されました）