DEV Community

Cover image for Aplicando uma estratégia DevSecOps com Veracode e GitFlow
Lucas Santos Ferreira for M3Corp

Posted on

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.

Image description

  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.

Top comments (0)