重要CVEsがレビューで崩壊した後、SQLiteがHacker Newsで話題に

SQLiteは、後に基本的な検証すら通らないことが判明した技術的主張にもかかわらず、6件の脆弱性レコードが深刻な評価を受け、そのうち3件がクリティカル評価となったことでHacker Newsに登場した。

JFrogの研究者によると、これらのアドバイザリは存在しない関数、不可能な行番号、捏造された修正、そして主張された障害を引き起こさない概念実証クエリを参照していた。問題の一括登録には、根拠となる主張が崩れ去る前に9.8のクリティカルスコアを付与されていたCVE-2026-51302も含まれていた。

この事案は、疑わしい1件の投稿にとどまるものではない。自動化された脆弱性公開と、証拠に基づくセキュリティレビューの対立を浮き彫りにしている。一見もっともらしいレコードは、誰かが申し立てられた欠陥を再現する前に、データベース、スキャナー、チケットキューへ入り込む可能性がある。

この対立が重要なのは、セキュリティチームがCVE、すなわちCommon Vulnerabilities and Exposures識別子を共有インフラとして扱うためだ。CVE番号は脆弱性の存在を証明するものではない。しかし、ソフトウェア資産管理やコンプライアンスのシステムは、この番号をしばしば運用上の事実として扱う。

したがって、このケースは通常のセキュリティに関する物語を逆転させる。見かけ上の危険は隠れたSQLiteのメモリ欠陥ではなかった。防御側に、そもそも存在しなかったコードを探させた、公式らしく見えるアラートだった。

SQLiteのCVEレコードが実際に主張していたこと

問題のレコードは深刻なメモリ安全性の障害を記述していたが、その技術的根拠はソース検査やテストに耐えられなかった。

この一括登録は、SQLiteの脆弱性とされる6件を対象としていた。3件はクリティカルなCVSS評価を受け、残りの3件は高評価だった。CVSS、すなわちCommon Vulnerability Scoring Systemは、攻撃の容易さや想定される影響などの要素を通じて技術的な深刻度を見積もる。

CVE-2026-51302には9.8のクリティカルスコアが付与されていた。そのアドバイザリは、SQLite 3.41.0のsqlite3ReleaseTempReg()とexprComputeOperands()に関係するuse-after-freeの状態を申し立てていた。

use-after-freeは、ソフトウェアが解放後のメモリへアクセスする場合に発生する。この種のバグはクラッシュ、データ漏えい、ときにはコード実行を引き起こし得る。そのため、広く組み込まれているデータベースライブラリの隣にこのラベルが表示されると、特に警戒を招く。

しかし、JFrogは直接的な矛盾を発見した。名指しされたexprComputeOperands()関数はSQLite 3.41.0には存在しなかった。研究者によると、この関数がコードベースに加わったのは2025年中であり、アドバイザリが影響対象として挙げたバージョンよりかなり後だった。

もう一方の名指しされた関数も、主張されたメモリ解放を実行していなかった。同関数は一時レジスタのインデックスを後で再利用するために回収していた。この動作は、報告されたuse-after-freeの仕組みを裏付けるものではなかった。

JFrogは隔離コンテナ内で公式SQLiteリリースをコンパイルし、AddressSanitizerを用いて提出されたクエリを実行した。AddressSanitizerは、実行中の無効なメモリアクセスを検出するコンパイラツールである。CVE-2026-51302のクエリは、主張されたクラッシュを発生させずに完了した。

技術調査では、残る5件のSQLiteレコードについても同様の問題が見つかった。

CVE-2026-51303は、ExprListDelete()が親構造内に危険な逆参照を残すと主張していた。また、SQLite 3.51.3には関連する修正が含まれるともしていた。JFrogは、これを裏付けるポインタ構造も、バージョン3.51.2と3.51.3の間におけるsrc/expr.cの対応する変更も見つけられなかった。

その概念実証は、申し立てられた脆弱なロジックに到達していなかった。提出されたクエリは無効なSQLであり、パーサーで停止した。

CVE-2026-51300は、別のuse-after-free問題の証拠としてexpr.c内の2行を引用していた。引用された一方の行はコメントで、もう一方は説明されたポインタと無関係なメモリ割り当て呼び出しだった。

そのクエリは正常に実行され、期待どおりの出力を返した。研究者らはテスト用の計測下で、メモリエラーもリークも報告していない。

