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.
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:
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.
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.
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.
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.
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.-
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). 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.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.
Top comments (0)