Pensando nos casos onde queremos construir um fluxo/pipeline automatizado, como poderíamos incluir além dos testes de integração e validações de qualidade, uma validação se o nosso projeto atende os requisitos de segurança?

Com as soluções da Veracode, pensando nesse cenário onde podemos ter várias solicitações sendo executadas ao mesmo tempo, vamos conseguir isso com a combinação de duas soluções.

A primeira é o SCA Agent-Based, ele nos permite validar os componentes de terceiros do projeto, sejam os diretos ou transitivos, buscando por eventuais falhas de segurança, versões desatualizadas e até mesmo se o licenciamento não representaria um risco para o projeto.

Nossa segunda solução é o Pipeline Scan, uma ferramenta que permite fazer um analise SAST, um tipo de análise que pega o projeto e analisa seu código fonte para localizar eventuais falhas de segurança via linha de comando e nos retorna no LOG todas as informações encontradas.

O interessante dessas duas soluções, fora sua capacidade de rodar simultaneamente mesmo em uma grande quantidade de validações ao mesmo tempo, é que os controles para definir a quebra ou não do fluxo são totalmente personalizados. Para esse exemplo vamos deixar as opções padrões das ferramentas, mas pode saber mais sobre cada uma das opções nas documentações de cada uma:

• SCA
• Pipeline Scan

Como exemplo, vamos pensar num pipeline criado no Jenkins, onde temos uma aplicação Java que precisa ser compilada com o MVN. Nesse fluxo, vamos aproveitar que o SCA não precisa aguardar o build concluir para poder ser executado e vamos paralelizar ele com a etapa de build. No início do nosso processo, quando fazemos o checkout do repositório no Git, vamos paralelizar a etapa de download das ferramentas que vamos utilizar.

No final do fluxo, depois do build, vamos fazer a análise com o Pipeline Scan. Para utilizá-lo vamos precisar do resultado da compilação e isso é um ponto bem importante de utilizar as soluções da Veracode.

Para as linguagens compiladas, como é o caso do nosso exemplo, a Veracode faz a análise com base no binário, para garantir que todos os tipos possíveis de falhas foram contemplados nessa análise, já que existem alguns tipos específicos que só surgem no momento da compilação.

No final, o desenho do nosso pipeline vai ficar assim:

Como o projeto escolhido para o exemplo tem falhas de segurança e eu escolhi deixar as opções padrões ativas, ele como esperado quebrou na etapa do Pipeline Scan, já que encontrou uma série de erros no código, como podemos ver por esse LOG:

Para o Pipeline Scan eu prefiro utilizar o parâmetro para mostrar os detalhes das falhas, isso adiciona ao retorno padrão que nos fala qual o CWE e onde ocorreu a falha, duas linhas adicionais, contendo uma descrição sobre essa falha e outra com um link para uma documentação de apoio um pouco mais visual, com dicas de remediação. Assim quem olhar esse LOG consegue já saber o que precisa fazer e ter algumas dicas.

A mesma coisa ocorre com a utilização do SCA, mas optei por configurar ele para não quebrar o fluxo:

Uma coisa muito interessante desse retorno é que vemos duas seções de vulnerabilidades, uma chamada Public Data e a outra Premium Data.

Na Public, temos as falhas que já são conhecidas no mercado e já receberam um CVE, um identificador formal para ela. Na categoria Premium, temos falhas que ainda não receberam essa formalização, mas são detectadas porque a Veracode fica constantemente monitorando esses componentes, e cria uma base de dados própria. Você pode acessar essa base de forma gratuita.

Certo, conversamos sobre as ferramentas e qual o desenho do nosso fluxo, mas como isso ficaria na prática?

Como base desse projeto, estou utilizando um repositório público com falhas conhecidas, a ideia dele é ser utilizado para aprender mais sobre falhas de segurança, sendo conhecido como VeraDemo.

Agora falando sobre o pipeline em si, que foi construído em Jenkins mas pode ser replicado para outras ferramentas de CI/CD sem problemas. Para entender ele, vamos precisar conhecer dois conceitos do Jenkins, sendo o paralelismo e o "With Credentials".

Com o paralelismo, definimos que algumas etapas podem rodar ao mesmo tempo sem precisar aguardar a conclusão de outras, e a segunda é um gestor de credenciais disponível no Jenkins, para evitar que coloquemos as credenciais diretamente no código.

Pensando em como isso fica em código, podemos utilizar algo assim:

pipeline {
    agent any

    environment {
        VeracodeProfile = 'Jenkins.ValidacaoPR'
        CaminhoPacote = 'target/verademo.war'
    }

    stages {
        stage('Configuracoes Iniciais') {
            parallel {
                stage('Git Clone') {
                    steps {
                        git "https://github.com/IGDEXE/Verademo"
                    }
                }
                stage('Download Veracode Tools'){
                    steps {
                        sh 'echo Donwload Veracode Pipeline Scan'
                        sh 'curl -sSO https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip'
                        sh 'unzip -o pipeline-scan-LATEST.zip'
                    }
                }
            }
        }
        stage('Build') {
            parallel {
                stage('MVN'){
                    steps {
                        sh 'mvn -B -DskipTests clean package'
                    }
                }
                stage('SCA') {
                    steps {
                        withCredentials([string(credentialsId: '3bc33950-df7e-4af9-8895-5eeae1fff0d3', variable: 'SRCCLR_API_TOKEN')]) {
                            sh 'curl -sSL https://download.sourceclear.com/ci.sh | bash -s scan --allow-dirty'
                        }
                    }
                }
            }
        }
        stage('Veracode SAST') {
            parallel {
                stage('Pipeline Scan'){
                    steps {
                        withCredentials([usernamePassword(credentialsId: '2d28cc05-036b-4f2c-bee5-f0c1c8691cd7', passwordVariable: 'VeracodeKey', usernameVariable: 'VeracodeID')]) {
                            sh 'java -jar pipeline-scan.jar -vid ${VeracodeID} -vkey ${VeracodeKey} -f ${CaminhoPacote} --issue_details true '
                        }
                    }
                }
            }
        }
    }
}

Para obter os valores necessários para criar as chaves VeracodeKey e VeracodeID, pode consultar o nosso guia sobre como obter as credenciais.

Com isso, vai conseguir replicar a ideia explicada nesse artigo, e adicionar etapas de validação de segurança em seus projetos.

Vale notar que as etapas especificas de Veracode são bem simples, onde basicamente rodamos um comando na pasta raiz do projeto para fazer a analise de SCA e no caso do Pipeline Scan, passamos como parâmetro o arquivo que ele deve analisar, sendo que esse arquivo é gerado com base no guia de empacotamento.

Para outras dicas de como implementar Veracode, consulte o GitHub da M3Corp, onde mantemos vários exemplos de código e guias.