Você precisa desta nova skill de segurança da Cloudflare

Autoria: Rob Shocks · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: You Need This New Security Skill from Cloudflare · Canal: Rob Shocks · 10:54 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Engenharia de software com IA

Resumo

Rob testa a nova skill de segurança open source da Cloudflare em um app de demonstração com seis vulnerabilidades intencionais e compara seus resultados com scanners gratuitos, a revisão de segurança integrada ao Cloud Code e um prompt simples. A skill da Cloudflare encontrou as seis falhas, mas levou mais tempo e pode gerar custos maiores em auditorias completas; o prompt simples encontrou cinco em um app pequeno. O teste mostra que scanners tradicionais e ferramentas de revisão com IA identificam tipos diferentes de problemas, por isso é importante combinar várias camadas de segurança. O vídeo recomenda três níveis de proteção, desde verificações básicas nesta semana até auditorias mais completas antes de lançar recursos críticos.

Pontos-chave

O app de teste, chamado Leak Cast, continha seis vulnerabilidades intencionais e um trecho de código seguro usado como isca para detectar falsos positivos.
GitLeaks encontrou uma chave secreta removida do código, mas ainda presente no histórico do Git; Trivy identificou uma versão vulnerável do Next.js.
Os scanners tradicionais não encontraram a injeção de SQL porque não analisam a lógica do código da mesma forma que um agent.
A revisão de segurança do Cloud Code encontrou quatro das seis falhas, mas analisa as mudanças recentes, a menos que se peça explicitamente uma auditoria mais ampla.
A skill da Cloudflare encontrou as seis falhas e tentou comprovar uma delas, mas uma execução completa pode exigir sandboxes e custar mais.
Um prompt simples encontrou cinco falhas em menos de um minuto, mas não examinou o histórico do Git para localizar a chave removida.
Nenhuma ferramenta sinalizou como vulnerabilidade o trecho seguro usado como isca; o teste também revelou uma senha de sessão codificada no código.
A recomendação é combinar scanners e revisão com IA, usando verificações mais rigorosas antes de lançamentos ou mudanças em autenticação e faturamento.

Capítulos

Início	Capítulo	Resumo
00:00	Por que a segurança de código com IA importa	O apresentador explica os riscos de segurança em apps escritos com IA e apresenta o teste com seis falhas intencionais.
02:35	Scanners e revisão de segurança integrada	GitLeaks e Trivy encontram problemas específicos, enquanto a revisão do Cloud Code detecta falhas de lógica, mas não cobre tudo.
04:40	Teste da skill da Cloudflare e de um prompt simples	A skill da Cloudflare encontra as seis falhas, e um prompt simples encontra cinco, com limitações diferentes de custo e escopo.
08:48	Três níveis de proteção recomendados	O apresentador propõe combinar verificações no histórico e nas dependências com revisões por PR e auditorias antes de lançamentos críticos.

Citações

Segurança é problema seu, é sua responsabilidade; não é da ferramenta, nem do agent. — 01:02

Se um hunter puder corrigir a própria prova, vai validar com confiança tudo o que produzir. — 04:40

Revise a base de código em busca de vulnerabilidades de segurança, indique o arquivo e o que um atacante consegue obter. — 06:45

Scanners e ferramentas de revisão com IA detectam coisas diferentes, e você precisa dos dois. — 08:17

Conceitos e entidades

Cloudflare (empresa): Empresa que lançou a skill de segurança open source testada no vídeo.
GitLeaks (ferramenta): Ferramenta que procura segredos, como chaves, no histórico do Git.
Trivy (ferramenta): Scanner que verifica dependências em busca de vulnerabilidades conhecidas.
Cloud Code (ferramenta): Ferramenta com uma revisão de segurança integrada que analisa mudanças no código.
Leak Cast (repo): App de demonstração criado para o teste, com vulnerabilidades intencionais.
Next.js (ferramenta): Framework usado no app de demonstração, cuja versão antiga foi sinalizada por uma vulnerabilidade conhecida.
Lovable (empresa): Plataforma mencionada em relação a apps que expunham dados por falta de regras de acesso ao banco de dados.
Opus 5.5 (modelo): Modelo que, segundo o apresentador, escreveu uma senha de sessão diretamente no código.
Dependabot (ferramenta): Ferramenta sugerida para monitorar vulnerabilidades em dependências.
Mozilla Observatory (ferramenta): Ferramenta citada para fazer verificações rápidas de cabeçalhos.

Tradução completa (pt-BR)

00:00 Então, a Cloudflare acabou de lançar uma nova skill de segurança open source, que eles usam na própria fábrica de software. E, para ser sincero, ela chegou na hora certa. Hackear ficou muito mais fácil agora com modelos de IA e engenharia reversa. Só nos últimos dias, tivemos algumas violações graves, e parece que isso só está acelerando. Então, o momento não poderia ser melhor para as skills de segurança da Cloudflare. Para testar, criei um app com seis falhas de segurança intencionais. Fiz isso basicamente para experimentar a nova skill open source da Cloudflare e, depois, compará-la com alguns scanners gratuitos, um prompt de revisão de segurança

00:31 que já vem no Cloud Code e um prompt simples, sem nenhuma skill. Sou Rob, da Suite Dimension, e, até o fim deste vídeo, você vai saber para que cada uma dessas opções serve. Também vou apresentar três níveis diferentes de segurança que você pode configurar para se proteger ainda esta semana. Então, por que tudo isso importa agora? Todos estamos usando agents de IA para programar, e eles são muito bons nas tarefas de manual. Peça ao Cloud Code um endpoint de busca, e ele vai validar alguns parâmetros numa consulta. Onde eles costumam falhar e ficar um pouco preguiçosos é na questão: de quem são esses dados, afinal? O agent vai verificar se você está conectado, mas vai se esquecer de verificar se o registro em questão pertence a

01:02 você: é uma segurança simples no nível da linha. No ano passado, um pesquisador encontrou mais de 170 apps criados com Lovable que estavam vazando dados, porque ninguém havia configurado as regras do banco de dados que definem quem pode ver quais linhas. Para ser justo com a Lovable nesse caso, eles dizem que cabe a cada cliente, proprietário dos apps, gerenciar a segurança, e isso é absolutamente verdade. A segurança é problema seu, sua responsabilidade; não é da ferramenta nem do agent. Então, antes de começar este teste, minha previsão era que os scanners tradicionais detectariam os bugs clássicos e que, para encontrar os bugs que a IA escreveria, seria preciso algo capaz de ler

01:33 seu código como um agent. E eu acertei mais ou menos. Criei este pequeno app chamado Leak Cast. Ele é pequeno, então não é um teste abrangente, mas é um clone deliberadamente vulnerável de outro app. Ele usa Next.js com um banco de dados e duas empresas, Acme e Globex. Cada uma tem seus próprios usuários e posts. Três dos bugs são clássicos: injeção de SQL na busca, uma chave secreta que commitei e depois apaguei e uma versão antiga do Next.js com um bug grave conhecido. E os outros três são do tipo que um agent de IA

02:05 escreveria. A Acme pode ler os posts da Globex, qualquer pessoa pode excluir qualquer post e a exportação despeja os dados de todas as empresas. Também incluí um código chamariz que parece perigoso, mas é seguro. Qualquer ferramenta que o sinalizar perde um ponto. Um dos problemas dos verificadores de código é que eles geram muitos falsos positivos, que podem consumir bastante tempo. Escrevi um exploit para cada bug e garanti que todos funcionassem. Depois, cada ferramenta recebeu seu próprio sandbox, para que não pudesse ver o que as outras estavam fazendo. Certo, a primeira rodada é com as ferramentas gratuitas. Então,

02:35 o GitLeaks examina todo o seu histórico do Git em busca de chaves que você commitou, inclusive as que talvez tenha apagado depois. Ele encontrou, em menos de um segundo, uma chave que eu tinha removido três commits antes. Lembre-se: apagar uma chave não a remove do histórico, e é assim que muitas chaves acabam vazando. O Trivy verifica todas as suas dependências, seus módulos do Node e assim por diante, em busca de vulnerabilidades conhecidas. Ele sinalizou imediatamente nossa versão antiga do Next.js, que permite contornar o middleware. Na verdade, sinalizou 42 itens, mas só estou contabilizando o que incluí de propósito. Tenha em mente que, se sua única verificação de autenticação estiver no

03:07 middleware, basta mais um cabeçalho para passar por ela. Veja. Dá para notar que o Trivy me informou que o pacote é vulnerável, mas não percebeu que minha página de administração depende apenas do middleware, que é metade do bug. É por isso que você precisa de um agent como scanner. Eu esperava que os scanners detectassem a injeção de SQL, mas nenhum dos dois detectou. O GitLeaks só procura segredos, e o Trivy só analisa uma lista de dependências; nenhum dos dois vai realmente ler seu código, o que é necessário. Então, os dois só encontraram dois dos seis problemas. Certo, na segunda rodada, vamos ver a revisão integrada do Cloud Code.

03:37 Seja usando CodeX, Cloud Code ou Cursor, todos têm uma dessas skills de revisão de segurança. Você digita {slash} security review, e ela verifica suas alterações. O detalhe é que ela analisa o que acabou de mudar. Então, para ser justo, dei a ela o app inteiro como se fosse uma única alteração, o que não é a forma como você normalmente usaria isso. Se você entrar em um app completo e executar security review, ela só vai verificar o diff mais recente. Não fará uma varredura completa de todo o aplicativo, a menos que você peça. A security review encontrou quatro dos seis problemas: a injeção de SQL, a

04:09 leitura entre empresas, a exclusão e a exportação. Levou cerca de 84 segundos e custou 16 centavos. Não detectou o desvio do middleware. Também não encontrou a chave, mas isso provavelmente foi culpa minha. Ela não chegou a ver o histórico do Git. Também ignora limitação de taxa por design, e a documentação diz que ela não é protegida contra prompt injection. Então, se você estiver executando isso em PRs open source ou PRs de outras pessoas, tome cuidado. Certo, agora vamos à skill de segurança da Cloudflare. Ela está ganhando bastante popularidade no GitHub. É bem simples: basta um comando para instalá-la e, depois, você pede ao seu agent uma auditoria de segurança completa.

04:40 Então, a configuração da Cloudflare é diferente em vários aspectos. Acho que o que realmente muda é o processo. Primeiro, ela mapeia o app e, depois, envia o que chama de hunter para cada tipo de ataque. E, se um agent encontrar um bug, ele nunca é o responsável por verificá-lo. Um agent separado faz isso. É uma boa medida. Já vimos isso antes: agents não são bons em avaliar o próprio trabalho. A Cloudflare colocou isso perfeitamente: se um hunter puder avaliar o próprio dever de casa, vai validar com confiança tudo o que produzir. Por isso, muitas vezes, chego ao ponto de usar um modelo completamente diferente

05:11 para verificar o trabalho de outro agent. Certo, ele carregou a skill, mapeou o app, descreveu cada fase e, depois, fez toda a busca por conta própria. No nosso pequeno teste, não iniciou nenhum hunter nem nenhum verificador. Para dar crédito a ele, marcou a própria execução como incompleta. Como nosso app era tão pequeno, não foi necessário fazer uma investigação completa. Não parei para testar isso em um app maior, mas a ideia é que ele distribua o trabalho entre vários agents. Não testei isso pessoalmente, então não me cobrem por essa afirmação. Então, mesmo nessa execução pequena, ele ainda identificou os seis

05:43 bugs. Foi a única ferramenta que testamos que encontrou todos, incluindo a chave no histórico do Git. Levou cerca de 5 minutos e custou 38 centavos, e chegou até a comprovar um dos bugs: a injeção de SQL em um banco de dados de teste. Para os outros cinco, o resultado foi “precisa de validação”. Isso não é uma falha da Cloudflare. Neste caso, ele simplesmente não executaria a verificação porque, para comprovar esses bugs, precisava de sandboxes isolados e dedicados. E eu não configurei isso para este teste. Vale lembrar que, em grande escala, isso vai custar dinheiro. Então, 38 centavos parece barato, mas é porque ele não foi executado

06:14 até o fim. Comprovar cada um desses bugs em sandboxes separados vai sair caro. E a própria Cloudflare diz que uma execução completa encontra apenas cerca de metade dos bugs. Então, normalmente, é preciso executar várias vezes para fazer uma análise minuciosa. E isso vai aumentar o custo. Você vai precisar avaliar com que frequência quer executar isso. Vai levar tempo e custar dinheiro. Talvez não seja algo para executar em cada pull request. Há mais um aspecto deste teste. Eu queria ter um controle: basicamente, o mesmo modelo, com todas as skills desativadas, usando apenas uma frase. Porque essas

06:45 Os modelos estão ficando muito bons agora. Eles precisam de toda essa ajuda? Então, revise a base de código em busca de vulnerabilidades de segurança, indique o nome do arquivo e o que um invasor conseguiria. Se você for guardar uma coisa deste vídeo, lembre-se deste prompt. E, enquanto pausa o vídeo para anotá-lo, aproveite para clicar em curtir e se inscrever no canal. Isso ajuda muito o canal. Essa execução levou cerca de 34 segundos, custou menos de um centavo e encontrou cinco dos seis bugs. Para ser justo, só deixou passar a chave do Git porque não examinou o histórico do Git, algo que talvez não seja óbvio. E também disse que o chamariz era

07:15 seguro. Agora, antes de tirar uma captura de tela, este é um aplicativo minúsculo que o modelo consegue ler de uma vez só, e três dos bugs são praticamente o mesmo erro. Quando se trata de aplicativos maiores, algo como as skills da Cloudflare ou uma série de agents que se distribuem e trabalham em paralelo vai ser indispensável. O que eu não esperava era que as três ferramentas sinalizassem um bug que eu não pretendia inserir. A senha da sessão está embutida no código-fonte, e o agent de IA que usei para ajudar a criar o aplicativo a escreveu desse jeito. Com isso, qualquer pessoa com o código pode falsificar o login de

07:47 administrador, e o Git Leaks não percebeu. É só um lembrete de quanto precisamos de várias verificações e camadas de segurança nos nossos sistemas. Vale a pena conferir meu vídeo anterior sobre a abordagem da Anthropic para revisão e revisão de segurança. Você encontra esse vídeo no canal principal. Então, esse é o tipo de bobagem que um agent faz. O agent acertou as partes de livro-texto e, mesmo assim, foi lá e deixou embutida a senha que protege todas as sessões. E esse era o Opus 5.5. Certo. Então, aqui está o quadro completo. Ele mostra o que cada ferramenta encontrou e comprovou, com o tempo e o custo na parte de baixo.

08:17 Então, como esperado, os scanners detectaram o que está fora do seu código: o histórico do Git e a lista de dependências. Todas as ferramentas de IA detectaram os bugs de lógica. E a única ferramenta que tentou comprovar alguma coisa foi a da Cloudflare, porque foi criada para isso. Mesmo tendo pulado os verificadores. E ninguém sinalizou o chamariz como um problema. Mas, para ser justo, era um chamariz fácil. Não tive tempo de criar algo mais complicado. Então, lembre-se: em todos os casos, foi apenas uma execução com um modelo pequeno. E o principal que você precisa entender é que scanners e ferramentas de revisão com IA detectam coisas diferentes, e você precisa dos dois. Agora, nenhuma dessas ferramentas realmente atacou o

08:48 aplicativo em execução. Eu mesmo fiz isso com meus próprios scripts de exploração, e foi assim que descobri as respostas. Ferramentas que atacam seu aplicativo são uma categoria totalmente diferente. Se quiser ver um vídeo sobre isso, deixe um comentário. Então, o que você deve fazer? Aqui estão três níveis. O nível um é bem simples. O que você deve fazer é executar o Git Leaks em todo o histórico do seu repositório, só para verificar se há alguma chave que não deveria estar lá. Depois, peça ao seu agent para configurar um hook para que o Git Leaks seja executado em cada pre-commit. Isso significa que qualquer código novo enviado será verificado. Em seguida, use algo como Dependabot ou

09:19 Trivy em todas as suas dependências. Dependências e módulos podem apresentar algum tipo de vulnerabilidade a qualquer momento, e você quer fazer verificações para garantir que isso não afete seu aplicativo. Depois, antes de lançar, basta pedir ao seu agent, com aquela frase simples, que revise as alterações ou use esta skill de revisão de segurança para verificar todas as mudanças que você fez antes de elas serem lançadas. Se você perceber que seu agent comete repetidamente o mesmo tipo de erro de segurança, inclua uma regra no arquivo agent.md ou Claude.md. Talvez uma regra que diga ao agent para sempre restringir cada consulta à organização. O nível dois é para

