Criando um Scan de Segurança no Azure DevOps com YAML

#devops #security #azure #sre

Atualmente, tenho me dedicado ao estudo de um conjunto de ferramentas extremamente úteis voltadas para análise de segurança, dentre elas destaca-se o Trivy, uma poderosa ferramenta de segurança de contêineres de código aberto, cujo objetivo é auxiliar na identificação de vulnerabilidades em suas imagens de contêiner, com recursos avançados com interface amigável, simplificando, assim, a tarefa de assegurar a segurança de suas aplicações em contêineres.
Veja algumas das várias características que a tornam popular em meio a tantas outras:

Detectando vulnerabilidades amplamente: Examina com detalhe suas imagens de contêiner em busca de vulnerabilidades conhecidas, utilizando base de dados abrangente de vulnerabilidades, atualizada regularmente, para garantir a detecção de ameaças atuais.

Compatibilidade com diversos tipos de imagens: suporta uma variedade de imagens de contêiner, incluindo imagens Docker, imagens do Kubernetes e imagens do Amazon Elastic Container Registry (ECR). Isso permite que você verifique a segurança em diferentes plataformas e ambientes.

Integração com pipelines de CI/CD: Pode ser facilmente integrado aos seus pipelines de integração contínua e entrega contínua (CI/CD), permitindo assim que você automatize a verificação de segurança das imagens de contêiner como parte do fluxo de trabalho de desenvolvimento.

Configuração simples: Oferece opções de configuração flexíveis para personalizar o processo de verificação de segurança de acordo com suas necessidades. Você pode definir a gravidade mínima das vulnerabilidades a serem detectadas, especificar políticas de exclusão para evitar alerta falsos e até mesmo exportar os resultados em diferentes formatos.

Comunidade ativa: Respaldado por uma comunidade dinâmica, que garante um suporte constante.

Bom, tentei fazer um resumo sobre a ferramenta, proponho iniciarmos.

Requisitos:

Certifique-se de ter uma conta na Azure DevOps e um agente configurado para executar as tarefas.
https://learn.microsoft.com/pt-br/azure/devops/user-guide/sign-up-invite-teammates?view=azure-devops
Adicione o serviço de conexão DockerHub na Azure DevOps para permitir o acesso ao registro de contêineres.
https://learn.microsoft.com/pt-br/azure/devops/pipelines/library/service-endpoints?view=azure-devops&tabs=yaml
Instale a extensão do Trivy na Azure DevOps para poder utilizá-lo no seu pipeline.
https://learn.microsoft.com/pt-br/azure/devops/marketplace/install-extension?view=azure-devops&tabs=browser
para esse projeto, importei um repositório público que pode ser encontrado no seguinte github, https://github.com/dotnet-architecture/eShopOnWeb

Nesse trecho do código, você encontrará a configuração responsável por controlar quando a pipeline será acionada e onde ela será executada. Essas definições são fundamentais para garantir um fluxo de trabalho seguro e eficiente no Azure DevOps.

Trigger: determina quando a pipeline será acionada, no caso exposto, será acionada quando houver alteração na branch main.
Paths: especifica quais arquivos ou diretório serão monitorados para acionar a pipeline.
Exclude: garante que modificações nesse arquivo não acionem o pipeline novamente, evitando loops indesejados.
Pool: define o pool de execução no qual o pipeline será executado. No exemplo, o pool padrão ("Default") é utilizado. Isso determina os recursos e capacidades disponíveis para a execução do pipeline.

Essas configurações combinadas permitem um controle preciso sobre quando e onde a pipeline é acionada, garantindo um fluxo de trabalho seguro, eficiente e alinhado com as necessidades do projeto.

Organizemos nosso trabalho em estágios, onde cada estágio será responsável por uma função específica.

Stage:
build: esse estágio é responsável pela construção da imagem do contêiner. Ele contém um único job (job: build) com as seguintes etapas
(steps): Task: Docker@2: essa tarefa utiliza a extensão Docker para construir e enviar (buildAndPush) a imagem do contêiner para o Docker Hub. O Dockerfile utilizado é "src/PublicApi/Dockerfile" e o contexto de construção é definido como "." (diretório atual). A imagem é marcada com o número da compilação (BuildNumber) para identificação.

Stage: Scan: Esse estágio é responsável pela verificação da imagem do contêiner em busca de vulnerabilidades. Ele contém um único job (job: scan) com as seguintes etapas (steps):
— Task: trivy@1: essa tarefa utiliza a extensão Trivy para escanear a imagem do contêiner em busca de vulnerabilidades. A versão "latest" do Trivy é utilizada. É feito o login no Docker Hub (loginDockerConfig: true) e a imagem é especificada como "$(repository):$(Build.BuildNumber)". O parâmetro "exitCode" está definido como "0" para indicar que o pipeline não será interrompida se forem encontradas vulnerabilidades.

Esse estágio é responsável pelo envio (push) da imagem do contêiner para o Docker Hub. Ele contém um único job (job: push) com as seguintes etapas (steps):
Task: Docker@2: Essa tarefa utiliza a extensão Docker para enviar (push) a imagem do contêiner para o Docker Hub. A imagem é especificada como "$(repository)" sendo marcada com o número da compilação (BuildNumber) para identificação.