Explorar os principais pontos de validação

A validação contínua de segurança deve ser integrada em cada etapa desde o desenvolvimento até a produção para garantir que os aplicativos permaneçam seguros durante todo o ciclo de vida. Essa abordagem transforma como as equipes de segurança interagem com o desenvolvimento, mudando da aprovação manual de cada versão para o monitoramento contínuo e a auditoria de todo o processo de CI/CD.

Transformando a discussão de segurança

Abordagem tradicional: As equipes de segurança revisam e aprovam manualmente cada versão antes que ela possa prosseguir para a produção. Isso cria gargalos, atrasa versões e não é dimensionado com frequências de implantação modernas.

Abordagem segura do DevOps: As equipes de segurança consentem com o processo de CI/CD em si, em vez de versões individuais. Eles definem requisitos de segurança, implementam a validação automatizada e monitoram o processo continuamente. A segurança se torna integrada em vez de uma porta separada.

Benefícios dessa mudança:

• As versões passam para o estágio seguinte automaticamente quando atendem aos critérios de segurança.
• As equipes de segurança se concentram em melhorar o processo em vez de revisar as alterações individuais.
• A validação de segurança é dimensionada para dar suporte a várias implantações por dia.
• Auditoria de trilhas documenta a validação de segurança automaticamente.
• Problemas de segurança são detectados imediatamente em vez de em tempo de revisão.

Pontos críticos de validação no fluxo de trabalho

O diagrama a seguir realça os pontos de validação críticos em um pipeline de CI/CD para criar aplicativos do zero:

Implementação gradual: Você pode implementar gradualmente as ferramentas de validação de segurança dependendo da plataforma e do estágio de ciclo de vida do aplicativo. Essa abordagem em fases é especialmente importante se o produto estiver maduro e você não tiver executado anteriormente a validação de segurança em seu site ou aplicativo. A introdução de todas as verificações de segurança ao mesmo tempo pode sobrecarregar as equipes com descobertas.

Estratégia de priorização: Ao implementar a validação de segurança em aplicativos existentes:

1. Comece com as verificações de segurança mais críticas (detecção de segredo, vulnerabilidades conhecidas).
2. Resolva os achados em áreas de alto risco primeiro.
3. Expanda gradualmente a cobertura para verificações de segurança adicionais.
4. Ajuste as ferramentas para reduzir falsos positivos antes de adicionar mais verificações.
5. Crie confiança do desenvolvedor demonstrando o valor da automação de segurança.

Validação de IDE e solicitação de pull

A validação de segurança começa antes que os desenvolvedores confirmem seu código no repositório compartilhado. Essa abordagem "shift left" captura os problemas o mais cedo possível quando eles são mais fáceis e menos caros de corrigir.

Verificações de segurança no nível do IDE

Análise de código estático no IDE: As ferramentas de análise de código estático integradas ao IDE fornecem a primeira linha de defesa para garantir que as vulnerabilidades de segurança não sejam introduzidas no processo de CI/CD.

Comentários em tempo real: Os desenvolvedores recebem comentários imediatos sobre problemas de segurança enquanto escrevem código:

• As vulnerabilidades de segurança são realçadas diretamente no editor de código.
• Sugestões para práticas de programação seguras aparecem à medida que os desenvolvedores digitam.
• Correções rápidas para problemas comuns de segurança estão disponíveis com um único clique.
• As explicações ajudam os desenvolvedores a entender por que determinados padrões são problemáticos.

Exemplo de ferramentas de segurança do IDE:

• Extensões de segurança do Visual Studio Code: Extensões como Snyk, SonarLint e GitHub Copilot fornecem diretrizes de segurança durante a codificação.
• Plug-ins de segurança intelliJ IDEA: Plug-ins focados em segurança analisam o código em tempo real.
• Analisadores de segurança do Visual Studio: Analisadores internos detectam problemas de segurança durante o desenvolvimento.

Benefícios das verificações no nível do IDE:

• Os problemas são flagrados quando o código está sendo escrito, não dias ou semanas depois.
• Os desenvolvedores aprendem práticas de codificação seguras por meio de comentários imediatos.
• Os problemas de segurança são corrigidos antes que o código seja integrado, reduzindo as falhas no pipeline.
• O circuito de feedback é medido em segundos, não em horas ou dias.

Controles de confirmação do repositório

Impedindo que o código vulnerável insira a base de código: O processo de confirmação de código em um repositório central deve ter controles que impedem que vulnerabilidades de segurança sejam introduzidas.

Políticas de branch do Git: Usar o controle do código-fonte git no Azure DevOps, no GitHub ou em plataformas semelhantes com políticas de branch fornece uma experiência de confirmação fechada que impõe a validação de segurança:

Imposição de proteção de ramificação: habilitar políticas de branch em branches compartilhados (como principal ou desenvolvimento) requer uma pull request para iniciar o processo de mesclagem. As confirmações diretas em branches protegidos são bloqueadas, garantindo que todas as alterações de código fluam por meio do processo de validação.

Requisitos de solicitação de pull: As solicitações de pull devem impor vários requisitos relevantes à segurança:

Requisito de revisão de código:

• Pelo menos um outro desenvolvedor deve examinar as alterações de código.
• Essa revisão manual é crucial para identificar problemas de segurança que as ferramentas automatizadas podem perder.
• Os revisores devem procurar especificamente por preocupações de segurança, incluindo:
  • Validação de entrada adequada.
  • Verificações de autenticação e autorização apropriadas.
  • Manipulação segura de dados confidenciais.
  • Uso correto de bibliotecas e estruturas de segurança.
  • Ausência de segredos ou credenciais embutidos em código.

Vinculação de item de trabalho:

• As confirmações devem ser vinculadas a itens de trabalho (histórias, tarefas, bugs) para auditoria.
• Essa vinculação documenta por que a alteração de código foi feita.
• Trilhas de auditoria ajudam as equipes de segurança a entender o contexto das alterações durante investigações de incidentes.
• A vinculação de item de trabalho permite a rastreabilidade de requisitos até a implantação.

Requisito de compilação de CI (integração contínua):

• Um processo de build de CI deve ser bem-sucedido antes que o pull request possa ser integrado.
• O build de CI inclui verificações de segurança automatizadas (abordadas na próxima seção).
• As falhas nas verificações de segurança bloqueiam a integração, impedindo que o código vulnerável entre no branch principal.
• Os resultados da compilação são visíveis na solicitação de pull, dando contexto de segurança aos revisores.

Verificações de status:

• Ferramentas de segurança externas podem fornecer relatórios de verificações de status em solicitações de pull.
• Todas as verificações de status necessárias devem ser aprovadas antes da mesclagem.
• Equipes de segurança podem adicionar novas verificações necessárias sem modificar as configurações de pipeline.

Exemplo de configuração de política de branch:

No Azure DevOps ou no GitHub, as políticas de branch podem exigir:

• Mínimo de 1 aprovação do revisor (2 para branches críticos).
• Itens de trabalho vinculados a todas as alterações.
• Validação de build bem-sucedida.
• Todos os comentários resolvidos antes da mesclagem.
• Branches atualizados (devem incorporar as alterações mais recentes antes da mesclagem).
• Verificações de status necessárias das ferramentas de segurança que passam.

Benefícios da validação da solicitação de pull:

• As verificações de segurança ocorrem antes que o código insira a base de código compartilhada.
• Várias perspectivas analisam o código para problemas de segurança.
• Documento de trilhas de auditoria que aprovou alterações potencialmente arriscadas.
• Os desenvolvedores recebem comentários de segurança dentro de seu fluxo de trabalho normal.
• A equipe cria uma cultura de reconhecimento de segurança por meio de revisões de código.

Verificações de segurança automatizadas em solicitações de pull:

As solicitações de pull podem disparar a análise de segurança automatizada:

• Análise estática: O código é verificado quanto a vulnerabilidades de segurança.
• Verificações de dependência: Dependências novas ou atualizadas são verificadas quanto a vulnerabilidades conhecidas.
• Detecção de segredo: Verificações detectam credenciais confirmadas acidentalmente.
• Verificações de qualidade de código: A análise identifica problemas de qualidade de código que podem levar a problemas de segurança.

Os resultados aparecem diretamente na interface de solicitação de pull, permitindo que revisores e autores resolvam problemas antes da mesclagem.