要約

  • CVE ID とそれに対応する Record は、複数の当事者が同じ脆弱性を指すための共通参照である。それだけでパッチ、配布パッケージ、資産への導入、修正完了は示さない。
  • ID の予約、Record の公開、供給者の advisory、下流の package、KEV の優先順位シグナル、運用者の remediation は、作者も証拠も異なる記録である。
  • Record から remediation までの短い receipt を残せば、公開の調整基盤を根拠のない安全宣言へ変えずに受け渡しを追える。

共通の名前は、共通の運用状態を作らない

CVE Program は、その役割を過大に説明していない。CVE ID と対応する CVE Record により、複数の人やツールが適切な脆弱性について確信をもって参照できる。CVE Numbering Authority、すなわち CNA は、自らの scope の中で ID を割り当て Record を公開する権限を持つ。 CNA Operational Rules この共通参照がなければ、発見報告、供給者の advisory、scanner の所見、package の changelog、内部 ticket が同じ欠陥を示していても、互いに別の出来事として扱われ得る。

しかし、同じ対象を指せることは、同じ運用上の結論を共有することではない。ID を割り当てる主体は供給者の修正を選ばない。advisory を出す主体はすべての distribution 向けの package を作らない。package を作る distribution は、どの asset がそれを受け取ったかを知るわけではない。asset を変更する operator も、それだけで依存サービスを含む安全性を証明できない。それぞれの仕事は重要でも、前の記録を次の記録の証明として無断で使うことはできない。

公式の process は最初の境界を明示している。発見、報告、CVE ID の reservation、最低限の情報を備えた後の Record publication を区別し、RESERVED、PUBLISHED、REJECTED も別の状態としている。 CVE Program process これは ID と公開 Record の状態であって、影響を受ける可能性のあるすべての machine の remediation 段階ではない。

FAQ はその差をさらに具体化する。Reserved-but-Public の ID は、詳細 Record が RESERVED のままでも公的資料で使用され得る。DISPUTED は、Program がどちらの主張が正しいかを裁定せずに、争いがあることを知らせる表示である。REJECTED Record は、ID と Record を用いるべきでないことが分かるよう残される。 CVE Program FAQ これらの状態から、特定の product に適用可能な patch があるか、local configuration が対象か、組織が変更を終えたかは導けない。

公開 Record の証拠は公開 Record の範囲に留まる

PUBLISHED の CVE Record は単独の番号より情報量が多い。説明と references を、人と machine が使える公的な形で提供する。ただし、公開という行為の意味は限られている。CNA rules は、対応する Record の publication より前または同時に public reference が Internet 上になければならず、CVE Record 自体が脆弱性の最初の public disclosure であってはならないとしている。 CNA Operational Rules

この仕組みは、次に読むべき advisory や説明を示す助けになる。だが、どの immutable な source revision が修正を含むか、distribution が backport したか、どの package が変更を運んだか、package が asset に該当するか、compensating control が exposure をどう変えるかを決めるものではない。これらは別々の system と責任者に属する観測である。

CVE Services の説明も、その境界を保っている。CNA が ID を reserve し Record を publish するための self-service の手段である。 CVE Services 文書化された目的は CVE content の管理だ。その目的から supplier の delivery、asset inventory の正確性、change approval、installation、remediation verification を推論するのは、参照層の機能を実行層の権限へ拡大することになる。

「CVE published」と「remediated」を一つの dashboard 行に置くと、二つの独立した主張が同じ色になる。前者は public Record で検証できる。後者には、asset、version または configuration、承認された action、実施時点、post-change の observation、責任者についての証拠が必要だ。一つの label が見やすさを与える代わりに、後者の証拠を消してはいけない。

優先順位の信号は、完了の認証ではない

CISA は Known Exploited Vulnerabilities Catalog を、実際に悪用されたことが知られる vulnerabilities の authoritative source と説明し、組織が vulnerability management の prioritisation framework への input として使うことを求めている。 CISA KEV Catalog これは調査と対応の順番を決めるための重いシグナルである。各組織の exposure や remediation 完了を記す ledger ではない。

制度上の scope も消してはならない。CISA の Binding Operational Directive 22-01 は、covered Federal Civilian Executive Branch agencies に remediation obligation と due date の枠組みを定める。 CISA BOD 22-01 Catalog が公開されているからといって、すべての company、project、operator に同じ義務が生まれるわけではない。「KEV にある」を「誰もが期限超過」と書けば、source が明示する scope と、個別 asset の状態に必要な証拠の双方を失う。

逆向きの短絡も誤りである。supplier advisory が存在しても、local asset がその path で更新できるとは分からない。asset が影響を受けるか、distribution が component を運ぶか、change が承認されているか、maintenance window が可能か、compensating control が何を覆うか、結果をどう validate するかを別に判断する必要がある。これは public information を否定することではない。その情報が operator に代わって運用決定を行えないことを認めるだけだ。

authority に沿って receipt をつなぐ

CVE を deployment service にしたり、CISA に全組織の change control を求めたりする必要はない。必要なのは、CVE ID と Record revision、CNA と state、supplier advisory と immutable fix reference、downstream distribution と package boundary、asset-specific applicability evidence、approved action、deployment または compensating control、validation observation、residual risk owner を結ぶ小さな receipt である。

各欄は別の問いに答える。Record revision は何を議論しているかを定める。supplier material は upstream の主張を定める。package boundary は実際の deliverable を定める。asset evidence は local に問題があるかを示す。change と validation は operator が何を行い何を観測したかを示す。residual risk owner は、未解決の exception が緑色の aggregate status の後ろへ消えないようにする。

この receipt は Daniel Kade の編集上の提案であり、新たな CVE rule ではない。Lu Heng の区別とも合う。参加と情報は証拠になり得るが、その結果を負う側への mandate を自動的に生まない。 The Multi-Stakeholder Mirage 主張が running system に近づくほど、決定的な根拠は upstream の label ではなく、その system と責任を負う operator から来るべきである。 Running-Code Primacy

この Record からは言えないこと

これらの source は、特定の CVE が exploit 可能、修正済み、package 化済み、適用可能、installed、mitigated、closed であることを証明しない。supplier、product、version、asset、組織、exploit、incident、期限、customer も選定していない。CVE state、public reference、supplier advisory、KEV entry は、ここでは特定組織の exposure、noncompliance、remediation outcome の証明ではない。提案する receipt は編集上の指針であり、CVE Program、CISA、supplier、regulator の要件ではない。

出典