A segurança sempre foi um desafio no desenvolvimento de software, mas com a adoção de práticas DevOps, a necessidade de integrar segurança de forma contínua se tornou ainda mais crítica. O modelo tradicional, onde a segurança era aplicada apenas no final do ciclo de desenvolvimento, não é mais suficiente. Nesta aula, vamos explorar o conceito de DevSecOps, que propõe a incorporação da segurança desde o início do processo, conhecido como shift left, e como construir pipelines seguros com regras de qualidade automatizadas.

DevSecOps

DevSecOps é uma extensão do DevOps que integra práticas de segurança em todas as fases do ciclo de vida do desenvolvimento de software. O objetivo é automatizar a segurança, tornando-a uma responsabilidade compartilhada entre todos os envolvidos: desenvolvedores, operações e equipes de segurança. Em vez de tratar a segurança como uma etapa separada, no DevSecOps ela é incorporada desde a concepção até a produção, garantindo que vulnerabilidades sejam identificadas e corrigidas precocemente.

Para implementar DevSecOps, é necessário adotar ferramentas que se integrem ao pipeline de CI/CD, como scanners de vulnerabilidades, análise de composição de software (SCA), análise estática (SAST) e análise dinâmica (DAST). Além disso, é fundamental criar uma cultura de segurança onde todos são responsáveis. Por exemplo, um desenvolvedor pode usar uma ferramenta de SAST localmente antes de enviar o código, enquanto o pipeline pode executar verificações adicionais de forma automática.

# Exemplo de comando para análise estática com Semgrep
semgrep --config=auto src/

Shift left

O termo "shift left" refere-se à prática de mover a segurança para as fases iniciais do ciclo de desenvolvimento, ou seja, "para a esquerda" no fluxo de trabalho. Em vez de esperar até o final para testar a segurança, as verificações são realizadas desde a escrita do código, durante a integração, e continuamente. Isso reduz custos e tempo de correção, pois encontrar um bug ou vulnerabilidade no início é muito mais barato do que corrigi-lo em produção.

Exemplos de práticas shift left incluem: revisões de código com foco em segurança, análise estática de código (SAST) integrada ao IDE, testes de segurança unitários e treinamento de desenvolvedores em segurança. Ferramentas como SonarQube, Checkmarx e Snyk podem ser configuradas para executar varreduras a cada commit. Um exemplo prático é usar um hook de pré-commit que executa um linter de segurança:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.16.1
    hooks:
      - id: gitleaks

Pipeline seguro

Um pipeline seguro é a espinha dorsal do DevSecOps. Ele deve incluir etapas automatizadas de segurança que são executadas a cada alteração no código. Isso envolve desde a verificação de dependências vulneráveis até a análise de configuração de infraestrutura. Um pipeline típico pode ter as seguintes etapas: commit, análise estática, verificação de dependências, build, testes unitários, análise dinâmica, e deploy, todas com verificações de segurança.

Para construir um pipeline seguro, é importante definir políticas que bloqueiem o progresso se certos critérios não forem atendidos. Por exemplo, se uma vulnerabilidade crítica for encontrada, o pipeline deve falhar. Ferramentas como Jenkins, GitLab CI, GitHub Actions e Azure DevOps permitem integrar gateways de segurança. Abaixo um exemplo de pipeline no GitHub Actions que executa um scanner de vulnerabilidades:

name: Security Scan
on: [push]
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Snyk
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

Regras de qualidade

As regras de qualidade no contexto de segurança são critérios que o código e a infraestrutura devem atender para serem considerados seguros. Elas podem incluir: cobertura de testes de segurança, ausência de vulnerabilidades conhecidas, conformidade com padrões (como OWASP Top 10), e uso de boas práticas de configuração. Essas regras são implementadas como gates no pipeline, que bloqueiam a entrega se não forem cumpridas.

Por exemplo, uma regra de qualidade pode ser: "nenhuma dependência com vulnerabilidade crítica pode ser usada". Para implementar isso, pode-se usar ferramentas como OWASP Dependency-Check ou Snyk. Outra regra pode ser: "o código deve passar por análise estática com zero alertas de alta severidade". É importante que essas regras sejam definidas em conjunto com a equipe e revisadas periodicamente. Exemplo de configuração de regra no SonarQube:

sonar.exclusions=**/*.test.js
sonar.coverage.exclusions=**/*.test.js
sonar.qualitygate.wait=true
sonar.qualitygate.timeout=300

Boas práticas e observações finais

Para implementar DevSecOps com sucesso, comece pequeno: integre uma ferramenta de segurança no pipeline existente e vá adicionando mais etapas gradualmente. Promova a cultura de segurança através de treinamentos e compartilhamento de responsabilidades. Lembre-se de que segurança não é um produto, mas um processo contínuo. Automatize o máximo possível, mas mantenha supervisão humana para casos complexos.

Referências

Exercícios

  1. Explique o conceito de "shift left" e dê um exemplo prático de como aplicá-lo no desenvolvimento de software.

    2. ✓ Resposta: Shift left significa mover a segurança para as fases iniciais do ciclo de desenvolvimento. Exemplo: incluir análise estática de segurança (SAST) no IDE do desenvolvedor, como usar o plugin do SonarLint para detectar vulnerabilidades antes do commit.
  2. Cite três ferramentas que podem ser usadas em um pipeline DevSecOps e para que serve cada uma.

    3. ✓ Resposta: 1. SonarQube: análise estática de código para detectar bugs e vulnerabilidades. 2. Snyk: verificação de dependências para encontrar vulnerabilidades conhecidas. 3. OWASP ZAP: teste de segurança dinâmico (DAST) para identificar falhas em aplicações web.
  3. Descreva como você configuraria um gate de segurança em um pipeline de CI/CD para impedir o deploy se uma vulnerabilidade crítica for encontrada.

    4. ✓ Resposta: Usaria uma ferramenta como Snyk ou Dependency-Check no pipeline. Configuraria para falhar se alguma vulnerabilidade de severidade crítica for encontrada. Exemplo no GitHub Actions: usar a ação 'snyk/actions/node' com 'args: --severity-threshold=critical' e definir 'continue-on-error: false'.
  4. Qual a diferença entre SAST e DAST? Dê um exemplo de ferramenta para cada.

    5. ✓ Resposta: SAST (Static Application Security Testing) analisa o código fonte sem executá-lo, identificando vulnerabilidades como injeção de SQL. Exemplo: Checkmarx. DAST (Dynamic Application Security Testing) testa a aplicação em execução, simulando ataques. Exemplo: OWASP ZAP.
  5. Por que é importante ter regras de qualidade de segurança automatizadas? Dê um exemplo de uma regra que poderia ser implementada.

    6. ✓ Resposta: Automatizar regras de qualidade garante consistência e rapidez na detecção de problemas. Exemplo de regra: "Nenhuma dependência com vulnerabilidade de alta severidade pode ser utilizada". Essa regra pode ser implementada com Snyk, bloqueando o build se detectar uma vulnerabilidade de alta severidade.