Os Desafios do Desenvolvimento Seguro em Tempos de Inteligência Artificial

Palestra apresentada na 23ª Latinoware - em Foz do Iguaçu/PR - BR, No dia 15 de Outubro de 2026.

A palestra aborda os desafios que o advento das Inteligencias Artificiais Modernas (LLM's) trazem devido ao aumento da quantidade de código gerado pelos times de desenvolvimento.

Transcript

1. Os Desafios do Desenvolvimento Seguro em Tempos de Inteligência Artificial DevSecOps, quality gates e a integração de SAST, SCA e DAST no pipeline de CI/CD Autor: DIEGO NEVES
2. :~$ whoami • • • • • • • 20y+ Trabalhando com Tecnologia 20y+ Usando apenas Linux nos meus PCs Sysadmin Especialista em Redes de Computadores 9y+ como Dev(Sec)Ops Atualmente como DevSecOps Specialist Pessoa Neurodivergente (AH/SD - TEA)
3. :~$ tree ├── Diagnostico ├── Novos Gargalos ├── O Paradoxo da Produtividade └── Novos Riscos ├── DevSecOps ├── Princípios ├── CICD ├── IDE/Push ├── Build └── Deploy ├── Quality Gates ├── Divisores ├── Tradicional vs Maduro └── Eixos de Decisão ├── SAST SCA DAST ├── SAST ├── SCA └── DAST └── Conclusões ├── IA na Defesa └── Métricas
4. O gargalo mudou de lugar Por quatro décadas, escrever código foi a atividade mais cara do ciclo. Assistentes baseados em LLM inverteram essa economia — mas só metade do pipeline ficou mais barata. Produção Verificação Consequência Gerar funções, testes e módulos passou a custar segundos. Automatizada e barata. Revisar, entender e responsabilizar-se pelo código continua sendo trabalho humano e caro. A pressão migrou inteira para a segunda metade da esteira — que quase ninguém reforçou. O desafio central não é produzir mais software — é sustentar a confiança sobre o software que se produz.
5. O paradoxo da produtividade O que acelerou O que não acelerou • Boilerplate, testes unitários e documentação • Revisão humana com profundidade crítica • Prototipagem e exploração de alternativas • Compreensão do contexto de negócio • Tradução entre linguagens e frameworks • Decisões arquiteturais e trade-offs • Onboarding em bases desconhecidas • Depuração de falhas sistêmicas • Responsabilização por decisões técnicas Quando a produção cresce e a verificação permanece constante, a dívida técnica e a de segurança se acumulam mais rápido.
6. Os novos vetores de risco Código inseguro por herança Alucinação de dependências Erosão do ownership O modelo reproduz o que é estatisticamente comum nos repositórios públicos — não o que é correto. Pacotes inexistentes são sugeridos e registrados por atacantes. Slopsquatting direto na build. Código que ninguém escreveu tende a ser código que ninguém entende às 3h da manhã. Superfície ampliada Fadiga de alertas Vazamento de contexto Prompt injection em agentes, servidores MCP com excesso de permissão, chaves expostas. Mais PRs geram mais achados. Sem priorização, o time aprende a ignorar o pipeline. Código proprietário e dados sensíveis enviados como contexto a modelos externos.
7. 00 DevSecOps De etapa final a propriedade contínua do pipeline Princípios Anatomia do pipeline IDE e Pull Request Build Deploy e Runtime
8. Três princípios que sustentam a resposta Shift-left virou shift-everywhere Antecipar controles para a IDE continua valendo, mas não basta. Cada fase — código, build, artefato, deploy e runtime — expõe uma classe de risco diferente. Segurança como código Políticas versionadas e executáveis (OPA/Rego, Kyverno, Conftest), revisadas em pull request. Política que vive em PDF não é executável; a que vive no repositório é. Guardrails em vez de gatekeepers Segurança deixa de aprovar manualmente e passa a construir os caminhos seguros por padrão: golden paths, templates de pipeline, imagens base endurecidas. O certo precisa ser o caminho mais fácil — é isso que faz segurança escalar sem virar gargalo.
9. Anatomia do pipeline: onde cada controle entra 00 01 02 03 04 IDE e pré-commit Pull Request Build Deploy Runtime segundos › minutos › minutos › min–horas › contínuo Linters · secret scanning SAST no diff · SCA SBOM · assinatura DAST autenticado · IAST Detecção de anomalia SAST incremental · hooks IaC scan · licenças SLSA · scan de imagem fuzzing · admission control CSPM · realimentação O estágio mais negligenciado é o quinto: um pipeline que não realimenta suas regras com o que escapou para produção não melhora.
10. IDE e Pull Request: feedback antes do custo subir IDE e pré-commit Pull Request Objetivo: feedback antes do commit, sem quebrar o fluxo Objetivo: decisão de mesclagem com evidência • Linters e formatação automática • SAST completo em modo incremental sobre o diff • Secret scanning (Gitleaks, TruffleHog) • SCA das dependências alteradas • Regras SAST leves e incrementais • Análise de IaC (Terraform, Kubernetes) • Pre-commit hooks padronizados no time • Verificação de licenças e revisão assistida por IA Quanto mais cedo o achado, mais barato o conserto — e maior a chance de o autor ainda ter o contexto na cabeça.
11. Build: integridade da cadeia de suprimentos SBOM Assinatura Atestação e SLSA Scan de imagem Inventário completo em CycloneDX ou SPDX, gerado e versionado a cada build. Artefatos assinados com Sigstore/cosign. Sem assinatura válida, não implanta. Proveniência verificável: quem construiu, a partir de qual commit e com qual pipeline. Camadas base, pacotes de SO e configuração do container antes do registry. Na era da alucinação de dependências, saber exatamente o que entrou na build deixou de ser boa prática e virou pré-requisito.
12. Deploy e Runtime: o que só aparece em execução Deploy e ambiente efêmero Runtime e realimentação • DAST autenticado — falhas de autorização estão atrás do login • Detecção de comportamento anômalo em produção • Testes de API a partir da spec OpenAPI/GraphQL • CSPM e correlação com inteligência de ameaças • IAST e fuzzing dirigido • Achados de produção viram novas regras de pipeline • Admission controllers validando política antes do cluster • Métricas de exposição real alimentam a priorização O loop de realimentação é o que diferencia um pipeline maduro de um conjunto avulso de scanners.
13. 01 Quality Gates De métrica única a decisão de risco Por que o gate tradicional falha Os quatro eixos da decisão
14. Por que o quality gate tradicional falha Gate tradicional Gate maduro • Binário e unidimensional: cobertura > 80%, zero críticas • Critério composto: severidade × alcance × exploração × exposição • Ignora contexto de exposição e explorabilidade • Clean as You Code: avalia apenas o código novo ou alterado • Avalia toda a base, inclusive o legado intocado • Política graduada: o que bloqueia, o que avisa, o que só registra • Bloqueia por achado irrelevante — ou é desligado sob pressão • Exceção com responsável nomeado e expiração automática • Exceções sem dono e sem prazo viram permanentes • Proveniência do código marcada (gerado por IA vs. autoral) Um gate que bloqueia tudo é um gate que será contornado. A graduação é o que mantém a política viva.
15. Os quatro eixos de um gate por risco real Severidade Alcançabilidade Explorabilidade Exposição CVSS e classe da falha. O ponto de partida — nunca o critério único. O código vulnerável é de fato invocado? Elimina de 70% a 90% do ruído. EPSS e catálogo KEV da CISA: existe exploração ativa no mundo real? O serviço está na internet? Processa dado sensível ou regulado? A decisão do gate Uma crítica inalcançável em biblioteca interna importa menos que uma média explorada ativamente em endpoint público. O gate não pergunta “qual a nota?” — pergunta “qual o risco de deixar isto entrar em produção hoje?”.
16. 02 SAST · SCA · DAST Uso maduro: menos ruído, mais decisão SAST SCA DAST Correlação e ASPM
17. SAST: rápido no PR, específico da sua organização • Execução incremental sobre o diff — varredura completa a cada commit mata a adoção • Regras customizadas que codificam os padrões proibidos da organização (Semgrep) • Taint analysis: rastrear dado não confiável da fonte até o destino sensível • Triagem assistida por LLM para reduzir o ruído de falso positivo SAST • Autofix proposto como pull request — sugerido pela máquina, aprovado por humano Static Application Security Testing Erro clássico: rodar a varredura completa da base a cada commit. O custo de tempo destrói a confiança no pipeline.
18. SCA: o diferencial não é detectar, é priorizar • Análise de alcançabilidade elimina de 70% a 90% dos achados irrelevantes • SBOM gerado, versionado e verificável a cada build • Dependências transitivas tratadas explicitamente — é onde o risco costuma morar • VEX para comunicar formalmente o que não se aplica ao seu contexto SCA • Atualização automatizada (Renovate, Dependabot) com testes de regressão Software Composition Analysis Função nova e crítica na era da IA: validar que cada pacote sugerido existe, é legítimo, é mantido e tem histórico compatível.
19. DAST: autenticado, ciente de API e em ambiente efêmero • Autenticado — as falhas de autorização estão atrás do login, não na home • Ciente de API: alimentado pela especificação OpenAPI/GraphQL, não por crawling cego • Executado contra ambiente efêmero provisionado pelo próprio pipeline • Complementado por fuzzing dirigido nos endpoints de maior exposição DAST • Encontra o que a estática não vê: configuração, autorização, comportamento de runtime Dynamic Application Security Testing Deixe de rodar apenas semanalmente em homologação: DAST desacoplado do ciclo de entrega gera achados que ninguém corrige.
20. Correlação: uma única fila de risco SAST › Um backlog de risco • Sem duplicidade entre ferramentas SCA › ASPM Deduplicação • Quando as três convergem no mesmo ponto, a confiança na criticidade cresce › • Ordenado por risco real, não por severidade nominal • Vive no Jira, no fluxo do time — não em um portal separado Correlação entre camadas DAST › Priorização por risco Integração com o backlog Três ferramentas gerando três backlogs produzem duplicidade, contradição e abandono.
21. A mesma tecnologia, do lado da defesa Onde a IA amplia a defesa • Triagem automática de achados com explicação em linguagem natural Onde o humano decide • Aceitação de risco e exceções de política • Validação de que a correção resolve a causa, não o sintoma • Correções geradas como PR, com testes que comprovam a mitigação • Decisões arquiteturais e de trade-off • Threat modeling assistido a partir de diagramas e diffs • Responsabilidade formal pelo que vai a produção • Geração de casos de teste e payloads de fuzzing • Definição do apetite de risco da organização • Sumarização de incidentes e de revisões extensas A IA propõe, o humano decide e assina. Aceitar uma correção sem entendê-la reproduz o problema que se quer resolver.
22. Meça o sistema, não a atividade 01 02 03 MTTR de vulnerabilidade Taxa de falha de mudança PRs aprovados no gate na 1ª Por severidade. O indicador mais honesto de maturidade real. Métrica DORA: a velocidade está custando estabilidade? Mede a qualidade do feedback antecipado ao desenvolvedor. 04 05 06 Cobertura de SBOM e assinatura Falso positivo por ferramenta Exceções vencidas em aberto Maturidade da governança da cadeia de suprimentos. Mede a confiança do time — e prevê o abandono do processo. Dívida de risco aceita e nunca revisitada.
23. Em resumo A IA não criou desafios inéditos. Ela comprimiu o tempo para lidar com os que já existiam. 01 02 03 Verifique na mesma velocidade Decida por risco, não por métrica Amplie o julgamento humano Automatizar a produção sem automatizar a verificação é antecipar a dívida. Gates compostos, graduados e aplicados sobre o código novo. Exceção com dono e prazo. Ferramenta nenhuma assume responsabilidade. Automação amplia o julgamento; não o substitui. Velocidade sem verificação é apenas dívida entregue mais cedo.
24. Dúvidas? Contato: diego@diegoneves.eti.br @diegoaceneves Nenhuma IA foi maltratada durante a produção dessa apresentação.