Forem: Lucas Santos Ferreira

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

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.

Configurando o agente DAST ISM Veracode em servidores Linux

Lucas Santos Ferreira — Fri, 23 Jun 2023 21:56:43 +0000

No post Como realizar uma análise dinâmica (DAST) com a Veracode em aplicações não publicadas? entendemos a importância e o porquê de se realizar uma análise DAST dentro de um ambiente pré-produção.

Nesse post, iremos fazer o passo a passo de como configurar o agent ISM em servidores Linux.

Pré Requisitos Técnicos

1. Sistema Operacional: Linux RHEL, CentOS, Ubuntu, Debian
2. Hardware: 8 GB RAM; 4 GB Livres de Disco
3. Software: Java JRE 8+ LTS
4. Rede:
- Conexão confiável do servidor endpoint com as aplicações internas a serem testadas
- 443 do servidor aberta para saída
- Garantir que o endereço 34.195.146.191 esteja acessível pela aplicação, ele é a origem das requisições da análise dinâmica
- É recomendado desabilitar IPS, WAF e outras camadas que possam interferir nos resultados do DAST originados do IP da Veracode (citado acima). 
5. O usuário que fará a criação do endpoint e download do executável, deverá ter uma dessas Roles permissions: **Administrator** ou **Security Lead**

Configuração do Internal Scanning

No menu de configuração ícone de engrenagem na parte superior da plataforma Veracode, clique em Internal Scanning Management

Clique em Configure Internal Scanning
Insira o nome e a descrição do gateway. Então clique Next
Insira o nome e a descrição do endpoint que você deseja conectar a este gateway
Selecione Other
Clique em Next

Download e Instalação do endpoint ISM

Clique em Download para baixar o arquivo ZIP contendo o instalador
Mova o arquivo ZIP baixado para dentro do servidor onde ele será executado
Crie um pasta específica e faça a extração do ZIP dentro dela
O endpoint será um arquivo .jar

Execução do endpoint ISM

Ao seguir os passos anteriores de criação do endpoint, ele irá te mostrar todos os comandos necessários para execução como a imagem a seguir:
A estrutura se baseia em alguns cenários que você deverá avaliar e escolher o que se adequa melhor na sua infraestrutura.

Se você não estiver usando um proxy da Web para acessar a Internet:

java -jar Veracode_ISM_Endpoint_{yourendpointname}.jar

Se você estiver usando um proxy da web não autenticado:

java -Dhttps.proxyHost={your_proxy_host} -Dhttps.proxyPort={your_proxy_port} -jar Veracode_ISM_Endpoint_{your_endpoint_name}.jar

Se você estiver usando um proxy da web autenticado, inicie o endpoint:

java -Dhttps.proxyHost={your_proxy_host} -Dhttps.proxyPort={your_proxy_port} -jar Veracode_ISM_Endpoint_{your_endpoint_name}.jar --authenticate

Depois de iniciar o endpoint para um proxy da web autenticado, execute o endpoint:

java -Dhttps.proxyHost={your_proxy_host} -Dhttps.proxyPort={your_proxy_port} -jar Veracode_ISM_Endpoint_{your_endpoint_name}.jar

Se você deseja usar apenas o proxy da web para comunicação entre o endpoint e o gateway:

java -Dhttps.proxyHost={your_proxy_host} -Dhttps.proxyPort={your_proxy_port} -jar Veracode_ISM_Endpoint_{your_endpoint_name}.jar --proxygatewayonly

Clique em Close

O novo gateway e endpoint agora aparecem na página Internal Scanning Management como as imagens de exemplo abaixo:

Se o endpoint não conseguir se conectar ao gateway, sua organização pode precisar adicionar o endereço IP do gateway ou o nome de domínio à sua lista de permissões. O endereço IP e o domínio são visíveis na página Internal Scanning Management e na página do gateway.

O gateway pode ter um status de Inicializando por alguns minutos depois de criá-lo. O endpoint tem um status de Pendente até que você o implemente com sucesso. Quando você implementa com sucesso o endpoint, ele tem um status de Ready.

Próximo passo

Após seguir o procedimento de criação do gateway, download e execução do endpoint, você estará pronto para iniciar a configuração DAST pelo portal utilizando o ISM que você pode seguir conforme os tutoriais abaixo:

Conteúdos em Português

Como fazer um DAST pelo portal

Ivo Dias for M3Corp ・ Jan 4

#veracode #beginners #tutorial #security

Conteúdos em Inglês

Como realizar uma análise dinâmica (DAST) com a Veracode em aplicações não publicadas?

Lucas Santos Ferreira — Fri, 23 Jun 2023 21:56:35 +0000

E colaboração aos posts anteriores sobre análise dinâmica (DAST)

Iremos entender nesse post, a importância de se utilizar o Internal Scanning Management [ISM] para realizar análises DAST em aplicações que estão fechadas para Internet.

ISM (Internal Scanning Management)

É um agente/endpoint que trabalha como uma espécie de Proxy Reverso dentro da rede da empresa. O objetivo dele é simplificar as análises DAST em aplicações que não estão publicados ainda, exemplo: ambientes de desenvolvimento e/ou homologação que não podem ser alcançáveis pela Internet.

Conforme a ilustração abaixo demonstra, o agente/endpoint estará rodando como um serviço dentro de um servidor interno que possui comunicação interna com as aplicações (Web ou API) e, realiza uma comunicação segura para Internet (porta 443) até seu Tenant na Veracode, permitindo que os scans sejam performados de forma segura.

Qual importância do uso do ISM?

Como boa prática, é recomendado realizar os testes de segurança "mais cedo possível", ou seja, em etapas antes da publicação para que os times tenham a possibilidade de saber antecipadamente se alguma vulnerabilidade crítica seja conhecida e corrigi-la antes que um atacante possa explorá-la. Geralmente os ambientes de desenvolvimento, homologação ou staging por exemplo, estão fechados para Internet o que impede que qualquer um fora da rede interna, onde as aplicações rodam, possam "enxergar" e realizar algum tipo de teste.
De modo geral, todo Web Scanner atua enviando requisições diretamente nas aplicações, com objetivo de simular as principais ações de um cyber criminoso. As aplicações recebem e processam certas requisições que podem não ser corretamente interpretadas e causar algum tipo de desfiguração.
O DAST da Veracode possui inteligência suficiente para enviar requisições de modo a não prejudicar a usabilidade das aplicações, mas, sempre há algum risco do alvo não processar corretamente as requisições.

Conclusão

Sempre que possível, utilize um endpoint/agent ISM para fazer as análises dinâmicas em ambientes não produtivos para que você possa ter maior segurança nos testes e principalmente conheça os riscos antecipadamente.

Os diferentes modos de se realizar SAST com a Veracode

Lucas Santos Ferreira — Tue, 14 Mar 2023 19:22:58 +0000

Em colaboração ao nosso post anterior: O que é SAST? iremos então desenvolver a ideia macro de quais são as formas de realizar análises SAST em nossas aplicações utilizando a Veracode, bem como alguns casos de uso e momentos em que cada uma pode se encaixar em seu ciclo de desenvolvimento.

A Veracode trabalha com os seguintes módulos de SAST:

IDE Scan (Greenlight)
Pipeline Scan
Sandbox Scan
Policy Scan

IDE Scan (Greenlight)

O que é?

Esse módulo permite que os desenvolvedores varram os códigos (classes, arquivos individuais) em busca de vulnerabilidades diretamente de sua IDE rapidamente enquanto estão programando.

Porque é importante?

Ele colabora com a implementação do conceito de shift-left dentro de ciclo de desenvolvimento seguro, fazendo com que vulnerabilidades sejam encontradas e corrigidas já no estágio inicial de construção do software, diminuindo o custo das correções, evitando a exposição do desenvolvedor e atraso nas entregas em uma sprint, além de apoiar na conscientização de codificação segura.

Pipeline Scan

O que é?

Esse módulo permite a análise estática da sua aplicação completa de forma muito rápida (cerca de 90 segundos dependendo do tamanho e complexidade de sua aplicação). Apesar de seu nome, ele possui a flexibilidade de ser executado em qualquer terminal (Windows, Linux, MacOs, esteiras CI/CD) pois é disparado por meio de uma CLI.

Porque é importante?

Quando pensamos em velocidade de entrega sem comprometer a segurança, certamente o Pipeline Scan da Veracode é um ótimo aliado. Ele possui uma tecnologia na qual colabora para apresentar as vulnerabilidades das aplicações em formato de texto e, não na geração de relatórios, dashboards detalhados ou correlação de históricos, com isso, a complexidade de apresentação de informações se torna mais simples.

Com ele é possível realizar análises SAST após cada commit, sem impactar na execução de esteiras em estágios iniciais do desenvolvimento (onde é normal ter um número maior de commits e de falhas identificadas) ou até mesmo diretamente pela estação de trabalho do desenvolvedor. Dependendo da maturidade ou necessidade, conseguimos barrar a esteira com Pipeline Scan a partir da identificação de vulnerabilidades de determinada severidade (crítica, alta, média), baseado em categorias do CWE (SQL Injection, XSS, etc...) ou até mesmo em uma política de compliance de segurança

Sandbox Scan

O que é?

É um espaço isolado para cada aplicação que permite que os times de desenvolvimento e colaboradores do processo de construção das aplicações possam submeter a aplicação ao SAST, avaliar os resultados e verificar se estes afetam as regras de segurança antecipadamente sem que os relatórios de conformidade sejam afetados (KPIs, compliance reports, etc).

Porque é importante?

As análises de segurança possuem relatórios, históricos, dashboards e KPIs com propósito de informar o estado atual e evolução da maturidade de segurança. Quando se atinge as metas me maturidade estabelecidas, também é importante que se mantenha uma constante evolução de todo o processo para que então os riscos sejam melhores gerenciados e a possibilidade de um incidente se reduza.
Pensando nesses pontos alinhados ao processo de desenvolvimento ágil, ter a possibilidade de realizar checagens e análises prévias com a garantia de que as aplicações serão entregues de acordo com a política de segurança estabelecida sem que haja retrabalhos ou atrasos é uma boa prática.

O Sandbox Scan da Veracode é um diferencial de mercado que atende os pontos acima citados como parte de sua oferta para o apoio de um programa de DevSecOps eficiente. Temos a possibilidade de dispará-lo via plugins de IDEs (Visual Studio, IntelliJ, Eclipse por exemplo) CLI/scripts diretamente de um terminal ou via esteira CI/CD. Esse último é um ótimo caso de uso pois, podemos fazer o SAST em Sandboxes de diferentes branches de um mesmo projeto (feature, desenvolvimento, homologação) dessa forma, podemos garantir que as revisões e análises de segurança sejam feitas antecipadamente antes de um processo da esteira em que decidirá se a aplicação poderá ou não ser publicada para uso (main, homolog ou dev por exemplo).

Policy Scan

O que é?

É um dos principais módulos SAST da Veracode. Ele armazena os relatórios de scans anteriores e, com os resultados de vulnerabilidades identificadas, correlaciona com as regras de segurança para indicar se a última versão da aplicação analisada está em compliance com a política estabelecida.

Porque é importante?

Acompanhar a evolução da maturidade de segurança, entender qual estado atual do ambiente na perspectiva de segurança, definir as métricas e necessidades atuais de segurança para os projetos desenvolvidos faz parte do core de um planejamento estratégico de segurança.

O Policy Scan é o módulo capaz de trazer todas essas possibilidades citadas e, prover insights que possam melhorar a postura e maturidade de segurança continuamente.

Como boa prática, é recomendado que esse módulo SAST especificamente, seja integrado em um momento da esteira ou ciclo de desenvolvimento onde se realiza verificações importantes que poderão passar por um exame de avaliação que permitirá ou não da aplicação seguir a uma etapa de publicação (produção/homologação/staging), ou seja, o Policy Scan é capaz de barrar a subida de uma aplicação baseado em métricas pré-definidas. É claro que nesse ponto, entende-se que a cultura de DevSecOps já está em um nível mais alto e principalmente já há processos bem definidos e estabelecidos para tal.

Para obter mais informações ou entrar em contato conosco, acesse: contato