Uw CI-pijplijn is zojuist rood geworden: Dependabot rapporteert een “kritieke” CVE op een transitieve bibliotheek. Het team raakt in paniek, iemand stelt aan het eind van de dag een hotfix voor - en dan ontdekken we dat de betreffende module nooit in productie wordt geladen, dat deze zich in een buildtool bevindt en dat de daadwerkelijk geïnstalleerde versie niet de versie is die in het bulletin staat. Resultaat: een slapeloze nacht voor een theoretisch risico, terwijl een XSS-kwetsbaarheid die op de publieke API is blootgelegd nog steeds op zijn beurt wacht.
Het probleem is niet het gebrek aan waarschuwingen. Dit is de afwezigheid van sortering: het behandelen van elke CVE als urgent komt erop neer dat er geen prioriteit aan wordt gegeven.
Wat een waarschuwing niet zegt
Een afhankelijkheidsscanner vergelijkt pakketversies met een database met bekende kwetsbaarheden. Het kent uw architectuur, uw firewalls en de vraag of de kwetsbare code bereikbaar is vanaf internet niet.
Drie filters scheiden ruis van reëel risico:
| Signaal | Wat het aangeeft | Limiet |
|---|---|---|
| CVSS-score | Theoretische zwaartekracht | Negeert lokale blootstelling |
| Bereikbaarheid (Snyk, Grype…) | Belpad in uw code | Afhankelijk van statische analyse |
| Netwerkoppervlak | Open poort, auth, WAF | Om jezelf in kaart te brengen |
Een CVE “9.8” in een devDependencies-afhankelijkheid heeft niet dezelfde urgentie als een “6.5” op uw openbare authenticatie-eindpunt.
Breng de belichting in kaart vóór het patchen
Voordat u een pull-aanvraag opent, beantwoordt u vier vragen in deze volgorde.
1. Waar wordt het onderdeel uitgevoerd? Productie, staging, CI, ontwikkelstation: elke omgeving heeft zijn eigen SLA. Een fout in een test-dockerimage rechtvaardigt vrijdagavond geen noodinzet.
2. Is deze van buitenaf bereikbaar? Een server achter een VPN, zonder openbare poort en zonder zichtbare reverse proxy verkleint de kans op opportunistische exploitatie aanzienlijk.
3. Welke rechten zou de aanvaller verkrijgen? RCE als root op een geïsoleerde pod zonder toegang tot gevoelige gegevens ≠ RCE op de hoofddatabase van PostgreSQL.
4. Is er sprake van actieve exploitatie (KEV, CERT-bulletins)? Kwetsbaarheden die als actief uitgebuit worden vermeld, komen op de voorgrond, zelfs met een gemiddelde CVSS-score.
Operationeel prioriteringsraster
Hier is een pragmatisch raster voor een webteam dat wordt gehost op VPS of in de cloud:
| Niveau | Criteria | Streefdeadline |
|---|---|---|
| P0 | Actieve exploitatie + publieke oppervlakte | Oplossing of oplossing < 24 uur |
| P1 | RCE/LFI op blootgestelde service, geen bekende exploit | < 7 dagen |
| P2 | Prod-afhankelijkheid, niet direct zichtbaar | Volgende releasecyclus |
| P3 | Ontwikkelen/testen, interne tooling | Maandelijkse achterstand |
Compenserende maatregelen zijn van belang: het blokkeren van een eindpunt, het beperken van een IP-bereik, het activeren van een WAF-regel of het tijdelijk verwijderen van een functie kan de tijd in beslag nemen van een schone patch.
SBOM, lockfiles en continuïteit
Zonder betrouwbare inventarisatie weet u niet wat er werkelijk draait. Lockfiles (package-lock.json, composer.lock, poetry.lock) en bevroren Docker-images zijn uw bron van waarheid - niet alleen de declaratieve package.json.
Genereer bij elke build een SBOM (Software Bill of Materials), sla deze op bij het geïmplementeerde artefact en scan afbeeldingen die al in productie zijn opnieuw wanneer er nieuwe CVE's verschijnen. Dit is de enige manier om eerlijk antwoord te geven op de vraag “worden wij getroffen?” » zonder een handmatige audit opnieuw te starten.
De top: de patchsnelheid meet de veiligheid niet
Dit is wat de dashboards ‘100% van de CVE’s gecorrigeerd in 48 uur’ behandelen.
Teams die sorteren op blootstelling, repareren minder tickets en nemen minder risico's.
Beslis en ga vooruit zonder blinde vlek
- Voeg een P0–P3-raster toe en deel dit met het product en de hosting.
- Verbind de scan met het CI en blokkeer alleen bereikbare waarschuwingen in productie.
- Bekijk elke week de oplossingen: een tijdelijke WAF mag niet permanent worden.
- Test het terugdraaien na een grote afhankelijkheidspatch, vooral op PHP, Node of Python, waar brekende wijzigingen gebruikelijk zijn.
Om een host te kiezen die uw patchcycli (snapshots, mirror staging, rollback) kan ondersteunen, bladert u door onze overzicht of de vergelijker.
Veelgestelde vragen
Moeten alle Dependabot- of Snyk-waarschuwingen onmiddellijk worden gecorrigeerd?
Nee. Repareer eerst wat wordt blootgesteld aan het netwerk of wordt uitgevoerd met verhoogde rechten. Een kritische CVE in een testafhankelijkheid kan wachten op een geplande cyclus.
Hoe weet ik of een kwetsbaarheid echt voor mij kan worden misbruikt?
Vergelijk het oproeppad, de exacte geïnstalleerde versie, de netwerkconfiguratie en bewijs van actieve exploitatie. Een CVSS-score alleen is niet voldoende.
Wat te doen als de update de compatibiliteit verbreekt?
Documenteer een tijdelijke oplossing met een vervaldatum. Een niet-gepatchte kwetsbaarheid zonder compenserende maatregelen is een overgenomen schuld.
SBOM en automatisch scannen, waar te beginnen?
Genereer een inventaris van afhankelijkheden in de productie, sluit een scanner aan op de IC en categoriseer vervolgens waarschuwingen op basis van blootstelling voordat u SLA's instelt.
De volgende rode waarschuwing vraagt niet "laten we alles patchen" - maar vraagt waar is de echte blootstelling?