JSON関連の2件のレコードにも、同様に明白な不整合があった。CVE-2026-51297はSQLite 3.41.0のjsonBlobEdit()を参照していたが、この関数はSQLiteのJSONB対応で後に追加されたものだった。提出された入力は、不正なJSONエラーで停止した。

CVE-2026-51296は、わずか2,706行しかないバージョンのjson.cについて、3555行目と3575行目を引用していた。JFrogは実際のjsonRemoveFunc実装をはるか前方に見つけ、対応するメモリ管理上の欠陥は確認されなかったと報告した。

最後に、CVE-2026-51304はsqlite3ExprListDelete()を引数1つで無効に呼び出す記述をしていた。実際の関数にはデータベースコンテキストの引数が必要である。周辺のSQLiteコードも、削除直後に該当するポインタをクリアしていた。

こうした観察のいずれも、それ単独ではアドバイザリがどのように作成されたかを確定するものではない。JFrogはAIコンテンツ検出器を使用し、この資料をLLM生成である可能性が高いと説明したが、自動検出器は決定的な帰属ツールではない。

より強い証拠は、アドバイザリそのものの中にある。存在しない関数、不可能な場所、架空のパッチ、効果のないテストは、文章を書いたのが誰であれ何であれ、検証可能な欠陥である。

8月4日時点で、CVE-2026-51302のNVDレコードは拒否済みの状態を示していた。その拒否通知では、さらなる調査の結果、報告された状態はセキュリティ上の問題ではないことが判明したと述べられていた。

この訂正は重要である。しかし、このレコードはすでにクリティカルというラベル、下流での可視性、そしてHacker Newsで議論されるに十分な注目を獲得していた。

なぜHacker Newsは検証の失敗に注目したのか

Hacker Newsで注目を集めたのは、不穏な逆転現象にあった。構造化されたセキュリティメタデータが、それが説明するはずのコードよりも権威的に見えたのだ。

CVE識別子は、報告された脆弱性に対して防御側が共通の名称を使えるように設計されている。これにより、ベンダー、研究者、スキャナー、顧客、政府システムは、曖昧さなく同じ問題について議論できる。

この識別子は、悪用可能性を認定することを目的としていない。新たに公開されたCVEには、より深い分析、訂正、またはベンダーレビューを待つ主張が含まれる可能性がある。この区別は脆弱性の専門家にはよく知られているが、自動化されたワークフローでは見えにくい。

SQLiteの事案は、機械が識別子を判断結果として取り込んだときに何が起きるかを示している。スキャナーは、引用された関数が存在するかどうかを確認せずに、製品バージョンに一致させ、深刻度スコアを継承し、修正チケットを作成できる。

クリティカルスコアは、さらに事態を重大にする。多くの組織は、クリティカルな検出結果の即時調査を求めるサービスレベル目標を使用している。報告された露出が解消されるまで、ソフトウェアリリースを止めたり、正式な例外処理を必要としたりする組織もある。

SQLiteのような組み込みコンポーネントでは、その影響範囲は広くなり得る。チームは、デスクトップアプリケーション、モバイルソフトウェア、ブラウザ、開発ツール、またはOSパッケージの中にSQLiteを見つけるかもしれない。

ライブラリを見つけても、露出があることは証明されない。それは分析の始まりにすぎない。防御側には、影響を受けるバージョン、到達可能なコードパス、現実的な攻撃者入力、そして実証されたセキュリティ上の結果が依然として必要である。

捏造された仕組みは、この評価を異例に高コストなものにする。エンジニアは、統合経路の調査、パッケージバージョンの比較、ソースツリーの検索、ベンダーへの連絡、緊急アップグレードの準備を行った末に、申し立てられた関数が最初から存在しなかったと発見する可能性がある。

元のリポジトリも、件数が多いように見せていた。その公開履歴には、6件のSQLiteレコードを含め、数十件のCVE名付きエントリが並んでいた。証拠の質が低くても、数量は情報源を活発に見せることがある。

JFrogは、同じアカウントに関連する55件のアドバイザリをレビューしたと述べた。同社は54件を捏造と分類し、1件は未検証のCVEメタデータに囲まれた実在のバグだと説明した。

