Usando a Ferramenta de Verificação de Vulnerabilidades Snyk

Tutoriais
Kubernetes

Introdução

O Snyk foi projetado para servir como uma plataforma de segurança para desenvolvedores e com flexibilidade em mente. Seu principal objetivo é ajudá-lo a detectar e corrigir vulnerabilidades no código-fonte de sua aplicação, dependências de terceiros, imagens de contêiner e arquivos de configuração de infraestrutura (por exemplo, Kubernetes, Terraform, etc).

O Snyk é dividido em quatro componentes:

  1. Snyk Code – ajuda você a encontrar e corrigir vulnerabilidades no código-fonte de sua aplicação.
  2. Snyk Open Source – ajuda você a encontrar e corrigir vulnerabilidades em quaisquer bibliotecas de terceiros ou dependências nas quais sua aplicação depende.
  3. Snyk Container – ajuda você a encontrar e corrigir vulnerabilidades em imagens de contêiner ou cargas de trabalho do Kubernetes usadas em seu cluster.
  4. Snyk Infrastructure as Code – ajuda você a encontrar e corrigir misconfigurações em seus manifestos do Kubernetes (Terraform, CloudFormation e Azure também são suportados).

O Snyk pode ser executado de diferentes maneiras:

  • Através da interface de linha de comando usando Snyk CLI. Esta é a maneira preferida de executar dentro de scripts e várias automações, incluindo pipelines de CI/CD.
  • No navegador como Interface de Usuário da Web da Snyk. A Snyk oferece uma plataforma baseada em nuvem na qual você pode investigar relatórios de varredura, receber dicas e tomar as medidas necessárias para corrigir problemas relatados, etc. Você também pode conectar repositórios do GitHub e realizar varreduras/auditorias a partir da interface web.
  • Através de plugins do IDE. Desta forma, você pode identificar problemas precocemente enquanto desenvolve usando seu IDE favorito (por exemplo, Visual Studio Code).
  • Programaticamente, via API da Snyk. A API da Snyk está disponível para clientes em planos pagos e permite integrar programaticamente com a Snyk.

A Snyk é gratuita?

Sim, as ferramentas são gratuitas, exceto a API da Snyk e alguns recursos avançados da interface web (como relatórios avançados). Também há uma limitação no número de testes que você pode realizar por mês.

Veja os planos de preços para mais informações.

A Snyk é de código aberto?

Sim, as ferramentas e a CLI da Snyk com certeza são. Você pode visitar a página inicial do GitHub da Snyk para encontrar mais detalhes sobre a implementação de cada componente. O portal em nuvem e todos os recursos pagos, como a implementação da API restante, não são de código aberto.

Outro conjunto importante de conceitos que o Snyk está usando são Alvos e Projetos.

Alvos representam um recurso externo que o Snyk escaneou através de uma integração, da CLI, UI ou API. Exemplos de alvos são um repositório SCM, uma carga de trabalho do Kubernetes, etc.

Por outro lado, os Projetos definem os itens que o Snyk escaneia em um determinado Alvo. Um projeto inclui:

  • A scannable item external to Snyk.
  • Configuração para definir como executar esse escaneamento.

Você pode ler mais sobre os conceitos principais do Snyk aqui.

Neste guia, você usará a CLI do Snyk para realizar análise de riscos para a cadeia de suprimentos de suas aplicações Kubernetes (imagens de contêineres, manifestos YAML do Kubernetes). Em seguida, você aprenderá como tomar a ação apropriada para remediar a situação. Por fim, você aprenderá como integrar o Snyk em um pipeline CI/CD para escanear vulnerabilidades nas primeiras etapas de desenvolvimento.

Índice

Pré-requisitos

Para concluir todos os passos deste guia, você precisará de:

  1. A working DOKS cluster running Kubernetes version >=1.21 that you have access to. For additional instructions on configuring a DigitalOcean Kubernetes cluster, see: How to Set Up a DigitalOcean Managed Kubernetes Cluster (DOKS).
  2. A DigitalOcean Docker Registry. A free plan is enough to complete this tutorial. Also, make sure it is integrated with your DOKS cluster as explained here.
  3. Kubectl CLI para interação com o Kubernetes. Siga estas instruções para conectar-se ao seu cluster com kubectl e doctl.
  4. CLI do Snyk para interagir com o scanner de vulnerabilidades do Snyk.
  5. A free Snyk cloud account account used to periodically publish scan results for your Kubernetes cluster to a nice dashboard. Also, the Snyk web interface helps you with investigations and risk analysis. Please follow How to Create a Snyk Account documentation page.
  6. A Slack workspace you own, and a dedicated Slack app to get notified of vulnerability scan issues reported by Snyk.

