Criar software 10x mais rápido exige segurança 10x mais madura

Em resumo

• Acelerar a produção de código não garante entregar software confiável mais rápido.
• Segurança precisa aplicar controles proporcionais ao risco e reduzir a dependência de avaliações manuais.
• A IA pode ampliar a capacidade de análise, mas decisões de risco continuam exigindo responsáveis humanos.

Em algumas empresas, o controle mais visível sobre o uso de IA no desenvolvimento parece ser o orçamento de tokens. Segurança entra depois, quando a solução já foi desenhada, o prazo anunciado e falta apenas um “de acordo”.

Se Engenharia ampliar a produção de mudanças, um sSDLC baseado em planilhas, scanners barulhentos e avaliações amostrais não irá dar conta.

Mais código também exige mais revisão #

Os ganhos dependem do contexto. Em um experimento do GitHub, desenvolvedores com Copilot concluíram uma tarefa em JavaScript em aproximadamente 55% menos tempo. Já a METR observou, com ferramentas do início de 2025, aumento de 19% no tempo de desenvolvedores experientes trabalhando em seus próprios projetos. São recortes distintos, não estimativas universais nem retratos das ferramentas atuais. ^{1 2}

Gerar código mais rápido pode aumentar a demanda por revisão, integração, testes e correções. O ganho em uma etapa não garante melhora na entrega inteira.

O mesmo rito para riscos diferentes #

Na minha experiência em organizações grandes e reguladas, a cobertura de Segurança ainda depende demais dos projetos que chegam ao radar e do tempo disponível antes de ir para a produção.

O problema fica evidente quando uma API pública que movimenta dinheiro via Pix e uma alteração cosmética em uma tela passam pelo mesmo questionário e aguardam a mesma aprovação. A organização padroniza a espera sem necessariamente controlar o risco.

Adicionar outro scanner não resolve essa distribuição de esforço. O OWASP SAMM conecta avaliação de ameaças, requisitos, arquitetura, testes e gestão de defeitos. A maturidade depende de como essas práticas funcionam ao longo da entrega. ³

Quatro capacidades para ganhar escala #

O modelo precisa absorver mais mudanças sem depender de crescimento proporcional do time de AppSec. Isso exige:

• Classificação contínua de risco: exposição, dados, privilégios e impacto no negócio devem determinar os controles. Essa avaliação precisa acompanhar mudanças no sistema, em vez de permanecer congelada no formulário inicial.
• Caminhos seguros por padrão: bibliotecas, templates, pipelines, identidade e gestão de segredos devem chegar prontos para uso. Adotar controles fica mais fácil quando o desenvolvedor não precisa construí-los a cada projeto.
• Evidências com contexto: SAST, SCA, secret scanning e testes precisam relacionar os achados ao ativo e à mudança. Exposição e possibilidade de exploração ajudam a priorizar; o volume de alertas, sozinho, não demonstra controle.
• Intervenção humana seletiva: especialistas devem concentrar esforço em arquitetura, abuso de regras de negócio, exceções e riscos de alto impacto. Um pipeline verde não substitui essas decisões.

Threat modeling como aplicação prática #

Threat modeling mostra onde a IA pode ajudar. Quando a prática depende de workshops e poucas pessoas, atualizar análises a cada mudança se torna caro. O documento existe, mas suas premissas podem já ter expirado.

Um agente pode reunir diagramas, contratos de API, infraestrutura como código e alterações de pull requests para propor cenários de ameaça e destacar premissas afetadas. É uma aplicação possível, cujo valor precisa ser validado no ambiente da empresa.

A análise deve apontar as evidências usadas e permitir revisão. Especialistas validam premissas, identificam abusos de negócio e encaminham a decisão sobre risco residual aos responsáveis. Automatizar a preparação e a manutenção pode liberar tempo para esse julgamento.

Acelerar exige mudar a operação #

Se Segurança mantiver o mesmo modelo diante de um volume maior de mudanças, a tendência será aumentar filas ou reduzir cobertura. Conhecer os ativos, diferenciar riscos e incorporar controles ao desenvolvimento permite enfrentar esse descompasso.

A empresa que acelerar apenas a escrita do código corre o risco de se tornar mais eficiente em levar incerteza para produção.