Demorei um tempo bom pra decidir como abrir esse texto, porque toda vez que eu tentava resumir DevSecOps numa frase só, saía capenga. Cheguei numa: apesar de pertencerem a rotinas completamente diferentes, cozinha de restaurante e esteira de deploy não têm tantas diferenças assim.
Pensa comigo: uma cozinha que só faz faxina grande na antevéspera da visita da vigilância sanitária tem, tecnicamente, o mesmo problema de um time que só chama o pessoal de segurança pra revisar o código na véspera do deploy pra produção. Fica tudo impecável no dia da inspeção, e uma bagunça em todos os outros 364.
Cara, isso parece exagero, né? Não é. So.. here we go.
O que é DevSecOps
DevSecOps é basicamente meter segurança dentro da esteira de desenvolvimento, ao invés de deixá-la pra depois, como aquele item do backlog que todo mundo empurra porque "dessa vez vai dar certo". Isso tem nome: shift-left. Empurrar a validação de segurança pra mais cedo no ciclo, lá na esquerda da linha do tempo, antes que o commit já esteja em produção e vire dor de cabeça de madrugada.
Um relatório da IBM de 2025 sobre custo de vazamento de dados mostra que uma brecha aberta em ambiente de nuvem pública leva, em média, 251 dias pra ser identificada e contida.
Duzentos e cinquenta e um dias com a porta aberta e ninguém percebendo.
O estrago sai por uns US$ 4,18 milhões, e se o incidente atravessar múltiplos ambientes — nuvem, on-premises, SaaS, tudo junto — a conta sobe pra US$ 5,05 milhões. Não é estatística de slide, é o motivo pelo qual seu gerente de repente virou fã de segurança.
Os 3 Pilares de DevSecOps
1. Shift-Left (SAST e verificação estática)
Ocorre quando você analisa o código antes mesmo dele virar build, procurando vulnerabilidade conhecida, segredo vazado (aquela chave de API esquecida no repositório — já commitei uma sem querer, uma vez, não me orgulho) e dependência desatualizada.
Sugestão: automatize o scan como gate obrigatório do pull request, não como sugestão do time de segurança que "quando der, a gente olha".
2. Segurança como Código (IaC + policy as code)
Ocorre quando a configuração de infraestrutura — bucket S3, security group, IAM role — é escrita, versionada e revisada como qualquer outro código, em vez de configurada manualmente no console da AWS "só dessa vez, depois eu documento". (Ninguém documenta depois.)
Sugestão: use ferramentas como Checkov, tfsec ou o próprio AWS Config pra bloquear infraestrutura mal configurada antes do apply. Existem guardrails automáticos, tipo Service Control Policies, mas nem toda organização os usa. Então: "Take it easy", mas configure.
3. Monitoramento Contínuo (runtime e resposta)
A segurança não acaba no deploy. Ela continua rodando junto com a aplicação em produção, de olho em comportamento anômalo, tentativa de escalonamento de privilégio, tráfego saindo de onde não devia.
Sugestão: visibilidade contínua (GuardDuty, CloudTrail, alerta bem calibrado) importa mais do que qualquer ferramenta cara comprada e esquecida no canto.
Algumas Dicas Extras
- Cuidado redobrado com bucket S3 público. Não importa se é "só um teste" — é o tipo de coisa que vira superfície de ataque enquanto você ainda procura o botão de tornar privado.
- Pegue leve com credencial hardcoded. Em repositório público, ela desenvolve vida própria rapidinho.
- ROTACIONE CREDENCIAL EXPOSTA NA HORA! Um secret vazado em repositório público costuma ser encontrado e testado por scanner automatizado em menos de um minuto.
Caso Real
Em 2019, a Capital One sofreu um dos incidentes mais estudados da história recente de segurança em nuvem: uma configuração incorreta de firewall em um WAF permitiu que uma ex-funcionária da AWS acessasse dados de mais de 100 milhões de clientes, explorando uma instância mal configurada pra assumir uma role com permissão excessiva.
Não foi "hacker genial usando zero-day sofisticado". Foi configuração, permissão de IAM generosa demais e falta de detecção em tempo hábil — os três pilares que a gente acabou de listar, ignorados ao mesmo tempo.
Raramente é uma causa isolada. É sempre uma sequência de pequenas negligências que, empilhadas, viram incidente grande. E o alerta, quando chega, geralmente é tarde: um pesquisador de segurança no Twitter, ou pior, um cliente.
Concluindo
Shift-left não é modinha de conferência. É o básico bem feito, todo santo dia, não só na véspera da auditoria. Terminei de escrever isso e já fui revisar as IAM roles do meu próprio ambiente.
No próximo texto entramos em um serviço específico da AWS e como ele se encaixa nesse ecossistema.
Ship safe, folks.
Top comments (0)