セキュリティはCVE開示から始まらない

Let me tell you a story ソフトウェアのセキュリティがどのように機能するべきかという、ほぼ学術的なバージョンがあります。それは会議会議、コンプライアンス文書、およびマーケティングスライドで見られる喜ばしい図に表示されます。 研究者はバグを見つけ、静かに(そして専門的に)上流に報告し、上流にパッチを付け、CVEが割り当てられ、下流のメンテナーターが修正を引っ張り、スキャナーが通知し、弁護士がパッチし、世界はほとんどOKです。 もしこれが本当の方法だったら、私は下流のみの修正、沈黙のパッチ、ある場所に存在し、別の場所で消えてしまうセキュリティ問題について書くつもりはありませんが、現実の世界には異なるリズムがあり、ますます存在しているものです。 そして、誰もが知る必要がある。 悩む この記事で学ぶべきこと The Security Timeline Inversion: How CVE disclosure is not the true start of the security timeline. セキュリティタイムラインの逆転:CVEの開示がセキュリティタイムラインの本当の始まりではない。 セキュリティの結果:なぜ、反応速度やツールではなく、通常のメンテナンスの決定がセキュリティの結果を決定するのか。 欠陥の指標:なぜCVEスコア、スキャナ、およびコンプライアンスの期限が効果的な早期警報システムではないのか。 脆弱性歪曲:埋め込まれた、フォークされた、および寿命の終わりのコンポーネントが脆弱性や責任をどのように隠蔽するか。 必要な変更: 統治とライフサイクルの変更は、構造的に「静かな」脆弱性に遅れることを避けるために必要です。 2025年2月、Apache Tomcatは、 彼らは緊急事態なく、コメントなし、重大なセキュリティ事件を伴うような騒音なしで到着した。 ルーチン ほとんどのチームでは、これらのリリースを他のメンテナンスアップデートとは異なり扱う直接的な理由はありませんでした. 何も壊れていないように見えました. 何も損なわれていないように見えました. 対応する脆弱性識別子はありませんでした. 数週間後、同じリリースは、セキュリティの緊急事態の中心となった。 CVE-2025-24813が3月に公開された時点で、脆弱なコードパスはすでに特定され、修正され、サポートされているTomcat支店に配信されていた。 他の誰にとっても、それは不愉快なサプライズとして来た:CVSSスコア9.8は、あなたの日を始めるための素晴らしい方法です。 CVEの詳細はこちらをご覧ください。 私たちは後でコンテンツを調べてみます、なぜなら、何が記録され、誰がそれを記録しているかはこの物語の一部だからです。CVEのゴリの技術的な詳細はほとんど無関係です。 モード: 可能にしなければなりません。 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 欠陥 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 このイベントの順序は、CVEがどのように進化するか、そしてそれが消費者にどのように影響を与えるかを理解するのに役立ちます。 セキュリティタイムラインの逆転 この逆転は、公開日時だけを見ると見逃すのが簡単です。セキュリティタイムラインは、通常、CVEが公開されたときに始まるかのように語られます。実際には、問題が報告されたり、コードを変更したときに始まります。 打ち上げパッドのロケットが数え始めたとき、ロケットが地面を離れる前にエンジンが起動するのがわかります. それはCVEで見たパターンです. この場合、Tomcatのセキュリティチームは、長期にわたるオープンソースインフラストラクチャにとって完全に正常なパターンに従いました. プライベートレポートが到着しました. 問題は調査されました. 修正が開発され、配送されました. 静かに、そしてすべての「ロケット」がパッドを離れる前に。 パッチバージョンが利用可能になってからのみ、公開が行われました。目的は秘密ではなく抑制でした:目的は、弁護者が実行可能な反応を持たないウィンドウを減らすことです。 ヒューズ vs. Hype このアプローチは、ポイントリリースを適用するものとして扱う組織にとってうまく機能します。 ルーチン これらのチームは、理由を知らずにアップグレードし、脆弱性が公に議論された時点で、すでに保護されていた。 行動のトリガーとして開示に依存する組織にとって、3月はゼロの日のように感じた。この脆弱性は完全に形成され、重症度のスコア、取の主張などが完成したように見えた。 両チームは1月に同一のTomcatバージョンを実行していた可能性があり、3月中旬までに非常に異なるポジションに達した。 それは 習慣です。 The Flawed Assumption of Loud Alerts(大きな警報の誤った仮定) 多くのエンジニアリング組織では、深刻なセキュリティの問題が注意を求めるほど大きな声で自分自身を発表するという継続的な仮定があります。この仮定はますます信頼性が低下しています。この場合、最も重要な指標は通常のメンテナンスとは区別できないものでありました。 CVE がリリースされると、通常のストーリーが引き継がれ、脆弱性は名前、スコア、ターゲットオーディションを獲得しました。 ストーリーより変化を優先 2月のリリースを幸運なタイミングと見るのは誘惑です. They were not. They were simply the result of a process that prioritizes fixing code over managing perception. 不快感は、いくつかの組織が知っていることに由来します。 変化ではなく物語に反応するように構造化され、異常よりも宣言に反応する。 無意識 より広範な生態系がCVE-2025-24813の影響を議論し始めた時点で、技術的な結果はすでに設定されていた。 このCVE(そして正直に言うと、すべてのCVEの圧倒的多数)が世界中で展開した方法は、解釈、評価、義務の衝突でした。 そこでこのケーススタディが興味深くなり、そのような素晴らしいサンプルを作ります。 こちらが主なタイムライン 重要な要素はすべて、NVDのCVEとCPEの情報の周りを回っています。 . https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 私はこれが何らかの不当なことが起こったことを示唆する意図ではないことを強調する必要がある。 私はこれが不正な何かが起こったことを示唆する意図ではないことを強調する必要があります。 . 物事はどのように 2025年1月13日 脆弱性 プライベートで報告 Apache Tomcat セキュリティ チームは、部分的な HTTP PUT リクエストとデフォルト ファイル サーブレットを含む脆弱性に関するプライベート レポートを受け取ります。 2025年1月24日:固定承諾。 コミット 通常と予想どおり、セキュリティの欠陥を修正しているという兆候はなく、関連するリクエストは「PARTY PUT によって使用される臨時ファイルのライフサイクルを改善する」と名付けられています。 https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c 2025年2月10日:Fix 静かにリリース。 Apache は安静に Tomcat 9.0.99, 10.1.35 および 11.0.3 をリリースし、修正が含まれています。 2025年3月10日:CVE-2025-24813公開 トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > ( (引用) https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 「この問題は、Apache Tomcat に影響を与えます: 11.0.0-M1 から 11.0.2, 10.1.0-M1 から 10.1.34 まで、 9.0.0.M1 から 9.0.98 まで。 2025年3月13日～14日:PoC取とアクティブな攻撃開始 開示後30時間以内に、コンセプトの証拠が公開されます。大量スキャンと利用の試みが即座に開始されます。攻撃方法:部分PUT経由でJSPウェブシェルをアップロードし、作成されたJSESSIONIDリクエスト経由でトリガーします。 Sources: Sonatype Blog | CyRisk Analysis 2025年3月17日:NVD CVEレコードにPOCエクスペリットを追加 https://github.com/absholi7ly/POC-CVE-2025-24813/blob/main/README.md 2025年3月18日:最初のCPE情報がCVEに追加される CPE CVEは基本的に機械で読み取れるようにする魔法の情報であり、CVEの自動消費者は製品のどのバージョンが脆弱であるかを「知る」ことができます。 https://nvd.nist.gov/products/cpe https://nvd.nist.gov/products/cpe この時点で、CPE は、以前見たオリジナルのバージョン範囲宣言と単に一致します。 2025年3月19日～26日:セキュリティ・ベンダー分析発表 Rapid7, Akamai, Wiz, and Sonatype は詳細な分析を発表しています。Rapid7 は、広範囲な取が確認されず、Apache の前提条件の一部が過大評価されたため、「パニックする必要はない」と指摘しています。 Sources: Rapid7 Blog | Akamai Blog | Wiz Analysis 2025年4月1日:CISAがKEVカタログに追加 CVE は、CISA が既知の脆弱性カタログに CVE-2025-24813 を追加し、積極的な取の証拠を引用していると記録している。 Sources: Keysight Analysis | Amazon Linux Advisories 2025年4月上旬:エンタープライズ・ベンダー・パッチがリリース Red Hat、Amazon、SUSE、Atlassian、およびその他のエンタープライズベンダーはパッチをリリースします。 ほとんどのベンダーは、デフォルトのサーブレットが読み込みのみであるため、デフォルトの構成が脆弱ではないことを強調します。 CPE エントリは debian tomcat エントリを獲得します。 Sources: Red Hat CVE | Amazon CVE 2025年7月3日:ユニット42が125K以上の攻撃未遂を報告 パロアルトのユニット42は、2025年3月だけで125,856件の取試みをブロックしたと報告している。 ほとんどの取トラフィックは、低精巧な俳優による公共のPoCを使用して「機会主義的」に見える。 Source: Unit 42 Report 完成しましたか? さて、一部のTomcatユーザー、バージョン9、10、11のユーザーにとっては、すべてOKです。 2025年8月7日 - CVE 更新 「古い、EOL バージョンも影響を受ける可能性があります」 HeroDevs が主導するいくつかのロビー活動の結果、Apache チームは警告を追加しました。これは重要です。これは非常に稀に起こりますが、Apache やその他の場所で警告が必要だと感じたエンジニアがいました。 CPE は更新されましたが、EOL バージョンについての情報は得られませんでした。 2025年8月8日 - CVE 更新 EOL バージョンについての詳細情報 CVE では、「CVE が作成された当時、以下のバージョンは EOL であったが、 影響を受けることが知られている: 8.5.0 から 8.5.100 」 今 CVE は公式に Tomcat の別のバージョンのストリームに適用されます。 今日 今日でも、このCVEは、スキャナーがバージョン 8.5 で問題を検出するのに役立つ CPE 情報を含むように更新されていません。 その一部は、CVEの性質に起因することができるので、脆弱性はデフォルト構成が変更された場合にのみ可能である。 変わる READYONLY=TRUE readonly = false つまり、理論的には、利用可能性は、Tomcatユーザーがこの変更を行うことができるときに依存します。Tomcatがこの構成が変更されるのを防ぐ方法で埋め込まれている場合、その「埋め込む」製品は正当に脆弱ではないと主張する可能性があります。 また、Apache Tomcatのフォークや商用バージョンもたくさんあります。例えば、それはSpring Bootのコンポーネントであり、Broadcom Tanzuもそれを組み込んでいます。 メッセージが溶ける方法 しばしば苦しい真理は、CVEの報告と適切な人々に適切な認識を得ることに失敗するということです。実際には、コンポーネントがフォークまたは埋め込みするほど、それについて知る必要がある人達に届くのは困難です。しばしば、その瞬間の暑さの中で、ダウンストリームのベンダーは初期のCVEのレポートに届きますが、アップデートのために戻って来ません。 『TANZU』 正確にCVEはTanzuに適用され、独自の識別子TNZ-2025-014を割り当てていると述べています。彼らはCVEがバージョン9.10と11に適用されることをユーザーに警告しますが、その後、いつものように、それは混乱します。Tanzuのスイートは複雑で複雑です。突然、CVEは単純ではなく、 「TanzuがTomcat 8またはそれ以前のバージョンを持っているかどうかは知らないが、彼らのアドバイスが2025年03月25日であることを考慮し、CVEが追加のEOLバージョン情報を追加する前からずっと前から、これは古いTanzu製品の大きな暴露であるかもしれないとしても、このエラーを同情することができます。 サポートページ are-you-exposed-or-not オリジナル 共通シナリオ CVE-2025-24813が名前、スコア、メディアサイクルを取得した時点で、結果はすでに異なっていた。 修正はCVE以前にも存在していたが、一部のシステムは何故か誰もが知る前に保護されていた。 その差異は、意識、ツール、あるいは脅威のインテリジェンスから来たものではなく、タイミングから来たものであり、より正確に言うと、セキュリティは脆弱性が宣言されたときから始まるという仮定からであり、コードが静かに変化した時よりもはるかに大きい。 次に続いたのは単一のイベントではなく、長期的なカスケードでした。CVEのテキストは進化しました。CPEデータは遅く、不完全に到着しました。サプライヤーのアドバイスは範囲を変更しました。コンプライアンスの期限は部分的な真実をポリシーに固めました。 これらは悪意のあるものではありませんでした. それは珍しいものではありません. それは単に 現代の脆弱性生態系は、開示をプロセスではなく瞬間として扱う場合に振る舞う。 どう それは1月、2月、3月、8月、そしてそれ以降に起こった。あなたがどこに座っているか、あなたが何に信号を頼っているかによって異なります。不快な現実は、より広い生態系が深刻さと利用可能性について議論を終えた時点で、技術的結果はすでに固定されているということです。 CVE-2025-24813 どう反応すべきか。 これはあなたにとって何を意味し、次に何をすべきか 私は「不快な真実」という言葉が嫌いですが、このような状況で最も頻繁に使われる言葉です。 だから、このケース研究の「不快な結論」は、 異常に危険なものであり、それがどのように報道され、管理されたかについて何も知らされていなかったということです。 受け入れる CVE-2025-24813 まったく珍しい 脆弱性は、いかなるファンフェリーも伴って到着しなかったが、緊急事態として自らを宣言しなかった。名前が付く前に解決された。生き残ったシステムは、より速く反応したからではなく、すでに変化に対処する方法を決めていたからである。 あなたのセキュリティポジションが依存している場合 なぜアップデートが重要なのは、それを適用する前に、あなたはすでに手遅れで動作しています。 知る 現代の生態系では、説明は行動に従うが、その逆ではない。 実践で何を意味するか 公開はもはやセキュリティのタイムラインの始まりではありません。 CVEが名前、スコア、そして最終的にコンプライアンスの期限を取得する時点で、決定的な技術的作業はしばしば他の場所ですでに行われている。 First スキャナーはあなたに予測を与えるのではなく、あなたが遅すぎることを告げるだけです。 Second CVEデータベース、CPE、KEVカタログは連携ツールで、物語が安定すると大きな生態系が一緒に動くのを助けます。 あなたのコードベースに入ったときも、静かに離れたときも、早期警告システムとして扱うことは、盲点を作り出す。 実際 「デフォルトセーフ」は戦略ではありません。 Third 多くのチームは、この脆弱性が非デフォルトの構成を必要とするという考えに安心しました。その区別は、埋め込まれた配布、フォーク、および脂肪JAR展開が画面に入った瞬間に崩壊しました。 コンポーネントが生産中にどのように構成されているかを証明できない場合、上流の安全性の仮定に頼ることはできません。 習慣はヒーローを打つ この物語の保護されたシステムと暴露されたシステムの違いは、ツール、脅威情報、または反応速度ではありませんでした。 Finally 次にやるべきこと 次のCVEがこれらの仮定をテストするのを待たないでください. あなたはすでに行動するのに十分な情報を持っています。 あなたのアップグレード決定の源を特定することによって。 Start 脆弱性が名前付け、スコア付け、または義務付けられた後にアップデートが優先される場合、これは技術的な問題ではなく、ガバナンスと制御の問題です。 どのツールが相談されるかではなく、決断が行われる。 いつ 「静かな」リリースをどう扱うか。 Examine あなたの環境のどの点のリリースが自動的に適用され、どの点が正当化されるまで延期されるかを尋ねる。 寿命終了部品の責任を明確にします。 Map 依存がアップストリームによってもはやサポートされていない場合、リスクはもはや抽象的で将来的なものではありません。セキュリティの責任はすでに転換されています。 私はここで自分の立場について明確にしなければなりません。私は会社のために働いています。 それは、古いソフトウェアに脆弱性が現れたときにコントロールを取り戻す一つの方法であり、時には非常に実用的な方法です。 (ヒロイン) しかし、それはあなたがここに到達した方法を理解するための唯一の選択肢でもなく、代替品でもありません。 拡張サポートはセキュリティネットワークであって、戦略ではないので、加速アップグレード、補償コントロール、孤立、またはアーキテクチャーの変更があります。これらはすべて異なる文脈における有効な応答です。 寿命の終わりは「デフォルトでは安全ではない」という意味ではありません。それは証拠の負担が移動したことを意味します。誰かが現在、セキュリティの責任を積極的に負わなければなりません。誰が誰であるかを指摘したり、その責任がどのように満たされているかを説明できなければ、リスクはすでに存在します。 セキュリティをイベントではなくライフサイクルとして扱います。 ほとんどの実際の脆弱性がそうである. あなたのプロセスが開示の瞬間にのみ関与する場合、あなたは結果ではなく、物語のために、物語のために最適化しています。 Finally CVE-2025-24813 セキュリティはエレベーターから始まらない ダウンカウントがゼロに達する時点で、エンジンはすでに長い間燃え続けています。唯一の質問は、あなたが気づいたかどうか、そして誰かがあなたに理由を伝える前にあなたのシステムを構築したかどうかです。