Esta é uma das mudanças mais importantes em exibição na RSAC este ano. A governação, há muito tratada como fricção, está a ser reformulada como infraestrutura, algo que deve ser automatizado para que o desenvolvimento impulsionado pela IA seja dimensionado.
A compensação é a complexidade. O modelo do Chainloop exige que as organizações pensem em termos de sistemas, proveniência e estruturas políticas, não apenas em ferramentas. Mas para as equipes que já enfrentam riscos na cadeia de fornecimento de software, essa abstração pode ser exatamente o que é necessário.
FireTail: ganhando visibilidade sobre o uso de IA em toda a organização
Descrita como uma plataforma de segurança de IA ponta a ponta, a FireTail dá um passo atrás para responder a uma questão mais ampla: quem está usando IA e como.
Isso pode parecer básico, mas não é um problema resolvido. À medida que as ferramentas de IA proliferam, o uso muitas vezes se espalha para além das equipes de desenvolvimento, incluindo gerentes de produto, analistas e outras funções de negócios. Em muitos casos, as organizações não possuem um inventário claro sobre quais ferramentas estão em uso, quais dados estão sendo compartilhados e onde os riscos podem ser introduzidos.
FireTail se concentra em fornecer essa visibilidade.
A plataforma monitora o uso dos funcionários, como interações com ferramentas como ChatGPT, e o uso em nível de aplicativo, como agentes criados em serviços de IA em nuvem. Ele agrega essa atividade em fluxos de log unificados, onde pode detectar possíveis problemas como vazamento de dados, violações de políticas ou comportamento anômalo.
“O primeiro caso de uso para cada cliente é saber quem está usando qual serviço de IA”, disse o fundador da FireTail, Jeremy Snyder. A partir daí, as organizações podem definir políticas e, em alguns casos, aplicá-las, especialmente no nível do endpoint ou do navegador.
Este é um tipo diferente de ponto de controle. Trata-se menos de impor o comportamento dentro do pipeline e mais de estabelecer visibilidade e governança básicas em toda a organização. Essa distinção torna o FireTail amplamente útil e um tanto periférico ao ciclo de vida de desenvolvimento principal. A visibilidade é um pré-requisito para o controlo, mas a aplicação exige medidas adicionais.
Ainda assim, à medida que a adoção da IA se expande para além da engenharia, essa visibilidade pode tornar-se um primeiro passo necessário, especialmente para as organizações que tentam compreender a sua exposição antes de decidirem como a gerir.
Raven: Impondo confiança onde o código é executado
No final do ciclo de vida do software, Raven representa um tipo diferente de mudança. Em vez de focar no código antes de ele ser executado, Raven se concentra no que acontece quando ele é executado.
Descrevemos o Raven no ano passado como uma plataforma de tempo de execução focada em priorização e detecção. Este ano, a ênfase mudou. A empresa agora está buscando a prevenção do tempo de execução, com uma postura mais agressiva sobre o que é importante e o que não é.
A ideia central é direta. A análise estática produz grandes volumes de vulnerabilidades, muitas das quais nunca são exercidas na produção. Ao mesmo tempo, a IA está a reduzir o tempo necessário para descobrir e explorar fraquezas reais. Como resultado, o modelo tradicional de procurar problemas conhecidos e priorizá-los com base em CVEs está a perder relevância.
A resposta de Raven é focar no comportamento em tempo de execução, em vez de assinaturas ou vulnerabilidades conhecidas. Ao observar como o código é executado dentro do aplicativo, a plataforma tenta identificar e interromper diretamente a atividade de exploração, independentemente de uma vulnerabilidade ter sido catalogada. Como disse o cofundador e CEO da Raven, Roi Abitboul: “Paramos de depender de CVEs e observamos o que o aplicativo está realmente fazendo”.
Esta é uma afirmação forte, mas reflecte uma tendência mais ampla.
A empresa utiliza uma abordagem em nível de kernel para observar o comportamento do aplicativo sem injetar código ou modificar o ambiente de execução, com o objetivo de minimizar o impacto no desempenho. Desse ponto de vista, ele pode identificar comportamentos anômalos em bibliotecas ou funções e bloquear a execução em tempo real.
É também aqui que Raven diverge de grande parte da narrativa atual de IA. Embora muitos fornecedores enfatizem a detecção orientada por IA, Raven argumenta que a IA é muito lenta para prevenção em tempo real e, em vez disso, a utiliza seletivamente para tarefas de análise e priorização. O resultado é um modelo que trata o tempo de execução como o ponto de controle final. Se os estágios anteriores falharem ou forem ignorados, a imposição ainda ocorrerá onde o código for executado.
Essa posição não é nova em princípio, mas o contexto é. À medida que a IA acelera o desenvolvimento e a geração de explorações, a lacuna entre a descoberta de vulnerabilidades e a exploração continua a diminuir. Nesse ambiente, a aplicação do tempo de execução torna-se menos uma alternativa e mais uma defesa primária.
Seezo: Protegendo o que é construído, antes que o código exista
Uma das mudanças mais dramáticas na segurança da informação está a acontecer logo no início do ciclo de vida do desenvolvimento.
Nos anos anteriores, os fornecedores de segurança de aplicativos se concentraram na digitalização do código depois de escrito. Seezo aposta que, num mundo movido pela IA, já é tarde demais. A empresa se concentra em gerar requisitos de segurança antes que o código seja escrito, moldando a forma como os desenvolvedores e os agentes de IA constroem sistemas desde o início. A premissa é simples: se a IA está gerando grandes volumes de código, então controlar o que é construído torna-se mais importante do que analisar o que foi construído posteriormente.
Como disse o cofundador e CEO da Seezo, Sandesh Mysore Anand: “O custo de geração de código caiu para zero, enquanto o custo de revisão do código ainda é muito alto”.
Esse desequilíbrio está a provocar uma mudança silenciosa mas importante. Em vez de interromper os desenvolvedores com verificações e descobertas, Seezo insere segurança na camada de requisitos, o único lugar em que humanos e sistemas de IA dependem para compreender a intenção.
Esta não é apenas uma história de mudança para a esquerda. É um reconhecimento de que quando os agentes de IA escrevem código, eles também leem instruções. Se essas instruções incluírem restrições de segurança, o código resultante será melhorado antes mesmo de atingir um pipeline.
A compensação é óbvia. Essa abordagem depende da adoção de um processo de requisitos mais disciplinado pelas organizações, algo que muitas equipes têm resistido historicamente. Mas à medida que a IA aumenta a produção, essa disciplina pode tornar-se menos opcional.
TestifySec: Transformando a conformidade em um controle contínuo
Prometendo transformar o pipeline de desenvolvimento em um “feed de auditoria ao vivo”, o TestifySec está enfrentando um gargalo persistente: a conformidade como função de controle.
Em ambientes tradicionais, provar que o software atende aos requisitos regulatórios ou de segurança é algo lento, manual e muitas vezes desconectado da forma como o código é realmente construído. Esse atraso se torna um problema real quando o desenvolvimento acelera, especialmente quando os agentes de IA geram mudanças mais rápido do que as equipes conseguem revisá-las.
Para responder a esse desafio, o TestifySec transfere a conformidade para o próprio pipeline, usando um modelo baseado em evidências. Em vez de depender de documentação e auditorias manuais, a plataforma mapeia códigos, resultados de testes e artefatos diretamente para controles de segurança e os avalia continuamente.
“As organizações agora podem escrever software rapidamente, mas não podemos distribuí-lo mais rápido porque não podemos medi-lo”, disse o cofundador e CEO da TestifySec, Cole Kennedy. Essa lacuna de medição é o que o TestifySec está tentando fechar.
A plataforma usa agentes de IA para analisar quais evidências devem existir para um determinado controle e, em seguida, procura essas evidências na base de código, nas saídas do pipeline e nos artefatos de suporte. Na prática, isso significa que os desenvolvedores podem obter feedback sobre a conformidade antes da fusão do código, em vez de esperar por um ciclo de auditoria posterior.
Esta é uma mudança sutil, mas importante. A conformidade deixa de ser uma etapa de validação post hoc para se tornar um sinal contínuo dentro do CI/CD.
O desafio é a confiança. A conformidade automatizada já foi prometida antes, e as organizações tendem a ser cautelosas ao substituir a validação humana por avaliações geradas por máquinas. Mas à medida que a velocidade de desenvolvimento aumenta, a alternativa pode ser pior: um acúmulo crescente de software que não pode ser enviado porque não pode ser certificado.
Todas as direções ao mesmo tempo
Se houve uma única conclusão do RSAC 2026, é que a indústria já não está a discutir se a IA mudará o desenvolvimento de software. Já aconteceu.
O que ainda está sendo resolvido é qual é o lugar da segurança quando os limites entre desenvolvimento, implantação e execução não forem mais válidos. Os fornecedores destacados aqui não estão convergindo para uma única resposta. Em vez disso, eles estão redefinindo pontos de controle em todo o ciclo de vida, desde requisitos e cadeias de ferramentas até pipelines, tempo de execução e fluxos de trabalho.
Algumas destas abordagens serão mais duradouras do que outras. Nem todas as novas camadas se tornarão uma categoria e nem todas as reivindicações resistirão à pressão do mundo real. Mas a direção é clara. À medida que a IA comprime o ciclo de vida de desenvolvimento de software e acelera o desenvolvimento e a exploração, a segurança não pode mais depender de pontos de verificação isolados.
A confiança tem de ser reforçada continuamente e em mais locais do que antes.
O desafio para as organizações não é apenas adotar novas ferramentas, mas decidir onde esses pontos de controle devem residir nos seus ambientes. A resposta irá variar, mas a mudança subjacente é a mesma: a segurança já não é um palco. Faz parte do próprio sistema.
