Het Gebruik van de Snyk Kwetsbaarheidsscanner

Inleiding

Snyk is ontworpen als een ontwikkelaarsbeveiligingsplatform met flexibiliteit in gedachten. Het belangrijkste doel is om u te helpen kwetsbaarheden te detecteren en op te lossen in de broncode van uw toepassing, afhankelijkheden van derden, containerimages en infrastructuurconfiguratiebestanden (bijv. Kubernetes, Terraform, enz.).

Snyk is verdeeld in vier componenten:

1. Snyk Code – helpt u kwetsbaarheden in de broncode van uw toepassing te vinden en op te lossen.
2. Snyk Open Source – helpt u kwetsbaarheden te vinden en op te lossen voor eventuele externe bibliotheken of afhankelijkheden waar uw toepassing op vertrouwt.
3. Snyk Container – helpt u kwetsbaarheden te vinden en op te lossen in containerimages of Kubernetes-workloads die in uw cluster worden gebruikt.
4. Snyk Infrastructure as Code – helpt u misconfiguraties te vinden en op te lossen in uw Kubernetes-manifesten (Terraform, CloudFormation en Azure worden ook ondersteund).

Snyk kan op verschillende manieren worden uitgevoerd:

• Via de command-line-interface met behulp van Snyk CLI. Dit is de voorkeursmethode om uit te voeren binnen scripts en diverse automatiseringen, inclusief CI/CD-pipelines.
• In de browser als Snyk Web UI. Snyk biedt ook een cloudgebaseerd platform aan waarop je scanrapporten kunt onderzoeken, hints kunt ontvangen en vereiste acties kunt ondernemen om gerapporteerde problemen op te lossen, enz. Je kunt ook GitHub-repositories verbinden en scans/audits uitvoeren vanuit de webinterface.
• Via IDE-plug-ins. Op deze manier kun je problemen vroegtijdig opsporen terwijl je ontwikkelt met behulp van je favoriete IDE (bijv. Visual Studio Code).
• Programmatisch, via de Snyk API. De Snyk API is beschikbaar voor klanten met betaalde abonnementen en stelt je in staat om op programmatische wijze te integreren met Snyk.

Is Snyk gratis?

Ja, de tools zijn gratis, behalve de Snyk API en enkele geavanceerde functies van de web-UI (zoals geavanceerde rapportage). Er is ook een limiet aan het aantal tests dat je per maand kunt uitvoeren.

Zie de prijsopties voor meer informatie.

Is Snyk open source?

Ja, de tools en de Snyk CLI zijn dat zeker. Je kunt de Snyk GitHub-startpagina bezoeken voor meer details over de implementatie van elk onderdeel. Het cloudportaal en alle betaalde functies zoals de REST API-implementatie zijn niet open source.

Een ander belangrijk concept dat Snyk gebruikt, zijn Doelen en Projecten.

Doelen vertegenwoordigen een externe bron die Snyk heeft gescand via een integratie, de CLI, UI of API. Voorbeelden van doelen zijn een SCM-opslagplaats, een Kubernetes-workload, enzovoort.

Projecten daarentegen definiëren de items die Snyk scant voor een bepaald Doel. Een project omvat:

• A scannable item external to Snyk.
• Configuratie om te definiëren hoe die scan moet worden uitgevoerd.

Je kunt meer lezen over de kernconcepten van Snyk hier.

In deze handleiding gebruik je Snyk CLI om risicoanalyses uit te voeren voor je Kubernetes-applicatiesupply chain (containerimages, Kubernetes YAML-manifesten). Vervolgens leer je hoe je de juiste actie onderneemt om de situatie te verhelpen. Ten slotte leer je hoe je Snyk integreert in een CI/CD-pijplijn om te scannen op kwetsbaarheden in de vroege ontwikkelingsfasen.

Inhoudsopgave

• Introductie
• Vereisten
• Stap 1 – Kennismaken met de Snyk CLI
• Stap 2 – Kennismaken met de Snyk Web UI
  • Begrip van Snyk Ernstniveaus
  • Ondersteunde oplossing voor gerapporteerde beveiligingsproblemen
• Stap 3 – Gebruik van Snyk voor het scannen op Kubernetes-configuratiekwetsbaarheden in een CI/CD-pijplijn
  • Implementatie van GitHub Actions CI/CD-workflow
• Stap 4 – Onderzoeken van Snyk Scan Resultaten en Oplossen van Gerapporteerde Problemen
  • Onderzoek en oplossen van kwetsbaarheden in containerimages
  • Onderzoek en oplossen van kwetsbaarheden in Kubernetes-manifesten
  • Monitor uw projecten regelmatig
  • Behandeling van uitzonderingen
  • Snyk voor IDE’s
