Explore 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 seu ciclo de vida. Essa abordagem transforma a forma como as equipes de segurança interagem com o desenvolvimento, mudando da aprovação manual de cada versão para o monitoramento e auditoria contínuos de todo o processo de CI/CD.

Transformando a conversa sobre 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 lançamentos e não acompanha as frequências de implantação modernas.

Abordagem de DevOps Seguro: As equipes de segurança consentem com o processo de CI/CD em si, em vez de lançamentos individuais. Eles definem requisitos de segurança, implementam validação automatizada e monitoram o processo continuamente. A segurança torna-se integrada em vez de um portão separado.

Benefícios desta mudança:

• As liberações prosseguem automaticamente quando atendem aos critérios de segurança.
• As equipas de segurança concentram-se em melhorar o processo em vez de rever alterações individuais.
• A validação de segurança é dimensionada para dar suporte a várias implantações por dia.
• As trilhas de auditoria documentam automaticamente a validação de segurança.
• Os problemas de segurança são detetados imediatamente, em vez de no momento da revisão.

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

O diagrama abaixo destaca pontos críticos de validação em um pipeline de CI/CD para a construção de aplicativos desde o início:

Implementação gradual: Você pode implementar gradualmente ferramentas de validação de segurança, dependendo da plataforma e do estágio do 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. Introduzir todas as verificações de segurança de uma só vez 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 (deteção secreta, vulnerabilidades conhecidas).
2. Aborde primeiro os resultados em áreas de alto risco.
3. Expanda gradualmente a cobertura para verificações de segurança adicionais.
4. Ajuste as ferramentas para reduzir os falsos positivos antes de adicionar mais verificações.
5. Construa a confiança do desenvolvedor demonstrando o valor da automação de segurança.

Validação da IDE e do pull request

A validação de segurança começa antes que os desenvolvedores confirmem seu código no repositório compartilhado. Essa abordagem de "deslocamento para a esquerda" deteta 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 vulnerabilidades de segurança não sejam introduzidas no processo de CI/CD.

Feedback em tempo real: Os desenvolvedores recebem feedback imediato sobre problemas de segurança enquanto escrevem código:

• As vulnerabilidades de segurança são destacadas diretamente no editor de código.
• As sugestões de práticas de codificaçã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 certos 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 orientação de segurança durante a codificação.
• Plug-ins de segurança IntelliJ IDEA: Plugins focados em segurança analisam o código em tempo real.
• Analisadores de segurança do Visual Studio: Os analisadores integrados detetam problemas de segurança durante o desenvolvimento.

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

• Os problemas são detetados 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 feedback imediato.
• Os problemas de segurança são corrigidos antes que o código seja comprometido, reduzindo as falhas no pipeline.
• O ciclo 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 entre na base de código: O processo de confirmação de código num repositório central deve incluir controlos que impeçam a introdução de vulnerabilidades de segurança.

Políticas de ramificação do Git: Usar o controle de origem do Git no Azure DevOps, GitHub ou plataformas semelhantes com políticas de ramificação fornece uma experiência de confirmação fechada que impõe a validação de segurança:

Aplicação da proteção de ramos: Habilitar políticas de ramificação em ramificações compartilhadas (como principal ou desenvolver) requer uma solicitação pull para iniciar o processo de mesclagem. As confirmações diretas para ramificações protegidas são bloqueadas, garantindo que todas as alterações de código fluam através do processo de validação.

Requisitos de pull request: As solicitações pull devem impor vários requisitos relevantes para a segurança:

Requisito de revisão de código:

• Pelo menos um outro desenvolvedor deve revisar as alterações de código.
• Esta 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 apropriadas de autenticação e autorização.
  • Tratamento seguro de dados sensíveis.
  • Uso correto de bibliotecas e estruturas de segurança.
  • Ausência de segredos ou credenciais codificadas.

Ligação de item de trabalho:

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

Requisito de construção de Integração Contínua (CI):

• Um processo de compilação de CI deve ser bem-sucedido antes que a solicitação pull possa ser mesclada.
• A compilação CI inclui verificações de segurança automatizadas (abordadas na próxima seção).
• Verificações de segurança com falha bloqueiam a mesclagem, impedindo que o código vulnerável entre na ramificação principal.
• Os resultados da compilação são visíveis na solicitação pull, dando contexto de segurança aos revisores.

Verificações de status:

• As ferramentas de segurança externas podem relatar verificações de status em solicitações pull.
• Todas as verificações de status necessárias devem passar antes da fusão.
• As equipes de segurança podem adicionar novas verificações necessárias sem modificar as definições de pipeline.

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

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

• Mínimo de 1 aprovação do revisor (2 para ramos críticos).
• Itens de trabalho que estão vinculados a todas as modificações.
• Validação de compilação bem-sucedida.
• Todos os comentários resolvidos antes da fusão.
• Sucursais atualizadas (devem incorporar as alterações mais recentes antes da fusão).
• Os controlos de estado obrigatórios das ferramentas de segurança foram aprovados.

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

• As verificações de segurança ocorrem antes que o código entre na base de código compartilhada.
• Várias perspetivas analisam o código em busca de problemas de segurança.
• Os registos de auditoria documentam quem aprovou alterações potencialmente arriscadas.
• Os desenvolvedores recebem feedback de segurança dentro de seu fluxo de trabalho normal.
• A equipe cria uma cultura de conscientização de segurança por meio de revisões de código.

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

As solicitações pull podem desencadear análises de segurança automatizadas:

• Análise estática: O código é verificado em busca de vulnerabilidades de segurança.
• Verificações de dependência: Dependências novas ou atualizadas são verificadas quanto a vulnerabilidades conhecidas.
• Deteção de segredos: As verificações detetam credenciais comprometidas acidentalmente.
• Verificações de qualidade do 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 pull, permitindo que revisores e autores resolvam problemas antes da fusão.