Docker Scout: hoe je container-images scant op kwetsbaarheden
Docker Scout analyseert container-images op kwetsbaarheden en genereert Software Bills of Materials. Het geeft je ingebouwd security-inzicht voor Docker-gebaseerde ontwikkelworkflows — geen aparte tools of complexe setup nodig.
Het verhaal gaat ongeveer zo: je hebt je Docker-image gebouwd, getagd en gedeployed. Alles lijkt prima tot je securityteam kwetsbaarheden markeert in een pakket waarvan je niet eens wist dat het erin zat. Of nog erger: compliance vraagt om een Software Bill of Materials (SBOM) en jij vraagt je af hoe je ontdekt welke afhankelijkheden met je images meekomen. Container-images kunnen black boxes zijn, en dat is een probleem als jij verantwoordelijk bent voor wat er in productie draait.
Docker Scout geeft je inzicht in je container-images door ze te scannen op kwetsbaarheden en automatisch SBOM’s te genereren. Het zit ingebouwd in Docker, dus je hoeft geen aparte tool te installeren of te leren.
In deze gids laat ik je zien hoe je images met Docker Scout scant en hoe je de gegenereerde kwetsbaarheidsrapporten begrijpt, zodat je weet wanneer het zinvol is om het te gebruiken.
Als je nieuw bent met Docker, bekijk dan ons artikel over de Top 18 Docker Commands. Deze zetten je op het juiste spoor om containers te bouwen, te draaien en te beheren.
Wat is Docker Scout?
Docker Scout is Docker’s eigen image-analysetool die je container-images scant op kwetsbaarheden en Software Bills of Materials (SBOM’s) genereert.
Het analyseert alles in je image: van basis-OS-pakketten, taalspecifieke afhankelijkheden tot applicatielibraries. Daarna kruist het die met bekende kwetsbaarheidsdatabases. Je krijgt een rapport dat laat zien welke pakketten beveiligingsproblemen hebben, hoe ernstig ze zijn en welke versies ze verhelpen.
In plaats van third-party scanners te gebruiken of te wachten tot securityteams na deployment problemen signaleren, kun je images scannen waar je ze bouwt. Scout draait in Docker Desktop, via de CLI en integreert met Docker Hub.
Zo past het in het Docker-ecosysteem: Docker bouwt en draait je containers, Docker Hub slaat ze op en Docker Scout vertelt je wat erin zit. Het is goed om te onthouden dat het nu onderdeel is van het platform, geen losse add-on.
Docker Scout vervangt het oudere docker scan-commando, dat op Snyk’s scanning engine vertrouwde. Scout gebruikt Docker’s eigen kwetsbaarheidsdatabase en geeft je meer controle over het scanproces. Als je nog docker scan gebruikt: het is verouderd — Scout is de officiële vervanger en is al beschikbaar in recente Docker Desktop-versies.
Docker Scout installeren en inschakelen
Docker Scout zit ingebouwd in Docker Desktop 4.17 en hoger, dus als je een recente versie draait, heb je het al.
Het werkt via de Docker CLI en verschijnt in de GUI van Docker Desktop. Gebruik je Docker Desktop, dan staat Scout standaard aan — je kunt meteen images scannen.
Om te controleren of Scout beschikbaar is op je systeem, voer je dit commando uit:
Je ziet output met de Scout CLI-versie en pluginstatus.
Docker scout version
Als het commando werkt, ben je klaar om images te scannen.
Krijg je een "command not found"-fout, dan is je Docker-versie te oud. Update Docker Desktop naar de nieuwste versie om toegang te krijgen tot Docker Scout.
Een image scannen met Docker Scout
De scan draaien kost één commando, en dat is het makkelijke deel. Wat soms uitdagend is, is begrijpen wat Scout vindt.
Een image analyseren
Je kunt dit commando draaien om een lokale image te scannen door de naam of ID aan Docker Scout door te geven:
Scout analyseert de imagelagen, haalt pakketinfo op en controleert op bekende kwetsbaarheden. De scan is binnen 30 seconden klaar voor de meeste images.
Scan results for Python 3.14 image
Je kunt ook images scannen die nog niet op je machine staan:
Scout haalt metadata uit de registry zonder de volledige image te downloaden. Zo kun je images controleren vóór je ze lokaal binnenhaalt.
Scan results for Postgres 18.1 image
Tijdens de analyse pakt Scout elke laag uit, identificeert geïnstalleerde pakketten en afhankelijkheden en kruist alles met zijn kwetsbaarheidsdatabase. Het volgt pakketten uit het basis-OS (zoals apt-pakketten in Ubuntu-gebaseerde images) en taalspecifieke afhankelijkheden (zoals Python-pakketten of Node-modules).
De output begrijpen
Scout groepeert kwetsbaarheden op ernst: Critical, High, Medium en Low.
Critical en High verdienen als eerste aandacht. Dit zijn actief misbruikte issues of ernstige bugs die je systeem kunnen compromitteren. Medium is belangrijk maar zelden direct. Low is het volgen waard, maar blokkeert doorgaans geen deployments.
Elke kwetsbaarheid laat zien in welk pakket het probleem zit. Als je door het rapport scrolt, zie je ongeveer dit:
Vulnerability report
Dit vertelt je precies wat kwetsbaar is (openssl), welke versie je draait en welke versie het oplost. Scout linkt ook naar de CVE-details zodat je zelf over de kwetsbaarheid kunt lezen.
De toeschrijving van pakketten laat zien waar kwetsbaarheden vandaan komen — base image-pakketten, applicatieafhankelijkheden of systeemlibraries. Dit helpt je beslissen of je de base image moet updaten, een afhankelijkheid in je code moet upgraden of op een upstream fix moet wachten.
Docker Scout gebruiken om SBOM’s te genereren en te bekijken
Een Software Bill of Materials (SBOM) is een complete inventaris van alles in je container-image — elk pakket, elke library en afhankelijkheid.
Het vertelt je precies wat er in je image zit, tot op specifieke versieniveaus. Securityteams gebruiken SBOM’s om te volgen wat er in productie draait, en compliancekaders vereisen ze vaak.
Docker Scout genereert SBOM’s automatisch wanneer je een image scant met de commando’s die ik in de vorige sectie liet zien. Nog even ter herhaling:
Dit geeft de volledige pakketlijst op je terminal. Scout analyseert de imagelagen en extraheert pakketmetadata, en formatteert dat vervolgens als een SBOM die je kunt opslaan of delen.
Je kunt de SBOM exporteren naar een bestand in plaats van ’m op het scherm te printen:
docker scout sbom postgres:18.1 --format spdx > postgres-sbom.jsonMogelijk gemaakt door
SBOM SPDX report
Scout ondersteunt twee standaard SBOM-formaten: SPDX (Software Package Data Exchange) en CycloneDX. Beide zijn breed gebruikte industriestandaarden. SPDX werkt goed voor compliance en juridische reviews, terwijl CycloneDX zich richt op security-use-cases en het volgen van kwetsbaarheden.
Je wisselt van formaat met de --format-vlag:
docker scout sbom postgres:18.1 --format cyclonedx > postgres-sbom.jsonMogelijk gemaakt door
SBOX CycloneDX report
Zodra je een SBOM-bestand hebt, kun je het delen met securityteams, invoeren in andere scantools of archiveren voor compliance-audits.
CVE’s vinden en begrijpen met Docker Scout
Docker Scout vindt kwetsbaarheden door pakketten in je image te matchen met een database van bekende beveiligingsissues.
Wanneer je docker scout cves draait, haalt Scout elk pakket uit je image — OS-pakketten, taallibraries, applicatieafhankelijkheden — en controleert elk tegen Common Vulnerabilities and Exposures (CVE)-records. Een CVE is een openbaar gemaakte beveiligingsfout met een uniek ID zoals CVE-2024-1234.
Scout haalt CVE-data uit meerdere bronnen:
De National Vulnerability Database (NVD)
Beveiligingsadviezen van Linux-distributies
Taalspecifieke securitydatabases voor Python, Node.js, Go en andere ecosystemen
Dit betekent dat Scout kwetsbaarheden kan vinden in zowel de OS-pakketten van je base image als in de afhankelijkheden van je applicatie.
Dat gezegd hebbende, is het belangrijk te onthouden dat de analyse anders werkt afhankelijk van waar je image staat.
Voor lokale images (die je hebt gebouwd of lokaal hebt gepulld) leest Scout de imagelagen direct uit je Docker-daemon. Het pakt elke laag uit, identificeert pakketten en draait de kwetsbaarheidscheck lokaal. Dit is snel en vereist geen netwerktoegang tot de image zelf.
Voor remote images op Docker Hub of andere registries haalt Scout de imagemanifest en laagmetadata op zonder de volledige image te downloaden. Zo kun je images scannen voordat je ze binnenhaalt. De kwetsbaarheidsdata komt nog steeds uit Scouts database, maar de image-analyse gebeurt op basis van registry-metadata.
Beide methoden geven je dezelfde kwetsbaarheidsinformatie. Het enige verschil is waar Scout de imagedata vandaan leest.
Richtlijnen voor herstel en aanbevelingen voor base images
Wanneer Scout een kwetsbaarheid vindt waarvoor een patch beschikbaar is, toont het exact welke versie het probleem oplost. Je ziet bijvoorbeeld "Fixed in: 1.2.3" naast elke CVE. Dit laat je weten of je een pakket moet updaten, je image met een nieuwere basis moet herbouwen of op een upstream fix moet wachten.
Scout raadt ook upgrades van base images aan wanneer overstappen op een nieuwere basis kwetsbaarheden wegneemt. Als je python:3.13 gebruikt en Scout vindt issues in de basis-OS-pakketten, dan kan het voorstellen om te upgraden naar python:3.14 of zelfs een specifiekere patchversie.
Deze aanbevelingen verschijnen wanneer Scout detecteert dat een andere base image-tag minder kwetsbaarheden heeft dan je huidige. De suggesties zijn uitvoerbaar — je kunt de nieuwe tag letterlijk in je Dockerfile plakken en herbouwen.
Waarom is dit belangrijk?
Je base image bevat de OS-pakketten, systeemlibraries en taalruntimes waar alles van afhangt. Een kwetsbare base image betekent dat elke container die je ervan bouwt die kwetsbaarheden erft. Kies je een minimale en actief onderhouden base image, dan verklein je het aanvalsoppervlak.
Officiële images op Docker Hub krijgen regelmatig securityupdates, maar je moet je images wel herbouwen om die fixes mee te nemen. Zo geeft het vandaag pullen van python:3.13 je andere pakketten dan zes maanden geleden.
Docker Scout gebruiken in CI/CD
Teams integreren Docker Scout in CI-pipelines om kwetsbaarheden te pakken vóór images productie bereiken.
Het idee is simpel: scan elke image als onderdeel van je buildproces en laat de build falen als er kritieke kwetsbaarheden opduiken. Je vindt problemen tijdens ontwikkeling in plaats van erna. De meeste teams stellen Scout zo in dat het automatisch draait wanneer iemand een nieuwe Dockerfile pusht of een base image bijwerkt.
Pipelines controleren meestal twee dingen:
Vulnerability regressions — Deze vergelijken je nieuwe image met de vorige versie. Als de nieuwe build meer Critical of High kwetsbaarheden introduceert dan de vorige, faalt de pipeline. Zo voorkom je dat je per ongeluk slechtere security uitrolt dan wat al draait
Policy drift — Deze verifiëren dat je image aan securitystandaarden voldoet. Je kunt bijvoorbeeld een policy hebben die zegt: "geen Critical CVE’s toegestaan" of "base images mogen niet ouder zijn dan 30 dagen". Scout kan deze regels automatisch afdwingen in je CI-workflow
Integratie met GitHub Actions, GitLab CI of Jenkins werkt conceptueel hetzelfde. Je bouwt je image, draait docker scout cves erop, leest de resultaten uit en beslist of de pipeline slaagt of faalt op basis van je criteria. Sommige teams integreren Scout liever in hun container registry-workflows om images direct na het pushen te scannen.
Docker Scout vs. andere imagescanners
Docker Scout is niet de enige tool. Het concurreert met tools zoals Trivy en Snyk, maar elk richt zich op andere workflows.
Trivy is een open-sourcescanner die overal draait: lokale machines, CI-pipelines en Kubernetes-clusters. Het scant container-images, filesystems en Git-repositories. Trivy geeft je meer flexibiliteit in waar en hoe je scant, en je hebt geen Docker-account nodig. Zie het als een zelfstandige scanner die onafhankelijk van Docker’s ecosysteem werkt.
Snyk richt zich op developerworkflows en integreert diep met IDE’s, GitHub en andere ontwikkeltools. Naast containers scant het applicatieafhankelijkheden, infrastructure as code en broncode. Snyk geeft ook gedetailleerde hersteladviezen en kan pull requests openen om kwetsbaarheden te fixen. Heb je beveiligingsdekking nodig over je hele stack, niet alleen containers, dan is Snyk een logische keuze.
Docker Scout werkt het best als je al Docker Desktop en Docker Hub gebruikt. De integratie is native, er is geen extra setup, geen API-keys om te beheren en geen aparte tools om te leren. Scout scant images die naar Docker Hub zijn gepusht en de CLI maakt deel uit van je Docker-installatie.
Kies Docker Scout als je team containers bouwt en draait met Docker-tools en je security-inzicht wilt zonder extra complexiteit. Kies Trivy als je een flexibel, open-source alternatief wilt dat overal werkt. Kies Snyk als je complete security wilt over containers, code en infrastructuur met geautomatiseerde fixes.
Veelvoorkomende beperkingen en aandachtspunten
Docker Scout scant container-images, maar monitort niet wat er gebeurt nadat je ze deployed hebt.
Het analyseert statische images — de pakketten en bestanden die in je container zijn ingebouwd. Het detecteert geen runtime-issues zoals privilege-escalatie, netwerkindringing of kwaadaardige processen die na deployment starten. Heb je runtime security monitoring nodig, gebruik dan tools zoals Falco of Sysdig die containergedrag in productie observeren.
Scout is ook geen vervanging voor volledige SAST (Static Application Security Testing) of DAST (Dynamic Application Security Testing). SAST-tools analyseren je broncode op securityfouten vóór je iets bouwt. DAST-tools testen draaiende applicaties door aanvallen te simuleren. Scout kijkt alleen naar de pakketten in je gebouwde image — het vindt geen kwetsbaarheden in je applicatielogica of configuratiefouten in je code.
Waar Scout wél in uitblinkt, is inzicht geven in wat er in je images zit en je richting fixes sturen. Het vertelt je welke pakketten kwetsbaar zijn, welke versies ze oplossen en welke base images het aanvalsoppervlak verkleinen. Dat maakt Scout nuttig voor securitychecks tijdens het builden en voor compliance-tracking, maar je hebt andere tools nodig om het volledige securityspectrum te dekken.
Best practices voor het gebruik van Docker Scout
Hier is een checklist om het meeste uit Docker Scout te halen.
Scan vroeg in je ontwikkelcyclus. Draai Scout op images tijdens lokale ontwikkeling, niet alleen in CI of vlak voor deployment. Kwetsbaarheden vroeg vinden betekent dat je ze fixt terwijl de context vers is en wijzigingen goedkoop zijn. Wachten tot productie betekent onder druk moeten patchen.
Vergelijk images in de tijd om securitytrends te volgen. Scout kan laten zien of je security verbetert of verslechtert. Draai scans op elke build en vergelijk de resultaten. Als je nieuwe build meer kritieke kwetsbaarheden introduceert dan de vorige, is er iets veranderd — misschien een dependency-update of een base image-wissel. Dat moet je uitzoeken.
Zie Scouts bevindingen als prioriteringssignalen, niet als absolute blockers. Niet elke kwetsbaarheid vraagt directe actie. Een low severity CVE in een development dependency die je niet in productie gebruikt kan wachten. Een kritieke CVE in een publiek blootgestelde service vraagt meteen aandacht. Gebruik Scouts ernstscores en pakketcontext om te beslissen wat voor jouw deployment telt.
Combineer Scout met hygiëne rond base images. Kies minimale, actief onderhouden base images en update ze regelmatig. python:3.14-slim in plaats van python:3.14 snijdt pakketten weg die je niet nodig hebt. Je images maandelijks herbouwen pikt securitypatches in de basislaag op. Scout kan je vertellen wat kwetsbaar is, maar goede bases kiezen voorkomt dat veel kwetsbaarheden überhaupt opduiken.
Conclusie
Docker Scout geeft je een praktische manier om te begrijpen wat er in je container-images zit.
Het past in Docker-gebaseerde ontwikkeling — geen aparte tools om te installeren, geen accounts om in te richten buiten wat je al gebruikt. Je draait een commando, krijgt kwetsbaarheidsrapporten en ziet welke pakketten updates nodig hebben.
Scout werkt het best als onderdeel van een bredere securityaanpak, niet als je enige optie. Combineer het met runtime-monitoring, broncode-analyse en regelmatige updates van base images. Gebruik het om kwetsbaarheden tijdens builds te vangen en voeg andere tools toe om te dekken wat er na deployment gebeurt.
Als je je afvraagt hoe Docker past in CI/CD-pipelines voor machine learning, schrijf je dan in voor onze CI/CD for Machine Learning-cursus. Je hebt alle antwoorden binnen één middag.
Senior Data Scientist, gevestigd in Kroatië. Top Tech-schrijver met meer dan 700 gepubliceerde artikelen en meer dan 10 miljoen weergaven. Auteur van het boek Machine Learning Automation with TPOT.
Docker Scout FAQs
Hoe helpt Docker Scout bij het automatiseren van kwetsbaarheidsscans in CI/CD-pipelines?⌄
Docker Scout integreert in CI/CD-pipelines door automatisch scans uit te voeren wanneer je een nieuwe image bouwt. Je kunt je pipeline zo configureren dat builds falen die Critical of High kwetsbaarheden introduceren, waardoor onveilige images de productie niet halen. Scout controleert op regressies in kwetsbaarheden en policy-overtredingen, zodat je team beveiligingsissues tijdens het buildproces vangt in plaats van na deployment.
Wat zijn de belangrijkste verschillen tussen Docker Scout en andere containerscantools zoals Trivy of Snyk?⌄
Docker Scout is ingebouwd in Docker en vereist geen aparte installatie, wat het het makkelijkst maakt voor teams die al Docker Desktop en Docker Hub gebruiken. Trivy is een open-sourcescanner die onafhankelijk draait en overal werkt zonder Docker-accounts of integratie. Snyk biedt bredere dekking over containers, broncode en infrastructuur met geautomatiseerde fixsuggesties, maar vereist een apart abonnement en setup.
Hoe integreert Docker Scout met systemen van derden zoals GitHub of JFrog Artifactory?⌄
Docker Scout kan worden aangeroepen vanuit GitHub Actions, GitLab CI of andere pipelinetools met Docker CLI-commando’s. Je draait docker scout cves als onderdeel van je buildworkflow, leest de resultaten uit en beslist of de pipeline slaagt of faalt. Voor registries zoals JFrog Artifactory kun je images scannen nadat ze gepusht zijn door ze remote te refereren, al hangt de integratie af van je specifieke registry-setup en authenticatie.
Kan Docker Scout worden gebruikt om containerbeveiliging in realtime te monitoren?⌄
Nee, Docker Scout scant alleen statische container-images, niet draaiende containers. Het analyseert wat er in je gebouwde images zit vóór of na deployment, maar monitort geen runtimegedrag zoals procesuitvoering, netwerkactiviteit of privilege-escalatie. Voor realtime securitymonitoring heb je tools zoals Falco of Sysdig nodig die containergedrag in productieomgevingen bewaken.
Wat zijn de voordelen van Docker Scout voor het beheren van beveiliging in de softwaresupplychain?⌄
Docker Scout genereert Software Bills of Materials (SBOM’s) die elk pakket en elke afhankelijkheid in je images documenteren, zodat je volledige zicht hebt op je softwaresupplychain. Dit helpt bij compliance-eisen, incidentrespons en het traceren van welke systemen geraakt worden wanneer nieuwe kwetsbaarheden bekend worden. Scout laat ook zien waar kwetsbaarheden vandaan komen — base images, applicatieafhankelijkheden of systeemlibraries — zodat je securityissues aan de bron kunt herleiden en op het juiste niveau kunt oplossen.
Het verhaal gaat ongeveer zo: je hebt je Docker-image gebouwd, getagd en gedeployed. Alles lijkt prima tot je securityteam kwetsbaarheden markeert in een pakket waarvan je niet eens wist dat het erin zat. Of nog erger: compliance vraagt om een Software Bill of Materials (SBOM) en jij vraagt je af hoe je ontdekt welke afhankelijkheden met je images meekomen. Container-images kunnen black boxes zijn, en dat is een probleem als jij verantwoordelijk bent voor wat er in productie draait.
Docker Scout geeft je inzicht in je container-images door ze te scannen op kwetsbaarheden en automatisch SBOM’s te genereren. Het zit ingebouwd in Docker, dus je hoeft geen aparte tool te installeren of te leren.
In deze gids laat ik je zien hoe je images met Docker Scout scant en hoe je de gegenereerde kwetsbaarheidsrapporten begrijpt, zodat je weet wanneer het zinvol is om het te gebruiken.
Als je nieuw bent met Docker, bekijk dan ons artikel over de Top 18 Docker Commands. Deze zetten je op het juiste spoor om containers te bouwen, te draaien en te beheren.
Wat is Docker Scout?
Docker Scout is Docker’s eigen image-analysetool die je container-images scant op kwetsbaarheden en Software Bills of Materials (SBOM’s) genereert.
Het analyseert alles in je image: van basis-OS-pakketten, taalspecifieke afhankelijkheden tot applicatielibraries. Daarna kruist het die met bekende kwetsbaarheidsdatabases. Je krijgt een rapport dat laat zien welke pakketten beveiligingsproblemen hebben, hoe ernstig ze zijn en welke versies ze verhelpen.
In plaats van third-party scanners te gebruiken of te wachten tot securityteams na deployment problemen signaleren, kun je images scannen waar je ze bouwt. Scout draait in Docker Desktop, via de CLI en integreert met Docker Hub.
Zo past het in het Docker-ecosysteem: Docker bouwt en draait je containers, Docker Hub slaat ze op en Docker Scout vertelt je wat erin zit. Het is goed om te onthouden dat het nu onderdeel is van het platform, geen losse add-on.
Docker Scout vervangt het oudere
docker scan-commando, dat op Snyk’s scanning engine vertrouwde. Scout gebruikt Docker’s eigen kwetsbaarheidsdatabase en geeft je meer controle over het scanproces. Als je nogdocker scangebruikt: het is verouderd — Scout is de officiële vervanger en is al beschikbaar in recente Docker Desktop-versies.Docker Scout installeren en inschakelen
Docker Scout zit ingebouwd in Docker Desktop 4.17 en hoger, dus als je een recente versie draait, heb je het al.
Het werkt via de Docker CLI en verschijnt in de GUI van Docker Desktop. Gebruik je Docker Desktop, dan staat Scout standaard aan — je kunt meteen images scannen.
Om te controleren of Scout beschikbaar is op je systeem, voer je dit commando uit:
Je ziet output met de Scout CLI-versie en pluginstatus.
Docker scout version
Als het commando werkt, ben je klaar om images te scannen.
Krijg je een "command not found"-fout, dan is je Docker-versie te oud. Update Docker Desktop naar de nieuwste versie om toegang te krijgen tot Docker Scout.
Een image scannen met Docker Scout
De scan draaien kost één commando, en dat is het makkelijke deel. Wat soms uitdagend is, is begrijpen wat Scout vindt.
Een image analyseren
Je kunt dit commando draaien om een lokale image te scannen door de naam of ID aan Docker Scout door te geven:
Scout analyseert de imagelagen, haalt pakketinfo op en controleert op bekende kwetsbaarheden. De scan is binnen 30 seconden klaar voor de meeste images.
Scan results for Python 3.14 image
Je kunt ook images scannen die nog niet op je machine staan:
Scout haalt metadata uit de registry zonder de volledige image te downloaden. Zo kun je images controleren vóór je ze lokaal binnenhaalt.
Scan results for Postgres 18.1 image
Tijdens de analyse pakt Scout elke laag uit, identificeert geïnstalleerde pakketten en afhankelijkheden en kruist alles met zijn kwetsbaarheidsdatabase. Het volgt pakketten uit het basis-OS (zoals
apt-pakketten in Ubuntu-gebaseerde images) en taalspecifieke afhankelijkheden (zoals Python-pakketten of Node-modules).De output begrijpen
Scout groepeert kwetsbaarheden op ernst: Critical, High, Medium en Low.
Critical en High verdienen als eerste aandacht. Dit zijn actief misbruikte issues of ernstige bugs die je systeem kunnen compromitteren. Medium is belangrijk maar zelden direct. Low is het volgen waard, maar blokkeert doorgaans geen deployments.
Elke kwetsbaarheid laat zien in welk pakket het probleem zit. Als je door het rapport scrolt, zie je ongeveer dit:
Vulnerability report
Dit vertelt je precies wat kwetsbaar is (
openssl), welke versie je draait en welke versie het oplost. Scout linkt ook naar de CVE-details zodat je zelf over de kwetsbaarheid kunt lezen.De toeschrijving van pakketten laat zien waar kwetsbaarheden vandaan komen — base image-pakketten, applicatieafhankelijkheden of systeemlibraries. Dit helpt je beslissen of je de base image moet updaten, een afhankelijkheid in je code moet upgraden of op een upstream fix moet wachten.
Docker Scout gebruiken om SBOM’s te genereren en te bekijken
Een Software Bill of Materials (SBOM) is een complete inventaris van alles in je container-image — elk pakket, elke library en afhankelijkheid.
Het vertelt je precies wat er in je image zit, tot op specifieke versieniveaus. Securityteams gebruiken SBOM’s om te volgen wat er in productie draait, en compliancekaders vereisen ze vaak.
Docker Scout genereert SBOM’s automatisch wanneer je een image scant met de commando’s die ik in de vorige sectie liet zien. Nog even ter herhaling:
Dit geeft de volledige pakketlijst op je terminal. Scout analyseert de imagelagen en extraheert pakketmetadata, en formatteert dat vervolgens als een SBOM die je kunt opslaan of delen.
Je kunt de SBOM exporteren naar een bestand in plaats van ’m op het scherm te printen:
SBOM SPDX report
Scout ondersteunt twee standaard SBOM-formaten: SPDX (Software Package Data Exchange) en CycloneDX. Beide zijn breed gebruikte industriestandaarden. SPDX werkt goed voor compliance en juridische reviews, terwijl CycloneDX zich richt op security-use-cases en het volgen van kwetsbaarheden.
Je wisselt van formaat met de
--format-vlag:SBOX CycloneDX report
Zodra je een SBOM-bestand hebt, kun je het delen met securityteams, invoeren in andere scantools of archiveren voor compliance-audits.
CVE’s vinden en begrijpen met Docker Scout
Docker Scout vindt kwetsbaarheden door pakketten in je image te matchen met een database van bekende beveiligingsissues.
Wanneer je
docker scout cvesdraait, haalt Scout elk pakket uit je image — OS-pakketten, taallibraries, applicatieafhankelijkheden — en controleert elk tegen Common Vulnerabilities and Exposures (CVE)-records. Een CVE is een openbaar gemaakte beveiligingsfout met een uniek ID zoals CVE-2024-1234.Scout haalt CVE-data uit meerdere bronnen:
Dit betekent dat Scout kwetsbaarheden kan vinden in zowel de OS-pakketten van je base image als in de afhankelijkheden van je applicatie.
Dat gezegd hebbende, is het belangrijk te onthouden dat de analyse anders werkt afhankelijk van waar je image staat.
Beide methoden geven je dezelfde kwetsbaarheidsinformatie. Het enige verschil is waar Scout de imagedata vandaan leest.
Richtlijnen voor herstel en aanbevelingen voor base images
Wanneer Scout een kwetsbaarheid vindt waarvoor een patch beschikbaar is, toont het exact welke versie het probleem oplost. Je ziet bijvoorbeeld "Fixed in: 1.2.3" naast elke CVE. Dit laat je weten of je een pakket moet updaten, je image met een nieuwere basis moet herbouwen of op een upstream fix moet wachten.
Scout raadt ook upgrades van base images aan wanneer overstappen op een nieuwere basis kwetsbaarheden wegneemt. Als je
python:3.13gebruikt en Scout vindt issues in de basis-OS-pakketten, dan kan het voorstellen om te upgraden naarpython:3.14of zelfs een specifiekere patchversie.Deze aanbevelingen verschijnen wanneer Scout detecteert dat een andere base image-tag minder kwetsbaarheden heeft dan je huidige. De suggesties zijn uitvoerbaar — je kunt de nieuwe tag letterlijk in je Dockerfile plakken en herbouwen.
Waarom is dit belangrijk?
Je base image bevat de OS-pakketten, systeemlibraries en taalruntimes waar alles van afhangt. Een kwetsbare base image betekent dat elke container die je ervan bouwt die kwetsbaarheden erft. Kies je een minimale en actief onderhouden base image, dan verklein je het aanvalsoppervlak.
Officiële images op Docker Hub krijgen regelmatig securityupdates, maar je moet je images wel herbouwen om die fixes mee te nemen. Zo geeft het vandaag pullen van
python:3.13je andere pakketten dan zes maanden geleden.Docker Scout gebruiken in CI/CD
Teams integreren Docker Scout in CI-pipelines om kwetsbaarheden te pakken vóór images productie bereiken.
Het idee is simpel: scan elke image als onderdeel van je buildproces en laat de build falen als er kritieke kwetsbaarheden opduiken. Je vindt problemen tijdens ontwikkeling in plaats van erna. De meeste teams stellen Scout zo in dat het automatisch draait wanneer iemand een nieuwe Dockerfile pusht of een base image bijwerkt.
Pipelines controleren meestal twee dingen:
Integratie met GitHub Actions, GitLab CI of Jenkins werkt conceptueel hetzelfde. Je bouwt je image, draait
docker scout cveserop, leest de resultaten uit en beslist of de pipeline slaagt of faalt op basis van je criteria. Sommige teams integreren Scout liever in hun container registry-workflows om images direct na het pushen te scannen.Docker Scout vs. andere imagescanners
Docker Scout is niet de enige tool. Het concurreert met tools zoals Trivy en Snyk, maar elk richt zich op andere workflows.
Kies Docker Scout als je team containers bouwt en draait met Docker-tools en je security-inzicht wilt zonder extra complexiteit. Kies Trivy als je een flexibel, open-source alternatief wilt dat overal werkt. Kies Snyk als je complete security wilt over containers, code en infrastructuur met geautomatiseerde fixes.
Veelvoorkomende beperkingen en aandachtspunten
Docker Scout scant container-images, maar monitort niet wat er gebeurt nadat je ze deployed hebt.
Het analyseert statische images — de pakketten en bestanden die in je container zijn ingebouwd. Het detecteert geen runtime-issues zoals privilege-escalatie, netwerkindringing of kwaadaardige processen die na deployment starten. Heb je runtime security monitoring nodig, gebruik dan tools zoals Falco of Sysdig die containergedrag in productie observeren.
Scout is ook geen vervanging voor volledige SAST (Static Application Security Testing) of DAST (Dynamic Application Security Testing). SAST-tools analyseren je broncode op securityfouten vóór je iets bouwt. DAST-tools testen draaiende applicaties door aanvallen te simuleren. Scout kijkt alleen naar de pakketten in je gebouwde image — het vindt geen kwetsbaarheden in je applicatielogica of configuratiefouten in je code.
Waar Scout wél in uitblinkt, is inzicht geven in wat er in je images zit en je richting fixes sturen. Het vertelt je welke pakketten kwetsbaar zijn, welke versies ze oplossen en welke base images het aanvalsoppervlak verkleinen. Dat maakt Scout nuttig voor securitychecks tijdens het builden en voor compliance-tracking, maar je hebt andere tools nodig om het volledige securityspectrum te dekken.
Best practices voor het gebruik van Docker Scout
Hier is een checklist om het meeste uit Docker Scout te halen.
Scan vroeg in je ontwikkelcyclus. Draai Scout op images tijdens lokale ontwikkeling, niet alleen in CI of vlak voor deployment. Kwetsbaarheden vroeg vinden betekent dat je ze fixt terwijl de context vers is en wijzigingen goedkoop zijn. Wachten tot productie betekent onder druk moeten patchen.
Vergelijk images in de tijd om securitytrends te volgen. Scout kan laten zien of je security verbetert of verslechtert. Draai scans op elke build en vergelijk de resultaten. Als je nieuwe build meer kritieke kwetsbaarheden introduceert dan de vorige, is er iets veranderd — misschien een dependency-update of een base image-wissel. Dat moet je uitzoeken.
Zie Scouts bevindingen als prioriteringssignalen, niet als absolute blockers. Niet elke kwetsbaarheid vraagt directe actie. Een low severity CVE in een development dependency die je niet in productie gebruikt kan wachten. Een kritieke CVE in een publiek blootgestelde service vraagt meteen aandacht. Gebruik Scouts ernstscores en pakketcontext om te beslissen wat voor jouw deployment telt.
Combineer Scout met hygiëne rond base images. Kies minimale, actief onderhouden base images en update ze regelmatig.
python:3.14-slimin plaats vanpython:3.14snijdt pakketten weg die je niet nodig hebt. Je images maandelijks herbouwen pikt securitypatches in de basislaag op. Scout kan je vertellen wat kwetsbaar is, maar goede bases kiezen voorkomt dat veel kwetsbaarheden überhaupt opduiken.Conclusie
Docker Scout geeft je een praktische manier om te begrijpen wat er in je container-images zit.
Het past in Docker-gebaseerde ontwikkeling — geen aparte tools om te installeren, geen accounts om in te richten buiten wat je al gebruikt. Je draait een commando, krijgt kwetsbaarheidsrapporten en ziet welke pakketten updates nodig hebben.
Scout werkt het best als onderdeel van een bredere securityaanpak, niet als je enige optie. Combineer het met runtime-monitoring, broncode-analyse en regelmatige updates van base images. Gebruik het om kwetsbaarheden tijdens builds te vangen en voeg andere tools toe om te dekken wat er na deployment gebeurt.
Als je je afvraagt hoe Docker past in CI/CD-pipelines voor machine learning, schrijf je dan in voor onze CI/CD for Machine Learning-cursus. Je hebt alle antwoorden binnen één middag.