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

ABEMAの広告配信システムのバックエンド開発を担当している黒崎 ( @kuro_m88 )です。 ...

G-gen の山崎です。当記事は、Google Cloud Next '26 in Las Vegas の2日目に行われたライトニングトークセッション「 8 Tips to Agentic Security Operations in 18 Minutes 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 AI を利用したセキュリティ運用における8つの Tips Tips 1: AI 推論の下に決定論的ルールを階層化する Tips 2: エージェントが必要とするデータを事前に計算する Tips 3: エージェントの権限を明示的に制限する Tips 4: ツールの出力は人間のためではなくエージェントのコンテキストウィンドウに合わせて設計する Tips 5: プロビナンスとリネージを通じてエージェントの決定に対する信頼を構築する Tips 6: 完璧な実行ではなくグレースフルデグラデーションを設計する Tips 7: 単体テストだけでなくシナリオハーネスを用いてシステムをテストする Tips 8: すべての要素、特にトークン使用量とアップストリームのレイテンシを観察する セッションの概要 Insight 社の John Giglio 氏と Hayden Holland 氏により、セキュリティ運用における AI エージェントの利用に関する実践的な8つの Tips が紹介されました。 セッションでは、AI を単なる確率論的な推論ツールとしてではなく、決定論的なシステムと組み合わせて安全かつ効率的に運用するための設計思想が語られています。 AI を利用したセキュリティ運用における8つの Tips Tips 1: AI 推論の下に決定論的ルールを階層化する エージェントの開発において、柔軟な AI の推論と、決定論的なルールベースの処理を組み合わせることが重要となります。AI の推論は確率論的であり、常に同じ結果を返すとは限りません。一方、決定論的なシステムは常に同じ結果を保証します。 セキュリティ領域においては、不確実性のある AI だけで環境に変更を加えることは大きなリスクを伴います。そのため、Insight 社では Site Reliability Engineering （以下、SRE）の手法に倣い、AI エージェントをデータのパターン認識や意思決定の補助として使用し、実際の実行部分は Python や Go 言語などで記述された決定論的なコードに委ねるアーキテクチャを採用しています。 SRE のマインドセットでは、運用業務を定期的に自動化して減らしていくことが求められますが、AI エージェントを使用することで、このプロセスをスピード感を持って対応することができます。 YAML や JSON スキーマ言語を多用してステップを定義し、期待される結果とそうでない結果を明確にしながらシステムを構築することで、AI エージェントは未知の脅威を探索する能力を提供し、決定論的なルールはシステムの安全な基盤を提供します。このように階層化することで、高い探索能力と耐久性のある実行の両立を実現できます。 Tips 2: エージェントが必要とするデータを事前に計算する Large Language Model （以下、LLM）を使用する推論やツール呼び出しには、多くのトークン消費とレイテンシが伴います。セキュリティ調査のたびに AI エージェントにあらゆる情報を探索させると、運用コストが膨大になり、回答を得るまでの時間も長くなります。 例えば、 MCP （Model Context Protocol）を使用して多数のツールをエージェントに接続し、すべてを自律的に推論させようとすると、処理が空回りし続ける可能性があります。この課題に対処するためには、エージェントにすべてを推論させるのではなく、エージェントが必要とするであろうデータを事前に計算し、準備しておくことが有効です。 エージェントには、明確に定義されたシステムプロンプトと、「この IP アドレスはウェブ環境で何をしているのか」といった特定のセキュリティのユースケースに特化した小さなスキル（skills）のみを使用させることが推奨されます。事前に与えられる情報が多いほど、エージェントの出力の精度は向上し、高価な LLM の呼び出し回数を最小限に抑えることができます。 参考 : What is the MCP and how does it work? 参考 : What is the Model Context Protocol (MCP)? Tips 3: エージェントの権限を明示的に制限する 現在、エージェントに自律的な意思決定をさせ、環境への変更権限を与えることには依然として高いハードルがあります。AI エージェントに対する完全な信頼が確立されていない段階では、エージェントの権限を明示的に制限するガードレールが不可欠です。コンテキストウィンドウ内に「何も編集しないで」という指示を含めたとしても、AI がそれを完全に遵守する保証はありません。 そのため、データを変更する可能性のあるツールの呼び出しについては、実行前に現在の権限レベルをチェックし、拒否ブロックを設ける必要があります。コンテキストウィンドウに指示を含めるだけでは、確実な保証は得られません。 2026年4月現在、多くの組織は「すべてを閲覧する」という読み取り専用の権限でエージェントを運用し、 Security Information and Event Management （SIEM）などのデータを通じて、エージェントの推論の精度を統計的に評価している段階とされています。 Tips 4: ツールの出力は人間のためではなくエージェントのコンテキストウィンドウに合わせて設計する エージェント間でデータを受け渡す際、ツールの出力結果はエージェントのコンテキストウィンドウに最適化されている必要があります。人間が見やすい形式で大量のデータをエージェントに渡すと、コンテキストウィンドウの上限に達し、重要な情報が無視されるなどの問題が発生します。システムは人間のためではなく、エージェントのために設計されなければなりません。 例えば、500件のファイアウォールルールのデータをそのまま返すよりも、関連性の高い上位10件の調査結果に絞り込み、「次に特定のルールについて詳細をクエリする」といったヒントを付与する方が効果的となります。エージェントは人間以上の情報を処理できる能力を持ちますが、コンテキストウィンドウの限界に配慮し、処理効率とのバランスを取る設計が求められます。適切なデータ量を提供することで、エージェントの能力を最大限に引き出すことができます。 Tips 5: プロビナンスとリネージを通じてエージェントの決定に対する信頼を構築する セキュリティチームがエージェントの自律的な意思決定を信頼するためには、ブラックボックスを排除し、推論の過程を検証できる仕組みが必要です。セッション内では、これを メタ可監査性 （Meta-auditability）と呼んで説明されています。 エージェントが導き出したすべての結論について、どのようなデータに基づき、どのような推論過程を経てそのツール呼び出しが行われたのかを遡って確認できるプロビナンスとリネージを設計に組み込む必要があります。セキュリティ担当者は本質的に懐疑的であり、証跡を直接確認できなければシステムを信頼しません。 運用の中でエージェントの行動パターンを継続的に監視・分析し、何十回も実行を繰り返す中で意思決定の傾向を把握します。この継続的な可視化を通じてのみ、少しずつシステムへの信頼を構築していくことができます。 Tips 6: 完璧な実行ではなくグレースフルデグラデーションを設計する システムの障害時に全体を停止させるのではなく、機能を縮小して稼働を継続する グレースフルデグラデーション の概念を、エージェントの設計にも取り入れることが推奨されます。 セキュリティ運用において、完璧な回答を待って時間がかかる、あるいは処理が失敗して何も情報が得られない状況は避けるべきであり、部分的でも正しい答えが得られるように出力結果に対してガードレールを設けることで、信頼性の高いシステムを目指すべきであると述べられました。 Tips 7: 単体テストだけでなくシナリオハーネスを用いてシステムをテストする エージェントをシステムとして本番環境に導入する前には、厳密なテストが不可欠です。しかし、単体テストや、結合テストによる検証だけでは不十分です。 AI エージェントが正しいセキュリティの意思決定を下すことを検証するためには、実際の運用に即したシナリオハーネスを使用する必要があります。サンドボックス環境を用意し、エージェントが予期せぬ挙動を示して制御不能に陥らないか、特定のシナリオにおいて適切なアクションを選択できるかを検証することが重要と語られました。 Tips 8: すべての要素、特にトークン使用量とアップストリームのレイテンシを観察する システムに対する信頼を維持するためには、エージェントの動作を継続的に観察し、可視化することが不可欠です。エージェントがどのような操作を行っているかを監視するだけでなく、トークン消費量やレイテンシの推移も把握する必要があります。 また、エージェントが機能しているように見えても、コンテキストが腐敗し、低品質な結果を出力し始めている可能性があります。コンテキストウィンドウの限界に近づいた際に見られる異常な応答やパフォーマンスの低下を検知するために、エージェントが行っているすべてを観察するという考え方を受け入れることが、安全な運用に繋がると述べられました。 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 13 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit