Auditores de Cardano pedem revisões contínuas enquanto recompensas da Intersect ficam sem financiamento

A discussão de 28 de setembro reuniu Philip DiSarro, da Midgard Labs, Santiago, da TxPipe, Aleksandr, da Tweag, Ben Hart, da MLabs, e Leathers. Moderada por Denicio Bute, da Cardano Foundation, ela examinou como a IA está mudando tanto a descoberta de vulnerabilidades quanto o trabalho necessário para defender aplicativos de Cardano.

IA divide especialistas de segurança de Cardano

Bute começou perguntando se explorações recentes no ecossistema Cardano poderiam ter envolvido atacantes assistidos por IA. DiSarro argumentou que os modelos atuais dão a atacantes qualificados ferramentas poderosas para examinar código e perseguir explorações complexas. Em sua visão, as equipes de desenvolvimento precisam testar repetidamente seus próprios protocolos à medida que essas ferramentas melhoram.

Hart contestou a ideia de que a IA já pode realizar sozinha o trabalho de um atacante ou auditor especialista. Em auditorias em que usou IA, as pessoas ainda identificaram os problemas mais significativos. Uma pessoa reconheceu a fraqueza na especificação de um produto e concebeu uma forma de realizar o teste, mesmo quando um modelo ajudou a produzir o código de teste.

Leathers descreveu um limite prático a partir dos relatórios de vulnerabilidade da Intersect. As submissões aumentaram acentuadamente, mas muitas não estabelecem um problema real de segurança. Ele disse que os relatórios mais sólidos geralmente ainda vêm de pesquisadores com experiência relevante. O painel não apresentou evidências específicas de casos que estabelecessem que a IA foi usada nas explorações de Cardano discutidas durante a sessão.

Os palestrantes também rejeitaram a suposição de que o modelo UTxO estendido de Cardano torna seus aplicativos difíceis de analisar por ferramentas de IA porque essas ferramentas são mais familiarizadas com código EVM. Leathers apontou para a documentação disponível de Cardano e Plutus. A arquitetura de Cardano impede algumas classes de ataque a contratos inteligentes, mas um aplicativo ainda pode conter falhas em sua própria lógica ou em sistemas adjacentes.

Auditorias em Cardano vão além dos contratos inteligentes

A discussão passou do código do contrato para todo o caminho pelo qual um aplicativo lida com os fundos dos usuários. Servidores, bibliotecas de software, conexões de carteira, dispositivos de assinatura e chaves administrativas podem afetar o resultado de uma transação. Um validador on chain seguro não pode proteger os usuários de todas as falhas nesses componentes.

Hart disse que o código gerado por IA tornou as especificações mais importantes. Se uma equipe de desenvolvimento não consegue descrever com precisão o que seu produto deve permitir e proibir, um auditor não tem um padrão confiável pelo qual verificar a implementação. Santiago acrescentou que as equipes devem definir seu modelo de ameaças e decidir quanta flexibilidade ou capacidade de atualização desejam, já que essas escolhas podem introduzir formas adicionais de alterar um sistema.

Esse trabalho dá aos testes e à verificação formal um propósito concreto: verificar se o aplicativo preserva suas regras declaradas. DiSarro argumentou que as equipes devem ir além, tentando ataques controlados contra seus próprios protocolos. As revisões também precisam acompanhar mudanças significativas em código, infraestrutura e procedimentos operacionais, em vez de depender indefinidamente de uma auditoria concluída antes do lançamento.

As empresas de auditoria descreveram a IA como parte desse processo. Modelos podem procurar padrões, comparar código com especificações e sugerir potenciais caminhos de ataque. Santiago disse que sua equipe confere os achados automatizados por meio de revisão humana; o painel também discutiu usar mais de um modelo porque ferramentas diferentes podem descobrir problemas diferentes. Falsos positivos ainda consomem tempo de revisão, enquanto código sensível e requisitos de computação afetam se uma equipe usa um modelo hospedado ou operado localmente.

Programa de bug bounty da Intersect enfrenta lacuna de financiamento

Leathers então identificou um problema separado para a divulgação coordenada de vulnerabilidades. Ele disse que o financiamento para bug bounty não foi aprovado no ciclo de tesouraria atual. Pesquisadores ainda podem enviar relatórios, e o Security Council continua a analisar esses relatórios, mas no momento não pode pagar novas recompensas por meio dessa via de financiamento. Ele disse que o conselho está trabalhando com a Intersect em alternativas e que uma retirada de tesouraria aprovada pela comunidade poderia fornecer financiamento.

A Intersect lançou seu programa de bug bounty em 2025 para infraestrutura e ferramentas que gerencia ou patrocina. Contratos inteligentes entram em seu escopo apenas quando incluídos de forma explícita. As observações de Leathers referiam se a esse programa; a Cardano Foundation opera um arranjo de recompensas separado.

Um volume maior de relatórios gerados por IA também eleva o custo de revisar as submissões. Leathers pediu uma triagem mais rigorosa para que vulnerabilidades reproduzíveis recebam atenção, enquanto achados incorretos e questões comuns de manutenção sejam classificados de forma apropriada. DiSarro, por sua vez, instou protocolos e bridges DeFi individuais a estabelecerem suas próprias recompensas e procedimentos de incidentes antes que uma exploração ocorra.

A mesa redonda deixou a Intersect com uma questão de governança definida. Seu canal de divulgação permanece aberto e o Security Council ainda está avaliando relatórios. O financiamento para recompensas a pesquisadores agora depende de um novo arranjo ou de uma decisão da tesouraria. Essa decisão determinará se um achado válido no âmbito do programa da Intersect poderá novamente levar ao pagamento que o programa foi concebido para oferecer.