A Dusk enviou 39 correções por meio do AEGIS. Entre os achados por trás dessa remediação, 7 foram classificados como críticos. Isso soa como um número grande de problemas de segurança separados. Mas esses 7 achados críticos se resumiram a apenas 4 causas-raiz, o que torna a contagem do título menos direta do que parece à primeira vista.
Trinta e nove correções me dizem a escala do trabalho de remediação da Dusk. Elas não me dizem quantos modos de falha independentes essas correções estavam de fato abordando. O que ainda não sei é se o processo de remediação da Dusk remove consistentemente as causas compartilhadas por múltiplos achados, em vez de apenas fechar os caminhos de exploração individuais que acabaram sendo descobertos.
O próprio processo AEGIS da Dusk oferece um mecanismo útil para observar. A remediação crítica é rastreada não apenas pelo encerramento da exploração, mas também pelo encerramento da causa-raiz e pela cobertura de regressão. Isso torna a recorrência futura para mim mais útil do que a contagem bruta de correções. Enviar um patch prova que um problema conhecido foi tratado. Evidência mais forte seria ver a mesma classe subjacente de falha deixar de reaparecer em revisões posteriores ou em partes adjacentes da pilha.
À medida que a Dusk constrói infraestrutura para fluxos nativos de emissão, nos quais mais do ciclo de vida de uma segurança regulamentada pode depender diretamente da rede subjacente, a remediação por causa-raiz se torna um sinal de segurança mais significativo do que o número bruto de correções enviadas.
Eu aprenderia mais com a evidência de que algumas causas-raiz compartilhadas foram totalmente removidas do que com uma contagem maior de correções sem saber quantos modos de falha independentes estavam por trás disso.
A questão é se o processo de segurança da Dusk está reduzindo as classes subjacentes de falha, e não apenas o número de achados em aberto. Estou observando se as mesmas causas-raiz aparecem novamente em auditorias posteriores, como evolui a cobertura de regressão e se suposições de baixo nível semelhantes reaparecem em outras partes da pilha.
#dusk $DUSK @Dusk ✨
Trinta e nove correções me dizem a escala do trabalho de remediação da Dusk. Elas não me dizem quantos modos de falha independentes essas correções estavam de fato abordando. O que ainda não sei é se o processo de remediação da Dusk remove consistentemente as causas compartilhadas por múltiplos achados, em vez de apenas fechar os caminhos de exploração individuais que acabaram sendo descobertos.
O próprio processo AEGIS da Dusk oferece um mecanismo útil para observar. A remediação crítica é rastreada não apenas pelo encerramento da exploração, mas também pelo encerramento da causa-raiz e pela cobertura de regressão. Isso torna a recorrência futura para mim mais útil do que a contagem bruta de correções. Enviar um patch prova que um problema conhecido foi tratado. Evidência mais forte seria ver a mesma classe subjacente de falha deixar de reaparecer em revisões posteriores ou em partes adjacentes da pilha.
À medida que a Dusk constrói infraestrutura para fluxos nativos de emissão, nos quais mais do ciclo de vida de uma segurança regulamentada pode depender diretamente da rede subjacente, a remediação por causa-raiz se torna um sinal de segurança mais significativo do que o número bruto de correções enviadas.
Eu aprenderia mais com a evidência de que algumas causas-raiz compartilhadas foram totalmente removidas do que com uma contagem maior de correções sem saber quantos modos de falha independentes estavam por trás disso.
A questão é se o processo de segurança da Dusk está reduzindo as classes subjacentes de falha, e não apenas o número de achados em aberto. Estou observando se as mesmas causas-raiz aparecem novamente em auditorias posteriores, como evolui a cobertura de regressão e se suposições de baixo nível semelhantes reaparecem em outras partes da pilha.
#dusk $DUSK @Dusk ✨