Aplicando uma estratégia DevSecOps com Veracode e GitFlow

Nesse artigo, iremos discutir de forma conceitual como podemos construir uma estratégia DevSecOps com as ferramentas da Veracode em um processo de Gitflow.

Os exemplos a seguir não refletem em sua totalidade um ambiente real, pois cada organização adota um processo único que melhor se adequa a sua necessidade mas, os conceitos poderão ajudar no entendimento e aplicação de algo semelhante em seu ambiente.

Recomendamos a leitura desses outros posts para entendimento das funcionalidades das ferramentas de segurança da Veracode caso ainda não conheça.

1. O que é SAST?

2. O que é SCA?

3. Diferentes modos de se realizar SAST com a Veracode

Overview Gitflow

De forma básica, o Gitflow é uma estratégia de desenvolvimento que ajuda na organização do versionamento de código através de branches (ramificações). Ele é recomendado para casos onde possui a necessidade de oferecer suporte a várias versões do softwares e que também tenham várias pessoas trabalhando ("commitando") dentro do repositório.

Conceito do funcionamento

O Gitflow se apoia em duas branches principais: Master e Develop que são permanentes e que mantêm o histórico de versionamento, além de outras branches temporárias de apoio que serão baseadas em uma dessas principais como exemplo: Release, Feature e entre outras.

Cada uma dessas branches possui uma função específica, exemplo:

1. Master branch -> como próprio nome diz, é a principal e armazena o código de produção. Em algum momento as novas funcionalidades estarão atreladas a ela e disponíveis para o público alvo.

2. Develop branch -> possui os novos códigos com funcionalidades desenvolvidos pela equipe e que ainda não estão publicados em produção mas, logo poderão ser associadas à Master branch.

3. Feature branch -> é uma ramificação que tem como base a Develop branch e, é destinada para o desenvolvimento de funcionalidades específicas. Após a finalização, as modificações serão acopladas à Develop e então sumirão.

4. Release -> serve como uma ponte da Develop para Master. Após a realização de testes dentro dessa branch, ocorre a "fusão" com a Master e, caso ocorra alguma modificação, será sincronizada com a Develop

Como inserir segurança nesse fluxo de trabalho?

A imagem abaixo representa o exemplo simples de como podemos inserir análises de segurança durante o desenvolvimento utilizando um fluxo de trabalho já estebelecido.

1. Feature branch
   Nessa branch, podemos aplicar o SAST + SCA para validar os
   novos códigos e bibliotecas que estão entrando na aplicação.
   Dessa forma a aplicação pode já ser construída de forma mais
   segura desde o início da codificação. Podemos fazer o uso dos
   plugins na IDE e da base dados de vulnerabilidades gerenciadas
   da Veracode para pesquisar o histórico de versões das
   bibliotecas mais seguras antes mesmo de importá-las para o
   projeto.

2. Develop branch
   Na branch develop, podemos aplicar uma estratégia muito
   interessante:

   SAST Sandbox Scan:
   para registrar as informações de forma gráfica na
   Plataforma da branch develop e, verificar se alguma
   vulnerabilidade presente nessa versão impactaria as
   políticas de compliance e segurança do Policy Scan de forma
   antecipada apoiando em uma tomada de decisão.

   SAST Pipeline Scan:
   rodando em paralelo com o Sandbox Scan, para ter um
   feedback rápido (aproximadamente de 90 segundos) de quais
   vulnerabilidades estão presentes na aplicação, quais
   riscos associados e também com possibilidade de uma quebra
   de build caso seja identificado um risco alto/grave ou que
   não esteja de acordo com as políticas de compliance e
   segurança. Também há a possibilidade de usarmos o Baseline
   do Pipeline Scan para comparar os resultados SAST
   anteriores com a versão mais recente da aplicação e
   verificar se há nova(s) vulnerabilidades introduzidas.

   SCA:
   para validar os possíveis riscos das bibliotecas externas.

   DAST:
   caso tenha uma versão publicada dessa aplicação em ambiente
   de desenvolvimento, podemos acionar uma trigger na esteira
   para iniciar uma análise dinâmica com escopo bem fechado e
   definido para analisar algumas partes da aplicação (Web ou
   API).

3. Release branch
   Poderíamos repetir os mesmos passos da branch develop, mas agora o time de segurança juntamente a todos os envolvidos, poderiam realizar a gestão de riscos, analisar os relatórios anteriores e verificar se de fato a aplicação está apta para publicação, necessita criar alguma medida de mitigação ou até mesmo aplicar alguma correção para algo mais crítico.
   Nesse momento a ideia é que a aplicação já tenha sido validada pelas ferramentas diversas vezes (SAST + SCA + DAST) e as correções necessárias aplicadas previamente para que esteja pronta para ser lançada.

4. Master branch
   Agora temos a nova versão publicada onde diversas análises e verificações ocorreram durante o ciclo de desenvolvimento com maior garantia de que está mais segura contra ataques.