SAST (Static Application Security Testing) é um scan de verificação de vulnerabilidades em códigos estáticos, ou seja, não depende que a aplicação seja em execução para fazer a verificação de vulnerabilidades. Esse scanner pode ser executado isoladamente, no início do pipeline de CI ou como um plug-in na IDE durante a codificação. No post sobre SBOM comentei que “algumas empresas podem conter até 90% do código bibliotecas opensource em sua composição (20% sendo o framework, 70% bibliotecas importadas para problemas simples)“, portanto devemos concentrar o SAST exatamente na parte de código onde os desenvolvedores atuam diretamente, que é o código proprietário.

O SAST garante que problemas de segurança como salvar uma senha em texto claro dentro do código fonte de uma aplicação sejam detectados antes desse código ser publicado em produção. Além disso é possível garantir se os padrões de boas práticas de programação sejam seguidas, portanto o SAST é um scan que depende da linguagem de programação que esteja sendo utilizada naquele projeto. Isso deve ser levado em consideração na hora de escolher uma ferramenta para fazer essa verificação.

Um dos objetivos do SAST é auxiliar na detecção de possíveis problemas desde os estágios iniciais do processo de desenvolvimento, por isso que ele deve ser integrado como plug-in da IDE ou na pipeline de CI. Quanto mais precoce a correção de vulnerabilidades, mais simples e barata se torna essa etapa. Além disso, aumenta a conscientização do desenvolvedor sobre possíveis problemas, ajudando-os a evitar outros problemas relacionados. Essas práticas estão relacionada ao “Shift-Left”, tema que será abordado em outro post.

Algumas vantagens do SAST:

  • Detecte cedo e corrija cedo: Como o SAST pode ser realizado até mesmo dentro da IDE, o processo de correção ocorre bem no início do processo de fatoração do código, evitando mais problemas maiores;
  • Exatidão na localização do problema: O SAST funciona no código estático, o relatório irá apontar qual arquivo, em qual linha e coluna um possível problema foi detectado. Dependendo da aplicação que foi utilizada, é possível fazer uma relação com CWEs, CVE ou OWASP Top 10. A correção se torna mais eficiente dessa forma;
  • Fácil automação: A execução do código SAST não precisa de nenhum tipo de interação, portanto é fácil fazer a automatização do processo. Tenha em mente que configurar corretamente a ferramenta é um outro processo;
  • Velocidade do Scan: Basicamente, as ferramenta SAST irão ler arquivos. Não é necessário validações e interações como é o caso do DAST. Com isso, a velocidade de SCAN é considerada rápida.


Para ter sucesso no scan, é necessário atenção em alguns pontos:
 
  • Escolha a ferramenta correta: O SAST verifica o código fonte de uma aplicação, por tanto existe uma linguagem de programação atrelada ao código, assim como existem melhores práticas para essa linguagem. Por tanto, ao escolher uma ferramenta, verifique se ela tem suporte para a linguagem do seu projeto e se ela tem bibliotecas, scripts, padrões de mercado, melhores práticas para a linguagem que você quer verificar. Algumas ferramentas têm a opção de importar essas opções tanto da comunidade como personalizadas;
  • Saiba onde fazer o Scan: Foque o SAST no código proprietário, ou seja, no que você e sua equipe de desenvolvedores estão de fato codificando. Qualquer parte da sua aplicações que seja de terceiros, como bibliotecas, faça utilizando outras ferramentas próprias para isso. Recomendo a leitura do post sobre SCA e o outro sobre SBOM;
  • Adicione o SAST na pipeline: Automatize o scan para que possa focar na resolução do problema e não na ferramenta em si;
  • Atenção aos Falsos-Positivos: Toda ferramenta automatizada pode trazer falsos-positivos, portanto atenção à cada ponto do relatório que a ferramenta ou equipe de segurança irá apresentar para a equipe de desenvolvimento. É importante identificar o que de fato é um falso-positivo e o que de fato é uma vulnerabilidade.

Algumas ferramentas SAST:

 

A análise de composição de software (SCA – Software Composition Analysis) é o processo que automatiza a identificação de softwares open source em uma base de código. De acordo com o relatório Gartner Market Guide for Software Composition Analysis, mais de 90% dos aplicativos utilizam componentes com código fonte aberto.

