編集者注(2026年10月14日): F5では、「hardened releases」を「critical releases」と呼ぶようになりました。この用語変更は、これらのリリースの重要性と、最新バージョンをできるだけ早く導入することの重要性を反映したものです。
7月に、私は月次の強化版リリースと月次のセキュリティ通知への移行について記事を書きました。当時、この頻度はその時点の状況に適しており、四半期ごとのサイクルから移行する原動力となった規律によって、状況の変化に応じて再び移行できると述べました。
1回のリリースサイクルを経て、多くのことを学びました。お客さまやパートナーからの声に加え、月次リリースが本番環境にどのように適用されるかを見守る中でも知見を得ました。こうして得た知見の一部を踏まえ、アプローチを変更しています。
9月2日のHR2以降、hardened releaseの提供頻度を月次から6週間ごとに変更します。また、これに合わせて公開を予定していた定期的なセキュリティ通知は一時停止します。
日付そのものよりも、そこに至った理由のほうが重要です。そこで、今回の判断に至った経緯をご説明します。
お客さまから寄せられた声
7月15日にHR1をリリースした後、私たちはお約束したとおり、お客さまの声に耳を傾けました。
寄せられた声は一貫しており、実際のところ、F5だけの問題ではありませんでした。最も重要なシステム経路でF5製品を運用している組織からは、月次のリリースサイクルでは、テスト、ステージング、デプロイに十分な時間を確保できないとの声が寄せられました。これは必ずしも、F5のリリースだけを見た場合に対応が難しいからではなく、他のベンダーのリリースと同時期に重なるためです。主要なベンダーはいずれも同じ変化に対応しており、その負担が積み重なって、各企業内の限られた同じチームに集中しています。
6週間という間隔は、誰も導入できない修正は修正とはいえない、という認識に基づいています。お客さまが変更を受け入れられる速度そのものが、今やセキュリティを左右する要素の一つです。その速度を上回るリリース頻度は、リスクを軽減するどころか、かえって増大させます。
“組織は、ユーザーとアプリケーションの間、エージェントとAPIの間にF5を配置しています。F5がこのような位置にあるからこそ、現在のペースで問題を発見して修正し、現在の方法でテストを行い、情報開示について今回の判断を下しました。”
もう1つ明らかになったのは、これとは逆の傾向です。フリート管理と自動化に投資したお客さまは、更新速度が大幅に向上しています。大規模なF5 BIG-IPフリートを運用するグローバル企業では、更新にかかる期間を6か月超から約2週間に短縮しました。
セキュリティ通知を一時停止する理由
2つ目の変更はより難しい判断であり、その理由を率直にお伝えします。
月次のセキュリティ通知を発表した際、セキュリティを強化したリリースから情報開示までに約30日間の猶予を設けることで、詳細が公開される前にお客さまがアップデートを実施できる現実的な期間を確保できると想定していました。これは、当時の状況に基づく最善の判断でした。
この前提はもはや成り立ちません。ここ数週間にわたり、お客さまや業界関係者と対話を重ねる中で、実際に機能するエクスプロイトの作成に必要な情報量について、F5の評価は変わりました。フロンティアモデルは、差分、部分的な説明、バージョン範囲といった限られた手掛かりから、実行可能な攻撃チェーンを導き出す推論能力を高め続けています。防御側のために設けたと考えていた猶予期間は、実際には攻撃側にも猶予を与えており、しかもその期間は短くなりつつあります。
そのため、この環境における責任ある情報開示のあり方を関係者とともに検討する間、定期的な通知を一時停止します。ただし、例外もあります。脆弱性が実際に悪用されている場合、研究者や政府機関と連携している場合、または規制上もしくは契約上の義務により開示が求められる場合には、異なる方法で対応します。これは、透明性に関する恒久的な方針ではありません。お客さまの保護を最優先するという制約のもとで下した判断であり、今後も継続的に見直していきます。
これが受け入れにくい判断であることは承知しています。元CISOである私自身にとっても、受け入れにくいものです。情報開示の規範には正当な理由があり、セキュリティコミュニティが数十年にわたる厳しい経験を通じて築き上げてきました。しかし、そうした規範は、「詳細の公開」から「エクスプロイトの利用可能」までの間隔が週単位だった時代を前提に定められたものです。今やその間隔はほぼなくなり、脆弱性情報を公開するすべての組織が、その意味するところに向き合わなければなりません。
より難しい問題:深刻度情報なしでのトリアージ
これは、業界がまだ十分に向き合っていない部分だと考えています。
脆弱性管理プログラムの多くは、深刻度を基準に構築されています。緊急の脆弱性には24時間以内、高は3日以内、中は1スプリント以内にパッチを適用し、低は時間に余裕があるときに対応します。このモデルは、深刻度評価によってリスクを有意に予測できること、そして判断材料となる深刻度評価が存在すること、という2つを前提としています。
この2つの前提は、いずれも成り立たなくなりつつあります。
1つ目の前提が崩れつつあるのは、フロンティアモデルを利用する攻撃者には重大な脆弱性が必要ないためです。攻撃者は複数の問題を連鎖させます。個別にはトリアージキューの下位に置かれかねない3つの低深刻度の問題でも、モデルが3つすべてを同時に推論できれば、侵害に至る有効な経路となります。F5が自社のコードをスキャンすると、連鎖する可能性のある低深刻度の問題という、この種の問題が見つかっています。こうした問題を体系的に取り除くことで、ソフトウェアを堅牢化できます。一方、深刻度に基づいて個別にトリアージすると、問題がそのまま残ることになります。
2つ目の前提が崩れつつあるのは、F5を含むベンダーが、今後は公開する詳細情報を減らし、公開時期も遅らせることになるためです。セキュリティチームがこれを、自らのコントロールが失われるように感じるのも理解できます。
では、代わりにどうすればよいのでしょうか?
評価ではなく、露出度に基づいて優先順位を付けます。 到達可能性、インターネットへの露出、影響範囲、ビジネス上の重要度は、入手できない可能性があるCVSSスコアよりも、長期的に有効な判断材料です。公開され、パッチが適用されていない資産は、アドバイザリの内容にかかわらずリスクとなります。
常に最新の状態を維持することを規律とする。 この環境で成果を上げる組織は、「最新のセキュリティ強化済みリリースを運用すること」を、深刻度評価をきっかけとする一時的な対応ではなく、継続的な運用上の責務として捉えています。これは技術面だけでなく組織文化の転換でもあり、継続するには経営層の後押しが必要です。
今こそ、変化を吸収する能力に投資を。自動化、システム群全体の可視性、繰り返し確保できるメンテナンス時間帯、検証済みのロールバックがあってこそ、より速い更新サイクルにも無理なく対応できます。現時点では、こうした投資は必須ではないように見えるかもしれません。しかし、1年後にはそうではなくなるでしょう。
ギャップの存在を前提に、防御策を講じる。どの組織もパッチを即座に適用できるわけではありません。振る舞い検知、仮想パッチ、特定の脆弱性に関する知識に依存しない制御などのランタイム保護は、修正策が提供されてから実際に適用されるまでの期間をカバーするのに役立ちます。この期間がなくなることはありません。回避するのではなく、存在を前提に計画してください。
考えを改めることについて
私たちは7月、その時点で得られた最善の情報に基づいて決定を下しました。その決定を実行に移し、お客さまやパートナーから学び、方針を調整しました。発表したからという理由だけで方針を変えずにいたなら、お客さまやパートナーにとって、より望ましくない結果になっていたでしょう。
7月に、状況やお客さまのニーズの変化に応じて、今後も適応を続けていくとお伝えしました。今回の対応は、それを実践したものです。現在、業界全体で従来の慣行がリアルタイムに見直されています。どのベンダーもこの現状を率直に認めるべきであり、この問題を完全に解決したと主張するのであれば、状況を正しく捉えているとは言えません。
変わらないのは、F5が自らに課す基準です。組織は、ユーザーとアプリケーションの間、エージェントとAPIの間にF5を配置しています。こうした立場にあるからこそ、F5は現在のペースで問題を発見して修正し、現在の方法でテストを行い、今回の情報開示に関する判断を下しました。この判断に影響を与えた皆さまからのフィードバックに感謝いたします。今後もぜひご意見をお寄せいただき、最新情報をご確認ください。
著者について

