DEV Community: M3Corp

Monitoramento

SE Team — Tue, 06 Feb 2024 15:00:00 +0000

Monitoramento em um contexto de DevOps é uma prática essencial para garantir a performance, confiabilidade e eficiência dos sistemas de software ao longo do ciclo de vida do desenvolvimento, implantação e operações. A abordagem de monitoramento em DevOps visa fornecer visibilidade contínua sobre o desempenho do sistema, identificar problemas rapidamente e permitir a tomada de decisões informadas para melhorar a qualidade e a entrega contínua de software.

Aqui estão alguns aspectos importantes do monitoramento em DevOps:

Monitoramento de Aplicações:
- Objetivo: Acompanhar o desempenho e a disponibilidade das aplicações em tempo real.
- Ferramentas: Uso de ferramentas como Prometheus, New Relic, AppDynamics, entre outras, para monitorar métricas como tempo de resposta, taxa de erros e utilização de recursos.
Monitoramento de Infraestrutura:
- Objetivo: Avaliar a saúde e o desempenho dos recursos de infraestrutura, incluindo servidores, redes e bancos de dados.
- Ferramentas: Ferramentas como Grafana, Nagios, ou Prometheus para monitorar recursos de infraestrutura, identificar gargalos e prevenir falhas.
Logs e Análise de Logs:
- Objetivo: Agregar, analisar e visualizar logs para identificar eventos importantes e diagnosticar problemas.
- Ferramentas: ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, ou Graylog para coleta e análise de logs.
Monitoramento de Segurança (DevSecOps):
- Objetivo: Identificar atividades suspeitas, vulnerabilidades e garantir a conformidade com políticas de segurança.
- Ferramentas: Ferramentas de monitoramento de segurança, como Wazuh ou Falco, para detectar anomalias e ameaças.
Monitoramento de Desempenho de Código (APM - Application Performance Monitoring):
- Objetivo: Rastrear o desempenho do código em produção para otimizar e corrigir possíveis problemas.
- Ferramentas: Ferramentas APM, como New Relic, Dynatrace ou Zipkin, para análise de desempenho do código.
Monitoramento de Containers e Orquestradores:
- Objetivo: Acompanhar o desempenho e a saúde de containers e orquestradores como Kubernetes.
- Ferramentas: Ferramentas específicas para monitoramento de containers, como cAdvisor ou Prometheus para Kubernetes.
Alertas e Ações Automáticas:
- Objetivo: Configurar alertas para notificar equipes sobre eventos críticos e, se possível, automatizar ações corretivas.
- Ferramentas: Integração com sistemas de alerta como PagerDuty, OpsGenie, ou sistemas de automação para correção automática.
Coleta de Métricas e KPIs:
- Objetivo: Definir e monitorar métricas e indicadores-chave de desempenho (KPIs) relevantes para os objetivos do negócio.
- Ferramentas: Uso de ferramentas de coleta e visualização de métricas como Grafana, Prometheus, ou InfluxDB.
Integração Contínua com Monitoramento:
- Objetivo: Integrar práticas de monitoramento no pipeline de integração contínua para garantir que problemas sejam identificados antes da produção.
- Ferramentas: Integração com ferramentas de CI/CD e automação.

O monitoramento em DevOps é um componente crítico para garantir a qualidade e a disponibilidade contínua dos sistemas, permitindo uma abordagem proativa na identificação e resolução de problemas.

Containers vs VMs

SE Team — Mon, 05 Feb 2024 15:00:00 +0000

Containers e Máquinas Virtuais (VMs) são duas abordagens diferentes para virtualização e isolamento de ambientes de execução. Aqui estão as principais diferenças entre containers e VMs:

Containers:

Eficiência de Recursos:
- Containers: Compartilham o mesmo kernel do sistema operacional hospedeiro, o que torna sua inicialização mais rápida e consome menos recursos em comparação com VMs.
- VMs: Cada máquina virtual possui seu próprio sistema operacional e kernel, resultando em maior consumo de recursos.
Isolamento:
- Containers: Oferecem isolamento de processos e recursos, mas compartilham o mesmo kernel. Isso implica em um nível de isolamento menor se comparado às VMs.
- VMs: Proporcionam um nível mais alto de isolamento, pois cada VM possui seu próprio sistema operacional independente.
Portabilidade:
- Containers: São altamente portáteis, já que encapsulam apenas as dependências específicas da aplicação, tornando fácil mover containers entre ambientes.
- VMs: Têm uma portabilidade relativamente maior em comparação com ambientes físicos, mas são geralmente mais pesadas e menos flexíveis.
Escalabilidade:
- Containers: São ideais para escalonamento horizontal, permitindo a execução de múltiplas instâncias do mesmo container em diferentes hosts.
- VMs: O escalonamento horizontal pode ser mais desafiador devido ao maior consumo de recursos e tempo de inicialização mais longo.

