Bloquear a entrada do ataque e eliminar suposições incorretas são duas coisas diferentes
A própria AEGIS enfatiza uma distinção bem honesta: o fato de o caminho de ataque principal estar bloqueado não significa que a causa raiz já foi totalmente reestruturada. A cadeia de custos do Phoenix pode, por meio de verificações de consistência e vinculação de campos, primeiro impedir a expansão, a interrupção da cadeia e a apropriação indevida de reembolsos; já a organização de um nível de design mais profundo ainda é outra frente de trabalho. Assim, o estado de segurança não é apenas algo do tipo “tem furo/não tem furo”.
A meu ver, esse tipo de formulação é mais adequado para infraestrutura financeira do que uma frase como “o problema já foi resolvido”. O objetivo da mitigação emergencial é reduzir rapidamente o risco real; a correção da causa raiz é eliminar suposições incorretas compartilhadas entre módulos — e, portanto, os prazos, a validação e os custos de migração de cada uma são diferentes. Misturar tudo em um “concluído” tira do mercado a base para julgar os riscos restantes.
Uma boa divulgação deve explicar separadamente: se a exploração existente já é inviável, quais trechos de código ainda dependem da estrutura antiga, como a reestruturação futura será validada e se a semântica das transações históricas foi afetada. Assim, os usuários não entram em pânico por causa de jargões técnicos, nem são acalmados por slogans de segurança excessivamente simplificados.
Vejo o progresso de segurança de @Dusk e registrarei “exploit closure” e “root-cause closure” separadamente. $DUSK , #dusk : o que merece confiança não é nunca admitir dívida técnica, e sim que cada camada de dívida tenha nome, estado e condição de encerramento.
A própria AEGIS enfatiza uma distinção bem honesta: o fato de o caminho de ataque principal estar bloqueado não significa que a causa raiz já foi totalmente reestruturada. A cadeia de custos do Phoenix pode, por meio de verificações de consistência e vinculação de campos, primeiro impedir a expansão, a interrupção da cadeia e a apropriação indevida de reembolsos; já a organização de um nível de design mais profundo ainda é outra frente de trabalho. Assim, o estado de segurança não é apenas algo do tipo “tem furo/não tem furo”.
A meu ver, esse tipo de formulação é mais adequado para infraestrutura financeira do que uma frase como “o problema já foi resolvido”. O objetivo da mitigação emergencial é reduzir rapidamente o risco real; a correção da causa raiz é eliminar suposições incorretas compartilhadas entre módulos — e, portanto, os prazos, a validação e os custos de migração de cada uma são diferentes. Misturar tudo em um “concluído” tira do mercado a base para julgar os riscos restantes.
Uma boa divulgação deve explicar separadamente: se a exploração existente já é inviável, quais trechos de código ainda dependem da estrutura antiga, como a reestruturação futura será validada e se a semântica das transações históricas foi afetada. Assim, os usuários não entram em pânico por causa de jargões técnicos, nem são acalmados por slogans de segurança excessivamente simplificados.
Vejo o progresso de segurança de @Dusk e registrarei “exploit closure” e “root-cause closure” separadamente. $DUSK , #dusk : o que merece confiança não é nunca admitir dívida técnica, e sim que cada camada de dívida tenha nome, estado e condição de encerramento.