Kunal Anandは、最高製品責任者としてF5の製品部門を率いています。製品のビジョン、戦略、実行を統括し、重要な課題を解決して優れた顧客体験を生み出す画期的なソリューションの開発を推進しています。前職の最高技術・AI責任者としては、F5のテクノロジーおよびAIに関する戦略とビジョンを策定しました。 F5入社以前は、Impervaで最高技術責任者と最高情報セキュリティ責任者を兼任していました。2013年に共同創業したアプリケーションセキュリティのスタートアップPrevotyが2018年に買収されたことを機に、Impervaに加わりました。Prevoty以前は、BBC Worldwideでテクノロジーディレクターを務めました。イノベーションと技術分野で豊富な実績と専門知識を有し、Gravity、MySpace、NASA Jet Propulsion Labでは、セキュリティ、データ、テクノロジー、エンジニアリングの各チームを率いる役職を歴任しました。 AIと機械学習の分野で15年以上の経験を持ち、モデルのトレーニング、AIを活用したアルゴリズムによる製品強化、AIアーキテクチャの設計と実装に携わってきました。 Babson Collegeでコンピューターサイエンスの理学士号を取得しています。
Kunal Anandのその他のブログ記事関連するブログ記事

F5 Distributed Cloud CDN:アプリを高速化、ワンクリックで有効化、コストを削減
F5 Distributed Cloud CDNなら、既存のセキュリティポリシーを変更することなく、ワンクリックでアプリを高速化し、オリジンの負荷とエグレスコストを削減して、コンバージョンを向上できます。

