samczsun: A segurança dos protocolos de cripto depende principalmente de auditorias proativas

Programas de recompensa por bugs são medidas passivas, enquanto a proteção de segurança precisa ser promovida ativamente.

Autor: samczsun, fundador da Security Alliance e ex-parceiro de pesquisa da Paradigm

Atualmente, o setor já chegou a um consenso de que a proteção de segurança em criptomoedas deve seguir três etapas-chave: escrever casos de teste durante o desenvolvimento para identificar erros básicos; realizar revisões abrangentes antes da implantação por meio de auditorias e competições; e estabelecer programas de recompensa por bugs para premiar pesquisadores que divulgam vulnerabilidades de forma responsável, prevenindo ataques. A popularização dessas melhores práticas reduziu significativamente o número de vulnerabilidades on-chain, forçando os atacantes a direcionarem seus esforços para o roubo de chaves privadas, invasão de infraestrutura e outras vulnerabilidades off-chain.

No entanto, mesmo protocolos que passaram por auditorias completas e oferecem recompensas generosas por bugs ainda são ocasionalmente vítimas de ataques hackers. Esses incidentes afetam não apenas o protocolo envolvido, mas também abalam a confiança de todo o ecossistema. Os recentes ataques hackers ao Yearn, Balancer V2, bem como os incidentes de segurança no início do ano envolvendo Abracadabra e 1inch, mostram que mesmo protocolos testados pelo tempo não são absolutamente seguros. O setor de cripto poderia ter evitado esses ataques? Ou isso é apenas um custo inevitável das finanças descentralizadas?

Comentaristas frequentemente sugerem que aumentar as recompensas por bugs poderia proteger esses protocolos. Mas, mesmo deixando de lado a realidade econômica, a recompensa por bugs é, em essência, uma medida de segurança passiva, colocando o destino do protocolo nas mãos de hackers white hat, enquanto a auditoria é uma ação proativa de autoproteção do protocolo. Aumentar a recompensa por bugs não impede ataques hackers, pois isso equivale a dobrar a aposta, apostando que hackers white hat encontrarão as vulnerabilidades antes dos black hats. Se um protocolo realmente deseja se proteger, deve realizar auditorias recorrentes de forma proativa.

Fundos do Tesouro e Valor Total Bloqueado (TVL)

Às vezes, hackers concordam em devolver a maior parte dos fundos roubados, ficando apenas com uma pequena parte (geralmente 10%) como recompensa. Infelizmente, o setor chama essa parte de "recompensa white hat", o que levanta a questão: por que o protocolo não oferece diretamente o mesmo valor por meio de um programa de recompensa por bugs, evitando negociações? Mas esse pensamento confunde os fundos que o atacante pode roubar com os fundos que o protocolo pode dispor.

Embora à primeira vista pareça que o protocolo pode usar ambos os fundos para proteção de segurança, ele só tem controle legal sobre os fundos do próprio tesouro, não podendo usar os fundos depositados pelos usuários. Os usuários dificilmente concederiam esse tipo de permissão antecipadamente; apenas em momentos de crise (por exemplo, quando precisam escolher entre perder 10% ou 100% dos depósitos) permitiriam que o protocolo usasse os depósitos em negociações. Em outras palavras, o risco cresce junto com o TVL, mas o orçamento de segurança não pode aumentar na mesma proporção.

Eficiência de Capital

Mesmo que o protocolo tenha fundos suficientes (por exemplo, um grande tesouro, alta lucratividade ou já tenha implementado uma política de taxas de segurança), como alocar esses fundos de forma eficiente para proteção de segurança ainda é um desafio. Comparado ao investimento em auditorias recorrentes, aumentar a recompensa por bugs é, na melhor das hipóteses, extremamente ineficiente em termos de capital e, na pior, pode causar desalinhamento de incentivos entre o protocolo e os pesquisadores.

Se a recompensa por bugs estiver atrelada ao TVL, quando os pesquisadores suspeitarem que o TVL do protocolo vai crescer e a probabilidade de vulnerabilidades repetidas for baixa, eles terão mais motivação para ocultar vulnerabilidades críticas. Isso acabará colocando pesquisadores e protocolos em lados opostos, prejudicando os interesses dos usuários. Simplesmente aumentar a recompensa por vulnerabilidades críticas também dificilmente trará o efeito desejado: o grupo de pesquisadores freelancers é grande, mas poucos dedicam a maior parte do tempo a programas de recompensa por bugs e têm habilidades suficientes para encontrar vulnerabilidades em protocolos complexos. Esses pesquisadores de elite concentram seu tempo nos programas de recompensa com maior potencial de retorno sobre o investimento. Para protocolos grandes e testados pelo tempo, como se presume que estão sempre sob o olhar atento de hackers e outros pesquisadores, a probabilidade de encontrar vulnerabilidades é considerada mínima, então, independentemente do valor da recompensa, dificilmente conseguirão atrair sua atenção.

Ao mesmo tempo, do ponto de vista do protocolo, a recompensa por bugs é uma reserva para pagar por uma única vulnerabilidade crítica. A menos que o protocolo aposte que nunca haverá uma vulnerabilidade crítica e esconda sua situação de liquidez dos pesquisadores, esses fundos não podem ser usados para outros fins. Em vez de esperar passivamente que pesquisadores encontrem vulnerabilidades críticas, é melhor usar o mesmo valor para realizar várias auditorias recorrentes ao longo dos anos. Cada revisão garante a atenção dos melhores pesquisadores e não limita artificialmente a descoberta a uma única vulnerabilidade, além de alinhar os interesses dos pesquisadores e do protocolo: se o protocolo for explorado, ambos sofrerão danos à reputação.

Precedentes Existentes

Nos setores de software e financeiro, auditorias anuais são uma prática comprovada e madura, além de serem a melhor maneira de avaliar se uma empresa pode lidar com um ambiente de ameaças em constante evolução. O relatório SOC 2 Tipo II é usado por clientes B2B para avaliar se fornecedores mantêm controles de segurança adequados; a certificação PCI DSS indica que a empresa tomou medidas apropriadas para proteger informações sensíveis de pagamento; o governo dos EUA exige que partes que lidam com informações governamentais obtenham a certificação FedRAMP para manter altos padrões de segurança.

Embora os contratos inteligentes sejam imutáveis, o ambiente em que operam não é estático. Configurações podem mudar ao longo do tempo, dependências podem ser atualizadas e padrões de código antes considerados seguros podem, na verdade, apresentar riscos. Auditorias de protocolo avaliam a segurança no momento da auditoria, não garantem a segurança futura do protocolo. A única maneira de atualizar essa avaliação é realizando uma nova auditoria.

Em 2026, o setor de cripto deve adotar auditorias anuais como o quarto passo na proteção de segurança dos protocolos. Protocolos existentes com grande TVL devem realizar auditorias recorrentes em suas implantações; empresas de auditoria devem oferecer serviços especializados focados na avaliação do estado geral das implantações; e todo o ecossistema deve mudar coletivamente sua percepção sobre relatórios de auditoria: eles são apenas avaliações de segurança em um momento específico, podem expirar e não são garantias de segurança permanente.