• Stap 5 – Het Automatisch Activeren van de Snyk CI/CD Workflow
• Stap 6 – Het Inschakelen van Slack Meldingen
• Conclusie
• Aanvullende Bronnen

Vereisten

Om alle stappen uit deze handleiding uit te voeren, heb je nodig:

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 voor interactie met Kubernetes. Volg deze instructies om verbinding te maken met je cluster met kubectl en doctl.
4. Snyk CLI om te communiceren met de Snyk kwetsbaarheidsscanner.
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.

Stap 1 – Kennismaking met de Snyk CLI

Je kunt handmatig scannen op kwetsbaarheden via de snyk command line interface. De snyk CLI is ontworpen om te worden gebruikt in verschillende scripts en automatiseringen. Een praktisch voorbeeld is in een CI/CD-pijplijn geïmplementeerd met verschillende tools zoals Tekton, Jenkins, GitHub Workflows, etc.

Wanneer de snyk CLI wordt aangeroepen, begint het direct het scanproces en rapporteert het problemen in een specifiek formaat. Standaard zal het een samenvattende tabel afdrukken met behulp van de standaarduitvoer of de console. Snyk kan ook rapporten genereren in andere formaten, zoals JSON, HTML, SARIF, etc.

Je kunt ervoor kiezen om de resultaten naar het Snyk Cloud Portal (of web-UI) te pushen via de --report vlag om de scanresultaten later op te slaan en te visualiseren.

De Snyk CLI is onderverdeeld in verschillende subcommando’s. Elk subcommando is gewijd aan een specifieke functie, zoals:

• Open source scannen – identificeert huidige projectafhankelijkheden en rapporteert gevonden beveiligingsproblemen.
• Code scannen – rapporteert beveiligingsproblemen die zijn gevonden in de broncode van uw applicatie.
• Afbeelding scannen – rapporteert beveiligingsproblemen die zijn gevonden in containerafbeeldingen (bijv. Docker).
• Scannen van infrastructuur als codebestanden – rapporteert beveiligingsproblemen die zijn gevonden in configuratiebestanden die worden gebruikt door Kubernetes, Terraform, enzovoort.

Voordat u verder gaat, zorg ervoor dat u een gratis account aanmaakt via de Snyk-webinterface. Zorg er ook voor dat de snyk CLI is geauthenticeerd met uw cloudaccount, zodat sommige opdrachten/subopdrachten kunnen worden uitgevoerd (bijv. snyk code test).

A few examples to try with Snyk CLI:

1. Open source scannen:

# Scant de code van uw project vanuit de huidige directory
snyk test
# Scan een specifieke pad vanuit de projectdirectory (zorg ervoor dat u de `<>` placeholders vervangt door de juiste waarden)
snyk test <path/to/dir>

2. Code scannen:

# Scan uw projectcode vanuit de huidige map
snyk code test

# Scan een specifiek pad vanuit uw projectmap (zorg ervoor dat u de `<>` placeholders dienovereenkomstig vervangt)
snyk code test <path/to/dir>

3. Afbeelding scannen:

# Scant de debian docker image door deze eerst op te halen
snyk container debian

# Geef meer context aan de scanner door een Dockerfile te verstrekken (zorg ervoor dat u de `<>` placeholders dienovereenkomstig vervangt)
snyk container debian --file=<path/to/dockerfile>

4. Infrastructuur als code scannen:

# Scan uw projectcode vanuit de huidige map
snyk iac test

# Scan een specifiek pad vanuit uw projectmap (zorg ervoor dat u de `<>` placeholders dienovereenkomstig vervangt)
snyk iac test <path/to/dir>

# Scan Kustomize-gebaseerde projecten (eerst moet u de uiteindelijke sjabloon renderen en deze vervolgens doorgeven aan de scanner)
kustomize build > kubernetes.yaml
snyk iac test kubernetes.yaml

De Snyk CLI biedt helppagina’s voor alle beschikbare opties. De onderstaande opdracht kan worden gebruikt om de hoofdhelppagina af te drukken:

snyk --help

De output ziet er vergelijkbaar uit met:

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.

Elk snyk CLI-commando (of subcommando) heeft ook een bijbehorende helppagina, die kan worden benaderd via snyk [commando] --help.

Bezoek alstublieft de officiële snyk CLI-documentatiepagina voor meer voorbeelden.

