Hackers de IA são mais rápidos que seu teste de invasão — Eli Cohen, Snyk

Autoria: AI Engineer · 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: AI Hackers Are Faster Than Your Pen Test — Eli Cohen, Snyk · Canal: AI Engineer · 19:03 · Assistir no YouTube

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

Resumo

Eli Cohen explica como a geração acelerada de código por agentes de IA aumenta o volume de vulnerabilidades e dificulta a correção no ritmo necessário. Ele compara análise estática, testes dinâmicos e testes de invasão tradicionais, destacando os limites de cada abordagem diante de ataques contínuos e falhas de lógica de negócio. Em seguida, apresenta a proposta de segurança ofensiva contínua com IA: combinar agentes especializados para reconhecimento, testes, validação de exploração, remediação e relatórios. Para avaliar soluções, recomenda verificar se elas testam continuamente, compreendem o contexto da aplicação, aproveitam dados de outras ferramentas e comprovam que as falhas são exploráveis.

Pontos-chave

A produção acelerada de código com agentes de IA pode aumentar o acúmulo de vulnerabilidades que as equipes precisam corrigir.
Atacantes também usam LLMs e podem combinar vulnerabilidades de baixa gravidade para formar ataques mais sérios.
A análise estática encontra certas falhas no código, mas não identifica problemas que dependem do comportamento em execução, como falhas de autorização.
Testes de invasão tradicionais ajudam a encontrar falhas de lógica de negócio, mas costumam ser caros e esporádicos.
A segurança ofensiva contínua busca testar a aplicação a cada alteração de código, em vez de apenas algumas vezes por ano.
O sistema descrito coordena agentes de reconhecimento, testes de vulnerabilidade, validação de exploração, remediação e geração de relatórios.
A qualidade dos resultados depende do contexto fornecido aos LLMs, incluindo dados de outros scanners e ambientes.
Uma solução isolada não é suficiente: diferentes abordagens são mais eficazes para diferentes classes de vulnerabilidade.
Ao comparar soluções, é importante verificar a continuidade dos testes, a compreensão do contexto e a validação de que uma falha é realmente explorável.

Capítulos

Início	Capítulo	Resumo
00:12	Aumento do código gerado e dos riscos	Cohen apresenta seu trabalho e descreve como o uso de agentes de IA aumenta a produção de código e o volume de vulnerabilidades.
05:06	Limites das abordagens tradicionais	A palestra compara análise estática, testes dinâmicos e testes de invasão, destacando o custo e a baixa frequência dos testes tradicionais.
09:17	Segurança ofensiva contínua com IA	Cohen apresenta o conceito de testes de invasão contínuos e explica como o contexto da aplicação e a validação de falhas podem melhorar os resultados.
14:40	Contexto e combinação de ferramentas	O palestrante defende enriquecer os testes com dados de outros scanners e combinar abordagens conforme a classe de vulnerabilidade.
17:26	Como avaliar uma solução	Cohen propõe quatro perguntas sobre continuidade, contexto, enriquecimento de dados e comprovação de que as falhas são exploráveis.

Citações

O que deveríamos fazer para ajudar a melhorar nossa postura de segurança? — 05:06

A grande promessa dos testes de invasão sempre foi o fato de que a pessoa entende muito bem o contexto de negócio. — 10:52

Contexto é tudo. Seus LLMs são tão bons quanto o contexto que você fornece a eles. — 14:40

Eles realmente raciocinam sobre o contexto da aplicação? — 17:26

Conceitos e entidades

Eli Cohen (pessoa): Palestrante da Snyk que aborda segurança de aplicações e segurança ofensiva contínua com IA.
Snyk (empresa): Empresa de segurança mencionada pelo palestrante, que apresenta sua oferta de segurança com IA.
EVO (ferramenta): Oferta de segurança da Snyk apresentada como uma solução de segurança ofensiva contínua.
LLM (conceito): Modelo de linguagem usado, segundo a palestra, para compreender o contexto da aplicação e apoiar testes de segurança.
AI pentesting (conceito): Uso de IA para realizar testes de invasão de forma contínua e em escala.
Static Application Security Testing (conceito): Análise estática do código para procurar classes de vulnerabilidades sem executar a aplicação.
Dynamic Application Security Testing (conceito): Teste dinâmico que interage com a aplicação em execução para identificar vulnerabilidades.
red teaming (conceito): Abordagem que simula ataques, inclusive em várias etapas, para avaliar a segurança de sistemas.
exploit validation (conceito): Validação destinada a determinar se uma vulnerabilidade encontrada é real e pode ser explorada.

