Aplicando uma estratégia DevSecOps com Veracode e GitFlow
Tags: gitflow, devsecops, development, veracode
Published: 2023-07-24 18:04:36

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?](https://dev.to/m3corp/o-que-e-sast-5213)

2. [O que é SCA?](https://dev.to/m3corp/o-que-e-sca-2j29)

3. [Diferentes modos de se realizar SAST com a Veracode](https://dev.to/m3corp/os-diferentes-modos-de-se-realizar-sast-com-a-veracode-1e8a) 

---

### *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.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/olfyc6pjn16ki25nfn08.png)

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.