00:00:00Este é o Shannon, um testador de invasão por IA autônomo e de código aberto que analisa códigos e executa
00:00:05exploits ao vivo usando automação de navegador para encontrar todos os tipos de vulnerabilidades de segurança, desde
00:00:11falsificação de solicitação do lado do servidor a cross-site scripting, injeção de SQL e muito mais, fornecendo um
00:00:17relatório de segurança detalhado e abrangente com zero falsos positivos. Mas com o anúncio da
00:00:22segurança de código do Claude e o fato de o Shannon ser construído no SDK do Claude, o que significa que você não pode
00:00:27usar sua assinatura, vale a pena aprender algo que pode não durar tanto tempo?
00:00:31Clique em se inscrever e vamos conferir.
00:00:32Em um dos meus empregos anteriores, pagávamos milhares de dólares para testadores externos antes de um
00:00:38lançamento importante, apenas para descobrir bugs que precisávamos corrigir e testar novamente,
00:00:43custando-nos muito tempo e, claro, dinheiro. Mas é exatamente isso que o Shannon veio resolver.
00:00:48Você pode executar o Shannon quantas vezes quiser. Pode até colocá-lo em um pipeline de CI/CD e executá-lo
00:00:53automaticamente. E por ser código aberto, é totalmente gratuito. Bem, existe uma versão paga,
00:00:58da qual falaremos mais tarde. Mas como alguém que não é especialista em segurança, prefiro passar meu projeto
00:01:03pelo Shannon do que iniciar o Kali Linux. Na verdade, vamos ver o Shannon em ação. O Shannon é construído
00:01:08usando o SDK de Agente da Anthropic. Portanto, você precisará de uma chave de API do Claude para funcionar. Infelizmente,
00:01:13a assinatura também não funcionará, mas eu o instalei em um VPS usando um usuário não raiz e vou
00:01:20executá-lo contra o OASP juice shop, que é um app projetado com várias vulnerabilidades
00:01:25para fins de teste. Já clonei o repositório do Shannon, que você precisará se quiser executá-lo.
00:01:30E para isso funcionar, você deve ter o repositório que deseja testar dentro do diretório
00:01:34repos do Shannon. Então, tenho o juice shop aqui dentro. E com o projeto juice shop rodando,
00:01:39vou executar este comando, que se conectará ao app rodando localmente para testes de navegador
00:01:44e ao repositório dentro do diretório repo para escanear o código. Agora, se esta for a primeira
00:01:50vez que você executa o Shannon, como ele usa Docker compose, ele terá primeiro que baixar várias
00:01:54imagens do Docker Hub. Mas como eu já passei por esse processo, ele pula direto para cá.
00:01:58Recebemos um link para o fluxo de trabalho do Temporal e podemos visualizá-lo na interface web,
00:02:03que é assim, mostrando todas as etapas necessárias. Ou podemos rodar este comando para ver os logs
00:02:07em tempo real, o que às vezes prefiro, já que a interface web nem sempre mostra todas as informações.
00:02:12Mas espere, o que é Temporal? Achei que estávamos falando do Shannon. Bem,
00:02:16os testes do Shannon podem levar uma ou várias horas dependendo do tamanho do projeto, e o Temporal
00:02:21garante uma execução durável, não importa o cenário. Se o seu computador travar no meio de um teste
00:02:26ou se acabarem os créditos do Claude e você precisar recarregar, você não perde o progresso. O Temporal
00:02:32lembra exatamente onde parou e reinicia o Shannon daquele ponto. Deixe nos comentários
00:02:36se quiser um vídeo dedicado sobre o Temporal, mas ele também orquestra todas as fases e atividades do Shannon.
00:02:42E embora existam apenas cinco fases, muita coisa acontece dentro delas.
00:02:47Deixe-me mostrar. Começando com a fase de pré-voo, que garante que as credenciais da API sejam válidas,
00:02:53os containers Docker estejam prontos e o repositório realmente exista. Depois, a etapa de pré-reconhecimento,
00:03:00que analisa o código para entender como o app funciona: arquitetura, mapeamento de pontos de entrada e padrões de segurança.
00:03:05Em seguida, vem a fase de reconhecimento real, que é bem diferente da prévia porque aqui
00:03:12o Playwright é usado para navegar pelo app. Ele clicará em botões, preencherá formulários e usará
00:03:18isso para observar requisições de rede, tirar prints, olhar cookies, basicamente mapear toda a
00:03:24funcionalidade do app. Então a fase quatro executa cinco pipelines em paralelo. Aqui temos
00:03:31vulnerabilidades e exploits de injeção, depois vulnerabilidades e exploits de cross-site scripting,
00:03:38seguidos por autenticação e falsificação de solicitação do lado do servidor (SSRF). E, finalmente, autorização.
00:03:45Ou seja, acesso a dados privilegiados ou informações de outras pessoas. Tudo isso acontece em paralelo
00:03:52em cinco agentes diferentes para vulnerabilidades e outros cinco para exploits. Por fim, temos a fase cinco,
00:03:59que compila tudo em um relatório abrangente de teste de invasão, combinando as últimas cinco verificações.
00:04:07Falando em relatório, vamos ver como está indo o nosso teste. Após quase duas horas e meia, o
00:04:12processo completo terminou e podemos ver aqui que começou com a validação de pré-voo antes de
00:04:17seguir para o pré-reconhecimento e o agente de reconhecimento. E aqui ele executa todas as
00:04:25verificações de vulnerabilidade: injeção, cross-site scripting, autorização e SSRF.
00:04:31Notem que em alguns destes a linha verde não está sólida. Isso aconteceu porque ele teve que tentar
00:04:36novamente pois meus créditos acabaram. Podem ver um “2” aqui; para os outros, não houve
00:04:40tentativas extras. Poderia ter sido mais rápido que duas horas e meia sem esses problemas, mas
00:04:46não acho que seria menos de duas horas. Enfim, após as cinco verificações de vulnerabilidade,
00:04:51ele passa para os cinco testes de exploit. Vemos SSRF aqui, o exploit de autenticação,
00:04:56o de injeção e assim por diante. E uma vez concluídos, percebemos que o exploit de
00:05:02autenticação é o que demora mais. Ele encerra tudo usando o agente de relatório. É claro,
00:05:07se quiséssemos, poderíamos expandir tudo isso para ver mais detalhes de cada etapa, mas
00:05:13não sou especialista em Temporal e tenho certeza de que a documentação explica muito mais sobre
00:05:17como usar a plataforma. Mas vamos dar uma olhada no relatório final que o Shannon gerou.
00:05:22Aqui, no diretório de entregáveis do nosso projeto juice shop, vemos a lista de todos os
00:05:28relatórios gerados. São muito mais do que eu esperava. Vamos olhar primeiro este aqui,
00:05:33que é a análise de autenticação. Notem o resumo no topo. E bem aqui,
00:05:37está anotado que 11 vulnerabilidades críticas foram identificadas e podemos ver quais são.
00:05:43Zero de seis endpoints de autenticação forçavam HTTPS, o que faz sentido porque eu estava
00:05:47rodando localmente. Também temos a falta de controle de segurança adequado.
00:05:52E os endpoints de autenticação não tinham limites de taxa adequados. Isso é muito detalhado.
00:05:56Se rolarmos para baixo, vemos exatamente quais eram os problemas, onde estavam
00:06:01e os endpoints que os causaram. Não vou entediar vocês passando por cada
00:06:05relatório, mas vamos ao resumo, chamado “Relatório Abrangente de Avaliação de Segurança”.
00:06:10Aqui temos detalhes sobre o modelo usado, o escopo do projeto e, se rolarmos
00:06:15para baixo, vemos que ele encontrou quatro vulnerabilidades críticas de autenticação que foram totalmente
00:06:21exploradas e as lista aqui embaixo. Uau, isso é muito minucioso, mas vejam só.
00:06:26Mais abaixo, ele fornece um resumo do relatório. Este é o primeiro caso de IDOR
00:06:31e, descendo mais um pouco, vemos exatamente como um invasor poderia explorar isso. O comando curl
00:06:38exato que poderiam rodar com os detalhes e o tipo de informação que poderiam extrair. E esse
00:06:43nível de detalhe existe para cada vulnerabilidade, o que mostra o quão profunda
00:06:48foi a avaliação. Se tiverem interesse, vou deixar um link para todos os relatórios
00:06:54na descrição. Mas duas horas e meia é muito tempo para o Claude Sonnet
00:06:59escanear um repositório. O Shannon Pro poderia ter ajudado? Parece que o
00:07:04Shannon Pro não ajudaria na velocidade, mas faz outras coisas como fornecer pontuação CVSS,
00:07:09que a versão básica gratuita não tem. Tem suporte a pipeline CI/CD, acesso a API e,
00:07:16mais importante, se você for um usuário corporativo, terá tudo o que se espera, incluindo relatórios de
00:07:22conformidade OWASP, além de SOC 2 e PCI DSS. Embora duas horas e meia seja muito tempo,
00:07:27pesquisei e descobri que a primeira execução do Shannon é a mais demorada e as
00:07:32seguintes são muito mais rápidas. Agora sei o que estão pensando: quase duas horas e meia rodando
00:07:37Claude Sonnet 3.5 em um único teste. Quanto custou em créditos? Digamos que bastante.
00:07:43Recarreguei cerca de 66 dólares e sobrou apenas isto. Então, quase 60 dólares em créditos do Claude
00:07:50foram gastos neste teste, o que é mais barato que contratar um testador humano, mas ainda é
00:07:55muito dinheiro. Eu adoraria ter usado minha assinatura Claude Pro ou Max, o que tornaria tudo
00:08:00muito mais barato, e é o que esperamos que a segurança de código do Claude permita quando
00:08:05for lançada oficialmente. A menos que a equipe da Keygraph reescreva o Shannon no SDK de agentes
00:08:10da OpenAI ou use o Vercel AI SDK, que permite usar muito mais modelos. No geral,
00:08:16se você é uma startup e não quer gastar muito com um testador humano, o Shannon é uma
00:08:21boa alternativa. Se você é um desenvolvedor independente com pouco orçamento, talvez seja melhor esperar e apenas
00:08:26lançar o produto para ver se as pessoas realmente o usam. E por falar em IA e segurança,
00:08:30se quiser saber como instalar o OpenWebUI com segurança em um VPS,
00:08:34confira o próximo vídeo onde mostro o passo a passo de como fazer isso.