09:51 cada pull request. É para isso que serve /security review, porque revisar alterações é basicamente a função dessa ferramenta. Então, você poderia executar a revisão de segurança da Claude em cada PR confiável, depois GitLeaks e Trivy na sua integração contínua, talvez com GitHub Actions, e, em seguida, verificações rápidas de cabeçalhos com algo como Mozilla Observatory. O nível três é antes de lançar algo ou sempre que você mexer em algo crítico, como autenticação ou cobrança. Então, você poderia executar a skill da Cloudflare em um ambiente isolado onde ela consiga executar seu código. Depois, é importante verificar a execução para garantir que os verificadores realmente rodaram, se o aplicativo for grande o bastante

10:22 E, de acordo com a Cloudflare, você deve fazer isso algumas vezes para garantir que encontrou tudo. Depois, você poderia direcionar um testador de invasão com IA para seu servidor de staging, não para o servidor de produção. Se quiser ser minucioso e acertar tudo, pague um profissional para fazer isso por você. Um profissional vai trazer uma visão abrangente que um agent não consegue oferecer. Então, para a maioria de nós, sinceramente: nível um nesta semana, nível dois neste mês e nível três antes de começar a receber pagamentos no seu aplicativo. Se você quer criar aplicativos como este corretamente com IA, é isso que fazemos no Switch Dimension Agent Accelerator.

10:54 O link está na descrição, logo abaixo. Adoraria saber nos comentários: qual foi o pior bug de segurança que você encontrou em código escrito por IA? E eu leio todos os comentários. E, se isto ajudou, inscreva-se no canal. Se quiser ver como a Anthropic lida com a revisão quando o Claude Code escreve 90% do código, assista a este vídeo a seguir.

Transcrição original

[00:00] So, Cloudflare just launched a new open-source security skill and they use it on their own software factory. And to be honest, it’s just in time. Hacking has become so much easier now with AI models and reverse engineering. In the last couple of days alone, we’ve had some serious breaches and it feels like it’s just speeding up. So, the timing couldn’t be any better for Cloudflare’s security skills. So, I built an app with six security holes in it on purpose. So, I did this basically to test out Cloudflare’s new open-source skill and then I put it up against some free scanners, a security review prompt

[00:31] that’s already inside Cloud Code, and then a plain prompt with no skill at all. I’m Rob from Suite Dimension and by the end of this, you’ll know what each of these is good for and I’ll give you three different levels of security you can set up to protect yourself this week. So, why does all this matter now? We’re all using AI agents to code and they are pretty good at the textbook stuff. Ask Cloud Code for a search endpoint and it’s going to troll some parameters on a query. Where they tend to fall down and get a little bit lazy is the question of whose data is this actually. The agent will check that you’re logged in, but will forget to check that the actual record belongs to

[01:02] you, simple row-level security. So, last year a researcher found more than 170 apps built with Lovable that were all leaking data because nobody had set up the database rules that say who can see which rows. To be fair to Lovable in that scenario, they say it’s down to each customer who owns their apps to manage the security and that is absolutely true. Security is your problem, your responsibility, it’s not the tool, it’s not the agent. So, going into this test, my prediction would be that the traditional scanners would catch the classic bugs and then you’d need something that was able to read

[01:33] your code like an agent to pick out the bugs that the AI would write. And I was kind of half right. So, I built this little app called Leak Cast. It’s small, so it’s not an extensive test, but it’s a deliberately broken clone of another app. It’s using Next.js with a database and two companies in there, Acme and Globex. Each one of these has their own users and posts. So, three of the bugs are classics, SQL injection in the search, a secret key I committed and then deleted, and then an old Next.js version with a nasty known bug. And then three are the kind an AI agent would

