Aqui iremos entender algumas maneiras (e seus prós e contras) para configurar uma ferramenta de Application Security Testing (AST) em uma pipeline de CI/CD. Esse artigo é baseado em alguns dos aprendizados relacionados à nossa experiência de cuidar desse processo em mais de 50 diferentes empresas, contabilizando algumas dezenas de milhares de ativos e esteiras.
Você também pode ouvir esse conteúdo:
Background
Para simplificar o escopo, iremos falar apenas sobre ferramentas de SAST, mas o contexto aqui aplicado também equivale para uma boa parte dos setups propostos por ferramentas de SCA e IaC.
Essas propostas de setup para ferramentas de AST, feita normalmente pelos fabricantes tem como objetivo tornar a vida da pessoa desenvolvedora mais simples, para que ela consiga configurar de forma rápida a ferramenta de segurança e aproveitar seus benefícios.
É muito comum que, quando temos problemas complexos e é feito uma proposta de “solução simples”, algumas coisas tenham sido ignoradas pelo autor da proposta, justamente para que fosse possível vender algo.
No caso de ferramentas de Application Security Testing, normalmente essas propostas tem alguns pontos de atenção:
1. É comum que apenas uma branch esteja configurada: normalmente essa branch é a antiga “master” talvez seu repositório utilize como padrão a “main”. Também considere executar a análise AST em branch de “homologação”, normalmente chamadas de “develop” ou “staging”, pois assim as vulnerabilidades serão detectadas mais cedo quanto ao momento do desenvolvimento.
2. Se atente ao momento em que o evento para a análise acontecer é acionado: a maior parte das ferramentas de segurança consideram apenas um momento, pull ou push, quando na verdade, é importante que os dois estejam especificados. Dessa forma, a cobertura de análise do código pode ser maior.
3. Além dos diffs de código entre um commit e outro, se tem uma análise da base de código completa em algum momento? Essa pergunta é interessante pois a maioria das ferramentas consideram:
- Apenas os diffs, ou seja, apenas arquivos que tiveram modificações e especificamente esses trechos modificados, serão analisados pela ferramenta de SAST. E isso é um problema, afinal um codebase pode ter vulnerabilidades em um trecho específico que nunca foi modificado após a inserção do SAST, assim sendo a ferramenta não vai analisar esses demais trechos.
- Alguns fornecedores vão te dizer que nas novas integrações, todo o codebase será considerado e por isso não tem nenhum problema com as análises futuras somente a partir dos diffs, mas na verdade tem mais um ponto que faz necessário esse agendamento de tempos em tempos para analisar o codebase completo: as regras do SAST podem evoluir/mudar. Um codebase que passou somente pela análise completo do início, no momento de setup, pode não se beneficiar de novas regras. Um código com problema/vulnerabilidade (detectável por essas possíveis novas regras) só seria identificado caso fosse modificado.
LEIA TAMBÉM: Mantendo seu código seguro no GitHub com a integração da Conviso Platform
Objetivo
Abaixo está um reflexo da até então, atual, proposta inicial de setup da Conviso Platform para pipelines usando Github Actions, que não cobre todos os pontos que foram listados na seção de background.
name: CI
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
conviso-ast:
runs-on: ubuntu-latest
container:
image: convisoappsec/flowcli
env:
- FLOW_API_KEY: ${{secrets.CONVISO_API_KEY}}
- FLOW_PROJECT_CODE: "<project code>"
steps:
- uses: actions/checkout@v3
- name: AST
run: conviso ast run
Dessa forma, o objetivo é fazer as alterações necessárias considerando os possíveis pontos de atenção listados anteriormente para que nossos clientes não enfrentem tais dores, e sim, benefícios de um setup bem estruturado.
Proposta
De forma simples, para solucionar o ponto 1 apresentado na seção de background, será especificado também a branch “main” pois assim nossos clientes vão entender mais facilmente que múltiplas branch’s podem ser utilizadas. Além de que caso o cliente apenas copie e cole isso, teremos certeza que ao menos uma das branch’s será válida.
Quanto ao ponto 2, ele já era considerado em nossa proposta, tanto pull quanto push estão especificados.
Em referência ao tópico de número 3, podemos fazer o uso do recurso de schedule, especificando um período usando a sintaxe do cron. No exemplo, será executado no quinto dia de cada mês, na quarta-feira às 14:15.
name: Conviso Platform AST
on:
push:
branches: [ "master", "main" ]
pull_request:
branches: [ "master", "main" ]
schedule:
- cron: '15 14 5 * *'
jobs:
conviso-ast:
runs-on: ubuntu-latest
container:
image: convisoappsec/flowcli
env:
FLOW_API_KEY: ${{secrets.CONVISO_API_KEY}}
FLOW_PROJECT_CODE: ${{secrets.CONVISO_PROJECT_CODE}}
steps:
- uses: actions/checkout@v3
- name: AST
run: conviso ast run
Essa proposta melhora agressivamente a eficiência dessa categoria de análises, garantindo uma melhor cobertura de código e uso de regras atualizadas do SAST. No entanto, o volume de código analisado será maior, se o fabricante da sua ferramenta de SAST faz cobranças baseado na quantidade de linhas analisadas (o padrão de toda industria), provavelmente seu custo irá aumentar. Outro custo que talvez possa aumentar é o da sua pipeline, pois agora ela será acionada mais vezes.
Lembre-se: qualquer decisão técnica sempre tem um ponto contra. Se você estiver tomando uma decisão acreditando não ter, isso provavelmente se deve por seu baixo entendimento da solução ou problema.
Referências:
