Manter a integridade do código é uma preocupação central em qualquer estratégia de segurança de software. Com o aumento de ataques à cadeia de suprimentos e a complexidade das pipelines modernas, garantir que o código fonte e os artefatos não sejam adulterados tornou-se essencial para organizações que adotam DevSecOps. Neste artigo, exploramos o conceito de integridade de código, as principais ameaças e as melhores práticas para proteger seu código contra modificações maliciosas.

O que é integridade de código?

Integridade de código refere-se à garantia de que o código fonte, bibliotecas, dependências e artefatos binários não foram alterados de forma não autorizada. Ela é um dos pilares da segurança da informação (confidencialidade, integridade e disponibilidade). No contexto de desenvolvimento, a integridade assegura que o código que está sendo executado em produção é exatamente o mesmo que foi revisado, testado e aprovado pela equipe. Sem integridade, um atacante pode introduzir backdoors, modificar lógica de negócios ou injetar malware sem que a equipe perceba.

No ambiente DevSecOps, a integridade do código é verificada em múltiplas camadas: desde o commit inicial até a implantação, passando pela construção de artefatos e armazenamento em registries. A adoção de práticas como assinatura de commits, verificação de checksums e atestados de pipeline ajuda a criar uma cadeia de confiança que garante que cada etapa do ciclo de vida do software é segura e rastreável.

Principais ameaças à integridade do código

Compreender as ameaças é o primeiro passo para se proteger. As principais ameaças à integridade do código incluem:

  • Injeção de código malicioso: Atacantes comprometem ambientes de desenvolvimento, estações de trabalho ou contas de desenvolvedor para modificar o código-fonte diretamente. Isso pode ocorrer via malware, engenharia social ou exploração de vulnerabilidades em ferramentas de desenvolvimento.
  • Ataques à cadeia de suprimentos: Dependências externas (pacotes npm, PyPI, bibliotecas Maven, imagens de container) podem ser comprometidas para incluir código malicioso. Exemplos notáveis como o ataque ao repositório Codecov e ao pacote ua-parser-js demonstram o impacto devastador que essas adulterações podem causar.
  • Adulteração de artefatos: Após a build, binários, imagens de container e pacotes podem ser alterados antes do deploy. Se o pipeline de CI/CD não valida a assinatura ou checksum, um artefato modificado pode ser implantado sem detecção.
  • Commits não autorizados: Desenvolvedores mal-intencionados ou contas comprometidas podem realizar pushes que alteram a lógica do software. Sem revisão de código e proteção de branches, essas alterações podem passar despercebidas.
  • Modificação em trânsito: Durante a transferência entre repositórios, registries ou ambientes, os artefatos podem ser interceptados e modificados se não houver canais seguros e verificação de integridade.

Boas práticas para proteger a integridade do seu código

Felizmente, existem práticas consolidadas que ajudam a mitigar essas ameaças. A implementação de controles de integridade ao longo de todo o ciclo de vida do software é fundamental para um programa de segurança eficaz.

Assinatura de código e commits

A assinatura digital de commits (GPG) e de artefatos (Cosign, Jarsigner) permite verificar a autoria e a integridade. Commits assinados garantem que uma alteração veio de uma fonte confiável. Já a assinatura de artefatos permite que o ambiente de implantação confirme que o binário ou imagem não foi alterado desde a build.

Verificação em pipeline de CI/CD

Incluir etapas de verificação de integridade no pipeline é essencial. Ferramentas como in-toto permitem criar atestados que descrevem cada etapa da pipeline, e esses atestados podem ser verificados antes do deploy. Além disso, a verificação de checksums (SHA256) e assinaturas deve ser automatizada.

Geração e verificação de SBOM

O Software Bill of Materials (SBOM) lista todos os componentes e dependências do software. Gerar SBOMs e verificá-los contra vulnerabilidades conhecidas é uma prática recomendada por órgãos como NIST e OWASP. Ferramentas como Syft, CycloneDX e SPDX ajudam a criar SBOMs que podem ser assinados e verificados.

Armazenamento imutável e registries seguros