これは、すべてのデータベース内のすべてのレコードに関する普遍的な判断ではなく、JFrogが報告した監査結果である。それでも、詳細なSQLiteの調査結果は、この一括登録を疑問視する再現可能な根拠を示している。

この事案は、すでにレビュー圧力を受けているエコシステムでも発生した。2024年、NISTはNational Vulnerability Databaseの分析バックログが増大していることを公に認めた。

同機関のプログラム発表では、バックログの原因としてソフトウェアと脆弱性の件数増加に加え、省庁間支援の変更を挙げていた。NISTは最も重要な報告を優先し、支援を追加しているとした。

バックログがあるからといって、NVDが精査なしにすべての主張を受け入れているわけではない。また、このケースは、強化されたすべてのレコードが信頼できないことを示すものでもない。ただし、処理能力と投稿量が、誤解を招くメタデータの訂正速度を左右することは示している。

CISAのAuthorized Data Publisherモデルは、参加組織の間でエンリッチメント作業を分担する。このアプローチは処理能力を拡大できるが、提出情報とそこから導出された情報の複数層から組み立てられるレコードも生み出す。

重要なのは、識別、説明、検証を区別することだ。CVEは主張を識別する。説明はその主張を要約する。再現とソースレビューが、技術的な仕組みが成立するかを判断する。

これらのステップは脆弱性ページ1枚に一緒に表示されることが多く、読者はそれらを単一の判断として扱いやすい。SQLiteのケースは、セキュリティチームがそれらを分けなければならない理由を示している。

Hacker Newsの読者は、制度上の帰結を認識した。もっともらしい技術文書が、機能する証拠よりも遠くまで広がるなら、脆弱性パイプラインは、他のAI生成コンテンツにも影響しているのと同じスケーリング問題に対して脆弱になる。

1件の報告が生むレビュー負担は限定的である。数十件の自動生成レポートはキューを作る。数千件になれば、希少な専門家の注意を本物の脆弱性からそらすことができる。

核心にある逆転は、自動化と検証の対立である

セキュリティ自動化は、人間のレビュアーが疑わしいレコードを反証するより速く、それらを増幅した。

自動化が価値を持つのは、現代の組織がすべてのコンポーネントとアドバイザリを手作業で調べられないためだ。ソフトウェア構成分析ツールは、インストール済みパッケージを脆弱性レコードと照合し、深刻度と到達可能性に基づいて検出結果の優先順位を付ける。

このモデルは、入ってくるレコードに最初の対応を正当化できるだけの真実が含まれていることを前提にしている。不確実性は許容するが、それでも識別子、バージョン、製品マッピング、技術説明が実在のソフトウェアに根ざしていることに依存している。

問題のSQLiteアドバイザリは、意図的か否かにかかわらず、その前提を突いていた。構造的には通常の脆弱性報告に似ていた。関数、バージョン、弱点クラス、影響、入力例が記載されていた。

詳細は具体性の錯覚を生んだ。しかし、具体性は正確性ではない。関数名はコードベース固有のものらしく聞こえても、引用されたリリースには存在しないことがある。

LLMは、このパターンを生み出すのに特に適している。ダングリングポインタ、細工されたSQL、ヒープ破壊、リモート実行といった一般的な概念を組み合わせることで、一貫したセキュリティ文書を生成できる。

モデルは、説得力のあるエクスプロイトの物語を書くために、動作するエクスプロイトを必要としない。出力が実際のバージョン管理されたソースツリーに基づいていない限り、実在する技術用語を架空の因果関係で結び付ける可能性がある。

6件のSQLiteレコードには、よくあるグラウンディングの失敗がいくつか見られた。

第一に、異なる時期のコードが混在していた。2025年中に導入された関数が、より古いコード状態のリリースであるSQLite 3.41.0に対する主張に登場した。

第二に、通常の実装動作を解放処理として扱っていた。レジスタインデックスの再利用は、どちらもリソース管理に関係していても、ヒープメモリの解放と同じではない。

第三に、裏付けの変更を捏造していた。3.51.3で修正されたとするパッチは、該当するソースファイルの変更に対応していなかった。

第四に、主張された脆弱な経路に到達する前に失敗する入力を提示していた。パーサーエラーでは、その後の実行ロジックにおけるメモリ障害を実証できない。

第五に、ソースファイル外の場所を引用していた。これはソフトウェアセキュリティにおいて、存在しないページを引用することに等しい。

