Segurança de aplicações na era da IA: estamos dirigindo no escuro
O mais recente relatório global de 2026 sobre segurança de aplicações da Checkmarx deixa pouco espaço para interpretações otimistas: o setor não sofre mais por falta de ferramentas, mas por incapacidade de usá‑las com eficácia. O ecossistema de desenvolvimento mudou radicalmente com a chegada da IA e do uso massivo de componentes open source, porém processos, governança, responsabilidades e cultura de segurança ficaram para trás.
Hoje, a inteligência artificial permeia praticamente todo o ciclo de vida de desenvolvimento de software. Pela primeira vez, o código escrito manualmente deixou de ser a regra e passou a ser a exceção. A estimativa é contundente: cerca de 49% do código em produção é gerado por IA, enquanto 67% das organizações afirmam que componentes de código aberto já representam pelo menos metade de sua base de código. A produtividade disparou, mas o risco acompanhou o mesmo ritmo – ou até o superou.
Nesse novo cenário, a função do desenvolvedor foi profundamente redefinida. Ele não é mais apenas o autor do código, mas se tornou um editor que precisa revisar, ajustar e aprovar um volume gigantesco de trechos gerados automaticamente por máquinas. A responsabilidade, porém, continua sendo humana: é o time de desenvolvimento que responde por um código que não escreveu linha por linha, mas que colocou em produção.
Essa mudança de papel vem com um custo alto. De acordo com o relatório, 96% das organizações já utilizam ou estão testando componentes de IA em suas aplicações. Na prática, isso significa que quase todas as camadas do software moderno – da interface ao backend, passando por integrações e bibliotecas – podem se transformar em vetores de ataque. A superfície de exposição cresceu e se tornou mais complexa, ao mesmo tempo em que a capacidade de inspeção humana não escala na mesma velocidade.
Ao priorizarem ciclos de entrega cada vez mais curtos, muitas empresas passaram a enxergar a presença de vulnerabilidades como um “custo de fazer negócios”, e não como uma exceção grave a ser evitada. A velocidade se tornou um argumento recorrente para justificar o aceite de riscos elevados. O problema é que não se trata apenas de mais código: trata-se de um código estruturalmente mais arriscado. Em 2025, 70% dos desenvolvedores afirmaram que a geração de código por IA aumentou a quantidade de vulnerabilidades introduzidas nas aplicações.
O peso dos componentes de código aberto intensifica ainda mais esse quadro. Como eles compõem hoje a maior parte da base de código de muitas empresas, os riscos são herdados sem que a organização tenha, de fato, controle sobre sua origem ou manutenção. Entre esses riscos, destacam‑se dependências sem correção disponível, pacotes maliciosos disfarçados de bibliotecas legítimas e ataques cada vez mais sofisticados à cadeia de suprimentos de software. Na prática, o que parece ganho de agilidade se converte em uma herança de fragilidades que podem ser exploradas em massa.
Os dados do relatório revelam um ciclo vicioso difícil de quebrar: quanto maior o percentual de código gerado por IA, maior a probabilidade de esse código chegar à produção com falhas. E quanto mais código vulnerável em produção, mais frequentes são as violações de segurança. Organizações que geram entre 81% e 100% do código com IA lançam software vulnerável a uma taxa 3,4 vezes maior do que empresas que utilizam IA em apenas 1% a 20% do desenvolvimento. Não por acaso, esses mesmos grupos registram um número significativamente superior de incidentes e violações.
Paralelamente, o relatório expõe uma lacuna perigosa entre percepção e realidade. A maior parte das empresas acredita ter alcançado um nível “maduro” de segurança de aplicações. Essa autoconfiança, porém, não se reflete nos resultados: violações continuam ocorrendo de forma constante, muitas vezes repetindo os mesmos padrões de falhas já conhecidas. A sensação de controle não corresponde ao que realmente acontece no ambiente de produção.
É verdade que a visibilidade sobre riscos melhorou. Ferramentas mais modernas de análise de código, varredura de dependências, SAST, DAST, SCA e monitoramento de runtime oferecem um mapa cada vez mais detalhado das vulnerabilidades existentes. O problema é o que se faz com esse mapa. Em muitos casos, as organizações simplesmente optam por ignorar os alertas ou os tratam como “ruído operacional”. Segurança, desenvolvimento e áreas de liderança até reconhecem os riscos, mas seguem desalinhados em relação a quem é responsável por agir, quais problemas devem ser priorizados e como será feita a prestação de contas.
Talvez o dado mais inquietante do relatório seja a normalização do risco consciente. Três em cada quatro organizações – 75% – admitem colocar em produção, de forma deliberada, código que sabem ser vulnerável. As justificativas variam: prazos impraticáveis, excesso de confiança em controles compensatórios, dificuldades técnicas para corrigir determinadas falhas ou impactos negativos em funcionalidades críticas. Em 30% dos casos, porém, a decisão é quase um ato de fé: a empresa simplesmente aposta que ninguém irá descobrir aquela brecha específica.
Essa lógica de “depois a gente resolve” não afeta apenas a camada técnica. Ela também se reflete na governança e na transparência. Segundo o levantamento, 95% dos CISOs relatam ter sofrido pressão, de forma frequente ou ocasional, para atrasar ou suavizar a divulgação de achados de segurança relevantes para compliance. Ou seja, o risco não está apenas passando despercebido; em pontos decisivos, ele é conscientemente minimizado ou ocultado. Isso cria um ambiente no qual o discurso público de segurança não corresponde ao que se sabe internamente.
Um dos pontos centrais revelados pelo estudo é que confiança não equivale a segurança. Aproximadamente 73% dos CISOs e gerentes de AppSec classificam a postura de segurança de suas organizações como madura ou avançada. Em contraste direto, 93% dessas mesmas empresas relatam ter sofrido pelo menos uma violação. O recado é claro: a percepção de maturidade não impede que atacantes encontrem brechas – e isso acontece repetidas vezes.
Outro aspecto crítico é a mudança na “janela de exploração”. Se antes uma vulnerabilidade recém‑divulgada podia demorar dias ou semanas para ser amplamente explorada, hoje esse intervalo encolheu drasticamente, muitas vezes para poucas horas ou mesmo minutos. Ferramentas automatizadas de varredura, também impulsionadas por IA, permitem que criminosos encontrem e explorem falhas em escala global quase em tempo real. Isso torna inaceitável qualquer abordagem de correção lenta, manual e desorganizada.
Nesse contexto, fica evidente que o problema principal não é mais descobrir vulnerabilidades, mas lidar com elas em um cenário de volume extremo. Os times se veem soterrados por relatórios, alertas e recomendações, sem uma estratégia clara para priorização baseada em risco real para o negócio. Vulnerabilidades críticas convivem com falhas de baixo impacto em filas de correção pouco estruturadas, o que aumenta a chance de que pontos realmente perigosos permaneçam expostos por longos períodos.
Para sair desse ciclo, não basta adicionar mais ferramentas ao pipeline. É necessário repensar o modelo de responsabilidade. Segurança de aplicações não pode ficar restrita a uma equipe isolada de AppSec, que atua como gargalo no final do processo. A mentalidade de “shift left” precisa ser levada a sério: desenvolvedores devem ser capacitados para prevenir erros na origem, lideranças precisam patrocinar uma cultura em que qualidade e segurança sejam objetivos de produto, e não apenas itens de checklist.
Outro ponto essencial é encarar a IA não apenas como risco, mas também como aliada. Se atacantes se valem de automação e modelos avançados para acelerar ataques, as equipes defensivas precisam usar IA para priorização inteligente, correção assistida, detecção em tempo real e análise de padrões de exploração. O desafio é construir mecanismos de validação, revisão humana e governança que mantenham a IA sob controle, em vez de delegar às cegas decisões críticas sobre segurança.
As organizações também terão de encarar, de frente, a questão da aceitação de risco. Implantar código vulnerável de forma consciente não pode ser uma decisão implícita, tomada às pressas por um time pressionado. Quando isso acontecer, deve haver um processo formal de avaliação de impacto, aprovação por instâncias de governança adequadas e plano de mitigação claro – com prazos, responsáveis e mecanismos de acompanhamento. Tornar explícito o risco assumido é um passo essencial para reduzir a cultura da aposta silenciosa.
Investir em educação contínua é outro pilar. Desenvolvedores, gestores de produto, líderes de tecnologia e executivos precisam compreender o impacto real das escolhas de segurança – incluindo custos de incidentes, danos à reputação, impacto regulatório e perda de confiança de clientes. Sem essa visão, decisões de curto prazo em prol da velocidade continuarão prevalecendo, mesmo quando se sabe que o preço a pagar é alto.
Por fim, a era da IA exige que segurança de aplicações seja entendida como disciplina estratégica de negócio, e não como detalhe técnico. Empresas que tratarem o tema apenas como obrigação de compliance tendem a permanecer “de olhos vendados” enquanto multiplicam sua exposição a riscos. Já aquelas que conseguirem alinhar automação, cultura, processos e responsabilidade tendem a colher o verdadeiro benefício da IA: não apenas desenvolver mais rápido, mas desenvolver melhor – com segurança como parte intrínseca da inovação, e não como remendo de última hora.