DuskはAEGISを通じて39件の修正を出荷しました。その是正の裏にある調査結果のうち、7件が重大（critical）と評価されています。これは、個別のセキュリティ問題が大量にあるようにも聞こえます。しかし、その7件の重大な指摘は、実はたった4つの根本原因に集約されます。つまり、見出しの件数は最初に見えるほど単純ではありません。

39件の修正は、Duskの是正作業の規模を教えてくれます。ただし、それらの修正が実際に対処していた独立した障害モードがいくつかまでは示してくれません。現時点で私が分からないのは、Duskの是正プロセスが、複数の指摘に共通する原因を一貫して取り除いているのか、それとも、たまたま表面化した個別のエクスプロイト経路を閉じるだけなのか、という点です。

Dusk自身のAEGISプロセスには、追跡に役立つ有用な仕組みがあります。重大な是正は、エクスプロイトのクローズだけでなく、根本原因のクローズや回帰（regression）カバレッジもあわせて追跡されます。だからこそ、将来の再発の有用性は、生の修正件数よりも私にとって価値の高い指標になります。パッチを出荷することは、既知の問題が対処されたことを証明します。さらに強い根拠は、同じ根本的な失敗クラスが、後続のレビューやスタックの近接部分において再び現れなくなることを見ることです。

Duskがネイティブ発行ワークフローのためのインフラを構築していくにつれ、規制対象となるセキュリティのライフサイクルのより多くが、根底にあるネットワークに直接依存するようになります。その場合、根本原因の是正は、生の出荷修正件数よりも、より意味のあるセキュリティシグナルになります。

どれだけ多くの修正件数があるかを、そこにいくつの独立した障害モードが含まれているか不明なまま見比べるよりも、「いくつかの共有された根本原因が完全に取り除かれた」という証拠の方から、私はより多くを学べるはずです。

論点は、Duskのセキュリティプロセスが、開いている指摘の数だけでなく、根底にある失敗クラスそのものを縮小しているかどうかです。私は、同じ根本原因が後続の監査でも再び現れるのか、回帰カバレッジがどのように進化しているのか、そして同種の低レベルな前提がスタックの別の場所で再浮上していないかを見ています。

#dusk $DUSK @Dusk ✨