DEV Community

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

Posted on

1

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.

Image of Datadog

Measure and Advance Your DevSecOps Maturity

In this white paper, we lay out a DevSecOps maturity model based on our experience helping thousands of organizations advance their DevSecOps practices. Learn the key competencies and practices across four distinct levels of maturity.

Get The White Paper

Top comments (0)

A Workflow Copilot. Tailored to You.

Pieces.app image

Our desktop app, with its intelligent copilot, streamlines coding by generating snippets, extracting code from screenshots, and accelerating problem-solving.

Read the docs

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay