Introdução

De um lado, a inteligência artificial acelera o desenvolvimento de produtos. É esse o foco do relatório “2026 State of Product Security for the AI Era”, que analisa como Product Security e AppSec estão lidando com a entrada massiva de IA no ciclo de desenvolvimento.

Do outro lado, o relatório “State of AI in Security Operations 2025” observa o impacto desse mesmo movimento dentro dos SOCs e dos times de SecOps e DevSecOps, em que o aumento da superfície de ataque se traduz em mais sinais, mais decisões e mais pressão operacional.

Este artigo parte desse contraste entre desenvolvimento de software (produto) e operações (segurança) para discutir como aproximar esses dois mundos e por que a estratégia Zero-CVE surge como um caminho consistente para alinhar velocidade, padrões e segurança no uso de IA.

1. IA no desenvolvimento de software: velocidade maior, visibilidade menor

No recorte de desenvolvimento de software, o estudo mostra que a IA já está amplamente presente no código e no fluxo de trabalho das equipes.

Os dados mais sensíveis não são de adoção, mas de risco e governança:

• Apenas 19% das organizações dizem ter visibilidade completa de onde a IA é usada no ciclo de desenvolvimento;

• 65% relatam que o risco de segurança aumentou desde a adoção de IA no desenvolvimento;

• Mais de 50% ainda não possuem uma governança centralizada de IA, tomando decisões de forma distribuída entre times.

O que isso significa, na prática

→ O código chega mais rápido à produção, mas nem sempre está claro onde, como e em que profundidade a IA participou da construção desse código.

→ Fica difícil identificar quais partes do produto carregam mais risco e quais decisões de segurança dependem diretamente de componentes gerados ou assistidos por IA.

Onde está o ponto crítico

Sem uma governança centralizada, cada time cria suas próprias regras de uso de IA, com níveis diferentes de cuidado e critérios.

O resultado é um descompasso: a velocidade e o volume de código crescem mais rápido do que a capacidade de entender onde a IA atua e quais riscos ela adiciona ao produto.

2. IA em SecOps: volume alto, escolhas difíceis

Do lado de operações de segurança, os dados mostram a pressão diária sobre os times de SOC:

• Empresas de grande porte lidam com cerca de 3.000 alertas de segurança por dia;

• Em média, 40% dos alertas não chegam a ser investigados;

• 57% das organizações suprimem regras de detecção para conseguir lidar com o volume, reduzindo o número de sinais que entram no funil do SOC.

O que isso significa, na prática

→ O SOC não consegue olhar para tudo; parte do risco é assumida de forma consciente, simplesmente porque não há capacidade humana para investigar todos os eventos.

→ A supressão de regras funciona como um “filtro de sobrevivência”: o time alivia o ruído, mas também abre mão de visibilidade justamente em superfícies críticas, como cloud e identidade.

Onde está o ponto crítico

Essa dinâmica força o SOC a operar em modo reativo, escolhendo o que vai (e o que não vai) ser visto, enquanto o ambiente continua acumulando eventos em ritmo cada vez maior.

A IA começa a entrar aqui como força de alívio, ajudando em triagem e priorização, mas, sem uma visão conectada com desenvolvimento e produto, ela resolve o sintoma do volume sem necessariamente atacar a origem do risco.

Leia mais: Glossário da cadeia de software (Kubernetes, containers, SBOM, CVEs): Edição Quor

3. Um caminho estratégico: conectar origem e efeito do risco

Os dois estudos apontam a mesma trava: muito ruído, pouco contexto.

Em desenvolvimento, falta clareza sobre como, onde e sob quais critérios a IA entra no ciclo de desenvolvimento de software e qual risco vem junto. No SOC, falta contexto para decidir o que realmente importa em meio a milhares de alertas diários.

Um caminho estratégico é mudar a pergunta. Em vez de olhar só para “quantas vulnerabilidades temos” ou “quantos alertas recebemos”, a questão passa a ser: quais critérios definem o que pode ser promovido para produção?

Isso exige ligar origem e efeito do risco: do código, das dependências e da software supply chain aos alertas, incidentes e tentativas de exploração.

O objetivo é claro: reduzir a chance de que vulnerabilidades conhecidas sejam introduzidas ou avancem no pipeline até o deploy, usando detecção como rede de proteção, não como primeira linha de defesa.

Leia mais: Você sabe o que é um CVE? E o que ele pode fazer com a sua estratégia de produto?

O que isso muda para os times

Para os times de desenvolvimento e Product Security, isso começa com uma mudança de mentalidade: nenhum componente que toque a infraestrutura crítica deveria chegar à produção sem rastreabilidade clara. É preciso saber a origem, a função e quais critérios técnicos sustentam a decisão de colocá-lo em operação. Isso vale para imagens de container, serviços centrais, integrações sensíveis, componentes apoiados por IA e elementos da software supply chain. Em outras palavras, decisões técnicas opacas deixam de ser aceitáveis.

Para SecOps, SOC e DevSecOps, o papel evolui do reativo para um modelo mais integrado em meio ao sprawl de ferramentas. A prioridade passa a ser conectar alertas e eventos ao seu contexto de origem e de impacto: de onde veio (código, dependências, pipeline, software supply chain), em que componente ou ativo está e qual o potencial caminho até produção. Com isso, a operação deixa de ser guiada pelo volume e passa a ser guiada por risco, reduzindo de forma contínua a chance de vulnerabilidades conhecidas permanecerem em componentes críticos em produção.

Para a organização como um todo, o ponto é alinhar linguagem e critérios e evitar que cada área opere de forma isolada, sem o contexto do todo. Engenharia, segurança, DevSecOps e produto precisam responder às mesmas perguntas: o que aceitamos em produção, em que tipo de componente e com qual prazo de correção. Em vez de tratar regulações, security by design e software supply chain security como demandas separadas, tudo isso passa a compor o mesmo quadro de decisão e a orientar trade-offs de velocidade, risco e priorização de forma consistente.

Leia mais: Nem Toda Herança É Boa: O Risco das Imagens de Containers

Conclusão

Os dois estudos apontam o mesmo desalinhamento: a velocidade do desenvolvimento aumentou, mas visibilidade, contexto e critérios ainda não acompanharam. No SOC, isso aparece como volume e escolhas difíceis; em desenvolvimento, como rastreabilidade inconsistente e decisões técnicas opacas.

Uma abordagem orientada a Zero-CVE, entendida aqui como objetivo e filosofia de operação, entra como ponto de convergência entre esses mundos. Ela significa estabelecer critérios claros e compartilhados entre desenvolvimento, Product Security, SecOps e operações sobre quais vulnerabilidades conhecidas, configurações inseguras e sinais de risco são bloqueadores antes da promoção de componentes de software e artefatos para produção.

Com isso, alertas e incidentes deixam de ser a primeira linha de defesa e passam a operar como rede de proteção. O resultado é um modelo mais consistente para controlar risco e exposição, sem depender apenas de reação e sem abrir mão de velocidade.

Referências:

• Cycode. 2026 State of Product Security for the AI Era. Disponível em: cycode.com/state-of-product-security-ai-era-2026/

• Prophet Security. State of AI in Security Operations 2025. Disponível em: resources.prophetsecurity.ai/state-of-ai-in-security-operations