Eu comecei a prestar mais atenção em como projetos de blockchain falam sobre segurança.
Uma longa lista de bugs pode soar impressionante no papel, mas o número em si não me diz muita coisa.
O que achei mais interessante no trabalho de segurança da Dusk com o AEGIS foi o que aconteceu por baixo dos números.
A auditoria gerou 39 achados, incluindo 7 classificados como críticos. Mas a Dusk agrupou esses problemas críticos em quatro causas raiz subjacentes, em vez de tratar cada achado como um problema sem relação.
Essa distinção importa.
Se cinco problemas diferentes vêm da mesma suposição, corrigir cinco sintomas não necessariamente torna o sistema cinco vezes mais seguro.
Um exemplo foi o cluster de taxas/ reembolso (fee/refund) da Phoenix. Uma fraqueza na forma como as informações de taxa foram vinculadas entre a geração de prova, a assinatura e a execução criou múltiplos resultados possíveis, incluindo redirecionamento de reembolso, inflação de fornecimento e até uma possível interrupção de cadeia.
Essa é a parte da engenharia de segurança que eu considero fácil de subestimar.
A pergunta importante não é apenas “Quantas vulnerabilidades foram corrigidas?”.
É “Que suposição permitiu que elas existissem em primeiro lugar?”.
Para infraestrutura financeira, essa diferença fica ainda mais importante. Um patch pode fechar um caminho de ataque hoje. Remover a suposição subjacente e falha pode evitar uma família inteira de problemas amanhã.
Talvez um processo de segurança forte não seja medido por quantos bugs um sistema tem.
Talvez seja medido por o quanto o time entende profundamente por que esses bugs eram possíveis.
#dusk $DUSK @Dusk
Uma longa lista de bugs pode soar impressionante no papel, mas o número em si não me diz muita coisa.
O que achei mais interessante no trabalho de segurança da Dusk com o AEGIS foi o que aconteceu por baixo dos números.
A auditoria gerou 39 achados, incluindo 7 classificados como críticos. Mas a Dusk agrupou esses problemas críticos em quatro causas raiz subjacentes, em vez de tratar cada achado como um problema sem relação.
Essa distinção importa.
Se cinco problemas diferentes vêm da mesma suposição, corrigir cinco sintomas não necessariamente torna o sistema cinco vezes mais seguro.
Um exemplo foi o cluster de taxas/ reembolso (fee/refund) da Phoenix. Uma fraqueza na forma como as informações de taxa foram vinculadas entre a geração de prova, a assinatura e a execução criou múltiplos resultados possíveis, incluindo redirecionamento de reembolso, inflação de fornecimento e até uma possível interrupção de cadeia.
Essa é a parte da engenharia de segurança que eu considero fácil de subestimar.
A pergunta importante não é apenas “Quantas vulnerabilidades foram corrigidas?”.
É “Que suposição permitiu que elas existissem em primeiro lugar?”.
Para infraestrutura financeira, essa diferença fica ainda mais importante. Um patch pode fechar um caminho de ataque hoje. Remover a suposição subjacente e falha pode evitar uma família inteira de problemas amanhã.
Talvez um processo de segurança forte não seja medido por quantos bugs um sistema tem.
Talvez seja medido por o quanto o time entende profundamente por que esses bugs eram possíveis.
#dusk $DUSK @Dusk