いずれの不備も、基本的な確認で検出できた。課題は、下流のシステムがその記録を拡散する前に、こうした確認を行うことにある。

レビュー担当者には、影響を受ける正確なリリース、ビルド構成、概念実証用の入力、検出ツールが必要となる。そのうえで、実行が主張されたコードに到達し、主張されたメモリ挙動を示すことを確認しなければならない。

この作業は、主張を生成するよりも時間がかかる。この不均衡こそが中核的な脅威である。

この事例はスパム経済に似ている。もっともらしい投稿を1件作るコストは、それが誤りだと立証するコストより低い。自動化はこの格差を広げる。投稿者は言語生成を大規模化できる一方、メンテナーやアナリストは依然としてコードを検査する必要があるためだ。

下流のシステムが深刻度に基づいて緊急度を割り当てると、この非対称性はさらに悪化する。9.8というラベルは、確認済みのエクスプロイト、到達可能なコードパス、攻撃者による活発な関心を持つ可能性のある、より低スコアの問題よりも報告を優先させる。

こうした状況では、偽陽性は単に煩わしいだけではない。優先順位付けを歪める。

チームはAIを追加することで対応できるかもしれないが、それには二次的なリスクがある。自動修復エージェントが架空の関数を探し、無関係なアップグレードを推奨したり、関係のないコード向けのパッチを生成したりする可能性がある。

チケットを満たすことだけを目的に、依存関係を変更する可能性もある。不必要なコード変更にはすべて回帰リスクが伴い、とりわけ緊急のタイムラインで適用される場合はその傾向が強い。

これは、AIがセキュリティ研究に不向きだという意味ではない。モデルはテストケースの生成、未知のコードの説明、重複報告のクラスタリング、レビュー担当者のソースナビゲーション支援に役立てられる。

境界線となるのは証拠である。AIは仮説を提案できるが、パイプラインは生成された文章を確認済みの結果として扱うべきではない。信頼できる報告には、入力から影響を受けるコード、そして観測可能な影響へと至る再現可能な経路が必要だ。

メンテナーも不可欠な文脈を提供する。SQLiteの公式脆弱性ガイダンスでは、サードパーティがSQLiteに関するCVEを作成しており、多くの場合、コア開発者の関与なしに行われていると述べられている。

このプロジェクトは、報告されたSQLiteの問題の多くで、攻撃者が任意のSQLを実行するか、悪意のあるデータベースファイルを提出する必要があると警告している。これらの前提条件は、多くの通常のデプロイメントでは成り立たない。

SQLiteはまた、バグとセキュリティ脆弱性を区別している。攻撃者がすでに任意のSQLを制御している場合にのみ到達可能なクラッシュは、元のインジェクション脆弱性を超える能力をほとんど追加しない可能性がある。

この立場には議論の余地がある。特に、信頼できないSQLやデータベースファイルが製品設計の一部である場合はそうだ。しかし、数値スコアが脅威モデルを置き換えられない理由を示している。

このインシデントでは、失敗はさらに手前で起きていた。実在するバグから導かれた結果が誇張されていたのではない。JFrogのテストは、説明された6件のバグが報告どおりには存在しなかったことを示した。

スコアではなく、セキュリティチームが信頼すべきもの

新たに公開された重大なCVEは、自動的な信用や自動的な却下ではなく、体系的な検証を促すべきである。

誤った対応は、CVEシステム全体を信用しなくなることだ。実際の脆弱性はいまも同じ経路で報告されており、対応の遅れは組織に深刻な被害をもたらす可能性がある。

よりよい対応は、初期トリアージと確認済みの修復を分けることだ。重大度スコアは即時レビューを正当化し得るが、レビューの結論をあらかじめ決めるべきではない。

まずベンダーまたはメンテナーによる裏付けを確認する。影響を受けるプロジェクトの公式セキュリティページ、リリースノート、ソース履歴、課題トラッカー、パッチコミットを確認する。

SQLiteは現在、争点となった6つの識別子を再現不能かつ明らかなAIハルシネーションとして列挙している。これはプロジェクトによる直接的な評価を反映しているため、単なる沈黙よりも強い証拠である。

ただし、沈黙には複数の説明がある。メンテナーが非公開で調査している場合、協調リリースを準備している場合、あるいは単にその記録を認識していない場合がある。したがって、ベンダーページに掲載がないことは結論ではなく、疑問を提起する材料とすべきだ。

