Como criar um pipeline de CI/CD seguro com GitHub Actions para sua aplicação Java

O GitHub Actions tornou mais fácil do que nunca criar um pipeline seguro de integração contínua e entrega contínua (CI/CD) para seus projetos no GitHub. Ao integrar seu pipeline de CI/CD ao repositório do GitHub, o GitHub Actions permite automatizar o pipeline de build, testes e implantação. Você pode criar workflows que fazem o build e testam cada pull request enviado ao repositório ou implantam em produção os pull requests mesclados. Ao integrar o Snyk ao CI/CD do GitHub, você também pode automatizar as verificações de segurança como parte do ciclo de build, antes da produção.

Como configurar um pipeline de CI com GitHub Actions para Java

Os workflows do GitHub Actions são arquivos YAML na pasta .github/workflows. Se você ainda não tem um workflow ou quer adicionar outro, selecione Ações e Novo workflow.

Para este projeto Java Spring Boot, criei um pipeline de CI usando Maven da seguinte maneira:

1name: Java CI with Maven
2
3on:
4 push:
5   branches: [ master ]
6 pull_request:
7   branches: [ master ]
8 workflow_dispatch:
9
10jobs:
11 build:
12
13   runs-on: ubuntu-latest
14
15   steps:
16   - uses: actions/checkout@v2
17   - name: Set up JDK 17
18     uses: actions/setup-java@v1
19     with:
20       java-version: 17
21   - name: Build with Maven
22     run: mvn -B package --file pom.xml

Esta ação será executada a cada push ou pull request na branch master. Ela usa o Ubuntu, faz checkout do repositório e, com a GitHub Action setup-java — usando Java 17 e Maven —, compila o arquivo JAR do Java. Se você já conhece a sintaxe, este workflow é relativamente simples. Para conferir todas as possibilidades, consulte a documentação do GitHub Actions.

Integrando o Snyk ao CI/CD do GitHub

Com o Snyk, você pode integrar testes de segurança ao seu novo projeto Java. Há duas formas principais de fazer isso. Antes, vamos garantir que dois pontos estejam configurados. Primeiro, entre na sua conta do Snyk ou crie uma gratuitamente, caso ainda não tenha uma. Depois, configure sua chave de API como um segredo chamado SNYK_TOKEN no repositório do GitHub.

Opção 1: integrar a CLI do Snyk a uma etapa de build do GitHub Actions

Você pode usar a CLI do Snyk para executar verificações de segurança automaticamente durante o build atual. Siga as etapas abaixo — incluindo as etapas adicionais após Build with Maven — para começar.

1 - name: Set up Node 14
2   uses: actions/setup-node@v3
3   with:
4     node-version: 14
5 - name: install Snyk CLI
6   run: npm install -g snyk
7 - name: run Snyk Open Source Test
8   run: snyk test
9 - name: run Snyk Code Test
10   run: snyk code test

Configure o NodeJS versão 14 e baixe a CLI do Snyk com o npm. Em seguida, analise suas dependências com o Snyk Open Source e use o Snyk Code para verificar se há vulnerabilidades no seu código personalizado.

Depois, declare SNYK_TOKEN como a variável de ambiente que contém sua chave de API. Você pode usar o segredo SNYK_TOKEN configurado anteriormente ou reutilizar o exemplo completo de código da GitHub Action.

1env:
2 SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

A vantagem dessa abordagem é que você só precisa compilar e fazer o build da aplicação uma vez, o que pode economizar bastante tempo em aplicações grandes. A desvantagem é que as etapas são executadas em sequência e podem ser ineficientes se uma das etapas posteriores falhar.

Opção 2: usar as GitHub Actions predefinidas do Snyk para criar seu pipeline de CI/CD

O Snyk criou um conjunto de GitHub Actions para verificar se há vulnerabilidades nos seus projetos. A ação necessária depende da linguagem de programação ou da ferramenta de build que você usa. Por exemplo, no projeto Java, usaremos a GitHub Action baseada em Maven mostrada abaixo.

As ações predefinidas garantem os pré-requisitos corretos para fazer o build da sua aplicação e incluem a versão mais recente da CLI para verificar seu código. Embora talvez seja necessário fazer o build da aplicação várias vezes, essas ações podem ser executadas de forma independente e em paralelo — uma grande vantagem dessa abordagem.

Vamos começar verificando nossas dependências. Já temos uma conta do Snyk e nossa chave de API está armazenada em um segredo chamado SNYK_TOKEN. Então, em vez de criar uma etapa adicional no job de build, crie um novo job chamado opensource-security.

1opensource-security:
2   runs-on: ubuntu-latest
3   steps:
4     - uses: actions/checkout@master
5     - name: Run Snyk to check for vulnerabilities
6       uses: snyk/actions/maven@master
7       env:
8         SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