Stap 2 – Kennismaking met de Snyk Web UI

Nadat je je hebt aangemeld voor een Snyk-account, authenticeren en inloggen op Snyk, opent de web-UI naar het dashboard, met een wizard die je door de installatiestappen begeleidt:

• Identificeren waar de code die je wilt controleren in Snyk zich bevindt.
• Het definiëren van welke projecten binnen je code je wilt dat Snyk scant.
• Het verbinden van Snyk met de relevante projecten om ze te scannen.
• Het beoordelen van de resultaten van je Snyk-scan.

De volgende functies zijn beschikbaar via de web-UI:

• Verken het dashboard
• Onderzoeksrapporten bekijken
• Projecten beheren
• Integraties beheren
• Beheer leden van de groep of organisatie
• Bekijk Snyk updates
• Krijg hulp
• Beheer uw gebruikersaccount

Bezoek alstublieft de officiële documentatiepagina om meer te weten te komen over de Snyk web-UI.

Begrijp Snyk Ernstigheidsniveaus

Bij elke scan verifieert snyk uw bronnen op mogelijke beveiligingsrisico’s en hoe elk risico van invloed is op uw systeem. Een ernstigheidsniveau wordt toegepast op een kwetsbaarheid om het risico voor die kwetsbaarheid in een toepassing aan te geven.

Ernstigheidsniveaus kunnen een van de onderstaande waarden hebben:

• Laag: de toepassing kan enige gegevens blootstellen waardoor kwetsbaarheden in kaart kunnen worden gebracht, die kunnen worden gebruikt met andere kwetsbaarheden om de toepassing aan te vallen.
• Gemiddeld: kan onder bepaalde omstandigheden aanvallers toegang geven tot gevoelige gegevens op uw toepassing.
• Hoog: kan aanvallers toegang geven tot gevoelige gegevens op uw toepassing.
• Kritiek: kan aanvallers toegang geven tot gevoelige gegevens en code uitvoeren op uw toepassing.

Het Common Vulnerability Scoring System (CVSS) bepaalt het ernstniveau van een kwetsbaarheid. Snyk gebruikt het CVSS-framework versie 3.1 om de kenmerken en ernst van kwetsbaarheden te communiceren.

De onderstaande tabel toont de mapping van elk ernstniveau:

In deze handleiding wordt de medium drempelwaarde gebruikt als de standaardwaarde in het voorbeeld van de CI/CD-pijplijn die wordt gebruikt. Gewoonlijk wilt u eerst de hoge en kritieke problemen beoordelen, maar in sommige gevallen vereist het mediumniveau ook aandacht. Wat betreft beveiliging en als algemene vuistregel, wilt u meestal erg streng zijn.

Bezoek alstublieft de officiële documentatie pagina voor meer informatie over ernstniveaus.

Ondersteunde Remediëring voor Gerapporteerde Beveiligingsproblemen

Een andere handige functie die wordt geleverd door de Snyk web-UI is hulp bij het oplossen van beveiligingsproblemen. Dit betekent dat u een aanbeveling ontvangt over hoe u elk beveiligingsprobleem dat is gevonden door de snyk-scanner kunt oplossen. Dit is erg belangrijk omdat het het proces vereenvoudigt en de kringloop sluit voor elke iteratie die u moet uitvoeren om elk gerapporteerd beveiligingsprobleem op te lossen.

De onderstaande afbeelding illustreert dit proces beter:

Voor elk gemeld probleem is er een knop die je kunt klikken om remediehulp te krijgen:

De hoofdprocedure is hetzelfde voor elk gemeld probleem. Dat betekent dat je op de knop ‘details weergeven’ klikt en vervolgens de voorgestelde stappen neemt om de oplossing toe te passen.

Stap 3 – Gebruik Snyk om te scannen op Kubernetes-configuratiekwetsbaarheden in een CI/CD-pijplijn

Hoe profiteer je van het insluiten van een beveiligingscompliance-scantool in je CI/CD-pijplijn en vermijd je onaangename situaties in een productieomgeving?

Het begint allemaal op het basisniveau, waar softwareontwikkeling begint. Over het algemeen wilt u voor elk stadium een aparte omgeving gebruiken. Dus, in de vroege stadia van ontwikkeling wanneer de toepassingscode zeer vaak verandert, moet u een toegewijde ontwikkelingsomgeving gebruiken (meestal de lagere omgeving genoemd). Vervolgens wordt de toepassing steeds verfijnder in de QA-omgeving, waar QA-teams handmatige en/of geautomatiseerde tests uitvoeren. Als de toepassing goedkeuring krijgt van het QA-team, wordt deze gepromoveerd naar de bovenliggende omgevingen, zoals staging, en uiteindelijk naar productie. In dit proces, waar de toepassing van de ene omgeving naar de andere wordt gepromoveerd, draait er een toegewijde pijplijn die voortdurend toepassingsartefacten scant en het ernstniveau controleert. Als het ernstniveau niet aan een specifieke drempel voldoet, mislukt de pijplijn onmiddellijk en wordt de promotie van toepassingsartefacten naar productie in de vroege stadia gestopt.