Passo 1 – Conhecendo a CLI Snyk

Você pode escanear manualmente por vulnerabilidades via interface de linha de comando snyk. A CLI da Snyk foi projetada para ser usada em vários scripts e automações. Um exemplo prático é em um pipeline CI/CD implementado usando várias ferramentas como Tekton, Jenkins, GitHub Workflows, etc.

Quando a CLI da Snyk é invocada, ela iniciará imediatamente o processo de escaneamento e reportará problemas em um formato específico. Por padrão, ela imprimirá uma tabela de resumo usando a saída padrão ou o console. A Snyk pode gerar relatórios em outros formatos também, como JSON, HTML, SARIF, etc.

Você pode optar por enviar os resultados para o Portal Cloud da Snyk (ou interface web) via a flag --report para armazenar e visualizar os resultados do escaneamento posteriormente.

Observação: Não é obrigatório enviar os resultados do escaneamento para o portal de nuvem da Snyk. A grande vantagem de usar o portal da Snyk é a visibilidade, porque ele oferece acesso a um painel agradável onde você pode verificar todos os relatórios de escaneamento e ver o impacto na cadeia de suprimentos do Kubernetes. Também ajuda a longo prazo com investigações e dicas de remediação.

A CLI da Snyk é dividida em várias subcomandos. Cada subcomando é dedicado a um recurso específico, como:

Antes de prosseguir, certifique-se de criar uma conta gratuita usando a interface da web do Snyk. Além disso, o CLI do Snyk precisa ser autenticado com sua conta na nuvem também para que alguns comandos/subcomandos funcionem (por exemplo, snyk code test).

A few examples to try with Snyk CLI:

  1. Varredura de código aberto:
# Varre o código do seu projeto do diretório atual
snyk test
# Varre um caminho específico do diretório do seu projeto (certifique-se de substituir os espaços reservados `<>` adequadamente)
snyk test <path/to/dir>
  1. Varredura de código:
# Digitalize o código do seu projeto a partir do diretório atual
snyk code test

# Digitalize um caminho específico a partir do diretório do seu projeto (certifique-se de substituir os espaços reservados `<>` adequadamente)
snyk code test <path/to/dir>
  1. Escaneamento de imagens:
# Escaneia a imagem do docker debian ao puxá-la primeiro
snyk container debian

# Dê mais contexto ao scanner fornecendo um Dockerfile (certifique-se de substituir os espaços reservados `<>` adequadamente)
snyk container debian --file=<path/to/dockerfile>
  1. Escaneamento de infraestrutura como código:
# Digitalize o código do seu projeto a partir do diretório atual
snyk iac test

# Digitalize um caminho específico a partir do diretório do seu projeto (certifique-se de substituir os espaços reservados `<>` adequadamente)
snyk iac test <path/to/dir>

# Digitalize projetos baseados em Kustomize (primeiro você precisa renderizar o modelo final e depois passá-lo para o scanner)
kustomize build > kubernetes.yaml
snyk iac test kubernetes.yaml

O Snyk CLI fornece páginas de ajuda para todas as opções disponíveis. O comando abaixo pode ser usado para imprimir a página de ajuda principal:

snyk --help

A saída se parece com:

Output
CLI commands help
  Snyk CLI scans and monitors your projects for security vulnerabilities and license issues.

  For more information visit the Snyk website https://snyk.io

  For details see the CLI documentation https://docs.snyk.io/features/snyk-cli

How to get started
  1. Authenticate by running snyk auth
  2. Test your local project with snyk test
  3. Get alerted for new vulnerabilities with snyk monitor

Available commands
  To learn more about each Snyk CLI command, use the --help option, for example, snyk auth --help or 
  snyk container --help

  snyk auth
    Authenticate Snyk CLI with a Snyk account.

  snyk test
    Test a project for open source vulnerabilities and license issues.

Cada comando (ou subcomando) do Snyk CLI tem uma página de ajuda associada também, que pode ser acessada via snyk [comando] --help.

Por favor, visite a página oficial de documentação do Snyk CLI para mais exemplos.

Passo 2 – Conhecendo a Interface Web da Snyk

Depois de se inscrever em uma conta da Snyk, autenticar e fazer login na Snyk, a Interface Web se abre no Painel, com um assistente para guiá-lo através das etapas de configuração:

  • Identificar onde o código que você deseja monitorar na Snyk está localizado.
  • Definir quais projetos dentro do seu código você deseja que a Snyk escaneie.
  • Conectar a Snyk aos projetos relevantes para escaneá-los.
  • Revisar os resultados da sua varredura da Snyk.