Tradução completa (pt-BR)

00:12 Ótimo. Oi, pessoal. Hoje vamos falar sobre segurança ofensiva contínua. Certo. Vou começar em breve. O que isso significa? Mas, antes disso, um pouco sobre mim. Estou muito feliz por estar aqui hoje. Sou Eli. Fui cofundador e CEO da Helios, uma empresa de segurança em tempo de execução. A empresa foi adquirida pela Snyk e, nos últimos dois anos e meio, tive o privilégio de trabalhar na Snyk, principalmente com gerenciamento de produtos de IA. Mais recentemente, fundei a função de CTO de campo, o que significa que trabalho com desenvolvedores e profissionais de segurança

00:43 para entender melhor e ajudá-los a definir sua estratégia de segurança de IA. Como proteger seus agentes de IA? Como trabalhar com seus agentes em produção? Ali atrás, você pode configurar o cronômetro para mim, por favor? O cronômetro, para eu saber quanto tempo tenho. Ótimo. Certo, agora também temos o cronômetro. Ótimo. Para eu conhecer vocês um pouco melhor: levantem a mão, por favor. Quem está mais do lado de desenvolvimento

01:16 da mesa? Desenvolvedores. Certo, ótimo. E quem está do lado de segurança? Sim, já conheço vocês. Ótimo. E outras pessoas, como vendas, marketing ou pessoas que operam agentes em produção e não são de desenvolvimento nem de segurança. Ótimo. Certo. Então temos todo mundo aqui. Vou adaptar esta sessão para todos. Obviamente, esta é uma conferência de engenharia de IA, certo? Então já sabemos que a quantidade de código gerada hoje é muito maior do que costumava ser. Certo. De acordo com nossos dados,

01:51 são 218% mais linhas de código por desenvolvedor do que antes. Certo. E mais de 85% dos desenvolvedores já estão usando agentes de programação — provavelmente vocês aqui hoje. Na verdade, deve ser mais de 100%, porque imagino que cada um de vocês tenha cinco sessões diferentes do Claude Code rodando simultaneamente. Senão, vocês não estariam aqui hoje. E o mais curioso sobre esses agentes que estão rodando em produção e gerando código para nós é que ele é muito menos seguro do que estamos acostumados. Certo, então

02:25 62% do conteúdo gerado por LLMs não é seguro ou está quebrado. Certo, imaginem só esses dados combinados. Isso significa que estamos gerando mais código do que nunca, e esse código inseguro está chegando à produção. Portanto, esse é um grande desafio para nós como comunidade, e o que isso realmente significa é que nosso backlog de problemas de segurança está ficando mais longo, maior e muito mais

02:55 difícil de corrigir. Certo. Estamos criando muitos outros problemas num ritmo que simplesmente não conseguimos corrigir nem mitigar. E não é só isso: a IA também está ajudando nossos atacantes. Eles conseguem encadear vulnerabilidades de baixa gravidade para formar vulnerabilidades críticas. O que está acontecendo é que nossos atacantes estão aproveitando esses LLMs e nos atacando, especialmente onde

03:29 é muito difícil usar o contexto da aplicação. É justamente nessa área que nossos LLMs têm mais dificuldade, porque estão criando muito mais vulnerabilidades nesses pontos. Então, obviamente, estamos aproveitando a IA, mas nossos atacantes também estão usando modelos de ponta. Certo. E os números são simplesmente incríveis. Estamos familiarizados com um modelo de IA que conseguiu identificar mais de 600 vulnerabilidades para violar 600 firewalls em mais de

04:01 55 países. Certo, é simplesmente inacreditável. E o tempo necessário para um ataque de IA ser bem-sucedido está diminuindo cada vez mais. Certo, o tempo médio para um ataque de IA ser bem-sucedido é de 24 a 34 minutos. Certo, e o menor tempo é de 4 minutos. Isso significa que, desde que comecei a falar, provavelmente já houve um ataque de IA capaz de