次に、記録内の参照先を確認する。信頼できるメモリ安全性の報告は、バージョン、コードパス、再現手順、クラッシュトレース、サニタイザー出力、修正、またはメンテナーによる議論を指しているはずだ。

正当な開示であっても、すべての証拠を直ちに公開できるとは限らない。エンバーゴやエクスプロイトのリスクにより、詳細が制限される場合もある。しかし、パッチ履歴がなく、矛盾するメタデータを含む匿名の記録は、追加の精査に値する。

バージョンの正確性も、価値の高い確認項目である。名前が挙げられたすべての関数と構造体について、正確な対象リリースを検索する。引用された行番号が関連するロジックに対応していることを確認する。

このテストにより、SQLiteに関する複数の主張は速やかに露呈した。また、脆弱性が実在するかを判断せずに基本的なソース確認を自動化できるため、完全なエクスプロイト分析よりも拡張性が高い。

その後、管理された環境で概念実証を再現する。プロジェクトの公式ソース、文書化されたビルド設定、適切なランタイム検出器を使用する。

クラッシュだけでは、アドバイザリが主張する完全な影響を証明できない。レビュー担当者は、クラッシュの原因、入力がサポートされたインターフェースに到達するか、現実的な攻撃者がその入力を制御できるかを明らかにしなければならない。

同様に、再現に失敗したからといって、必ずしも脆弱性が否定されるわけではない。コンパイラ、アーキテクチャ、機能フラグ、アロケータの挙動、環境状態の違いが結果に影響することがある。

SQLiteの事例では、クラッシュしないテストが1回あった以上の強い矛盾が示された。研究者は、再現失敗に加え、存在しない関数、誤ったシグネチャ、不可能な行参照、存在しない修正を組み合わせた。

この組み合わせは、独立した不整合が同じ結論に収束するため、確信を持った却下を裏付ける。

チームは、自社製品内での到達可能性も評価すべきだ。SQLiteの最近のCVE一覧は、コアライブラリの欠陥と、オプション拡張、コマンドラインツール、ラッパー、別アプリケーションを繰り返し区別している。

製品にSQLiteという名称が含まれていても、関連するコンポーネントを公開していない場合がある。パッケージの識別子だけに一致するスキャナーは、根本のCVEが有効であってもリスクを過大評価する可能性がある。

セキュリティプログラムは、これらの確認を証拠状態として正式化できる。

新しい記録は、まず「報告済み」として開始できる。ベンダーが認めた時点で「裏付け済み」、テストで挙動が確認された時点で「再現済み」、組織のデプロイメントがその経路を公開している時点で「適用対象」に移行できる。

修復の緊急度は、重大度、証拠、到達可能性、悪用状況という4つすべての次元を反映すべきだ。重大度だけが示すのは、記録の前提条件のもとでの仮想的な技術的結果である。

この方針は、監査人にもより明確な追跡可能性を与える。説明なくスキャナーのアラートを抑制する代わりに、アナリストは確認したソースバージョン、テスト内容、経路が到達不能である理由を記録できる。

その証拠を維持することは、セキュリティ上の問題であると同時に、ナレッジマネジメントの問題でもある。エンジニアリングチームには、アドバイザリ、依存関係インベントリ、テスト結果、例外、アップグレード判断の間を検索可能に結び付けるリンクが必要だ。

構造化された技術ナレッジベースは、繰り返されるアラートのたびに新たな調査へ変えることなく、チームをまたいでこうした判断を保存できる。

組織は、報告済み段階での自動パッチ適用には慎重であるべきだ。エージェントはソース参照を収集し、テスト環境を準備できるが、本番環境の変更には影響を受けるコードが存在するという証拠が必要となる。

同じルールは生成された要約にも当てはまる。システムが複数のソースを要約する場合、その状態と見解の相違を保持すべきだ。読みやすさのためだけに、主張を確認済みの記述へ変換してはならない。

これらを行っても、虚偽の記録がなくなるわけではない。広範な修復作業を引き起こす前に弱い証拠を検出することで、そのコストを下げられる。

Hacker Newsの記事が次に変えるもの

次の試金石は、スキャナー、エージェント、コンプライアンスシステムが事実として扱う前に、脆弱性インフラが裏付けのない記録を却下できるかどうかだ。

