Una alarma contra humo resulta menos tranquilizadora si solo la pruebas una vez.
Así fue más o menos como empecé a analizar el trabajo de AEGIS de Dusk. El titular era la ola de remediación, pero el detalle más silencioso que noté aparece después de las correcciones.
AEGIS envió correcciones para 39 hallazgos de auditoría, incluidos 7 clasificados como críticos.
Pero cerrar un hallazgo es solo un momento en el trabajo de un auditor.
Dusk también añadió cobertura de regresión basada en los patrones de fallo reales descubiertos durante la auditoría. Para los problemas de comisiones y reembolsos de Phoenix, eso incluyó pruebas de intentos de inflación, rutas de desbordamiento y manipulación de comisiones.
Me resulta más útil que tratar “resuelto” como el estado final.
Un fallo corregido aún puede volver más tarde mediante refactorización, cambios en dependencias u otra ruta de código. Una prueba de regresión mantiene el caso de fallo anterior dentro del proceso de verificación.
Dusk también agrupó el trabajo de seguimiento por causa raíz, donde varios hallazgos eran en realidad síntomas distintos del mismo problema subyacente.
Esa es la capa que yo vigilaría como auditor.
El informe deja constancia de lo que estaba mal.
El artefacto más sólido es una batería de pruebas que sigue preguntando si volvió.
@Dusk_Foundation $DUSK #dusk
Así fue más o menos como empecé a analizar el trabajo de AEGIS de Dusk. El titular era la ola de remediación, pero el detalle más silencioso que noté aparece después de las correcciones.
AEGIS envió correcciones para 39 hallazgos de auditoría, incluidos 7 clasificados como críticos.
Pero cerrar un hallazgo es solo un momento en el trabajo de un auditor.
Dusk también añadió cobertura de regresión basada en los patrones de fallo reales descubiertos durante la auditoría. Para los problemas de comisiones y reembolsos de Phoenix, eso incluyó pruebas de intentos de inflación, rutas de desbordamiento y manipulación de comisiones.
Me resulta más útil que tratar “resuelto” como el estado final.
Un fallo corregido aún puede volver más tarde mediante refactorización, cambios en dependencias u otra ruta de código. Una prueba de regresión mantiene el caso de fallo anterior dentro del proceso de verificación.
Dusk también agrupó el trabajo de seguimiento por causa raíz, donde varios hallazgos eran en realidad síntomas distintos del mismo problema subyacente.
Esa es la capa que yo vigilaría como auditor.
El informe deja constancia de lo que estaba mal.
El artefacto más sólido es una batería de pruebas que sigue preguntando si volvió.
@Dusk_Foundation $DUSK #dusk