F5 BIG-IP v21.1を先行紹介:AIセキュリティ、PQC、ソフトウェアの機能強化
F5のBIG-IP v21.1がAIセキュリティとPQC対応への準備をどのように実現するかをご紹介します。
新しいAI AssistantでGuardrailsを高度化し、セキュリティを強化
F5の新しいAI Assistantは、AI Guardrailのカスタムスキャナー機能に直接組み込まれています。この機能により、企業はGenAIを活用して、自社固有のユースケースや独自のリスクプロファイルに沿ったポリシーを作成し、標準搭載の保護機能を超える対策を実現できます。
EU AI Actへの準拠がより容易に
AIシステム全体でEU AI Act、特に最も重大な禁止事項を運用に落とし込むには、どうすればよいのでしょうか。GenAIを導入するチームにとって、Article 5の「禁止されるリスク」に関する規定への対応には特有の課題があります。操作的な行為、生体認証による監視、ソーシャルスコアリングなど、最も重大な違反の多くは、従来のセキュリティツールでは容易に検出できないためです。F5のAI […]
AIレッドチームに欠けているものと、その改善方法
レッドチーミングは長年にわたり、企業セキュリティの要となってきました。しかし生成AIに関しては、多くの組織が新たな脅威環境に旧来の手法を適用しています。静的なプロンプトテスト、単発の監査、CLIベースのツールでは明らかな不具合を発見できる場合もありますが、導入後の生成AIシステムの挙動が持つ現実世界の複雑さを捉えられることはほとんどありません。 […]
欧州連合の人工知能法
AIが国際ビジネスのあり方を変える中、欧州連合の人工知能法(EU AI Act)は、AI技術の進化における重要な節目となっています。27か国で法制化されたこの重要な規制枠組みは、AIの利用を予定するあらゆる企業や組織に影響を及ぼし、AIシステムのあり方を形作ることになります。[…]