Máquinas Virtuais (VMs):

Overhead:
- Containers: Têm menos overhead, pois compartilham recursos do sistema operacional hospedeiro.
- VMs: Têm mais overhead, pois cada VM inclui seu próprio sistema operacional completo e uma camada de hypervisor para gerenciar as VMs.
Flexibilidade de Sistema Operacional:
- Containers: Normalmente são usados para isolar aplicações em um único sistema operacional.
- VMs: Oferecem maior flexibilidade, permitindo a execução de diferentes sistemas operacionais em diferentes VMs no mesmo host.
Segurança:
- Containers: Têm um nível menor de isolamento em comparação com VMs, o que pode ser uma consideração importante em ambientes de segurança crítica.
- VMs: Oferecem um isolamento mais robusto entre máquinas virtuais, tornando-se uma opção preferida em ambientes que exigem alta segurança.
Ambiente de Desenvolvimento:
- Containers: São populares em ambientes de desenvolvimento devido à rápida inicialização e facilidade de uso.
- VMs: Podem ser mais apropriadas para ambientes que exigem a execução de sistemas operacionais diferentes ou configurações complexas.

Ambos os containers e VMs têm seus lugares e casos de uso específicos, e a escolha entre eles depende das necessidades e requisitos específicos de cada aplicação e ambiente. Em muitos casos, as organizações utilizam uma combinação de ambas as tecnologias para obter os benefícios desejados.

O que são Containers

SE Team — Fri, 02 Feb 2024 15:00:00 +0000

Containers são uma forma leve e portátil de empacotar, distribuir e executar aplicativos. Eles encapsulam o código, suas dependências e configurações em um ambiente isolado, tornando-os consistentes e executáveis em qualquer ambiente que suporte a tecnologia de containers. Diferentemente de máquinas virtuais, os containers compartilham o kernel do sistema operacional hospedeiro, o que os torna mais eficientes em termos de recursos e mais rápidos para iniciar.

Componentes Principais de Containers:

Imagens:
- Representam um pacote executável que inclui o código, bibliotecas, dependências e configurações necessárias para executar um aplicativo. Imagens são usadas para criar containers.
Containers:
- Instâncias em execução de uma imagem. Cada container é isolado dos outros e do sistema operacional hospedeiro, mas compartilha o mesmo kernel.
Docker (ou outras plataformas de containers):
- Ferramenta popular para criar, distribuir e executar containers. Docker simplifica o processo de gerenciamento de containers, fornecendo uma interface fácil de usar.

Usos Comuns de Containers:

Desenvolvimento e Ambientes de Teste:
- Os desenvolvedores podem empacotar suas aplicações juntamente com todas as dependências em containers, garantindo consistência entre os ambientes de desenvolvimento, teste e produção.
Implantação de Aplicações:
- Containers tornam a implantação de aplicações consistente e fácil de gerenciar. Eles podem ser movidos entre ambientes sem alterações significativas.
Microservices:
- Facilitam a implementação de arquiteturas de microservices, onde diferentes componentes da aplicação são executados em containers independentes.
Escalonamento Horizontal:
- Containers permitem o escalonamento horizontal, adicionando ou removendo instâncias do aplicativo conforme necessário para lidar com variações de carga.
Orquestração de Containers:
- Ferramentas como Kubernetes são usadas para orquestrar a implantação, gerenciamento e escalonamento automático de containers em ambientes de produção.
Ambientes Isolados:
- Containers fornecem isolamento eficiente, garantindo que as aplicações não interfiram umas nas outras ou no sistema operacional hospedeiro.
Atualizações e Rollbacks:
- Facilitam a implementação de atualizações e rollbacks de forma rápida e reversível, garantindo a continuidade do serviço.
Computação em Nuvem:
- São amplamente usados em ambientes de computação em nuvem para facilitar a migração e execução de aplicações em diferentes provedores de nuvem.

Em resumo, containers oferecem flexibilidade, eficiência e consistência no desenvolvimento, implantação e operação de aplicações, tornando-se uma tecnologia essencial na infraestrutura moderna de TI.

CI, CD e as esteiras

SE Team — Thu, 01 Feb 2024 18:36:43 +0000

Vamos entender o que são CI, CD e como as esteiras de deploy (ou pipelines CI/CD) se encaixam:

Integração Contínua (CI):
- Definição: CI refere-se à prática de integrar e testar automaticamente o código produzido pelos desenvolvedores em um repositório compartilhado. Esse processo é acionado sempre que há uma alteração no código-fonte.
- Objetivo: Identificar rapidamente e corrigir conflitos de integração, erros de código ou problemas de compatibilidade, garantindo que a base de código seja sempre funcional.
Entrega Contínua (CD):
- Definição: CD é uma extensão da CI e envolve a automação do processo de entrega do software até ambientes de produção. Isso inclui testes adicionais, como testes de aceitação do usuário, e a capacidade de implantar automaticamente no ambiente de produção.
- Objetivo: Possibilitar a entrega contínua de software pronto para produção, garantindo que as alterações de código sejam entregues rapidamente e de forma confiável.
Esteiras de Deploy (Pipelines CI/CD):
- Definição: Esteiras de deploy são conjuntos automatizados de processos (pipelines) que incorporam CI e CD. Elas automatizam desde a integração e teste de código até a entrega e implantação em ambientes de produção.
- Funcionamento: As esteiras de deploy são geralmente compostas por estágios, onde cada estágio representa uma fase do processo. Esses estágios podem incluir compilação, testes automatizados, implantação em ambientes de pré-produção e, finalmente, implantação em produção.
- Benefícios: Reduzem erros manuais, aceleram a entrega, proporcionam feedback rápido, garantem consistência nas implantações e permitem a rápida detecção de problemas.

Fluxo típico em uma Esteira de Deploy (Pipeline CI/CD):

Integração (CI):
- Desenvolvedores fazem push de código.
- Esteira de CI é acionada automaticamente.
- Compilação e testes automatizados são executados.
Entrega (CD):
- Se os testes de CI passam, a esteira de CD é acionada.
- Testes adicionais (como testes de integração e aceitação) são executados.
- Se bem-sucedido, o software é implantado automaticamente em ambientes de pré-produção.
- Testes finais são conduzidos.
Implantação em Produção:
- Se todos os testes passam, o software é implantado automaticamente em produção.

Benefícios:

Rapidez: Reduz o tempo entre o desenvolvimento e a entrega em produção.
Consistência: Garante a consistência nas implantações.
Qualidade: Facilita a detecção precoce de erros.
Automatização: Minimiza a intervenção manual, reduzindo erros humanos.

Em resumo, CI, CD e esteiras de deploy são fundamentais para a prática DevOps, permitindo uma entrega de software rápida, confiável e de alta qualidade.

Veracode & AzDevOps: Trabalhando com Task Groups

Ivo Dias — Thu, 01 Feb 2024 18:32:09 +0000

O recurso de Task Groups pode ser muito útil para agilizar implementações. Nossa ideia com esse artigo é trabalhar com dois já prontos, para os cenários onde temos Frontends em JavaScript e Backends em .NET.
Sempre recomendamos a leitura do guia de empacotamento e do nosso GitHub com exemplos, para otimizar o processo e modifica-lo caso tenha uma necessidade diferente da que temos nesse exemplo.

Importando os TGs
Em nosso REPO, já temos os dois modelos que vamos utilizar prontos:

.NET (PRD/SB)
JS (PRD/SB)

O fluxo deles vai ser bem parecido:

Criar o pacote dos arquivos para analise
Iniciar o scan com o Wrapper
Fazer a analise SCA e retornar os resultados para o Pipeline
Fazer a analise SAST e retornar os resultados para o Pipeline

A principal diferença é que no caso do .NET vamos empacotar apenas as DLLs e PDBs, conforme o guia de empacotamento.

Um outro ponto principal é que vamos ter as versões PRD e SB:
PRD -> Usamos sempre que é o scan do que vai subir para produção
SB -> Para todos os outros casos

Por exemplo, caso eu tenha três ambientes (DEV, HML e PRD) organizados em pipelines distintos, eu vou utilizar o TG de PRD para o respectivo e o SB para DEV e HML. Com isso, nossos resultados na plataforma vão ficar organizados.

Parâmetros dos TGs
Nos dois modelos de TGs, vamos ter em comum as seguintes variáveis:

caminhoPacote -> Caminho do pacote criado para a analise
veracodeAppProfile -> Nome do projeto
VeracodeID -> Credencial da Veracode
VeracodeKey -> Credencial da Veracode
VeracodeSCA -> Credencial do SCA

Para os TGs de Sandbox (SB), vamos ter uma extra:

nomeAmbiente -> Onde colocamos o nome do ambiente (DEV, QA, HML..)

Você pode deixar as variáveis já definidas no próprio TG (por padrão a de caminhoPacote já vem) ou gerar um grupo de variáveis para alimenta-las.

Como utilizar?
Importe os TGs para o seu ambiente do Azure conforme a documentação da Microsoft, depois em seu pipeline, busque por ele como se fosse uma Task.

Esses TGs de modelo foram criados para Linux/Mac, mas é possível utiliza-los em Windows com pequenas modificações.

Cultura DevOps

SE Team — Thu, 01 Feb 2024 18:30:22 +0000

A cultura DevOps é uma abordagem colaborativa que visa integrar as equipes de desenvolvimento (Dev) e operações (Ops), promovendo a automação, comunicação eficaz e responsabilidade compartilhada. O objetivo é melhorar a eficiência, acelerar o ciclo de vida do desenvolvimento e garantir a entrega de software de alta qualidade. Aqui estão os principais pontos para aprender sobre a cultura DevOps:

Colaboração:
- Princípio: Promover a colaboração entre equipes de desenvolvimento, operações e outras partes interessadas.
Automação:
- Princípio: Automatizar processos para acelerar a entrega, reduzir erros e melhorar a consistência.
Entrega Contínua:
- Princípio: Implementar práticas que permitam a entrega de software de forma rápida, segura e sustentável.
Infraestrutura como Código (IaC):
- Princípio: Codificar a infraestrutura para garantir consistência, rastreabilidade e facilidade de gerenciamento.
Monitoramento e Feedback:
- Princípio: Implementar monitoramento contínuo para obter feedback rápido sobre o desempenho do sistema e identificar problemas rapidamente.
Responsabilidade Compartilhada:
- Princípio: Todos os membros da equipe têm responsabilidade pela qualidade e segurança do software em todas as fases do desenvolvimento.
Ciclo de Melhoria Contínua:
- Princípio: Buscar constantemente melhorias nos processos, ferramentas e colaboração para otimizar o desempenho.

Principais Pontos para Aprender em DevOps:

Automação de CI/CD:
- Aprender: Ferramentas como Azure DevOps, GitLab CI, ou GitHub Actions para automatizar a integração contínua e entrega contínua.
Ferramentas de Controle de Versão:
- Aprender: Git para gerenciamento eficaz de versões e colaboração.
Monitoramento e Logging:
- Aprender: Ferramentas como Prometheus, ELK Stack (Elasticsearch, Logstash, Kibana) para monitoramento e análise de logs.
Infraestrutura como Código (IaC):
- Aprender: Ferramentas como Terraform, Ansible ou Chef para automatizar a configuração da infraestrutura.
Cultura de Segurança:
- Aprender: Integrar práticas de segurança desde o início do ciclo de vida do desenvolvimento (DevSecOps).
Colaboração e Comunicação:
- Aprender: Ferramentas de comunicação como Slack e práticas de colaboração eficazes.
Ciclo de Vida do Desenvolvimento:
- Aprender: Compreender e participar de todo o ciclo de vida do desenvolvimento, desde a concepção até a entrega.
Cultura de Feedback:
- Aprender: Estabelecer uma cultura que valorize o feedback construtivo e utilize métricas para melhorar continuamente.
Habilidades Técnicas e Multidisciplinares:
- Aprender: Desenvolver habilidades técnicas, mas também cultivar uma compreensão abrangente de todo o ecossistema de desenvolvimento e operações.

A cultura DevOps é uma abordagem holística que transcende ferramentas e se concentra na colaboração e na melhoria contínua. A aplicação prática desses princípios e a familiaridade com ferramentas relevantes são essenciais para o sucesso na implementação de práticas DevOps.

Como corrigir vulnerabilidades de software automaticamente com o Veracode Fix

Lucas Santos Ferreira — Thu, 30 Nov 2023 19:51:15 +0000

O tutorial a seguir tem por objetivo mostrar como realizar o scan e a correção automática de vulnerabilidades utilizando o Veracode FIX

LINGUAGENS E VULNERABILIDADES SUPORTADAS

CONFIGURAR AS CREDENCIAIS API NA ESTAÇÃO DE TRABALHO

IMPORTANTE!

seguir as orientações de empacotamento da Veracode para realização do scan:

Geral: https://docs.veracode.com/r/compilation_packaging
Java: https://docs.veracode.com/r/compilation_java
JavaScript / TypeScript: https://docs.veracode.com/r/compilation_jscript
C# / .NET: https://docs.veracode.com/r/compilation_net

1. Para aplicações Java, realizar a compilação para gerar o (.war ou .jar ou .ear)
2. Para .NET, executar o build, e criar um zip a pasta com as DLLs e pdb files
3. Para JavaScript e TypeScript, criar um zip a pasta com os arquivos de código da aplicação

BAIXAR O VERACODE CLI PARA UTILIZAR O FIX

Mac/Linux/Windows com WSL

curl -fsS https://tools.veracode.com/veracode-cli/install | sh

Deixar o binário executavel

chmod +x veracode

Rodar o comando abaixo para configurar a CLI e indicar as credenciais API (as mesmas utilizadas no arquivo de credenciais configurado no passo 1)

./veracode configure

Quando for perguntado pelo apiID e apiKEY, inserir suas credenciais de API, conforme abaixo:

Configuring credentials for the Veracode CLI ...
API ID [Your Veracode API ID]
API Secret Key [Your Veracode Secret Key]  
Validated API credentials successfully.
Wrote configuration to /$HOME/.veracode/veracode.yml

EXECUTAR A CLI PARA FAZER O STATIC SCAN

Iremos primeiramente realizar um scan SAST em nosso app para armazenar os resultados de vulnerabilidades que serão utilizados posteriormente nas correções

./veracode static scan <<caminho da sua aplicação empacotada/compilada>>

Exemplo usando Java:

./veracode static scan app.war

Exemplo usando C#/.NET ou JavaScript/Typescript:

./veracode static scan app.zip

Após isso, o scanner irá salvar os resultados dentro do results.json

EXECUTAR A CLI PARA FAZER O FIX

Após executar o scan, iremos avaliar em qual(ais) arquivos vulneráveis da app iremos iniciar as correções
Para iniciar a correção, basta executar o comando com a sintaxe:

veracode fix --results <<local onde está o results.json gerado no static scan>> <<caminho exato do arquivo da app que iremos fazer as correções>>

Exemplo:

./veracode fix --results verademo/docs/scan_results/results.json verademo/app/src/main/java/com/veracode/verademo/commands/IgnoreCommand.java

Após terminar, basta analisar qual vulnerabilidade você irá começar a corrigir, passar a ele o "ISSUEID" indicado na tela, como 1010 ou 1020, etc... e, aguardar a consulta na base de inteligência interna da Veracode.
Após isso, irá surgir as sugestões de correção no código fonte, onde você poderá analisar e escolher qual será aplicada em seu código

Mais informações:

https://www.veracode.com/fix
https://docs.veracode.com/r/veracode_fix
https://docs.veracode.com/r/Fix_Quickstart

Credenciais do Veracode SCA

Ivo Dias — Mon, 27 Nov 2023 20:59:26 +0000

Na tela inicial do portal da Veracode, vamos na seção "Scans & Analysis" e selecionamos "Software Composition Analysis":

Nessa nova tela, selecionamos a aba "Agent-Based Scan", clicamos no botão "Actions" e selecionamos "Create Workspace":

Informamos um nome para esse ambiente e caso seja necessário vincular ele a um time, após digitar o nome clicamos em "More Options" e informamos o time, caso não seja necessário apenas clicamos em "Create".

A tela de configuração do agente vai ser aberta, nela podemos seguir guias específicos sobre como gerar e configurar o agente em varias ferramentas e sistemas. Como nosso objetivo é apenas pegar a credencial para utilizar a solução, podemos clicar em qualquer um, mas recomendo para agilizar que clique em "Jenkins / Hudson" e depois em "Create Agent & Generate Token":

Conforme as orientações que vemos na tela, para autenticar com esse valor vamos precisar adiciona-lo a uma variável chamada SRCCLR_API_TOKEN independente de qual seja a ferramenta que vai implementar.

Como configurar as CLIs da Veracode em seu workstation usando docker

Lucas Santos Ferreira — Tue, 08 Aug 2023 17:38:15 +0000

É inegável que saber utilizar CLIs é importante no dia a dia de um profissional de tecnologia, pois elas podem trazer diversas possibilidades de interações e automações, além de nos ajudar a ganhar produtividade.

Nesse artigo, iremos mostrar como configurar e utilizar as CLI e API wrappers da Veracode em seu workstation para te ajudar a ganhar produtividade, dar a possibilidade de criar scripts e automações de forma mais simples.

Pré requisitos

1 - Sistema operacional Linux
2 - Caso utilize o Windows, poderá adaptar para o WSL
3 - Docker
4 - Conta de acesso à Veracode
5 - Credenciais API configuradas em no arquivo credentials

Criar credenciais API

Faça login na Plataforma Veracode [https://analysiscenter.veracode.com/].
No menu esquerdo clique em API Credentiais.
Clique em Gerar credenciais de API.
Copie o ID e a chave secreta para um local seguro.

Configurar credenciais API

Na linha de comando, navegue até a pasta do seu nome de usuário $HOME.

cd $HOME

Execute este comando para criar a pasta .veracode

$ mkdir .veracode

Navegue até a pasta .veracode

$ cd .veracode

Execute este comando de toque para criar o arquivo de credenciais

$ touch credentials

Abra o arquivo credentials com algum editor de texto
Copie este texto e cole-o no arquivo de credenciais

[default]
veracode_api_key_id = Your API ID
veracode_api_key_secret = Your API key

Substitua os valores pelas credenciais da API Veracode.
Salve o arquivo de credenciais.
Opcionalmente, você pode executar o seguinte comando para restringir o acesso ao arquivo de credenciais

chmod 600 ~/.veracode/credentials

Download e configuração das CLIs

Nesse ponto, iremos utilizar as imagens Docker da Veracode disponíveis em

hub.docker.com

Com algum editor de texto, abra o arquivo .bashrc que carrega configurações do usuário a cada vez que o sistema inicializa, exemplo:

vim  ~/.bashrc

No fim do arquivo, dê alguns espaços e adicione os seguintes comandos para configurar as chamadas dos CLIs pelo terminal

pipeline scan

alias 'veracode-pipeline-scan'='docker run -it --rm -v $PWD:/home/luser -v ~/.veracode/credentials:/home/luser/.veracode/credentials veracode/pipeline-scan:cmd'

api-wrapper-java usado para SAST upload and scan, bem como todas as interações com as APIs XML da Veracode

alias 'veracode-api-wrapper'='docker run -it --rm -v $PWD:/home/luser -v ~/.veracode/credentials:/home/luser/.veracode/credentials veracode/api-wrapper-java:cmd'

api-signing para interação com as REST API da Veracode

alias 'veracode-http'='docker run -it --rm -v $PWD:/home/luser -v ~/.veracode/credentials:/home/luser/.veracode/credentials veracode/api-signing:cmd'

Após isso, executar o comando abaixo

source ~/.brashrc

E depois sair da sessão do terminal, ou reiniciar o sistema.

Agora quando abrir um terminal CMD, poderá então utilizar sempre as versões mais atualizadas da CLI e API wrappers de forma mais fácil.

Observação: Na primeira vez que executar os comandos, as imagens docker serão baixadas para sua máquina antes de serem executadas de fato

Como utilizar as imagens docker da Veracode para automatizar as integrações SAST

Lucas Santos Ferreira — Thu, 27 Jul 2023 18:25:52 +0000

No mundo de DevOps temos o Docker engine como um grande auxiliador dentro das etapas de desenvolvimento para testes, build, homologação e etc.

Dentro de um pipeline CI/CD, alguns players oferecem os recursos dos containers docker para facilitar os testes e automações, assim cada etapa como: job, task ou step, podem ser facilmente executadas sem a necessidade de se preocupar em instalar dependências e realizar configurações que consomem tempo.

Nesse artigo, iremos entender um pouco sobre como podemos aplicar a estratégia de esteira DevSecOps utilizando imagens de container Docker para automatizar Scans SAST com a Veracode.

Abaixo iremos utilizar como exemplo o Github Actions, mas isso poderia ser aplicado a qualquer outra ferramenta CI/CD adaptando o uso de acordo com a respectiva solução.

As imagens oficiais Veracode podem ser encontradas diretamente no Dockerhub Veracode. Elas são constantemente atualizadas e hardenizadas para garantir que tudo funcione da forma mais segura. Logo que um novo API Wrapper é lançado, automaticamente já será anexado a uma nova versão da imagem, garantindo que tenhamos os recursos mais atualizados já disponíveis.

Exemplo abaixo será usado um exemplo de projeto em Django (PyGoat):

1. Etapa - SAST Policy Upload and Scan

  Veracode-SAST-Policy-Scan:
    runs-on: ubuntu-latest
    container:
      image: veracode/api-wrapper-java:latest
      options: --user root
    steps:
    - uses: actions/checkout@master

    - name: scan 
      run: |
          zip -r pygoat.zip . -i '*.py' '*.html' '*.js'
          java -jar /opt/veracode/api-wrapper.jar -vid "${{ secrets.VID }}" -vkey "${{ secrets.VKEY }}" -action UploadAndScan -createprofile false -appname "Pygoat-Showroom" -version "${{ github.run_id }}" -filepath pygoat.zip -scantimeout 20

No primeiro exemplo temos o SAST Policy Scan sendo executado a partir da imagem veracode/api-wrapper-java:latest
Por padrão a imagem roda com um usuário não privilegiado e, para executar todas ações necessárias, utilizamos o recurso de --user root temporariamente
Essa imagem já contém o CLI do ZIP instalado, assim evita que tenhamos que criar uma etapa anterior de ZIP ou Archive, salvar esse artefato com a aplicação dentro e executar em outro container para Upload and Scan ou até mesmo instalar o ZIP dentro a imagem utilizada
No ZIP, estamos solicitando que seja incluso somente os arquivos referente à aplicação, assim o artefato terá seu tamanho otimizado e, também ignoramos outros arquivos que não fazem sentido para o scan SAST como: PDF, JPG, etc.
Em seguida, executamos o API Wrapper com a action de UploadAndScan para o SAST

2. Etapa - SAST Pipeline Scan

   Veracode-SAST-Pipeline-Scan:
    runs-on: ubuntu-latest
    container:
      image: veracode/pipeline-scan:latest
      options: --user root
    steps:
      - name: checkout
        uses: actions/checkout@master

      - name: scan 
        run: |
          zip -r -v pygoat.zip . -i '*.py' '*.js' '*.html'  
          java -jar /opt/veracode/pipeline-scan.jar -vid "${{ secrets.VID }}" -vkey "${{ secrets.VKEY }}" -f pygoat.zip -p "PyGoat-Showroom" -pn "Veracode Recommended Medium"

O Pipeline Scan também possui uma imagem Docker dedicada veracode/pipeline-scan:latest onde o seu uso é praticamente igual a da Etapa - SAST Policy Upload and Scan

Tanto a imagem veracode/api-wrapper-java quanto veracode/api-signing podem ser utilizadas para automatizar outras tarefas além do SAST, pois elas interagem diretamente sobre as APIs da Veracode, assim podemos por exemplo: criar usuários, times, download de relatórios, busca de informações e trigger para execução de uma análise Dinâmica (DAST).

Aplicando uma estratégia DevSecOps com Veracode e GitFlow

Lucas Santos Ferreira — Mon, 24 Jul 2023 18:04:36 +0000

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.

Criando uma pergunta personalizada

Ivo Dias — Wed, 05 Jul 2023 13:57:00 +0000

Mesmo com a imensa biblioteca que já vem por padrão na ferramenta, e que está sendo constantemente atualizada, pode ser necessário criar uma pergunta personalizada para alguma necessidade especifica do seu projeto.

As perguntas fazem parte da pesquisa, ou Survey, que gera os pontos de atenção do nosso projeto. Com a criação das personalizadas, consegue otimizar o poder da ferramenta da Security Compass.

Para fazer isso, na barra superior clique em Library e depois em Project Survey e clique no botão +Add Section no canto superior direito. Caso queria adicionar a uma seção já existente, selecione-a em vez de criar uma nova.

Depois clique em +Add SubSection, definindo um nome para essa sub seção e depois em +Add Question.

Responda o formulário para criar sua pergunta personalizada.
Para mais detalhes, pode saber tudo sobre as pesquisas clicando aqui.