Dusk entregó 39 correcciones a través de AEGIS. Entre los hallazgos detrás de esa remediación, 7 se calificaron como críticos. Eso suena a una gran cantidad de problemas de seguridad separados. Pero esos 7 hallazgos críticos se redujeron a solo 4 causas raíz, lo que hace que el recuento del titular sea menos directo de lo que parece.
Treinta y nueve correcciones me dicen la magnitud del trabajo de remediación de Dusk. No me dicen cuántos modos de fallo independientes estaban abordando realmente esas correcciones. Lo que aún no sé es si el proceso de remediación de Dusk elimina de manera consistente las causas compartidas detrás de múltiples hallazgos, en lugar de solo cerrar las rutas de explotación individuales que casualmente salieron a la luz.
El propio proceso de AEGIS de Dusk ofrece un mecanismo útil para observar. La remediación crítica se rastrea no solo mediante el cierre de la explotación, sino también mediante el cierre de la causa raíz y la cobertura de regresión. Eso hace que la recurrencia futura sea más útil para mí que el recuento bruto de correcciones. Publicar un parche demuestra que se abordó un problema conocido. Una evidencia más sólida sería ver que la misma clase subyacente de fallo deje de reaparecer en revisiones posteriores o en partes adyacentes del stack.
A medida que Dusk construye infraestructura para flujos de emisión nativos, donde más del ciclo de vida de la seguridad regulada puede depender directamente de la red subyacente, la remediación de causas raíz se convierte en una señal de seguridad más significativa que el número bruto de correcciones enviadas.
Aprendería más de la evidencia de que se eliminaron por completo algunas causas raíz compartidas que de un recuento de correcciones más grande sin saber cuántos modos de fallo independientes estaban detrás.
La pregunta es si el proceso de seguridad de Dusk está reduciendo las clases subyacentes de fallos, y no solo el número de hallazgos abiertos. Estoy observando si las mismas causas raíz vuelven a aparecer en auditorías posteriores, cómo evoluciona la cobertura de regresión y si supuestos de bajo nivel similares resurgen en otras partes del stack.
#dusk $DUSK @Dusk ✨
Treinta y nueve correcciones me dicen la magnitud del trabajo de remediación de Dusk. No me dicen cuántos modos de fallo independientes estaban abordando realmente esas correcciones. Lo que aún no sé es si el proceso de remediación de Dusk elimina de manera consistente las causas compartidas detrás de múltiples hallazgos, en lugar de solo cerrar las rutas de explotación individuales que casualmente salieron a la luz.
El propio proceso de AEGIS de Dusk ofrece un mecanismo útil para observar. La remediación crítica se rastrea no solo mediante el cierre de la explotación, sino también mediante el cierre de la causa raíz y la cobertura de regresión. Eso hace que la recurrencia futura sea más útil para mí que el recuento bruto de correcciones. Publicar un parche demuestra que se abordó un problema conocido. Una evidencia más sólida sería ver que la misma clase subyacente de fallo deje de reaparecer en revisiones posteriores o en partes adyacentes del stack.
A medida que Dusk construye infraestructura para flujos de emisión nativos, donde más del ciclo de vida de la seguridad regulada puede depender directamente de la red subyacente, la remediación de causas raíz se convierte en una señal de seguridad más significativa que el número bruto de correcciones enviadas.
Aprendería más de la evidencia de que se eliminaron por completo algunas causas raíz compartidas que de un recuento de correcciones más grande sin saber cuántos modos de fallo independientes estaban detrás.
La pregunta es si el proceso de seguridad de Dusk está reduciendo las clases subyacentes de fallos, y no solo el número de hallazgos abiertos. Estoy observando si las mismas causas raíz vuelven a aparecer en auditorías posteriores, cómo evoluciona la cobertura de regresión y si supuestos de bajo nivel similares resurgen en otras partes del stack.
#dusk $DUSK @Dusk ✨