Utilize repositórios e registries que suportam imutabilidade e verificação de conteúdo. Docker Content Trust (Notary) para imagens de container, e repositórios Git com branches protegidas e push restrito, reduzem a superfície de adulteração.

Revisão de código e controle de acesso

Exigir revisão obrigatória por pares (code review) antes do merge em branches críticas (como main/master) é uma das defesas mais eficazes. Combinado com controle de acesso baseado em função (RBAC) e autenticação multifator (MFA), reduz drasticamente o risco de commits maliciosos.

Integrando a verificação de integridade no pipeline DevSecOps

Em uma cultura DevSecOps, a segurança é integrada em cada etapa do pipeline. A verificação de integridade deve ser contínua e automatizada:

  • Commit: Assinatura GPG obrigatória, hooks de pre-commit para verificar dependências.
  • Build: Geração de SBOM, assinatura de artefatos com cosign, verificação de checksums.
  • Teste: Verificação de integridade de dependências (ex: verificação de assinatura de pacotes npm).
  • Armazenamento: Push para registry imutável com verificação de assinatura (Notary).
  • Deploy: Verificação de atestados in-toto, confirmação de que o artefato corresponde ao aprovado na revisão.

Ferramentas como Sigstore simplificam a assinatura e verificação ao fornecer uma infraestrutura de chave pública transparente e sem necessidade de gerenciamento complexo de chaves. Já o framework TUF (The Update Framework) protege mecanismos de atualização contra adulteração.

Ferramentas essenciais para garantir a integridade do código

Algumas ferramentas se destacam na implementação de práticas de integridade:

  • GPG (GNU Privacy Guard): Para assinar commits e tags no Git.
  • Cosign (parte do Sigstore): Assinatura de imagens de container e outros artefatos.
  • Notary / Docker Content Trust: Verificação de integridade de imagens Docker.
  • in-toto: Atestados de pipeline para garantir que cada etapa foi executada conforme esperado.
  • Sigstore: Assinatura transparente e sem gerenciamento de chaves.
  • Syft / CycloneDX: Geração de SBOM.
  • Grype / Trivy: Varredura de vulnerabilidades em dependências (complementar à integridade).

A escolha das ferramentas depende do ecossistema da sua organização, mas a adoção de pelo menos um mecanismo de assinatura e verificação é fortemente recomendada.

Conclusão

Proteger a integridade do código não é uma tarefa opcional — é um requisito fundamental para a segurança de software, especialmente no contexto de DevSecOps. Ao adotar práticas como assinatura de código, verificação em pipeline e geração de SBOM, as organizações podem reduzir significativamente o risco de ataques à cadeia de suprimentos e garantir que o software implantado é confiável. A implementação dessas medidas requer investimento inicial, mas o retorno em termos de segurança e confiança é imensurável. Comece com pequenos passos: assine seus commits, verifique as dependências críticas e automatize a verificação de integridade na sua pipeline. Seu código (e seus usuários) agradecem.

Perguntas frequentes (FAQ)

O que é integridade de código?

Integridade de código é a garantia de que o código fonte, dependências e artefatos não foram alterados de forma não autorizada. Ela é mantida por meio de assinaturas digitais, checksums e verificações contínuas no pipeline.

Como a assinatura de código ajuda na segurança?

A assinatura de código permite verificar a origem e a integridade do artefato. Se um atacante modificar o código após a assinatura, a verificação falhará, impedindo que o artefato comprometido seja utilizado.

Qual a diferença entre assinatura de commit e assinatura de artefato?

A assinatura de commit (GPG) garante que um commit específico veio de um autor confiável. A assinatura de artefato (Cosign, Jarsigner) garante que o artefato binário ou imagem de container não foi alterado após a build. Ambas são complementares.

O que é SBOM e por que é importante para a integridade?

SBOM (Software Bill of Materials) é uma lista detalhada de todos os componentes e dependências de um software. Ele é importante porque permite rastrear a origem de cada componente e verificar se há versões conhecidas como vulneráveis, além de ajudar na verificação de integridade ao comparar o SBOM gerado com o que está em produção.