04:32 invadir com sucesso um sistema de produção. E 43% de todos os servidores MCP têm vulnerabilidades. Certo, juntando todos esses dados, percebemos que estamos produzindo muito mais código do que nunca. Cada um de nós tem algumas sessões do Claude Code e do Codex rodando simultaneamente. Esse código é inseguro e está chegando à produção. E as pessoas que enfrentamos, os atacantes, estão aproveitando as mesmas ferramentas e agindo mais rápido do que nunca para

05:06 aproveitar essas vulnerabilidades. Nosso backlog está simplesmente se acumulando, e não conseguimos dar conta dele. É exatamente sobre isso que quero falar hoje: o que devemos fazer para melhorar nossa postura de segurança. Isso está muito ligado a como podemos aproveitar a segurança ofensiva, não só para os atacantes, mas também para nós, defensores. Então, por que a segurança tradicional não consegue acompanhar? Hoje temos um público misto

05:38 com pessoas tanto do lado de desenvolvimento quanto do lado de segurança. Quero começar abordando alguns conceitos básicos para garantir que todos estejam familiarizados com eles. O que costumava ser muito simples de operar era a análise estática de código, ou SAST. Imaginem que vocês estão enviando código novo para produção. Um scanner estático analisa esse código e procura por injeção de SQL e cross-site scripting. Costumava ser relativamente barato e fácil executar esse processo em cada alteração de código. E isso é ótimo. Mas o que

06:09 ele não detecta são os problemas que surgem em tempo de execução. Certo, se houver problemas de autorização ou de configuração, vocês vão precisar de testes dinâmicos de segurança de aplicações. Ou seja, precisam de algo que teste a aplicação dinamicamente. Um exemplo é BOLA, a falha de autorização em nível de objeto, que basicamente significa que o usuário A pode acessar os dados do usuário B. Esse tipo de vulnerabilidade nunca pode ser encontrado com análise estática. Para isso, é preciso sondar a

06:43 aplicação em tempo de execução. O que um scanner DAST faz é pegar um conjunto predefinido de muitos payloads e enviá-los à aplicação, para diferentes endpoints de API; assim, consegue encontrar vulnerabilidades. Isso também permitia encontrar coisas novas, mas não era bom para o maior desafio que temos com o código produzido por LLMs: a lógica de negócios. Para isso, o que temos usado como

07:14 indústria é o teste de intrusão. Certo. Qual é a ideia por trás do teste de intrusão? Um profissional humano que entende de verdade o conceito e a lógica de negócios da aplicação tenta quebrá-la e encontrar todas as vulnerabilidades. Hoje, esse é o padrão ouro em testes de segurança de aplicações, mas tem alguns desafios, certo? Primeiro, custa muito dinheiro, porque é preciso ter um pesquisador de segurança, uma pessoa — não uma pessoa no

07:44 processo —, alguém que realmente faça os testes e tente quebrar a aplicação. E isso custa muito dinheiro. O segundo problema é que, como custa muito e o processo era tão lento, as empresas só conseguem fazer isso uma vez por ano, duas vezes por ano, talvez três vezes por ano. Certo? Considerando que hoje nossos atacantes de IA tentam nos atacar continuamente, fazer esse teste de intrusão duas vezes por ano simplesmente

08:15 não é suficiente. Certo. O que vocês vão fazer nos outros 350 dias do ano, quando ninguém testou a aplicação? E não é só isso: os resultados que vocês recebiam eram um relatório em PDF todo elaborado e cheio de pompa, que precisavam enviar aos desenvolvedores para que eles analisassem o que era real e o que não era, começassem a corrigir os problemas e, depois, vocês tivessem de testar tudo novamente. Certo, parece um filme dos anos 90. Não faz mais sentido fazer isso. Mas esse era o padrão ouro. Era isso que estávamos

08:46 fazendo. A questão é que esse é o melhor método disponível para testar a lógica de negócios da aplicação. Certo. O que muda agora? Hoje temos uma nova tecnologia, e é exatamente sobre isso que quero falar: como aproveitar essa nova geração de ferramentas de IA, LLMs e modelos de ponta para realizar testes de intrusão de forma contínua e escalável.

09:17 E é por isso que estamos apresentando o EVO, segurança ofensiva contínua. Certo, isso está obviamente muito ligado ao que fazemos na Snyk, mas o que vou contar a vocês hoje é geral. Certo, vocês podem aplicar os princípios do que estou contando e verificar isso com qualquer fornecedor presente na feira. Certo, quero que pensem no seguinte. O que vocês precisam fazer hoje é preparar o sistema de produção para as incógnitas desconhecidas. Certo, e para isso vocês precisam de um

09:49 novo paradigma. Certo. Antes de tudo, obviamente vocês precisam dos recursos de pentest com IA, sobre os quais vou me aprofundar daqui a pouco. Mas também precisam começar a adotar o conceito de red teaming. Certo. A ideia do red teaming de agents é realizar ataques em várias etapas. Certo. É tentar simular prompt injection, exfiltração de dados e sequestro de objetivos, e obviamente combinar isso com testes dinâmicos, que são bons para identificar problemas de autorização. Então, estamos reunindo todos esses recursos. Estamos criando uma suíte com tudo isso para

10:21 segurança ofensiva como parte da nossa oferta EVO. A ideia é ajudar vocês a mitigar ou lidar com o fato de que os atacantes estão usando as mesmas ferramentas que nós usamos, e estão fazendo isso continuamente, 24 horas por dia, 7 dias por semana, encontrando vulnerabilidades mais rápido do que antes. E o backlog de vocês simplesmente não consegue acompanhar. Então, o que estamos fazendo de diferente no pentest com IA? Certo. Eu disse antes que a grande

10:52 promessa do pentest sempre foi o fato de que os humanos, no fim das contas, entendem muito bem o contexto de negócios. Certo. Agora estamos levando isso para o LLM e, se há algo em que os LLMs são muito bons, é justamente tentar entender o contexto de negócios. Então, nos bastidores, usamos LLMs e fazemos isso continuamente. Certo? Vocês não vão mais fazer coisas como pentest duas ou três vezes por ano. Vamos fazer isso a cada mudança no código. Certo? A cada PR que vocês enviarem, a cada alteração, vamos

11:25 executar esse pentest para vocês e dizer aos desenvolvedores o que precisam corrigir e como devem fazer isso de outra forma. Obviamente, usamos nosso entendimento do contexto da aplicação, mas também ajudamos a reduzir os falsos positivos. Como setor, temos um problema sério de falsos positivos. Então, mostramos que as vulnerabilidades que encontramos são realmente exploráveis, em vez de simplesmente sinalizá-las como bugs. Ajudamos vocês a provar que elas são exploráveis e coletamos contexto de muitas máquinas diferentes

11:58 e de muitos ambientes diferentes, combinando tudo isso para orientar nossos LLMs. Certo, é isso que fazemos de diferente, e acho que é isso que torna essa solução tão única e tão bem posicionada diante do fato de que cada um de nós tem alguns agentes de programação rodando em produção e enviando mais código do que nunca. Então, como fazemos isso? Como funciona nos bastidores? Certo, quero que entendam que não pegamos scanners estáticos ou scanners DAST e simplesmente os combinamos com um LLM.

12:32 Certo, nós construímos tudo do zero usando LLM. Temos uma série de alguns agents trabalhando juntos. O primeiro é o orquestrador de LLM. Certo, imaginem-no como o cérebro. Esse agent trabalha de acordo com um plano dinâmico que segue e sabe como operar todos os diferentes subagents. O primeiro agent — na verdade, o segundo — é o de reconhecimento. Certo, vocês podem imaginá-lo como uma unidade de inteligência de elite. A ideia é coletar todos os dados possíveis sobre

13:05 os diferentes endpoints de rede, as diferentes APIs, as diferentes impressões digitais, reunir todos esses dados, formalizar uma arquitetura com base neles e entregá-la ao próximo agent. E o próximo agent é o de testes de vulnerabilidade. Na verdade, é mais uma série de alguns agents especializados. Alguns têm como alvo classes de vulnerabilidades conhecidas. Outros caçam vulnerabilidades no ambiente real e tentam quebrar a aplicação para entender o contexto de negócios e descobrir de onde

13:36 um atacante pode partir. Depois, eles encaminham os resultados ao juiz — como gosto de chamá-lo —, o agent de validação de exploits. Assim, cada vulnerabilidade encontrada pelo agent anterior é encaminhada a esse juiz, cujo objetivo é nos dizer se é uma vulnerabilidade real ou não, e se pode ser explorada ou não. Isso é justamente porque queremos reduzir a carga cognitiva. É justamente porque queremos reduzir a quantidade de falsos positivos