Dus, de beveiligingsscanningtool (bijv. snyk) fungeert als een poortwachter die ongewenste artefacten tegenhoudt om vanaf de vroege stadia van ontwikkeling in uw productieomgeving te komen. Op dezelfde manier gebruiken pijplijnen voor bovenliggende omgevingen snyk om toepassingsartefacten toe te staan of te verbieden om de uiteindelijke productiestadium te betreden.

Implementatie van GitHub Actions CI/CD Workflow

In deze stap leer je hoe je een voorbeeld CI/CD-pijplijn kunt maken en testen met geïntegreerde kwetsbaarheidsscanning via GitHub-workflows. Voor de basisprincipes van het gebruik van Github Actions met DigitalOcean Kubernetes, raadpleeg deze handleiding.

De pijplijn die in de volgende sectie wordt geleverd, bouwt en implementeert de game-2048-voorbeeld toepassing uit de DigitalOcean kubernetes-sample-apps repository.

Op een hoog overzichtsniveau bestaat de game-2048 CI/CD-workflow die wordt geleverd in de kubernetes-sample-apps repo uit de volgende stappen:

1. Toepassingsbouw- en testfase – bouwt hoofdapplicatieartefacten en voert geautomatiseerde tests uit.
2. Snyk toepassingsafbeeldingsscaneerfase – scant toepassingsdockerafbeelding op bekende kwetsbaarheden. Het fungeert als een poort, en de uiteindelijke pijplijnstatus (geslaagd/mislukt) is afhankelijk van deze stap. In geval van falen wordt een Slack-melding verzonden.
3. Toepassingsafbeeldingsbouw- en pushfase – bouwt en tagt de toepassingsafbeelding met de laatste git-commit SHA. Vervolgens wordt de afbeelding naar DOCR gepusht.
4. Snyk-infrastructuur als code (IAC) scanfase – scant op bekende kwetsbaarheden in de Kubernetes YAML-manifesten die zijn gekoppeld aan de toepassing. Fungeert als een poort, en de uiteindelijke pijplijnstatus (geslaagd/mislukt) is afhankelijk van deze stap. In geval van een storing wordt ook een Slack-melding verzonden.
5. Toepassingsimplementatiefase – implementeert de toepassing naar Kubernetes (DOKS).

Het onderstaande diagram illustreert elke taak van de pijplijn en de bijbehorende stappen met acties (alleen relevante configuratie wordt getoond):

Hoe laat je de pijplijn falen als een bepaald beveiligingsniveau niet wordt gehaald?

Snyk CLI biedt een vlag genaamd --severity-threshold voor dit doel. Deze vlag correleert met het algehele ernstniveau dat na elke scan wordt berekend. In het geval van Snyk neemt het ernstniveau een van de volgende waarden aan: laag, gemiddeld, hoog of kritiek. U kunt de pijplijn laten mislukken of slagen op basis van de ernstniveauwaarde en de toepassingsimplementatie stoppen als niet aan de voorwaarden wordt voldaan.

De onderstaande afbeelding illustreert de flow voor de voorbeeld CI/CD-pijplijn die in deze handleiding wordt gebruikt:

Volg de onderstaande stappen om de snyk CI/CD GitHub-workflow te maken en te testen die wordt geleverd in het kubernetes-sample-apps GitHub-opslagplaats:

1. Vork de kubernetes-sample-apps GitHub-opslagplaats.
2. Maak de volgende GitHub versleutelde geheimen aan voor je kubernetes-voorbeeld-apps kopie (Instellingen Tabblad -> Geheimen -> Acties):
   • DIGITALOCEAN_ACCESS_TOKEN – bevat jouw DigitalOcean account token.
   • DOCKER_REGISTRY – bevat de naam van jouw DigitalOcean Docker registry inclusief de eindpunt (bijv. registry.digitalocean.com/sample-apps).
   • DOKS_CLUSTER – bevat de naam van jouw DOKS cluster. Je kunt het volgende commando uitvoeren om de naam van jouw DOKS cluster te krijgen: doctl k8s cluster list --no-header --format Name.
   • SNYK_TOKEN – bevat jouw Snyk gebruikersaccount ID – voer uit: snyk config get api om de ID te krijgen. Als dat niet werkt, kun je de token ophalen van je gebruikersaccountinstellingen pagina.
   • SLACK_WEBHOOK_URL – bevat jouw Slack inkomende webhook URL gebruikt voor snyk scan meldingen.