As seguintes funcionalidades estão disponíveis via interface web:

Por favor, visite a página de documentação oficial para saber mais sobre a interface web do Snyk.

Entendendo os Níveis de Gravidade do Snyk

Em cada verificação, o snyk verifica seus recursos em busca de possíveis riscos de segurança e como cada um impacta seu sistema. Um nível de gravidade é aplicado a uma vulnerabilidade para indicar o risco dessa vulnerabilidade em uma aplicação.

Os níveis de gravidade podem ter um dos valores abaixo:

  • Baixa: a aplicação pode expor alguns dados permitindo o mapeamento de vulnerabilidades, que podem ser usadas com outras vulnerabilidades para atacar a aplicação.
  • Média: pode permitir que atacantes, sob algumas condições, acessem dados sensíveis em sua aplicação.
  • Alta: pode permitir que atacantes acessem dados sensíveis em sua aplicação.
  • Crítica: pode permitir que atacantes acessem dados sensíveis e executem código em sua aplicação.

O Common Vulnerability Scoring System (CVSS) determina o nível de gravidade de uma vulnerabilidade. O Snyk utiliza o framework CVSS versão 3.1 para comunicar as características e a gravidade das vulnerabilidades.

A tabela abaixo mostra o mapeamento de cada nível de gravidade:

Severity level CVSS score
Low 0.0 – 3.9
Medium 4.0 – 6.9
High 7.0 – 8.9
Critical 9.0 – 10.10

Neste guia, o limiar do nível médio é utilizado como o valor padrão no exemplo do pipeline CI/CD em uso. Geralmente, você desejará avaliar primeiro as questões de alto e crítico impacto, mas em alguns casos o nível médio também precisa de atenção. Em termos de segurança e como uma regra geral, você normalmente desejará ser muito rigoroso.

Por favor, visite a página de documentação oficial para aprender mais sobre os níveis de gravidade.

Remediação Assistida para Problemas de Segurança Relatados

Outra funcionalidade útil fornecida pela interface web do Snyk é a assistência na remediação de problemas de segurança. Isso significa que você recebe uma recomendação sobre como corrigir cada problema de segurança encontrado pelo scanner snyk. Isso é muito importante porque simplifica o processo e fecha o ciclo para cada iteração que você precisa realizar para corrigir cada problema de segurança relatado.

A imagem abaixo ilustra melhor esse processo:

Para cada problema relatado, há um botão que você pode clicar e obter assistência de remediação:

O procedimento principal é o mesmo para cada problema relatado. Significa que você clica no botão de mostrar detalhes e, em seguida, segue as etapas sugeridas para aplicar a correção.

Passo 3 – Usando o Snyk para Escanear Vulnerabilidades de Configuração do Kubernetes em um Pipeline CI/CD

Como você se beneficia ao incorporar uma ferramenta de escaneamento de conformidade de segurança em seu pipeline CI/CD e evita situações desagradáveis em um ambiente de produção?

Tudo começa no nível da base, onde o desenvolvimento de software tem início. Em geral, você vai querer usar um ambiente dedicado para cada etapa. Portanto, nas primeiras fases do desenvolvimento, quando o código da aplicação muda com muita frequência, você deve usar um ambiente de desenvolvimento dedicado (geralmente chamado de ambiente inferior). Em seguida, a aplicação fica cada vez mais refinada no ambiente de QA, onde equipes de QA realizam testes manuais e/ou automatizados. Depois, se a aplicação recebe a aprovação da equipe de QA, ela é promovida para os ambientes superiores, como o de staging, e finalmente para produção. Nesse processo, onde a aplicação é promovida de um ambiente para outro, é executado um pipeline dedicado, que escaneia continuamente artefatos da aplicação e verifica o nível de severidade. Se o nível de severidade não atender a um limiar específico, o pipeline falha imediatamente e a promoção de artefatos da aplicação para produção é interrompida nas fases iniciais.

Portanto, a ferramenta de escaneamento de segurança (por exemplo, snyk) atua como um guardião impedindo que artefatos indesejados entrem em seu ambiente de produção desde as fases iniciais de desenvolvimento. Da mesma forma, os pipelines dos ambientes superiores utilizam o snyk para permitir ou proibir a entrada de artefatos da aplicação na etapa final de produção.

Implementação do Fluxo de Trabalho de CI/CD do GitHub Actions