14:08 que temos no sistema. Em seguida, vem o agent de correção, porque queremos que tudo o que fazemos seja acionável. Certo, não queremos relatar uma vulnerabilidade e deixar os desenvolvedores sem saber o que fazer a respeito. Depois dele, vem o agent de relatórios, porque tudo precisa ser relatado. Então, o que nos diferencia — e estes são os pontos que recomendo que vocês verifiquem com qualquer fornecedor que esteja tentando oferecer essa solução, ou caso queiram

14:40 implementar internamente uma solução de pentest com IA — é o seguinte: este é um setor enorme agora. Acho que o mais importante a lembrar, e vocês já sabem disso, especialmente os desenvolvedores na sala, é que o contexto é tudo. Seus LLMs são tão bons quanto o contexto que vocês fornecem a eles. O que estamos tentando fazer não é oferecer nossa solução de pentest com IA como algo independente. Na verdade, alimentamos a solução com dados de todos os scanners anteriores. Certo, o scanner estático de código, o scanner dinâmico de código,

15:15 todos os diferentes mecanismos de agents são combinados e usados para alimentar nossa solução de pentest com IA, porque assim sabemos como personalizar e orientar o LLM sobre onde procurar. E, como vocês também sabem, com Mythos ou Frame, quando esses modelos sabem onde procurar, os resultados são significativamente melhores. Essa é uma das coisas que fazemos de forma muito única e diferenciada. E também quero que se lembrem de que uma solução não basta.

15:51 Certo. O ótimo é que, quando combinamos essas coisas e nos baseamos nos dados que vemos tanto nos laboratórios quanto nos dados reais dos clientes, combinar os dados é realmente o que importa, e não dá para usar apenas uma delas. Certo. Há certas classes de vulnerabilidades para as quais o DAST é o melhor scanner. Certo? Porque ele tem um conjunto de cargas úteis realmente abrangente que

16:23 vocês podem enviar para a aplicação. Por exemplo, ele é muito bom para cross-site scripting. Certo. Para cross-site scripting, o DAST é a melhor solução. Mas, se vocês querem encontrar problemas de lógica de negócios, devem combiná-lo com pentest, porque essa será a melhor solução. Então, o que realmente quero que vocês levem daqui, se há uma coisa que quero que levem daqui, é a percepção de que o mundo está mudando. Vocês já sabem disso. Foi por isso que vieram. Mas

16:53 antes testávamos nossas aplicações uma vez a cada poucos meses, porque as mudanças e o ritmo delas eram muito lentos, e havia pessoas no fim do processo analisando a aplicação e as mudanças. Mas esse mundo já não existe. Certo? Agora estamos enviando código para produção 24 horas por dia, 7 dias por semana, e temos LLMs tentando raciocinar sobre o contexto da aplicação e tentando quebrá-la continuamente. Alguns conseguem fazer isso em apenas quatro minutos. Certo,

17:26 isso é quase cinco vezes o tempo da palestra, da sessão que acabei de fazer. Então, quando forem procurar novas soluções para esse problema, precisam se fazer quatro perguntas. Certo. Primeiro: executamos essa solução continuamente ou é apenas uma solução pontual, que usamos de vez em quando? Certo, essa é uma diferença importante. Segundo: eles realmente raciocinam sobre o contexto da aplicação? Certo, porque, dada a natureza desses LLMs, é no contexto da aplicação que estão as novas vulnerabilidades

17:59 de onde vêm. E, em terceiro lugar, quanto mais contexto eles conseguem processar? Certo, como podem enriquecer os dados? Porque, quanto mais ricos forem os dados, melhor e, aliás, mais barata será a operação do LLM. E a quarta parte é: eles realmente me ajudam a provar que há um bug e a garantir que ele é explorável, ou simplesmente o sinalizam como um bug? Certo, então nosso objetivo não é apenas

18:30 ajudar você a encontrar bugs mais rápido, mas também fazer isso melhor e com menos custo, além de ajudar você, como desenvolvedor ou profissional de segurança, a se concentrar no que mais importa. Então, muito obrigado. Eu costumava fazer isso em todas as palestras. Sabe, meu sonho era ser um astro do rock, mas tive que me tornar um empreendedor de segurança cibernética. Então, em vez disso, vou tirar fotos. Mãos para cima, pessoal. Certo, ótimo. Muito obrigado. Estou à disposição para perguntas. Se quiser,