このインシデントが持続的な対応につながるかどうかは、3つの兆候で判断できる。

1つ目は、関連記録の扱いである。CVE-2026-51302は現在却下されており、SQLiteは争点となった6つの識別子をすべてバグではないと分類している。NVD、アドバイザリフィード、スキャナーデータベース全体で一貫した訂正が行われれば、却下メタデータが効果的に伝播していることを示す。

伝播が不完全であれば、元の主張が崩壊した後も、組織は古いアラートへの対応を続けることになる。セキュリティベンダーは訂正を保持し、却下された記録を有効な重大なエクスポージャーとして表示し続けるべきではない。

2つ目の兆候は、提出および情報拡充の段階における証拠の取り扱い強化である。有用な変更には、機械で確認可能な影響対象バージョン、ソースコミット、再現可能な入力、未検証の主張を示すより明確なラベルなどが含まれる。

すべての提出に公開証明を求めれば、それ自体が問題を生む。一部の脆弱性には協調開示が必要であり、エクスプロイトを早期に公開するとリスクが高まる可能性がある。

実務的な目標は、すべてを公に再現することではない。検証責任を負う組織が利用できる説明可能な証拠と、下流で可視化される信頼度ラベルを組み合わせることだ。

3つ目の兆候は、セキュリティ自動化が矛盾するソースをどのように扱うかである。成熟したシステムは、CVEが存在しない関数を挙げている場合、公式プロジェクトページと矛盾する場合、取り込み後に却下された場合を検知すべきだ。

信頼度を下げ、以前の判断を再検討し、影響を受けるチームに通知すべきである。古くなったスナップショットから緊急作業を生成し続けてはならない。

元の投稿におけるAIの利用については、依然として不確実性がある。テキスト分類器では作者を確実に特定できず、どのモデルやワークフローがアドバイザリを生み出したのかを証明する公開技術証拠もない。

この不確実性は中心的な教訓を弱めない。人間が書いた脆弱性報告も、誤っていたり、捏造されていたり、誇張されていたりする可能性がある。低コストな生成と自動取り込みが組み合わさると、規模に関するリスクが高まる。

Hacker Newsでの議論によってこのSQLiteの事例が可視化されたのは、矛盾が異例なほど明確だったためだ。重大な記録が、研究者が存在しないと示せるコードを指していた。

今後の事例はより難しくなる。生成されたアドバイザリが実在する関数を参照し、実際のクラッシュを引き起こしながら、それでも悪用可能性や影響を受けるバージョンを捏造するかもしれない。真実と捏造が混在する場合には、より深いレビューが求められる。

したがって、セキュリティリーダーは自らのパイプラインについて直接的な問いを投げかけるべきだ。重大な記録が到着してから、人々が本番システムの変更を始めるまでの間に、何が起きるのか。

答えが「スキャナーがチケットを起票するだけ」であれば、その組織は懐疑を自動化せずに受け付けだけを自動化している。

よりよいワークフローでは、ベンダーの声明、ソースの証拠、バージョン対応、到達可能性データ、再現結果を集める。そうすれば人間は、機械的な収集ではなく、未解決の判断に注意を向けられる。

開発者は、逆方向の過剰反応にも抵抗すべきだ。虚偽のSQLite記録が発見されたからといって、新たな脆弱性報告を安全に無視できるようになるわけではない。

識別子は手掛かりとして扱う。重大度は初期推定として扱う。コード、再現手順、メンテナーの回答、そして自社のデプロイメント状況を証拠として扱う。

このアプローチは、共有された脆弱性命名の価値を維持しつつ、公式らしく見えるすべてのエントリーに自動的な権威を与えない。

SQLiteの事例がHacker Newsで注目を集めたのは、より広範な問題を一つの鮮やかな逆転劇として捉えていたためだ。このデータベースに、発表された重大な欠陥が存在することは示されなかった。むしろ、脆弱性パイプラインが、誰もコードを検証する前に説得力のある説明を受け入れてしまうことが明らかになった。

セキュリティチームには今、実践的な検証方法がある。却下されたCVEがスキャナー、チケット、AIエージェントをどのように流れるかを確認し、修正対応の前にエビデンスゲートを設けるべきだ。システムが、公表された申し立てと再現済みの脆弱性を区別できないなら、この事案は、より見えにくい標的を相手に繰り返されることになる。