[02:05] write. So, Acme can read Globex’s posts, anyone can delete any post, and the export dumps every company’s data. And then I also put in one decoy code that looks dangerous, but it’s actually safe. And any tool that flags it loses a point. A lot of the problems with these code checkers is they raise a lot of false positives that can be actually quite time-consuming. I made sure to write an exploit for every bug and that everyone worked. And then each tool got its own sandbox, so it couldn’t see what anyone else was doing. Okay, so round one is the free stuff. So,

[02:35] GitLeaks looks through your whole Git history for keys you’ve committed, even ones that you might delete later. So, it successfully found a key I’d removed three commits ago in under a second. Remember that deleting a key doesn’t take it out of your history, and that’s how a lot of keys are leaked. So, Trivy will check all your dependencies, your node modules, etc. against known vulnerabilities. So, it instantly flags our old Next.js version, which has a middleware bypass. It actually flagged 42 things here, but I’m only scoring it on the one I planted. Now, bear in mind, if your only authentication check is

[03:07] middleware, one extra header will get you past it. Watch. You notice here Trivy told me the package is bad, but it didn’t tell me my admin page depends on middleware alone, which is half the bug. This is why you would need an agent as a scanner. I expected the scanners to catch the SQL injection, and neither of them did. GitLeaks is only looking for secrets, and Trivy only looks at a dependency list, but neither of them is going to actually read your code, which is needed. So, both of these only grabbed two of the six issues. Okay, so round two, let’s look at Cloud Code’s

[03:37] built-in review. So, whether using CodeX, Cloud Code, Cursor, they all have one of these security review skills. You type {slash} security review, and it checks your changes. Now, the catch here is it reviews what has just changed. So, to be fair, I gave it the whole app as one change, which isn’t how you’d normally use it. If you step into a full-blown app and run security review, it’s only going to check the latest diff. It won’t actually do a full scan of the whole application, unless you ask it to. So, security review got four of the six, the SQL injection, the

[04:09] cross-company read, the delete, and the export. Took about 84 seconds and 16 cents. It missed the middleware bypass. It also missed the key, but that’s probably my fault. It didn’t actually see the Git history. It also skips rate limiting by design, and the docs say that it’s not hardened against prompt injection. So, if you’re running this on open-source PRs or other people’s PRs, just be careful. Okay, so then Cloudflare’s security skill. So, this one is getting lots of traction on GitHub. It’s pretty simple. It’s just one command to install, and then you ask your agent for a full security audit.

[04:40] So, this Cloudflare setup is different in many ways. What’s really different, I guess, is its process. So, first thing it does is it goes and maps the app, and then it sends what it calls a hunter against each kind of attack. And then, if an agent does find a bug, it’s never the one that actually checks it. A separate agent will do that. And this is a pretty good step. We’ve seen this before. Agents are not good at grading their own work. Cloudflare has put it perfectly here. If a hunter is allowed to grade its own homework, it will confidently validate everything it outputs. This is why I’ll often go as far to use a completely different model

[05:11] when checking another agent’s work. Okay, so it loaded the skill, it went and it mapped the app, and then it wrote out every phase, and then it did all the hunting itself. In our small test, it started zero hunters against zero verifiers. To its credit, it marked its own run as incomplete. Because our app was so small here, it didn’t require a full investigation. I didn’t take the time to do this on a larger app, but the idea here is that it will fan out multiple agents. Haven’t tested it personally, so don’t hold me on that one. So, even though we just had a small run here, it still named all the six

[05:43] bugs. It’s the only tool we tested here that got all of them, including the key in the Git history. Took about 5 minutes and 38 cents, and it even went and proved one of the bugs, the SQL injection on a dummy database. The other five came back then with needs validation. So, that’s not a miss on Cloudflare’s part. In this case, it just wouldn’t run because in order to prove those bugs, it needed dedicated lockdown sandboxes. And for this test, I haven’t set that up. Now, it’s worth bearing in mind, at scale, this scale is going to cost you money. So, 38 cents sounds cheap, but that’s because it didn’t run

[06:14] to its full extent. Proving out each one of these bugs in separate sandboxes will add up. And then Cloudflare themselves say a full run only finds about half of the bugs. So, usually it needs to be run several times in order to be thorough. And that’s going to add up in terms of cost. So, you’ll need to weigh up how often you want to run this. It’s going to take time, and it’s going to cost you. It’s not something you might run on every single pull request. So, there’s one more side to this test. I wanted a control, basically just the same model and all the skills turned off, and basically one sentence. Because these