19:03 vá até o estande. Fica bem aqui perto. snyk.io. Conheça Evo, nossa nova oferta de segurança com IA. Muito obrigado.

Transcrição original

[00:12] Great. Hi everyone. We’re going to talk today about continuous offensive security. Okay. I’m going to speak quite soon. What does it mean? Uh but before that, a little bit about me. I’m very excited being here today. I’m Ellie. Uh used to be co-founder and CEO of Helios, a runtime security company. got acquired by sneak and in the last two and a half years I had the privilege in working in sneak primarily on product management for AI products but more recently founding field CTO meaning I’m working with developers and with security folks

[00:43] to better understand and to help them shape their strategy around AI security. So how do you take your AI agents and making sure they are um secured? How do you work with your agents in production? Um, back there, can you set up the timer for me, please? The timer. So, I’ll know the time. Great. Okay, now we have the timer also. Great. Um, so just so I’ll get to know a bit better. Please raise your hand. Who is here more from the development side

[01:16] of the table? Developers. Okay, great. From the security side of the table. Yeah, I already know you. Great. and other people like sales, marketing, other people running agents in production that are not from developmental security. Great. Okay. So, we have everyone here. So, I’m going to tailor this uh session towards everyone. So, obviously this is an AI engineering conference, right? So, we already know that the amount of code generated today is incredibly bigger than it used to be before. Okay. According to our data,

[01:51] it’s 218% more lines of code per the developer than it used to be before. Okay. And more than 85% of the developers are actually using coding agent now probably running here today. It’s more than 100% right because I guess that each one of you probably have five different session of cloud code running simultaneously. Otherwise, you wouldn’t be here today. And the funny thing about those agents running in production and generating fork for us is that it’s far less secured than we are used to. Okay, so

[02:25] 62% of the output generated by LLMs is not secure or it’s broken. Okay, so just imagine this data combined together. It’s meaning that we are generating more code than we ever did and this insecure code is getting into production. So that’s a huge challenge for us as a community and what it actually means is that our backlog of security issues is becoming longer and bigger and much more

[02:55] challenging to remediate it. Okay. So we are actually creating many more issues at a pace that we simply couldn’t remediate or mitigate. And not only that, AI is helping our attackers also. So they are able to chain low vulnerabilities together and to form critical vulnerabilities from those um low low severity vulnerabilities. And what’s actually is going on is that our attackers are leveraging those LLMs and they’re attacking us especially where

[03:29] it’s very difficult using um application context. This is actually where our LLMs are struggled the most because they are creating many more vulnerabilities around those areas. So obviously we are leveraging AI but our attackers are also leveraging frontier models. Okay. And the numbers are simply incredible. Okay. We are familiar with an operating model that actually was able to identify more than 600 vulnerabilities uh to breach 600 firewalls in more than

[04:01] 555 countries. Okay, this is simply unbelievable. And the time for an AI attack to be effective is constantly getting faster and faster. Okay, so the average time for an AI attack to be successful is 24 34 minutes. Okay, well the fastest time is 4 minutes. Okay, it means that since the moment I began talking, there is probably an AI attack out there that was able to successfully

[04:32] breach a production system and 43% of all the MCP servers actually has vulnerabilities. Okay, so combining all of this data together, what we realize is that we are producing much more code than ever. Each one of us has a few sessions simultaneously of cloud code of codex. Those this code is insecure. It’s getting into production and the people we are facing the attackers are actually leveraging the same tools and they are acting faster than ever in trying to

[05:06] actually leverage those vulnerabilities and our backlog is simply getting piled up and we are not able to get it. And this is exactly what I want to talk about today. what we should be doing to to help improve our security posture. And this is ties heavily to how we can leverage offensive security not just for the attackers but for us as defenders. So why traditional security can’t really keep up? So there is a mixed audience

[05:38] today both people from the development side also people from the security side. So I want to cover first a few basic concepts okay to make sure everyone is familiar with. So what used to be really easy about operating was static code scanning okay SAS. So imagine that you are pushing new code to production. There is a static scanner that is scanning that and is looking for SQL injection cross-ite scripting. So it used to be relatively cheap and relatively easy to run this across every code change. And this is great. Now what

[06:09] it doesn’t catch, it doesn’t catch things that are going into runtime. Okay, so if you have any authorization issues, if you have any configuration issues, for that you will need dynamic application security testing. Okay, you’ll need something that test application dynamically. One example is bola uh broken object level authorization which basically it means that user A can access the data of user B. Okay, those kind of vulnerabilities you can never find with static analysis. For that you need to prop the