De acordo com a documentação, o comando padrão é test. Sem nenhuma configuração adicional, ele verifica se há vulnerabilidades conhecidas nas dependências da sua aplicação. Para definir um argumento específico da CLI, como --all-projects, e incluir projetos aninhados, use a palavra-chave with e defina a propriedade como args.

Enquanto o Snyk verifica nossas dependências, vamos procurar vulnerabilidades no código Java usando nossa GitHub Action. Para isso, repita o processo anterior, criando um terceiro job específico e definindo a propriedade command como code test.

1 code-security:
2   runs-on: ubuntu-latest
3   steps:
4     - uses: actions/checkout@master
5     - name: Run Snyk to check for vulnerabilities
6       uses: snyk/actions/maven@master
7       env:
8         SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
9       with:
10         command: code test

Observe que os três jobs serão executados em paralelo, o que, em muitos casos, é mais eficiente.

Como adicionar entrega contínua segura ao CI/CD do GitHub

Agora, vamos falar sobre a etapa de implantação — ou entrega — do CI/CD do GitHub. Depois que o build e os testes forem concluídos, é hora de publicar o pacote no GitHub. Para isso, usaremos o plugin Maven Release no nosso projeto Java.

Como queremos liberar o pacote somente quando o job de build e os dois jobs de segurança forem concluídos com sucesso, vamos adicionar uma propriedade needs com uma lista dos jobs necessários para a liberação. Assim, garantimos que o pacote não seja implantado antes de estar totalmente compilado e seguro.

1release:
2   needs: [opensource-security, code-security, build]
3   runs-on: ubuntu-latest
4   steps:
5     - uses: actions/checkout@v2
6     - name: Set up JDK 17
7       uses: actions/setup-java@v1
8       with:
9         java-version: 17
10     - name: Set Git user
11       run: |
12         git config user.email "ghactions@brianvermeer.nl"
13         git config user.name "GitHub Actions"
14     - name: Publish JAR
15       run: mvn -B release:prepare release:perform -DskipTests
16       env:
17         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Os comandos do Maven release:prepare e release:perform verificam se a versão da release está correta e publicam o pacote no repositório do GitHub. Como vamos deixar essa tarefa a cargo do Maven, faça as seguintes configurações no arquivo pom.xml.

1  <scm>
2       <developerConnection>scm:git:https://github.com/bmvermeer/ghaction-example.git</developerConnection>
3       <tag>HEAD</tag>
4   </scm>
5   <distributionManagement>
6       <repository>
7           <id>github</id>
8           <name>GitHub</name>
9           <url>https://maven.pkg.github.com/bmvermeer/ghaction-example</url>
10       </repository>
11   </distributionManagement>

Embora nossa aplicação recém-lançada não tenha vulnerabilidades no momento, isso não significa que ela continuará segura para sempre. Novas vulnerabilidades podem surgir em vários pontos. Por isso, é essencial monitorar continuamente o código e as dependências após a implantação da aplicação.

Além de fazer verificações durante o desenvolvimento, também podemos usar o Snyk para monitorar as dependências após a implantação. Quando a release estiver concluída, use novamente a ação predefinida do Snyk, mas desta vez defina a propriedade command como monitor.

1 opensource-monitor:
2   needs: [release]
3   runs-on: ubuntu-latest
4   steps:
5     - uses: actions/checkout@master
6     - name: Run Snyk to check for vulnerabilities
7       uses: snyk/actions/maven@master
8       env:
9         SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
10       with:
11         command: monitor

Isso enviará ao Snyk a árvore de dependências, que permanece estática após a release, para monitoramento. Agora, podemos ver nosso projeto na interface do Snyk e receber notificações automáticas se uma nova vulnerabilidade for encontrada em alguma dependência usada — ajudando a manter nosso projeto Java publicado livre de vulnerabilidades.

Integrando segurança ao GitHub Actions

Com o GitHub Actions, é simples criar um pipeline de CI/CD para seu projeto no GitHub. E com as ações do Snyk, você pode integrar facilmente verificações de segurança em vários níveis para todas as suas aplicações.

O GitHub representa visualmente o pipeline que criamos hoje na imagem a seguir. Alguns jobs são executados em paralelo, enquanto outros dependem da conclusão bem-sucedida de outros jobs. Confira o projeto de exemplo completo neste repositório do GitHub.

Hoje, usamos o Snyk Code e o Snyk Open Source para verificar o código-fonte Java e as dependências do pipeline. Você também pode ampliar a cobertura verificando arquivos Docker com o Snyk Container e arquivos do Kubernetes com o Snyk IaC.

Com as GitHub Actions do Snyk, você pode adicionar verificações automaticamente ao workflow do GitHub Actions e combinar as ações conforme as necessidades do seu projeto, mantendo seu código seguro agora e no futuro.