[06:45] models are getting really good now. Do they need all this help? So, review the code base for security vulnerabilities, name the file, and what an attacker gets. If you’re going to take one thing from this video, just remember this one prompt. And while you’re pausing it to remember it, just hit the like and subscribe button there. It’s a big help to the channel. So, this run took about 34 seconds, it cost under a cent, and it found five out of the six bugs. In fairness, it only missed the Git key because it never looked at the Git history, something that might not be obvious. And it also called the decoy

[07:15] safe. Now, before you screenshot that, this is a tiny app the model can read in one go, and three of the bugs are pretty much the same mistake. When it comes to larger applications, having something like a Cloudflare skills or a series of agents that fan out and work in parallel is going to be a must. What I didn’t expect was all three tools flagged a bug that I didn’t intend to plant. Their session password is hardcoded in in source, and the AI agent I used to help build this wrote it in that way. With that, anyone with the code can forge the

[07:47] admin login and Git Leaks missed it. It’s just a reminder of how much we need multiple security checks and layers in our systems. It’s actually worth checking out my last video on Anthropic’s approach to review and security review. You find that on the main channel. So, this is kind of the silly stuff an agent will do. The agent got the textbook parts right and it still went and hardcoded the password that protects every session. And this was Opus 5.5. So, okay. So, here’s the full board. It shows found and proved for each tool with time and cost along

[08:17] the bottom. So, as expected, the scanners caught what sits outside your code, your Git history, and your dependency list. Every AI tool caught the logic bugs. And the only tool that attempted to prove anything was Cloudflare because it’s built to do that. Even though it did skip the verifiers. And the decoy, nobody flagged it as an issue. But in fairness, it was an easy decoy. Didn’t have time to write something more complicated. So, remember in all cases, it was just one run on one small model. And the key thing you need to understand is scanners and then AI review tools catch different things and you need to have both. Now, none of these tools actually attacked the

[08:48] running app. I did that myself with my own exploit scripts, which is how I know the answers. Tools that attack your app are a whole different category. If you want to see a video on that, let me know in the comments. So, what should you do? Here are three levels. So, level one is pretty simple. What you want to do is run Git Leaks on your whole history of your repository. Just to check if there’s any keys in there that shouldn’t be there. And then ask your agent to set up a hook so that Git Leaks is run on every pre-commit. So, that means any new code going up is going to get scanned. Then put something like Dependabot or

[09:19] Trivy on all your dependencies. Dependencies and modules at any given point have some kind of a vulnerability appear and you want to be scanning to make sure that it’s not going to affect your app. Then before you ship, just ask your agent that one plain sentence to review or use these security review skill to check all the changes you’ve made before they go live. If you’re seeing that your agent repeatedly makes the same kind of security mistakes, then you bake that into your agent.md or Claude.md file. Maybe a rule that tells the agent to always scope every query to the organization. So, level two is for

[09:51] every pull request. That’s where /security review belongs because reviewing changes is basically what it’s for. So, you could run Claude’s security review on every trusted PR, then GitLeaks and Trivy in your continuous integration, maybe with GitHub Actions, and then quick header checks with something like Mozilla Observatory. Level three then is before you launch something or whenever you touch something that’s critical like auth or billing. So, you might run Cloudflare skill in a sandbox where it can run your code. And then you want to check it’s run to make sure that the verifiers actually did run if it’s a big enough

[10:22] app. And according to Cloudflare, you want to do this a couple of times to make sure that you’ve caught everything. Then you might point an AI pen tester at your staging server, not your production server. If you want to be thorough and get this absolutely right, pay a professional human to do this for you. A professional human will bring a big picture approach here that an agent can’t offer you. So, for most of us, honestly, level one this week, level two this month, and then level three before you’re starting to take payments in your app. If you want to build apps like this properly with AI, that’s what we do in the Switch Dimension Agent Accelerator.

[10:54] The link is in the description down below. I’d love to know in the comments, what is the worst security bug you found in AI-written code? And I do read all the comments. And if this helped, please subscribe. If you want to see how Anthropic handle review when Claude code writes 90% of the code, watch this one next.