[06:43] application in runtime. So what actually a dust scanner is doing it just takes a predefined set of tons of payloads and it just sending to the application to the different API endpoints and by that it managed to find vulnerabilities. So this was also something that could find new things but it wasn’t good with the biggest challenge we have with the code that LM are producing and this is the business logic. So for that we’ve been you what we’ve been using as an

[07:14] industry it’s the pentesting. Okay. So what’s the idea about pentesting? It’s a human pentester that really understands the concept and the business logic of the application and is trying to break it and to find all the vulnerabilities. Now it is the golden standard in application security testing but it has some challenges right. First of all, it’s cost a lot of money, right? Because you actually needed to have a security researcher, a human, not a human in the

[07:44] loop, a human that is actually doing the testing and trying to break the application. And that’s cost a lot of money. Now, the second problem is because it cost a lot of money and because the process was so slow, companies can only do it once a year, two times a year, maybe three times a year. Okay? So combining the fact that nowadays our AI attackers are trying to continuously attack us like doing this pan testing two times a year is simply

[08:15] not good enough. Okay. So what you going to do with the rest of the 350 days you have a year that no one tested your application. Not now not only that the results you got the result you got this crazy and glorified report in PDF that you had to send to your developers. there to take it back to understand what’s real and what’s not and then to start fixing that and then you had to retest. Okay, it sounds like a movie from the 90s, right? It doesn’t make sense to do this anymore. But this was the Gund standard. This is what we were

[08:46] doing. Now the thing is this is the best method out there to actually test your application for its business logic. Okay. So what changes today? Today we have a new technology and this is exactly what I want to talk how we can leverage this new area of AI tools and LLM and frontier models to actually do pentesting on a continuous manner in a scalable manner

[09:17] and this is why we’re introducing EVO continuous offensive security. Okay, so this is obviously very tied up to what we’re doing within SNIK, but what I’m going to tell you today is general. Okay, you can take the principles of what I’m telling you and you can actually verify that with any vendor out there in the expo. Okay, so I want to I want you to think about the following things. Okay, so what you need to do today, you need to prepare your production system from the unknowns unknowns. Okay, and for that you need a

[09:49] new paradigm. Okay. So first of all obviously you need the AI pentesting capabilities which I will double click on soon again. But you also need to start taking the concept of red teaming. Okay. So agent red teaming the idea is to take multi-steps attacks. Okay. So to try to simulate prompt ejection or data excfiltration and goal aenting and obviously to combine it with dynamic testing that is good at identifying authorization issues. So we are taking all of those capabilities together. We are building one suite out of that for

[10:21] offensive security as part of our EVO offering. And the idea is to help you actually mitigate or help you uh handle the fact that the attackers are leveraging the same tools that we are using and they are doing that in a continuous manner 24/7 finding vulnerabilities faster than before and your backlog simply cannot can stand up with that. So what we’re doing differently within AI pentesting. Okay. So we I told you before the great

[10:52] promise of pentesting was always the fact that the human and the end really understand the business context. Okay. So now we are taking this to the LLM and if there is something that LLM are very good at is really trying to understand the business context. So behind the scene we are leveraging the LLMs and we are doing that in a continuous manner. Right? So no longer you’re going to do things like do pent testing twice a year or three times a year. We’re going to do it on every code change. Okay? Every PR that you send, every delta, we’re going

[11:25] to run this pentest for you and we’re going to tell your developers what do they need to fix and how do they need to do it differently. Obviously we leverage our understanding of the application context, but we also help reduce the false positive. For us as a industry, we have a severe problem of false positive. So we are actually proving you that the vulnerabilities that is that we are finding are actually exploitable and we just just flag them as bugs. We actually help you prove that they are exploitable and we take contexts for many different

[11:58] machines and for many different environments and we combine them together to help guide our LLMs. Okay, so this is what we’re doing differently and I think this is really what’s makes this solution so unique and so well positioned to the fact that each one of us have a few coding gadgets running in production and pushing more code than ever. Now how do we do it? How does it work behind the scenes? Okay, so what I want you to understand is we are not taking the static scanners or the dust scanners and just combine him with LLM.

