Diretriz DevSecOps da OWASP

A Diretriz DevSecOps da OWASP explica como podemos implementar um pipeline seguro e usar as melhores práticas e introduzir ferramentas que podemos usar nesse sentido. Além disso, o projeto procura nos ajudar a promover a cultura de segurança shift-left no nosso processo de desenvolvimento. Este projeto ajuda empresas de todos os tamanhos que possuem um pipeline de desenvolvimento ou, por outras palavras, possuem um pipeline DevOps. Procuramos traçar uma perspetiva de um pipeline DevOps seguro durante este projeto e depois melhorá-lo com base nos nossos requisitos personalizados.

O objetivo ideal é "detetar problemas de segurança (por conceção ou vulnerabilidade da aplicação) o mais cedo possível."

Como a diretriz está organizada

A diretriz está construída em torno de três pilares:

• Pessoas — equipas, funções, cultura e formação.
• Processo — atividades de segurança integradas em todas as fases do SDLC: Design, Develop, Build, Test, Release, Deploy, Operate.
• Governança — conformidade, policy as code, relatórios, ASPM e governança de IA.

A edição atual foi atualizada para 2025/2026 e está alinhada com frameworks como NIST SSDF, OWASP SAMM, OWASP DSOMM e SLSA. Consulte o Índice abaixo, ou navegue pela versão atual.

Passos iniciais

DevSecOps consiste em colocar segurança no DevOps. Mas para acompanhar o ritmo do CI/CD, a segurança tem de ser injetada precocemente na escrita e no teste de software.

O OWASP Proactive Controls lista os 10 principais controlos de segurança que cada programador tem de implementar ao programar qualquer aplicação. Considere este conjunto como o ponto de partida quando tiver de conceber, escrever ou testar código no ciclo DevSecOps.

Também pode seguir o OWASP Software Assurance Maturity Model (SAMM) para estabelecer o que considerar em termos de requisitos de segurança (e mais) de acordo com o seu nível de maturidade.

O que adicionar num pipeline

Inicialmente, consideramos implementar os seguintes passos num pipeline básico:

• Analisar repositórios git para encontrar potenciais fugas de credenciais.
• SCA (Software Composition Analysis)
• SAST (Static Application Security Test)
• Análise de IaC (análise de código Terraform, HelmChart para encontrar más configurações)
• Segurança da cadeia de fornecimento de software (SBOM, assinatura de artefactos e proveniência, segurança do pipeline CI/CD)
• IAST (Interactive Application Security Testing)
• Segurança de API
• DAST (Dynamic Application Security Test)
• CNAPP (Cloud Native Application Protection)
• Análise de infraestrutura
• Análise contínua a partir de outras ferramentas
• Verificação de conformidade e policy as code
• Portões de segurança (quality gates que bloqueiam builds e releases de risco)
• Relatórios centralizados e ASPM (Application Security Posture Management)
• Segurança de IA/LLM e governança de IA (proteger o desenvolvimento assistido por IA e funcionalidades com IA)

Podemos personalizar os passos do nosso pipeline de acordo com o nosso Software Development Life Cycle (SDLC) ou arquitetura de software e adicionar automação progressivamente se estivermos a começar. Por exemplo, podemos passar de SAST/DAST para uma suite de testes regular com controlos de segurança incorporados ou adicionar um script de auditoria que verifica dependências vulneráveis conhecidas.

CI/CD é uma vantagem para o SecOps, um ponto de entrada privilegiado para medidas e controlos de segurança. No entanto, ao usar ferramentas de CI/CD para fornecer automação, tenha em mente que as próprias ferramentas frequentemente ampliam a sua superfície de ataque, por isso coloque controlos de segurança no software de build, deployment e automação.

---

Índice