3. Navigeer naar het Acties tabblad van uw geforkte repo en selecteer de Game 2048 Snyk CI/CD Voorbeeld workflow:
   
4. Klik op de Workflow uitvoeren knop en laat de standaardwaarden staan:
   

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:

De pipeline zal mislukken en stoppen wanneer de snyk-container-beveiligingscontrole taak wordt uitgevoerd. Dit is te verwachten omdat de standaardwaarde voor de ernstniveau die wordt gebruikt in de workflow invoer, medium, niet aan de verwachtingen voldoet. U zou ook een Slack-melding moeten ontvangen met details over de uitgevoerde workflow:

In de volgende stappen leert u hoe u het snyk scanrapport kunt onderzoeken om de problemen op te lossen, het ernstniveau te verlagen en de pipeline te laten slagen.

Stap 4 – Onderzoeken van Snyk Scan Resultaten en Oplossen van Gerapporteerde Problemen

Wanneer de drempel voor het ernstigheidsniveau niet wordt gehaald, zal de game-2048 GitHub-workflow mislukken en wordt er een Slack-melding verzonden met aanvullende details. Je krijgt ook beveiligingsrapporten gepubliceerd op GitHub en toegankelijk in het Beveiliging-tabblad van je projectrepository.

De game-2048 workflow voert twee beveiligingscontroles uit:

1. Controle van containerbeeldbeveiliging – de snyk-container-beveiligingscontrole taak wordt hiervoor gebruikt. Het equivalente snyk-commando dat wordt gebruikt is – snyk container test <GAME-2048-IMAGE>:<TAG> --file=/pad/naar/game-2048/Dockerfile.
2. Controle van Kubernetes-manifesten op misconfiguratie – de snyk-iac-beveiligingscontrole taak wordt hiervoor gebruikt. Het equivalente snyk-commando dat wordt gebruikt is – snyk iac test /pad/naar/project/kubernetes/manifesten.

Hierdoor wordt het verlagen van het ernstigheidsniveau en het doorgeven van de workflow bereikt door:

1. Problemen onderzoeken en oplossen die worden gerapporteerd door de snyk-container-beveiligingscontrole taak.
2. Problemen onderzoeken en oplossen die worden gerapporteerd door de snyk-iac-beveiligingscontrole taak.

Daarna leer je hoe je elk van hen aanpakt.

Het onderzoeken en verhelpen van kwetsbaarheden in containerimages

De voorbeeld-pijplijn die in deze handleiding wordt gebruikt, voert beveiligingscontroles uit voor het game-2048 containerimage en het bijbehorende Dockerfile via de snyk-container-security-check-taak.

De snyk-container-security-check-taak voert de volgende stappen uit:

1. Bouwt lokaal de Docker-image van de game-2048 applicatie. Deze stap wordt geïmplementeerd met behulp van de docker-build-push GitHub-actie.
2. Voert Snyk-beveiligingscontroles uit voor het applicatiecontainerimage en Dockerfile. Deze stap wordt geïmplementeerd met de snyk container test-opdracht. Scanresultaten worden geëxporteerd naar het GitHub SARIF-formaat. De beveiligingsniveautreshold wordt gecontroleerd via het –severity-threshold-argument – het wordt ingesteld op de snyk_fail_threshold-invoerparameter als de workflow handmatig wordt gestart, of op de SNYK_FAIL_THRESHOLD-omgevingsvariabele, als de workflow automatisch wordt uitgevoerd.
3. De scanresultaten (SARIF-indeling) worden gepubliceerd in het beveiligingsgedeelte van uw applicatierepository. Deze stap is geïmplementeerd met de GitHub-actie codeql.

Hieronder staat een fragment van de hoofdlogica van de taak 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 }} \

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

Om de gerapporteerde problemen op te lossen, moet u eerst het beveiligingsgedeelte van uw vork van de kubernetes-sample-apps-repository controleren:

FROM node:18.6.0-slim AS builder
WORKDIR /usr/src/app
COPY . .
RUN npm install --include=dev
 U ziet dan een aantal kwetsbaarheden voor het basis-Docker-image in dit geval. Klik op elk om uit te vouwen en meer details te zien: 
 Om het onderzoek af te ronden en aanbevelingen van Snyk te zien, moet u de uitvoer van de taak snyk-container-security-check van de hoofdworkflow inspecteren: 
 Opmerking: Snyk container test biedt de mogelijkheid om resultaten in SARIF-indeling te exporteren, maar weet niet hoe rapporten naar het Snyk-cloudportaal moeten worden geüpload. Aan de andere kant biedt snyk container monitor de mogelijkheid om resultaten naar het Snyk-cloudportaal te uploaden, maar het kan geen SARIF exporteren. Daarom gebruikt deze handleiding snyk container test met de mogelijkheid tot SARIF-export. Sommige aanbevelingen zijn helaas niet beschikbaar in de SARIF-uitvoer. Daarom moet u ook in de uitvoer van de taakconsole kijken voor aanbevelingen.
De snyk-container-security-check taakuitvoer toont aan dat Snyk aanbeveelt om de versie van de basisimage bij te werken van node:16-slim naar node:18.6.0-slim. Deze wijziging elimineert het hoog risico op issue(s) en verlaagt ook het aantal andere gerapporteerde kwetsbaarheden van 70 naar 44 - dit is een aanzienlijke vermindering van bijna 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"]

Open nu het Dockerfile van de game-2048 applicatie van je fork en wijzig de FROM directives zodat deze verwijzen naar de nieuwe versie (node:18.6.0-slim op dit moment van schrijven):

#

# Bouwmodus kan worden ingesteld via de NODE_ENV omgevingsvariabele (development of production)

# Zie project package.json en webpack.config.js

#

Tenslotte, commit de wijzigingen naar je GitHub repository en activeer de workflow opnieuw (laat de standaardwaarden staan). Deze keer zou de snyk-container-security-check taak moeten slagen:

Als je naar het beveiligingstabblad van je project gaat, zouden er geen problemen gerapporteerd moeten worden.

Hoe zorg je ervoor dat je in de toekomst het aantal kwetsbaarheden in de basisimage vermindert?

1. De beste aanpak is om een basisafbeelding te gebruiken met een minimale footprint – hoe minder binaries of afhankelijkheden in de basisafbeelding, hoe beter. Een andere goede praktijk is om uw projecten voortdurend te monitoren, zoals uitgelegd in de sectie Monitor uw Projecten op Regelmatige Basis van deze handleiding.
2. Je zult merken dat de pipeline nog steeds mislukt, maar deze keer in de fase snyk-iac-security-check. Dit is te verwachten omdat er beveiligingsproblemen zijn met de Kubernetes-manifests die worden gebruikt om de toepassing te implementeren. In de volgende sectie leer je hoe je deze situatie kunt onderzoeken en de aanbevelingen van Snyk kunt toepassen om de gerapporteerde problemen op te lossen.

Het Onderzoeken en Oplossen van Kwetsbaarheden in Kubernetes-manifests

- 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

De pipeline faalt nog steeds en stopt bij de job snyk-iac-security-check. Dit is te verwachten omdat de standaardwaarde voor de ernst van het niveau die wordt gebruikt in de invoer van de workflow, medium, niet voldoet aan de beveiligingseisen voor het project.

1. De job snyk-iac-security-check controleert op kwetsbaarheden (of verkeerde configuraties) in Kubernetes-manifests en voert de volgende stappen uit:
2. Snyk-beveiligingscontroles voor Kubernetes-manifesten vanuit de projectdirectory game-2048-example. Deze stap wordt geïmplementeerd met behulp van de snyk iac test opdracht. Scanresultaten worden geëxporteerd met behulp van het GitHub SARIF formaat. Het beveiligingsniveau wordt gecontroleerd via het argument –severity-threshold – het is ingesteld op de invoerparameter snyk_fail_threshold als de workflow handmatig wordt gestart, of op de omgevingsvariabele SNYK_FAIL_THRESHOLD, als de workflow automatisch wordt uitgevoerd. Ten slotte wordt het argument –report ook gebruikt om scanresultaten naar het Snyk-cloudportaal te sturen.

Scanresultaten (SARIF-formaat) worden gepubliceerd op het tabblad Beveiliging van uw toepassingsrepository. Deze stap wordt geïmplementeerd met behulp van de codeql GitHub-actie.

Hieronder wordt de daadwerkelijke implementatie van elke stap uit de snyk-iac-security-check taak weergegeven:

–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

Om de gerapporteerde problemen op te lossen, hebt u twee opties:

• Gebruik het Snyk-cloudportaal en open het game-2048 project om details te controleren:
  
• Gebruik het beveiligingstabblad van de repository van je game-2048-app om details te controleren:
  
• Hoe dan ook, je krijgt aanbevelingen over hoe je de gerapporteerde problemen kunt oplossen.
• Voor deze handleiding gebruik je het Snyk-cloudportaal om de gerapporteerde beveiligingsproblemen te onderzoeken. Klik eerst op de game-2048-voorbeeld-vermelding in de projectenlijst en selecteer vervolgens het kustomize/resources/deployment.yaml-bestand:

Vink vervolgens het Gemiddeld-selectievakje aan in het Ernst-submenu aan de linkerkant om alleen problemen van gemiddeld niveau weer te geven:

Vervolgens kun je elke gerapporteerde probleemkaart inspecteren en de details controleren. Klik op de knop Meer details weergeven van de kaart Container wordt uitgevoerd zonder controle over de rootgebruiker – je ontvangt meer details over het huidige probleem en belangrijke aanwijzingen over hoe je het kunt oplossen:

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

1. Na het verzamelen van alle informatie van elke kaart, kun je doorgaan en het deployment.yaml-bestand bewerken vanuit je repo (te vinden in de game-2048-voorbeeld/kustomize/resources-submap). De fixes zijn al aangebracht, je hoeft alleen de laatste regels uit het bestand uit te commentariëren. Het uiteindelijke deployment.yaml-bestand zou er als volgt uit moeten zien:
2. readOnlyRootFilesystem – voert containerbeeld uit in alleen-lezen modus (kan bestanden niet wijzigen via kubectl exec in de container).

allowPrivilegeEscalation – het instellen van allowPrivilegeEscalation op false zorgt ervoor dat geen enkel kindproces van een container meer privileges kan verkrijgen dan zijn ouder.

capabilities.drop – Om containers veiliger te maken, moet u containers voorzien van de minste hoeveelheid privileges die nodig is om te draaien. In de praktijk laat u standaard alles vallen en voegt u stap voor stap benodigde mogelijkheden toe. U kunt meer leren over containermogelijkheden hier.

Tenslotte, commit de wijzigingen voor het deployment.yaml bestand en push naar de hoofdtak. Na het handmatig triggeren van de workflow moet deze deze keer succesvol worden voltooid:

U moet ook een groene Slack-melding ontvangen van de snyk-scanjob. Ga naar de Snyk-portallink en controleer of de problemen die u onlangs heeft opgelost verdwenen zijn – er mogen geen mediumniveau problemen worden gemeld.

Controleer of de game-2048-implementatie een alleen-lezen (onveranderlijk) bestandssysteem heeft door te schrijven naar het index.html-bestand dat door de game-2048-toepassing wordt gebruikt:

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

Het uitvoer ziet er vergelijkbaar uit:

Uitvoer
/bin/bash: /public/index.html: Alleen-lezen bestand systeem
commando beëindigd met exit code 1

Controleer of de game-2048-implementatie een alleen-lezen (onveranderlijk) bestandssysteem heeft door te schrijven naar het index.html-bestand dat door de game-2048-toepassing wordt gebruikt:

Het uitvoer ziet er vergelijkbaar uit:

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 }}
      
      ...

Controleer of de container wordt uitgevoerd als een niet-rootgebruiker (moet een ander geheel getal dan nul afdrukken – bijv. 1000):

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

Controleer of de container wordt uitgevoerd als een niet-rootgebruiker (moet een ander geheel getal dan nul afdrukken – bijv. 1000):

Als alle controles slagen, dan heeft u de vereiste beveiligingsaanbevelingen succesvol toegepast.

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 }}

Monitor uw projecten regelmatig

De kwetsbaarheidsscanautomatisering die u tot nu toe heeft geïmplementeerd, is een goed startpunt maar niet perfect. Waarom?

Een probleem met de huidige aanpak is dat u nooit weet wanneer er nieuwe problemen worden gemeld voor de assets die u al hebt geïmplementeerd in uw omgevingen. Met andere woorden, u heeft de beveiligingsrisico’s beoordeeld en maatregelen genomen om de problemen op een specifiek moment in de tijd op te lossen – wanneer uw CI/CD-automatisering werd uitgevoerd.

Maar wat als er intussen nieuwe problemen worden gemeld, en uw applicatie opnieuw kwetsbaar is? Snyk helpt u deze situatie te overwinnen via de monitoring-functie. De monitoringfunctie van Snyk helpt u nieuwe kwetsbaarheden aan te pakken, die voortdurend worden gemeld. In combinatie met de Snyk Slack-integratie (uitgelegd in Stap 6 – Slack-meldingen inschakelen), kunt u onmiddellijke acties ondernemen om nieuw gemelde problemen op te lossen die van invloed kunnen zijn op uw applicatie in een productieomgeving.

Om van deze functie te profiteren, hoeft u alleen het snyk monitor-commando te gebruiken vóór eventuele implementatiestappen in uw CI/CD-pijplijn. De syntaxis is zeer vergelijkbaar met de snyk test-opdrachten (een van de coole dingen aan de snyk CLI is dat deze is ontworpen met uniformiteit in gedachten). Het snyk monitor-commando stuurt een momentopname naar het Snyk-cloudportaal, en van daaruit wordt u op de hoogte gebracht van nieuw gemelde kwetsbaarheden voor uw project.

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.

Wat betreft de automatisering van de GitHub-workflow, kunt u uw applicatiecontainer monitoren in de snyk-container-security-check-taak, na het testen op kwetsbaarheden. Het onderstaande fragment toont een praktische implementatie voor de pijplijn die in deze handleiding wordt gebruikt (sommige stappen zijn weggelaten voor duidelijkheid):

1. –bestand=${{ env.PROJECT_DIR }}/Dockerfile \
2. –ernst-drempel=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
3. –doel-naam=${{ env.PROJECT_NAME }} \
4. –doel-referentie=${{ env.ENVIRONMENT }} \

–sarif-bestand-uitvoer=snyk-container-scan.sarif

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

Hierboven zie je een extra stap genaamd Monitor de toepassingscontainer met behulp van Snyk waar de werkelijke Snyk-containermonitor wordt uitgevoerd.

Na het uitvoeren van de Snyk monitor opdracht, kun je inloggen op de Snyk Web UI om de laatste momentopname en geschiedenis van je project te zien:

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

Je kunt ook je toepassingsbroncode testen en monitoren in de bouw-en-test-toepassing taak. Hieronder zie je een voorbeeldimplementatie voor de GitHub-workflow die in deze handleiding wordt gebruikt:

Vervolgens ontvang je regelmatig Slack-meldingen over nieuw bekendgemaakte kwetsbaarheden voor je project.

Uitzonderingen behandelen

Er zijn situaties waarin je niet wilt dat het eindrapport wordt beïnvloed door bepaalde problemen die je team als veilig beschouwt om te negeren. Snyk biedt een ingebouwde functie om uitzonderingen te beheren en deze situatie te overwinnen.

Je kunt meer lezen over deze functie hier.

Snyk voor IDE’s

Snyk biedt ondersteuning voor verschillende IDE’s, zoals:

Eclipse-plug-in.

JetBrains-plug-in.

• Visual Studio-extensie.
• Visual Studio Code-extensie.
• De bovenstaande plugins helpen je bij het detecteren en oplossen van problemen in de vroege stadia van ontwikkeling, waardoor frustratie, kosten en beveiligingsfouten in productiesystemen worden geëlimineerd. Ook helpt het je om de iteraties en menselijke inspanningen op de lange termijn te verminderen. Als voorbeeld, voor elk gemeld beveiligingsprobleem door je CI/CD-automatisering moet je teruggaan en het probleem in je code oplossen, wijzigingen committen, wachten op de CI/CD-automatisering opnieuw, en dan herhalen in geval van fouten.
• Vanuit de officiële documentatie kun je meer lezen over deze functies op de Snyk voor IDE’s pagina.
• Stap 5 – Het Snyk CI/CD-workflow automatisch activeren
• Je kunt de workflow instellen om automatisch te worden geactiveerd bij elke commit of PR tegen de hoofdbranch door de volgende regels bovenaan het bestand game-2048-snyk.yaml uit te commentariëren:
• Na het bewerken van het bestand, commit de wijzigingen naar je hoofdbranch en je zou klaar moeten zijn om te gaan.
• Stap 6 – Slack-meldingen inschakelen
• Je kunt Snyk instellen om Slack-meldingen te versturen over nieuwe kwetsbaarheden die zijn ontdekt in je projecten en over nieuwe upgrades of patches die beschikbaar zijn gekomen.
• Om dit in te stellen, moet je een Slack webhook genereren. Dit kun je doen via Incoming WebHooks of door je eigen Slack App te maken. Zodra je je Slack Webhook URL hebt gegenereerd, ga je naar je ‘Organisatie beheren’ instellingen, voer je de URL in en klik je op de Verbinden knop: