Por que as descobertas de baixa gravidade dizem mais sobre sua auditoria do que os bugs críticos Muitas empresas de auditoria concentram seu discurso de vendas no número de Highs encontrados como se esse número não fosse apenas ruído sem conexão com o contexto: auditorias anteriores, revisão por pares, níveis de cobertura de teste, complexidade de código, contagem de linhas e muitas outras métricas. É a forma mais baixa de vendas, não diferente de comparar, por exemplo, a qualidade da unidade USB por seu comprimento em milímetros. Para mostrar uma alternativa, primeiro devemos afirmar a exatidão de várias afirmações de apoio: - A probabilidade de injeção acidental de bugs não tem viés para impactos mais altos (os desenvolvedores não são mais imprudentes em códigos de alto risco, geralmente o oposto). - As mesmas metodologias abrangentes usadas para descobrir falhas de várias gravidades também descobririam problemas de alta gravidade (o oposto não é válido). - Existem requisitos muito mais altos para que um bug aleatório se qualifique como de alta gravidade (muitas vezes ele seria bloqueado por condições inacessíveis ou tocaria em funcionalidades não críticas). - Das estatísticas básicas: uma taxa de amostragem mais alta se correlaciona com um menor desvio/variância esperada e, portanto, uma medição mais precisa. Vamos definir um relatório de auditoria como o resultado da amostragem da qualidade de uma base de código. Deduzimos que o número real esperado (sem erros) de máximos é muito menor do que os mínimos, e o desvio esperado em torno dele é muito maior (devido à amostra menor). Em outras palavras, o número de máximas nos diz muito pouco sobre o número de máximas perdidas. Então, surpreendentemente, um relatório de 1 alta, 10 baixas é mais tranquilizador do que um relatório de 10 altas, 1 baixa sendo tudo o mais igual. Embora, de fato, a grande maioria dos vendedores prefira mostrar o último como uma indicação de qualidade. A questão é que uma métrica de alta frequência é uma ferramenta melhor para medir resultados de baixa frequência. Construtores Web3, da próxima vez que as empresas acenarem com suas contagens Crit/High e X bilhões de $ linha segura, você sabe onde se concentrar para procurar o sinal verdadeiro. Auditores da Web3, reconheçam que não existe uma fórmula secreta consistente para encontrar todos os altos sem também procurar os baixos - cada baixa não totalmente investigada é uma alta potencial - e dê a melhor atenção a cada linha. Seu cliente vai agradecer por isso. A baixa gravidade é definida como erros de codificação concretos que não resultam em impactos de nível mais alto. Não inclui formatação, práticas recomendadas e descobertas de preenchimento.

Um crítico no git lançado ontem que pode ser acionado pelo clone git de repositório não confiável. Esse é o vetor dos sonhos para enganar os auditores e roubar suas recompensas / dinheiro de auditoria. Corrija seus sistemas antes de cotar novos clientes! E espere visitantes em sua caixa de entrada nas próximas semanas...

Acontece que você pode ganhar recompensas de 5 figos em concursos sem realmente descobrir nenhum problema, apenas um cérebro semi-funcional necessário. No concurso OP Fault Proofs de março de 2024, os desenvolvedores corrigiram um problema crítico um dia antes de começar, mas não o mesclaram. 🔗 Apenas olhando para o log de commit público, você obtém uma pontuação alta 🔗 🔗 Acabou sendo uma recompensa de $ 16680: É apenas um dos muitos truques para encontrar bugs dentro do escopo sem realmente procurá-los. Sempre tente trabalhar de forma inteligente, não difícil.

Decidi experimentar a Cantina em outubro passado, 8 meses depois os resultados finalmente foram divulgados... Dezenas de descobertas solo na 1ª auditoria Java e superando os principais manos da tabela de classificação da Cantina em 3-7x é muito bom, não vou mentir. É uma pena que a experiência pós-auditoria tenha sido tão terrível que jurei nunca mais voltar a essa plataforma. *aviso de discurso retórico justificado* - Tempo de resolução de 8 meses, até o momento da redação - recompensa ainda não enviada. - Dezenas de horas gastas escalando e defendendo submissões de veredictos errados. - Contados ~ 104 erros de julgamento (ingênuos errados, inválidos claros, gravidade errada) que foram corrigidos. Mais que não. - Perda de valor de ~ $ 110.000 devido à resolução demorar 7 meses a mais do que deveria e o token OP cair para ~ 50 centavos. Claro, ao competir em competições que não sejam em dólares, as flutuações dos potes são um risco aceito. Mas 8 meses de juízes sendo incompetentes e não sendo capazes de encerrar uma competição não faziam parte do meu modelo de ameaça. Durante os dias de julgamento do C4, eu processava totalmente 1000 descobertas em menos de uma semana (solo), OP-Java tinha 360 e vários juízes. Não é surpresa que a Cantina nunca tenha anunciado nas redes sociais os resultados, ao contrário de 5 outros concursos que foram concluídos esta semana, certamente não poderia ser o caso de eles quererem evitar a má imprensa ou destacar o domínio do TrustSec, certo? É uma pena que tenhamos que continuar discutindo as más práticas da plataforma de recompensas em vez de bugs críticos, mas não há outra escolha a não ser manter todos responsáveis. Um post de análise técnica sem desabafos para as descobertas solo chegará em breve.

Imagine um mundo onde dizer que os pesquisadores não devem ser abusados é uma tomada controversa. Isso é o que acontece quando uma empresa com dinheiro ilimitado aparece e compra seu caminho para o domínio do mercado. O despejo em pesquisadores com políticas extrativistas simplesmente se torna o novo equilíbrio de Nash

A cada dia que passa, fica cada vez mais claro para nós que @cantinaxyz é uma entidade extrativa e um negativo líquido para o espaço. Uma semana passada @jack__sanford artigo matador sobre as inúmeras deficiências do concurso de Cork e nenhum indício de uma resposta em breve. Com a quantidade de atenção que o artigo recebeu, se eles pudessem montar uma defesa, certamente o fariam, também conhecido como silêncio, é uma admissão de culpa. Esta semana, nosso envio de recompensas da Cantina, que eles concordaram, mostra uma perda limitada de fundos para um operador de blockchain em alta probabilidade, resolvida em mediação para baixa gravidade. Tendo lido 10 relatórios de Spearbit / Cantina e 100 de artigos de recompensas, a perda monetária de qualquer valor nunca está abaixo do impacto médio, então eles estão claramente transmitindo a perspectiva do patrocinador em uma mentalidade clássica de "o cliente está sempre certo", como sempre fazem. Na verdade, eles nem se escondem fazendo isso. Por seus próprios documentos, eles assumem a perspectiva do cliente como padrão. Acho que apenas nos casos mais flagrantes eles rejeitam a opinião do cliente. E se o cliente simplesmente ignorar sua mediação? Em qualquer outra plataforma (por exemplo, @immunefi) com a qual trabalhamos, não respeitar a mediação é motivo para remoção imediata do cliente. Na Cantina, o cliente tem um subsídio de 5 golpes de recompensa por ano. Sim, você leu certo. Também descobrimos recentemente que o programa de bolsas tem uma cláusula de exclusividade altamente agressiva. Os bolsistas não podem enviar nada para outras plataformas de recompensas ou notificar projetos diretamente, mesmo que milhões de dólares estejam em risco. Em vez disso, esse conhecimento altamente sensível e urgente deve ser compartilhado com a Cantina, que decide como proceder. Eles são os chefes, dão as ordens, se curvam ou deixam a mentalidade. Temos mais exemplos de manuseio ultrajante na Cantina, mas vamos deixá-los para outro dia. Por enquanto, queremos aumentar a conscientização, como outros membros importantes da comunidade, de que os auditores devem votar com os pés quando se trata de onde passam seu precioso tempo caçando. Uma plataforma de segurança que perde o equilíbrio e favorece projetos em detrimento de caçadores de recompensas prejudica todo o processo de chapéu branco e incentiva os pesquisadores a ganhar seu valor por meios menos éticos! Vamos trabalhar como uma comunidade para fortalecer organizações de alta integridade, transparentes e positivas sobre os agressores do setor. A declaração acima é a opinião pessoal dos membros da diretoria da TrustSec e deve ser interpretada como tal.

- Manter a LoC que muda de estado abaixo de 500 - usar o padrão ++counter para mapear chaves - não suportam tokens nativos - manter a máquina de estado em exibição aberta por meio de enumerações de estado - Relação teste/LoC de 1:1 - formatar cada linha de código com uma régua Veja, ganhar o jogo não é tão difícil

Como um veterano da indústria de concursos de auditoria, vou lhe dizer como negócios como esses são feitos. > Seja protocolo com dinheiro e faça 3+ auditorias colaborativas > Saiba que a base de código provavelmente não tem bugs significativos > Deseja sinalizar para a comunidade, investidores e outras partes interessadas que você se preocupa com a segurança > Não tenho intenção de gastar mais dinheiro em segurança > plataforma "Concurso" tem solução > Organize um concurso de tapete garantindo que os potes High/Crit não sejam desbloqueados > Faça o pote Med super pequeno > Se High encontrado, então minimize a sumissão, caso contrário, o cliente está insatisfeito (lembra de Euler?) > plataforma "Concurso" e você obtém marketing gratuito > SRs robustos, mas você não se importa > Repita, mas torne o próximo anúncio do concurso de tapetes ainda mais otimista.

Aviso ⚠️: Não é um novo artigo sobre recompensas Todos nós, auditores, gostamos de nos concentrar nas críticas suculentas e manter o trabalho não técnico no mínimo. Quem se importa com papelada e reuniões quando você acabou de encontrar uma nova maneira de drenar um contrato DeFi? Mas todas as coisas devem ser feitas com moderação, e muitas vezes vemos pesquisadores independentes economizando totalmente em obter até mesmo um acordo básico assinado com o cliente. Isso foi algo que também fizemos nos primeiros meses do TrustSec - conectar-se com um cliente no TG / discord, discutir equipe, preço e cronograma e apenas começar. Parecia suave e sem atrito, então qual é o problema? Como acontece com muitas coisas, funciona bem até que não funcione. Quando você gerencia 50+ auditorias por ano, começa a se deparar com casos extremos. E quando você faz isso, ter as coisas limpas com antecedência evita uma tonelada de atrito em pontos potencialmente sensíveis no cronograma de auditoria. Veja, o objetivo de um contrato de serviços não é que ele possa ser litigado em um tribunal a milhares de quilômetros de sua localização atual. Claro, na pior das hipóteses, possivelmente pode ser. Mas, principalmente, é feito para alinhar as expectativas de ambos os lados, uma maneira de forçar os dois lados a falar sobre detalhes que, de outra forma, não fariam. Aqui estão apenas alguns cenários que surgiram e devem ser tratados explicitamente: - O cliente não está pronto com a confirmação final antes da data de início. - Por motivos imprevistos, um ou mais auditores não estão disponíveis para parte ou para toda a janela de auditoria. - O escopo final requer mais tempo de revisão, aumentando os custos. - Debater sobre qual ferramenta e formatação são usadas para contar o SLOC final. - O cliente introduz uma nova funcionalidade para revisão na auditoria de correção. - Solicitar que o pagamento seja enviado somente após a entrega do relatório. - O cliente deseja cancelar a auditoria com apenas 24 horas de antecedência. - O cliente deseja enviar o pagamento em seu blockchain preferido. - Objeções sobre o relatório ser publicado após um período de espera aceitável. Além de deixar claro como lidar com esses cenários, um acordo também fornece aos auditores proteção crítica: - Renuncia a qualquer responsabilidade por bugs e exploits perdidos. - Mantém os direitos de PI sobre ferramentas, conceitos de ataque desenvolvidos durante a auditoria (na medida em que a lei permite). - Providencia adiantamentos, taxas de cancelamento e assim por diante. - Atende aos requisitos de due diligence, KYB e estrutura legal. Isso é relevante para os requisitos de tributação, conformidade e fonte de fundos. Por esses motivos, descobrimos rapidamente que vale a pena gastar um pouco de tempo extra antes de reservar as coisas e incentivamos todos os auditores que administram um negócio legítimo a fazer o mesmo.

No final de 2024, a TrustSec descobriu um bug de consenso em @OPLabsPBC cliente Optimism. Na pior das hipóteses, o op-node teria uma visão errada do estado L2, causando uma divisão da cadeia de outros clientes. Por nossa pesquisa, a OP Labs generosamente nos concedeu uma recompensa de US$ 7,5 mil. Confira todos os detalhes no artigo técnico abaixo!