Neste passo, você aprenderá como criar e testar uma amostra de pipeline CI/CD com verificação integrada de vulnerabilidades via fluxos de trabalho do GitHub. Para aprender os fundamentos de usar as Ações do Github com o Kubernetes da DigitalOcean, consulte este tutorial.

O pipeline fornecido na seção seguinte constrói e implementa a aplicação game-2048-example do repositório kubernetes-sample-apps da DigitalOcean.

Em uma visão geral de alto nível, o fluxo de trabalho de CI/CD do jogo 2048 fornecido no repositório kubernetes-sample-apps é composto pelas seguintes etapas:

  1. Etapa de construção e teste da aplicação – constrói os artefatos principais da aplicação e executa testes automatizados.
  2. Etapa de verificação da imagem da aplicação pelo Snyk – verifica a imagem docker da aplicação em busca de vulnerabilidades conhecidas. Ela atua como um portão, e o estado final do pipeline (passar/falhar) depende desta etapa. Em caso de falha, uma notificação no Slack é enviada.
  3. Etapa de construção e envio da imagem da aplicação – constrói e marca a imagem da aplicação usando o último SHA do commit git. Em seguida, a imagem é enviada para o DOCR.
  4. A fase de verificação da infraestrutura como código (IAC) da Snyk – verifica vulnerabilidades conhecidas nos manifestos YAML do Kubernetes associados à aplicação. Age como um portão, e o estado final do pipeline (passar/falhar) depende desta etapa. Em caso de falha, uma notificação no Slack também é enviada.
  5. A fase de implantação da aplicação – implanta a aplicação no Kubernetes (DOKS).

O diagrama abaixo ilustra cada trabalho do pipeline e as etapas associadas com ações (apenas a configuração relevante é mostrada):

Notas:

  • No caso de projetos baseados em kustomize, é melhor renderizar o manifesto final para capturar e escanear tudo (incluindo recursos remotos). Por outro lado, pode ser difícil identificar qual recurso do Kubernetes precisa ser corrigido. Isso ocorre devido ao fato de que o arquivo de manifesto resultante é composto por todos os recursos a serem aplicados. É assim que o kustomize funciona – ele reúne todos os fragmentos de configuração de cada sobreposição e os aplica sobre uma base para construir o composto final.
  • Você também pode dizer à Snyk para escanear a pasta inteira onde você mantém suas configurações kustomize. Desta forma, é mais fácil identificar qual recurso precisa ser corrigido em seu repositório. Recursos remotos usados pelo kustomize precisam ser corrigidos upstream. Além disso, segredos do Kubernetes e ConfigMaps gerados via kustomize não são capturados.

Como você falha o pipeline se um determinado nível de conformidade de segurança não for atendido?

O Snyk CLI fornece uma flag chamada --severity-threshold para esse fim. Essa flag está correlacionada com o nível de gravidade geral calculado após cada verificação. No caso do Snyk, o nível de gravidade pode assumir um dos seguintes valores: baixo, médio, alto ou crítico. Você pode fazer com que o pipeline falhe ou passe com base no valor do nível de gravidade e interromper a implantação da aplicação se as condições não forem atendidas.

A imagem abaixo ilustra o fluxo para o exemplo de pipeline CI/CD usado neste guia:

Por favor, siga os passos abaixo para criar e testar o fluxo de trabalho do Snyk CI/CD fornecido no repositório do GitHub kubernetes-sample-apps:

  1. Faça um fork do repositório do GitHub kubernetes-sample-apps.
  2. Crie os seguintes secrets criptografados do GitHub para sua cópia do kubernetes-sample-apps (Guia de Configurações -> Segredos -> Actions):
    • DIGITALOCEAN_ACCESS_TOKEN – armazena o token da sua conta DigitalOcean.
    • DOCKER_REGISTRY – armazena o nome do registro do Docker da DigitalOcean incluindo o endpoint (por exemplo, registry.digitalocean.com/sample-apps).
    • DOKS_CLUSTER – armazena o nome do seu cluster DOKS. Você pode executar o seguinte comando para obter o nome do seu cluster DOKS: doctl k8s cluster list --no-header --format Name.
    • SNYK_TOKEN – armazena o ID da sua conta de usuário Snyk – execute: snyk config get api para obter o ID. Se isso não funcionar, você pode recuperar o token na página de configurações da sua conta de usuário.
    • SLACK_WEBHOOK_URL – armazena a URL do webhook de entrada do Slack usada para notificações de verificação do Snyk.
  3. Navegue até a aba Ações do seu repositório bifurcado e selecione o fluxo de trabalho Exemplo de CI/CD do Jogo 2048 do Snyk:
  4. Clique no botão Executar Fluxo de Trabalho e deixe os valores padrão:

A new entry should appear in the below list after clicking the Run Workflow green button. Select the running workflow to observe the pipeline progress:

O pipeline falhará e será interrompido quando o trabalho verificação de segurança do contêiner do snyk for executado. Isso é esperado porque o valor padrão de nível de gravidade usado na entrada do fluxo de trabalho, que é médio, não atende às expectativas. Você também deve receber uma notificação do Slack com detalhes sobre a execução do fluxo de trabalho:

Nos próximos passos, você aprenderá a investigar o relatório de varredura do snyk para corrigir os problemas, diminuir o nível de gravidade e passar pelo pipeline.

Passo 4 – Investigando os Resultados da Verificação do Snyk e Corrigindo os Problemas Relatados

Quando o limite do nível de gravidade não é atingido, o fluxo de trabalho do GitHub do game-2048 falhará, e uma notificação no Slack será enviada com detalhes adicionais. Você também recebe relatórios de segurança publicados no GitHub e acessíveis na aba Segurança do repositório do seu projeto.

O fluxo de trabalho do game-2048 executa duas verificações de segurança:

  1. Verificações de segurança da imagem do contêiner – o trabalho snyk-container-security-check é usado para esse fim. O comando equivalente do snyk sendo usado é – snyk container test <IMAGEM-DO-GAME-2048>:<TAG> --file=/caminho/para/o/Dockerfile/do/game-2048.
  2. Verificações de configuração incorreta dos manifestos do Kubernetes – o trabalho snyk-iac-security-check é usado para esse fim. O comando equivalente do snyk sendo usado é – snyk iac test /caminho/para/o/projeto/kubernetes/manifestos.

Dessa forma, diminuir o nível de gravidade e passar no fluxo de trabalho consiste em:

  1. Investigar e corrigir problemas relatados pelo trabalho snyk-container-security-check.
  2. Investigar e corrigir problemas relatados pelo trabalho snyk-iac-security-check.

A seguir, aprenderá como abordar cada um em sequência.

Investigação e Correção de Vulnerabilidades em Imagens de Containers

O pipeline de exemplo usado neste guia executa verificações de segurança para a imagem do container do jogo-2048 e o Dockerfile associado por meio da tarefa verificação de segurança de container do snyk.

A tarefa verificação de segurança de container do snyk executa as seguintes etapas:

  1. Constrói a imagem Docker da aplicação do jogo-2048 localmente. Esta etapa é implementada usando a ação do GitHub docker-build-push.
  2. Executa verificações de segurança do Snyk para a imagem do container da aplicação e Dockerfile. Esta etapa é implementada usando o comando teste de container do snyk. Os resultados da verificação são exportados usando o formato SARIF do GitHub. O limiar de nível de segurança é controlado via argumento –severity-threshold – ele é definido como o parâmetro de entrada snyk_fail_threshold se o fluxo de trabalho for acionado manualmente, ou para a variável de ambiente SNYK_FAIL_THRESHOLD, se o fluxo de trabalho for executado automaticamente.
  3. Os resultados da varredura (formato SARIF) são publicados na aba de segurança do seu repositório de aplicativos. Este passo é implementado usando a ação do GitHub codeql.

Abaixo, um trecho mostra a lógica principal do trabalho snyk-container-security-check:

- name: Build App Image for Snyk container scanning
  uses: docker/build-push-action@v3
  with:
    context: ${{ env.PROJECT_DIR }}
    push: false
    tags: "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}"

- name: Check application container vulnerabilities
  run: |
    snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
      --file=Dockerfile \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-container-scan.sarif
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk report SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-container-scan.sarif
    category: snyk-container-scan

–file=Dockerfile \

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

–sarif –sarif-file-output=snyk-container-scan.sarif

Para corrigir os problemas relatados, você precisa primeiro verificar a aba de segurança do seu repositório de aplicativos kubernetes-sample-apps forkado:

FROM node:18.6.0-slim AS builder
WORKDIR /usr/src/app
COPY . .
RUN npm install --include=dev
Você verá uma série de vulnerabilidades para a imagem base do Docker neste caso. Clique em cada uma para expandir e ver mais detalhes:
Para concluir as investigações e ver as recomendações oferecidas pelo Snyk, você precisa inspecionar a saída do trabalho snyk-container-security-check do fluxo de trabalho principal:
Nota:O teste de contêiner Snyk oferece a possibilidade de exportar resultados no formato SARIF, mas não sabe como enviar relatórios para o portal de nuvem do Snyk. Por outro lado, o monitor de contêiner Snyk oferece a possibilidade de enviar resultados para o portal de nuvem do Snyk, mas não pode exportar SARIF. Portanto, este guia está usando o teste de contêiner Snyk com a funcionalidade de exportação SARIF. Algumas recomendações não estão disponíveis na saída SARIF, infelizmente. Portanto, você também deve procurar as recomendações na saída do console do trabalho.
O trabalho snyk-container-security-check mostra que a Snyk recomenda atualizar a versão da imagem base de node:16-slim para node:18.6.0-slim. Essa mudança elimina o(s) problema(s) de alto risco e também reduz o número de outras vulnerabilidades relatadas de 70 para 44 - uma redução substancial de quase 50%!!!
ENV NODE_ENV=development
RUN npm run build

FROM node:18.6.0-slim
RUN npm install http-server -g
RUN mkdir /public
WORKDIR /public
COPY --from=builder /usr/src/app/dist/ ./
EXPOSE 8080
USER 1000
CMD ["http-server"]

Agora, abra o Dockerfile do aplicativo game-2048 em seu fork e altere as diretivas FROM para apontar para a nova versão (node:18.6.0-slim no momento da escrita):

#

# O modo de construção pode ser definido via variável de ambiente NODE_ENV (desenvolvimento ou produção)

# Consulte o package.json e webpack.config.js do projeto

#

Por fim, faça o commit das alterações no seu repositório GitHub e acione o fluxo de trabalho novamente (mantendo os valores padrão). Desta vez, o trabalho snyk-container-security-check deve ser aprovado:

Ao acessar a aba de segurança do seu projeto, não deve haver problemas relatados.

Como garantir a redução de vulnerabilidades na imagem base no futuro?

  1. A melhor abordagem é usar uma imagem base com uma pegada mínima – quanto menos binários ou dependências na imagem base, melhor. Outra boa prática é monitorar continuamente seus projetos, conforme explicado na seção Monitorar seus Projetos Regularmente deste guia.
  2. Você notará que o pipeline ainda falha, mas desta vez na fase snyk-iac-security-check. Isso é esperado porque há problemas de segurança nos manifestos do Kubernetes usados para implantar a aplicação. Na próxima seção, você aprenderá como investigar esta situação e aplicar recomendações de segurança do Snyk para corrigir os problemas relatados.

Investigando e Corrigindo Vulnerabilidades nos Manifestos do Kubernetes

- name: Check for Kubernetes manifests vulnerabilities
  run: |
    snyk iac test \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-iac-scan.sarif \
      --report
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk IAC SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-iac-scan.sarif
    category: snyk-iac-scan

O pipeline ainda está falhando e para no trabalho snyk-iac-security-check. Isso é esperado porque o valor padrão do nível de gravidade usado na entrada do fluxo de trabalho, que é médio, não atende aos requisitos de segurança do projeto.

  1. O trabalho snyk-iac-security-check verifica vulnerabilidades (ou configurações erradas) nos manifestos do Kubernetes e executa as seguintes etapas:
  2. As verificações de segurança da Snyk para manifestos do Kubernetes são realizadas a partir do diretório do projeto game-2048-example. Este passo é implementado usando o comando snyk iac test. Os resultados da verificação são exportados usando o formato GitHub SARIF. O limiar do nível de segurança é controlado através do argumento –severity-threshold – ele é definido como o parâmetro de entrada snyk_fail_threshold se o fluxo de trabalho for acionado manualmente, ou como a variável de ambiente SNYK_FAIL_THRESHOLD, se o fluxo de trabalho for executado automaticamente. Finalmente, o argumento –report também é usado para enviar os resultados da verificação para o portal da nuvem da Snyk.

Os resultados da verificação (formato SARIF) são publicados na aba de segurança do repositório da sua aplicação. Este passo é implementado usando a ação do GitHub codeql.

Abaixo está um trecho que mostra a implementação real de cada etapa do trabalho snyk-iac-security-check:

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: game-2048
spec:
  replicas: 1
  selector:
    matchLabels:
      app: game-2048
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: game-2048
    spec:
      containers:
        - name: backend
          --sarif --sarif-file-output=snyk-iac-scan.sarif \
          image: registry.digitalocean.com/sample-apps/2048-game:latest
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 200m
              memory: 100Mi
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - all

Para corrigir os problemas relatados, você tem duas opções:

  • Use o portal da nuvem da Snyk e acesse o projeto game-2048 para verificar os detalhes:
  • Use a guia de segurança do seu repositório do aplicativo game-2048 para verificar os detalhes:
  • De qualquer forma, você receberá recomendações sobre como corrigir os problemas relatados.
  • Para este guia, você usará o portal de nuvem do Snyk para investigar os problemas de segurança relatados. Primeiro, clique na entrada game-2048-example na lista de projetos, em seguida, selecione o arquivo kustomize/resources/deployment.yaml:

Em seguida, marque a caixa de seleção Médio no submenu Severidade à esquerda para exibir apenas problemas de nível médio:

Depois, você pode inspecionar cada cartão de problema relatado e verificar os detalhes. Continue e clique no botão Mostrar mais detalhes do cartão Container está sendo executado sem controle de usuário root – você receberá mais detalhes sobre o problema atual e dicas importantes sobre como corrigi-lo:

A few final checks can be performed as well on the Kubernetes side to verify if the reported issues were fixed:

  1. Depois de coletar todas as informações de cada cartão, você pode prosseguir e editar o arquivo deployment.yaml do seu repositório (localizado na subpasta game-2048-example/kustomize/resources). As correções já estão no lugar, você só precisa descomentar as últimas linhas do arquivo. O arquivo deployment.yaml final deve parecer com o abaixo:
  2. readOnlyRootFilesystem – executa a imagem do contêiner somente leitura (não pode alterar arquivos por kubectl exec no contêiner).

allowPrivilegeEscalation – configurar allowPrivilegeEscalation como false garante que nenhum processo filho de um contêiner possa obter mais privilégios do que seu pai.

capabilities.drop – Para tornar os contêineres mais seguros, você deve fornecer aos contêineres a menor quantidade de privilégios necessários para executar. Na prática, você remove tudo por padrão e, em seguida, adiciona as capacidades necessárias passo a passo. Você pode aprender mais sobre as capacidades de contêiner aqui.

Finalmente, comite as alterações para o arquivo deployment.yaml e faça push para o ramo principal. Após acionar manualmente o fluxo de trabalho, ele deve ser concluído com sucesso desta vez:

Você também deve receber uma notificação verde do Slack do trabalho de verificação do Snyk. Acesse o link do portal do Snyk e verifique se os problemas que você corrigiu recentemente desapareceram – não deve haver problemas de nível médio relatados.

Verifique se a implantação do jogo 2048 possui um sistema de arquivos somente leitura (imutável) escrevendo no arquivo index.html usado pela aplicação do jogo 2048:

kubectl exec -it deployment/game-2048 -n game-2048 -- /bin/bash -c "echo > /public/index.html"

A saída se parece com:

Saída
/bin/bash: /public/index.html: Sistema de arquivos somente leitura
comando terminado com código de saída 1

Verifique se a implantação do jogo 2048 possui um sistema de arquivos somente leitura (imutável) escrevendo no arquivo index.html usado pela aplicação do jogo 2048:

A saída se parece com:

snyk-container-security-check:
    runs-on: ubuntu-latest
    needs: build-and-test-application

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      ...

      - name: Check application container vulnerabilities
        run: |
          snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile \
            --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
            --target-name=${{ env.PROJECT_NAME }} \
            --target-reference=${{ env.ENVIRONMENT }} \
            --sarif-file-output=snyk-container-scan.sarif
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Monitor the application container using Snyk
        run: |
          snyk container monitor "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      
      ...

Verifique se o contêiner é executado como um usuário não root (deve imprimir um número inteiro diferente de zero – por exemplo, 1000):

kubectl exec -it deployment/game-2048 -n game-2048 -- id -u

Verifique se o contêiner é executado como um usuário não root (deve imprimir um número inteiro diferente de zero – por exemplo, 1000):

Se todas as verificações forem aprovadas, então você aplicou com sucesso as recomendações de segurança necessárias.

build-and-test-application:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm test
        working-directory: ${{ env.PROJECT_DIR }}

      - name: Snyk code test and monitoring
        run: |
          snyk test ${{ env.PROJECT_DIR }}
          snyk monitor ${{ env.PROJECT_DIR }}
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Monitore seus Projetos Regularmente

A automação de verificação de vulnerabilidades que você implementou até agora é um bom ponto de partida, mas não é perfeito. Por quê?

Um problema com a abordagem atual é que você nunca sabe quando novos problemas são relatados para os ativos que você já implantou em seus ambientes. Em outras palavras, você avaliou os riscos de segurança e tomou as medidas para corrigir os problemas em um ponto específico no tempo – quando sua automação de CI/CD foi executada.

