Dusk hat 39 Fixes über AEGIS ausgeliefert. Unter den Erkenntnissen, die zu dieser Behebung führten, wurden 7 als kritisch eingestuft. Das klingt nach einer großen Zahl separater Sicherheitsprobleme. Doch diese 7 kritischen Befunde ließen sich auf nur 4 Hauptursachen zurückführen – dadurch ist die Schlagzeilen-Zählung weniger eindeutig, als sie zunächst wirkt.

Neununddreißig Fixes zeigen mir das Ausmaß der Sanierungsarbeit von Dusk. Sie sagen mir jedoch nicht, wie viele unabhängige Ausfallmechanismen diese Fixes tatsächlich adressierten. Was mir noch fehlt, ist die Frage, ob der Sanierungsprozess von Dusk die gemeinsamen Ursachen hinter mehreren Befunden konsistent entfernt – oder ob er lediglich die einzelnen Exploit-Pfade schließt, die gerade zufällig aufgetaucht sind.

Der eigene AEGIS-Prozess von Dusk bietet dafür einen nützlichen Mechanismus zur Beobachtung. Kritische Behebungen werden nicht nur anhand der Schließung von Exploits verfolgt, sondern auch anhand der Behebung der Hauptursachen und der Regressionsabdeckung. Das macht zukünftige Wiederholungen für mich aussagekräftiger als die reine Fix-Anzahl. Ein Patch beweist, dass ein bekanntes Problem adressiert wurde. Stärker wäre die Evidenz, wenn dieselbe zugrunde liegende Fehlerklasse in späteren Reviews oder in angrenzenden Teilen des Stacks nicht erneut auftaucht.

Während Dusk Infrastruktur für native Ausgabe-Workflows aufbaut, bei denen mehr vom Lebenszyklus einer regulierten Sicherheit direkt vom zugrunde liegenden Netzwerk abhängen kann, wird die Behebung der Hauptursache zu einem aussagekräftigeren Sicherheitsindikator als die rohe Zahl der ausgelieferten Fixes.

Ich würde mehr Erkenntnisse aus dem Beleg gewinnen, dass ein paar gemeinsame Hauptursachen vollständig entfernt wurden, als aus einer größeren Fix-Anzahl, ohne zu wissen, wie viele unabhängige Ausfallmechanismen dahinterstanden.

Die Frage ist, ob der Sicherheitsprozess von Dusk die zugrunde liegenden Fehlerklassen verkleinert – nicht nur die Anzahl offener Befunde. Ich beobachte, ob dieselben Hauptursachen in späteren Audits wieder auftauchen, wie sich die Regressionsabdeckung entwickelt und ob ähnliche Annahmen auf niedriger Ebene andernorts im Stack erneut zutage treten.

#dusk $DUSK @Dusk