[12:32] Okay, we build it from the ground up using LLM. So we have a series of a few agents working together. The first one is the LLM orchestrator. Okay, imagine it as the brain. This agent is working according to a dynamic plan that it follows and it knows how to operate all the different sub agents. The first agent or actually the second agent is the recon. Okay, you can imagine it as your elite intelligence unit. The idea is to collect all the data it can about

[13:05] the different network endpoints, the different APIs, the different fingerprints, collect all of this data together, formalize an architecture out of that and hand it to the next agent. And the next agent is the vulnerability testing. It’s actually again a series of a few specialized agents. Some of them are targeting the well-known classes of vulnerabilities. Some of them are actually hunting for vulnerabilities in the wild and they are trying to break your application to understand the business context and to understand where

[13:36] can attacker can get from and then they hand it into the judge as I like to call it the exploit validation. So actually every vulnerability that the previous agent find are now being handed over to this judge and the goal of the judge is to tell us whether this is a real vulnerability or or not to tell us whether this can be exploitable or not. Exactly because we want to reduce the cognitive load. Exactly because we want to reduce the amount of false positive

[14:08] we have in the system. Coming up next is the remediation agent because everything we do we want to make actionable. Okay, we don’t want to report about a vulnerability that eventually the developers they don’t know what they can do with that. And coming after that is the reporting agent because everything needs to be reported. So what makes us different and those are the point I urge you to check with every vendor out there trying to provide you with the solution or whether you want to

[14:40] implement a solution inhouse for AI pentesting. This is a huge industry right now. So I think the most important thing you need to remember is and you already know that especially the developers in the room context is everything. your LLM are as good as the context that you feed them with. So what we’re trying to do, we are not just taking our AI pen testing solution as a standalone. We actually feed it with data from all the previous scanners. Okay, so the the statics code scanner, the dynamic code

[15:15] scanner, all of the different agent engines are being combined together and they are being fed into a our AI pentesting solution because that way we know how to tailor and we know how to guide the LLM where to look for and as you know also for mythos or for frame when those models know where to look the results are significantly better. So that’s one thing we’re doing that is you know very unique and very differentiated. Um and also what I want you to remember is that one solution is not enough.

[15:51] Okay. The great thing about it is when you combine those things together and based on the data that we see both from the labs and from real data from customers combining the data together is really what’s important and you can’t really you can’t really use just one of them. Okay. There are certain classes of vulnerabilities. This dust is the best scanner for that. Okay? Because you have a set of really exhaustive pre um a set of really exhaustive uh payloads that

[16:23] you can send to your application. So it’s very good for example with quite scripting. Okay. So dust for crossite scripting is the best solution. But if you want again like business logic then you should combine it with uh pentesting because it will be the best solution. So I think what I really want you to take from this, if there is one thing I want you to take from here is to realize that the world is changing. You already know that. That’s what made you come in. But

[16:53] you know we used to test our application once every few months because the change and the velocity of the change was so slow and we’re we had people at the end that were reasoning about the application and about the change. But that world is does not longer exist. Right? Right now we are pushing code to production 24/7 and we have LLMs that are trying to reason about the application context and they are trying to break it continuously. Some of them can do it in like as fast as four minutes. Okay,

[17:26] that’s almost five time of the lecture of the session that I just did. So when you’re coming to look for new solutions for this problem, you have to ask yourself four questions. Okay. First of all, do we run this solution in a continuous way or is it just a point solution that we run every once in a while? Okay, that’s a major difference. Second, do they really reason about the application context? Okay, because given the nature of those LLM, application context is really where the new vulnerabilities are

[17:59] coming from. And third, what more context can they digest? Okay, how can they enrich the data? Because the richer the data is, the better and by the way cheaper the LLM operation is going to be. And the fourth part is do they really help me prove that there is a bug and to make sure that this is exploitable or they they just flag it as a bug. Okay, so our goal is not only to

[18:30] help you find the bugs faster, but to actually do it better and cheaper and to help you as a developer or as the security people here focus on what matters most. Um, so thank you very much and uh I used to do it in every lecture. You know, my my my dream was to be a rockstar, but I had to be a cyber entrepreneur. So instead of that, I’m going to take pictures. So hands up everyone. Okay, great. Thank you so much. And I’m here for questions. If you want,

[19:03] go for the boot. It’s very close here. sneak.io. Meet Evo, our new AI security offering. Thank you so much.