Mas e se novos problemas forem relatados enquanto isso, e sua aplicação estiver vulnerável novamente? O Snyk ajuda você a superar essa situação por meio do recurso de monitoramento. O recurso de monitoramento do Snyk ajuda a lidar com novas vulnerabilidades, que são constantemente divulgadas. Quando combinado com a integração do Snyk Slack (explicada no Passo 6 – Habilitando Notificações no Slack), você pode tomar ações imediatas para corrigir problemas recém-divulgados que possam afetar sua aplicação em um ambiente de produção.

Para aproveitar esse recurso, tudo o que você precisa fazer é usar o comando snyk monitor antes de qualquer etapa de implantação em seu pipeline CI/CD. A sintaxe é muito semelhante aos comandos snyk test (uma das coisas legais sobre a CLI do Snyk é que ela foi projetada com uniformidade em mente). O comando snyk monitor enviará uma captura instantânea para o portal de nuvem do Snyk e, a partir daí, você será notificado sobre vulnerabilidades recém-divulgadas para seu projeto.

A more efficient approach is where you integrate vulnerability scan tools directly in your favorite IDE (or Integrated Development Environment). This way, you can detect and fix security issues ahead of time in the software development cycle.

Em termos de automação do fluxo de trabalho do GitHub, você pode monitorar sua aplicação contêiner no trabalho verificação de segurança do contêiner do Snyk, após testar as vulnerabilidades. O trecho abaixo mostra uma implementação prática para o pipeline usado neste guia (algumas etapas foram omitidas para maior clareza):

  1. –file=${{ env.PROJECT_DIR }}/Dockerfile \
  2. –severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
  3. –target-name=${{ env.PROJECT_NAME }} \
  4. –target-reference=${{ env.ENVIRONMENT }} \

–sarif-file-output=snyk-container-scan.sarif

–file=${{ env.PROJECT_DIR }}/Dockerfile

O trecho acima mostra uma etapa adicional chamada Monitorar o contêiner da aplicação usando o Snyk onde o monitor real do contêiner do Snyk é executado.

Após a execução do comando de monitoramento do Snyk, você pode fazer login na interface da web do Snyk para ver o instantâneo mais recente e o histórico do seu projeto:

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

Você também pode testar e monitorar o código-fonte da sua aplicação no trabalho compilar e testar a aplicação. O trecho abaixo mostra um exemplo de implementação para o fluxo de trabalho do GitHub usado neste guia:

Em seguida, você receberá notificações no Slack regularmente sobre vulnerabilidades recém-divulgadas para o seu projeto.

Tratando Exceções

Há situações em que você não deseja que o relatório final seja afetado por alguns problemas que sua equipe considera seguro ignorar. O Snyk oferece um recurso integrado para gerenciar exceções e superar essa situação.

Pode ler mais sobre esta funcionalidade aqui.

O Snyk para IDEs

O Snyk oferece suporte para uma variedade de IDEs, tais como:

Plugin Eclipse.

Plugin JetBrains.

  • Extensão Visual Studio.
  • Extensão Visual Studio Code.
  • Os plugins acima ajudarão a detetar e corrigir problemas nas fases iniciais de desenvolvimento, eliminando assim frustrações, custos e falhas de segurança nos sistemas de produção. Além disso, ajuda a reduzir as iterações e o esforço humano a longo prazo. Como exemplo, para cada problema de segurança reportado pela sua automação de CI/CD, é necessário voltar atrás e corrigir o problema no seu código, fazer commit das alterações, aguardar pela automação de CI/CD novamente e repetir em caso de falha.
  • A partir da documentação oficial, pode ler mais sobre estas funcionalidades na página Snyk para IDEs.
  • Passo 5 – Disparar automaticamente o Fluxo de Trabalho do Snyk CI/CD
  • Você pode configurar o fluxo de trabalho para ser acionado automaticamente a cada commit ou PR contra o ramo principal descomentando as seguintes linhas no topo do arquivo game-2048-snyk.yaml:
  • Após editar o arquivo, faça commit das alterações no seu ramo principal e você estará pronto para começar.
  • Passo 6 – Habilitando Notificações no Slack
  • Você pode configurar o Snyk para enviar alertas no Slack sobre novas vulnerabilidades descobertas em seus projetos e sobre novas atualizações ou patches que se tornaram disponíveis.
  • Para configurar isso, você precisará gerar um webhook do Slack. Você pode fazer isso via Incoming WebHooks ou criando seu próprio Aplicativo Slack. Depois de gerar sua URL de webhook do Slack, vá para as configurações de ‘Gerenciar organização’, insira a URL e clique no botão Conectar:

Source:
https://www.digitalocean.com/community/developer-center/using-the-snyk-vulnerability-scanning-tool