A tendência de adoção do código fonte aberto tem ganhado força pois permite que os desenvolvedores foquem mais no código proprietário, assim podendo serem mais produtivos e realizam entregas mais rápidas e com maior qualidade.

O SCA pode garantir que esses códigos fontes incorporados ao código fonte proprietário sigam um padrão de mercado garantindo as melhores práticas de segurança, licença, propriedade intelectual ou violação de dados.

Além disso, as ferramentas de SCA são capazes de rastrear os componentes utilizados nos códigos e gerar uma “Lista de Materiais de Software” (SBOM), ou seja uma lista com todos os componentes utilizados no software. Esse assunto será abordado com mais detalhes em outro post.

E como funcionam as ferramentas de SCA?

Em regra, as ferramentas dependem de uma base de dados onde todas as vulnerabilidades conhecidas estão catalogadas, essa base de dados é consultada e comparada com os dados que foram coletados do software. Essa base de dados pode ser tanto fechada como aberta. Um exemplo de base de dados aberta de vulnerabilidades é o NVD (https://nvd.nist.gov/vuln/full-listing).

Após essa comparação com a base de dados, são atribuídos valores para cada um dos componentes como quais são as vulnerabilidades e licenças utilizadas em cada componente. Com esses dados, é possível fazer uma priorização das ações que serão tomadas para a correção de cada item.

Um exemplo prático de utilização de código fonte aberto e vulnerabilidade identificadas é o caso do Log4J. Para os desenvolvedores não criarem um sistema que permita a guarda de informações geradas pela aplicação, a biblioteca Log4J da Apache Software Foundation foi criada e disponibilizada com esse objetivo.

Essa biblioteca era bastante popular no momento em que foi descoberto uma vulnerabilidade crítica (CVE-2021-44228), sendo importado nos códigos fontes proprietários. Caso a equipe responsável pelo monitoramento dos componentes open source em um código proprietário utilize uma ferramenta SCA/SBOM, rapidamente identifica os pontos de vulnerabilidades causadas por essa biblioteca, assim ganhando agilidade para mitigação do problema.

Podemos observar que o SCA traz algumas vantagens como:

Identificação e gerenciamento de:

  • Componentes de código open source em um código proprietário;
  • Vulnerabilidades nos componentes do software;
  • Conformidade de licenças;

Criação de relatórios e lista de todos os componentes que integram o software;

Controle e governança utilizando alguns padrões de controle como SDLC/SSDLC, OWASP DSOMM/SAMM e CIS Controls.

 

A adoção de uma ferramenta leva em consideração muitos fatores. Aqui está uma lista de algumas empresas/ferramentas que fazem análise:

Checkmarx
Fortify
Gitlab
JFrog Xray
OWASP Dependency-Check
ShiftLeft
Sonatype
Snyk
Synopsys
Trivy
Veracode

Nesse post, vou abordar a instalação do GitLab 15.0 em um Ubuntu Server 20.04.4 LTS / Focal Fossa. Também instalarei o gitlab-runner localmente e também em container. Além da instalação, farei o cadastro dos dois Runners.

Inicialmente, vamos instalar algum pacotes necessários:

apt install -y curl openssh-server ca-certificates tzdata perl

Em seguida, vamos adicionar o repositório oficial da versão community do GitLab.

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Agora com o repositório oficial já na lista dos repositórios que o nosso gerenciador de pacotes irá verificar, basta instalar o gitlab usando apt

apt install gitlab-ce -y

Ao concluir a instalação, vamos configurar a URL que servirá de acesso ao Gitlab. No nosso caso, não estamos utilizando nenhuma entrada de DNS ou domínio, portanto vamos apontar o IP do servidor mesmo. Nesse caso, é o IP interno 192.168.0.115. Esse procedimento não é recomendável para produção, que deve ser utilizado inclusive com certificado válido.

Para fazer a configuração, vamos editar o arquivo /etc/gitlab/gitlab.rb. Esse arquivo será lido no momento de configuração do gitlab.

vim /etc/gitlab/gitlab.rb

Agora, vamos procurar a linha que contém “external_url” e vamos colocar nosso ip:

Para iniciar o modo de edição do vim, basta apertar a tecla “i”. Ao concluir, basta apertar “Esc” e depois para sair do vim, basta digitar :wq!

Agora, vamos iniciar a configuração do gitlab usando o binário gitlab-ctl:

gitlab-ctl reconfigure

Ao concluir a configuração, o gitlab informará que a senha inicial do usuário root está em um arquivo chamado initial_root_password. Portanto, vamos exibir esse arquivo para visualizarmos a senha.

cat /etc/gitlab/initial_root_password

A senha será exibida na tela. Vamos copiá-la para o acesso inicial ao gitlab. Esse acesso inicial se dará pelo navegador e com o endereço informado anteriormente. Nesse caso, vou usar o Firefox para acessar o ip 192.168.0.115.

1 – No campo Username or email vamos colocar o usuário root

2 – No campo Password, vamos colocar a senha que copiamos anteriormente.

Depois basta clicar em Sign In.

 

Para modificar a senha do root, clique no lado direito superior e depois em Preferences.

 

No menu esquerdo, clique em Password.

 

1 – Inserir a senha atual em Current Password que foi copiada do arquivo initial_root_password

2 – Inserir uma senha nova em New password / Password confirmation.

Depois basta clicar em Save password para confirmar a senha. Ao clicar, você será redirecionado para a página inicial onde deve entrar novamente com o usuário root e a nova senha.

 

Instalação e Registro dos Runners (Shell e Docker)

Vamos fazer a instalação de depois Runners: um localmente e outro utilizando Docker.

Assim como o Gitlab, vamos fazer a configuração do repositório oficial do Runners.

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

Agora, vamos instalar o gitlab-runner

apt install gitlab-runner -y

Após a instalação, vamos registrar o primeiro Runner. Para fazer o registro, vamos precisar do token. Esse token pode ser acessado em Admin que fica no Menu da esquerda.

Após o acesso da área Admin, vamos em Runners, ainda do lado esquerdo.

Já em Runners, no lado direito, clique em Register an instance runner e logo em seguida, vamos clicar no segundo símbolo para fazer a cópia do token.

Agora com o Token copiado, vamos voltar ao terminal e registrar o Runner que já foi instalado.

Abaixo o comando que deve ser inserido no terminal para fazer o registro do Runner.

É necessária a substituição das opções url (colocar a URL que está acessando o Gitlab), registration-token (colar o token que foi copiado anteriormente).

gitlab-runner register -n --url http://192.168.0.115 --registration-token se8sztuB1o1ewFbXHVav --executor shell --description "Runner Shell"

Ao acessar novamente os Runners no Gitlab, verá que o Runner foi registrado como Shell e com o descrição Runner Shell.

Em seguida, vamos subir um Runner usando Docker e depois fazer o registro desse Runner que estará rodando em container.

Caso não tenha o Docker instalado, seguem os comandos para a instalação. Não será abordado os detalhes aqui, pois o foco é a instalação e configuração do GitLab.

apt remove -y docker docker-engine docker.io containerd runc
apt update -y
apt install ca-certificates curl gnupg lsb-release
mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
apt update -y
apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Primeiramente, vamos executar o container do gitlab-runner:

Executando o Runner em Docker
docker run -dit \
--name runner-docker \
--restart always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /opt/gitlab-runner/config:/etc/gitlab-runner \
gitlab/gitlab-runner:latest

Agora com o Runner já sendo executado em container, vamos fazer o registro desse Runner. A ideia de registro é a mesma do Runner que está rodando localmente, porém precisamos fazer isso para o container, por tanto será necessário os ajustes da URL e Token assim como feito no anterior. Não é necessário a geração de um novo token. Pode-se aproveitar o token que foi utilizado para o runner anterior.

docker exec -it runner-docker \
gitlab-runner register -n \
--url http://192.168.0.115 \
--registration-token se8sztuB1o1ewFbXHVav \
--clone-url http://192.168.0.115 \
--executor docker \
--docker-image "docker:latest" \
--docker-privileged

Agora, onde havia apenas um Runner, há dois Runners sendo executados e registrados no Gitlab.

Referências:

https://about.gitlab.com/install/?version=ce
https://docs.gitlab.com/runner/install/
https://docs.docker.com/engine/install/ubuntu/

Ao som de: Ney Matogrosso – Sorte