Hoe u ruis in kwetsbaarheidsbeheer vermindert

Waar ruis in kwetsbaarheidsbeheer vandaan komt

Neem één backlog en sorteer die op de herkomst van elke bevinding. De cijfers hieronder zijn ter illustratie, geen benchmark, maar de categorieën zijn de categorieën die teams tegenkomen wanneer ze een steekproef uit hun eigen backlog nemen.

Herkomst van de bevinding	Van 1.000 bevindingen (ter illustratie)	Stap die haar weghaalt
Componenten die u niet levert: vermeldingen in lockfiles en manifesten, builderlagen, ontwikkel- en testtools	300	1. Maak de inventaris kloppend
Dezelfde CVE gemeld door meerdere tools, of één keer per repository	250	2. Tel elke bevinding één keer
Verkeerde matches: botsende CPE-namen, backports van distributies	80	1. Maak de inventaris kloppend
Terechte bevindingen die in uw product niet te misbruiken zijn	150	4. Voeg context over misbruikbaarheid toe
Terechte bevindingen waarvoor nog geen fix bestaat	70	5. Een beleidsbeslissing met een vervaldatum
Bevindingen zonder eigenaar	50	5. Stuur door naar een eigenaar
Over om te rangschikken en te repareren	100	Prioritering

Eén onderscheid maakt de rest van deze pagina eenvoudiger. Sommige van deze bevindingen zijn false positives: de bevinding klopt niet, omdat het component er niet is of de versie niet getroffen is. Andere zijn ruis: de bevinding klopt, maar verandert niets aan wat u deze week doet. Ze vragen om verschillende oplossingen, en wie ze door elkaar haalt, onderdrukt uiteindelijk terechte bevindingen of discussieert over onterechte.

False positive: de bevinding klopt niet	Ruis: klopt, maar is niet urgent
Het component zit niet in wat u levert	De kwetsbare code kan in uw product niet worden bereikt of geactiveerd
De match klopt niet: een CPE-botsing, of een gebackporte fix die het versienummer verbergt	Er is nog geen fix, of het product is intern en niet blootgesteld
Los het op door de inventaris en de matching te corrigeren	Los het op met context, een vastgelegde beslissing en een eigenaar

Stap 1. Laat de inventaris overeenkomen met wat u levert

Dit is de grootste afzonderlijke hefboom, omdat elke volgende stap de fouten van de inventaris vermenigvuldigt. Een component dat wel vermeld staat maar nooit wordt geleverd, levert een bevinding op in elke scanner, elke repository en elke release.

• Leg vast uit de build. Bouw de inventaris op uit wat de releasebuild daadwerkelijk heeft gebruikt, niet uit manifesten of een scan van het eindproduct. Een build-time SBOM bevat wat de job heeft opgehaald, inclusief wat in geen enkele lockfile staat.
• Identificeer componenten met PURL's. Een package URL zoals pkg:npm/[email protected] benoemt het ecosysteem, het pakket en de versie precies. Matchen met advisories die op PURL zijn gesleuteld, zoals de ecosysteemadvisories in OSV, haalt de verkeerde matches weg die ontstaan wanneer een CPE uit een productnaam wordt geraden.
• Gebruik distributiebewuste matching voor OS-pakketten. Debian en andere distributies backporten beveiligingsfixes naar de versie die ze hebben uitgebracht in plaats van te upgraden, waardoor het versienummer ouder kan lijken dan de upstreamfix. Match tegen de eigen security tracker van de distributie, niet tegen upstream versiebereiken.
• Houd de volledigheid bij. Weet wanneer de inventaris iets niet kon zien, in plaats van aan te nemen dat die volledig is. Een ontbrekend component is erger dan een component met ruis: het levert helemaal geen bevinding op.

Uitgewerkt voorbeeld. De lockfile van een Node.js-service bevat [email protected], een library voor glob-matching waarvan test- en buildtools afhankelijk zijn. Een lockfilescan meldt CVE-2024-4067, een denial of service via een reguliere expressie, opgelost in 4.0.8. De releasejob installeert alleen productieafhankelijkheden, met npm ci --omit=dev, dus micromatch komt nooit in de build die wordt geleverd. Een vastlegging van die build bevat het niet, en de bevinding bereikt de backlog nooit. De CVE is echt; voor dit product is de bevinding een false positive.

Stap 2. Tel elke bevinding één keer

Dezelfde CVE komt binnen via de SCA-tool, de containerscanner en het SBOM-platform, en nog eens voor elke repository die de library gebruikt. Dedupliceer op één sleutel: package URL, versie en CVE. Zo is pkg:npm/[email protected] met CVE-2024-45296 één bevinding, hoeveel tools haar ook melden.

• Tel één bevinding per geleverd artefact, niet één per scanner.
• Bundel over builds en repositories heen, zodat de CVE van een gedeelde library één beslissing is die overal geldt, geen veertig tickets.
• Consolideer overlappende scanners. Een eenvoudige regel: bevindingen in afhankelijkheden komen uit één SCA- of SBOM-bron, bevindingen in images uit één containerscanner, bevindingen in uw eigen code uit één SAST-tool. Melden twee tools hetzelfde signaal, houd dan de tool die het dichtst bij het geleverde product zit (SAST vs SCA).

Stap 3. Lever minder

Elke afhankelijkheid die u niet levert, is een bron van bevindingen die u nooit hoeft af te handelen.

• Verwijder ongebruikte afhankelijkheden. De meeste projecten slepen een paar pakketten mee die niets meer importeert.
• Upgrade het pakket dat de kwetsbare pakketten binnenhaalt. Express 4.19.2 pint [email protected] en [email protected] vast, met CVE-2024-45590 en CVE-2024-45296. Zonder overrides kunt u die niet los bijwerken. Express 4.20.0, uitgebracht in september 2024, hangt af van de gerepareerde versies, dus één upgrade lost beide op (transitieve afhankelijkheden).
• Gebruik minimale base images. Slim- en distroless-images bevatten minder pakketten van het besturingssysteem, dus er zijn minder advisories van toepassing. Containerscanning behandelt de hefbomen die specifiek voor images gelden.
• Pin en update bewust. Lockfiles en digests houden de inventaris stabiel tussen builds.
• Blokkeer builds die een bekende kwetsbare versie bevatten. Een policy gate die de build stopt, houdt een kwetsbare library buiten de deur voordat die een bevinding wordt die iemand moet triëren.

example-service
└─ [email protected]          → upgrade to 4.20.0
   ├─ [email protected]    CVE-2024-45590
   └─ [email protected]  CVE-2024-45296

Stap 4. Voeg context over misbruikbaarheid toe

Wat na stap 1 tot en met 3 overblijft, is echt. Context bepaalt wat daarvan urgent is.

• VEX. Leg "niet getroffen" één keer vast, met een onderbouwing, als VEX-verklaring, en hergebruik die voor alle releases en klanten. Sturen klanten hun eigen scans van uw product door, dan beantwoorden dezelfde vastleggingen die vragen: zie een PSIRT opschalen en, voor antwoordsjablonen, hoe u klanten antwoordt na een aanval op de softwareketen.
• Reachability, waar uw tools die bieden, laat zien of uw code de kwetsbare functie kan aanroepen. Het helpt, binnen grenzen (reachability-analyse).
• Signalen van misbruik. CISA KEV zegt dat een kwetsbaarheid in het wild wordt misbruikt; EPSS schat hoe waarschijnlijk misbruik in de komende 30 dagen is.
• Blootstelling. Een product dat aan internet hangt, gaat voor op een interne tool in een privénetwerk.

Stap 5. Stuur bevindingen door naar een eigenaar, met beleid

• Leg drempels vast als beleid. Stel drempels voor ernst en misbruikbaarheid per product of repository in een beleid vast, niet als dashboardfilter dat één persoon heeft ingesteld.
• Wijs eigenaren toe per repository of team, zodat elke bevinding iemand heeft die beslist.
• Neem expliciet een besluit bij "geen fix beschikbaar": accepteren met een vervaldatum, mitigeren of het component vervangen. Een bevinding zonder fix hoort niet open te blijven staan zonder beslissing.

Developers negeren bevindingen om vier redenen: geen eigenaar, geen context, geen deadline of het verkeerde kanaal. Teams die we spreken, beschrijven hoe engineering scanners uitzette omdat de output te veel ruis bevatte om te lezen. Pak elke reden aan: een eigenaar per repository, de context uit stap 4 erbij, een deadline uit het beleid, en levering daar waar het team al werkt.

Ruis verminderen of risico verbergen

Een kleinere backlog is alleen beter als die om de juiste redenen is gekrompen.

• Onderdrukken zonder reden en vervaldatum is verborgen schuld. Het komt terug bij een audit of een incident, als niemand meer weet waarom.
• Ondergrenzen voor ernst verbergen onterechte bevindingen in plaats van ze weg te halen. "Niets onder CVSS 7" laat een false positive met CVSS 6 verdwijnen en laat er een met CVSS 9 staan.
• Elke beslissing om niet te repareren moet worden vastgelegd. Klanten vragen erom, en regelgeving ook, zoals de EU Cyber Resilience Act, die van fabrikanten verwacht dat ze kwetsbaarheden afhandelen gedurende de ondersteuningsperiode van een product.

Hoe u het meet

• Bevindingen per geleverde release, niet per scan.
• Het aandeel bevindingen waarop is gehandeld: gerepareerd, gemitigeerd of besloten.
• Gesloten als niet getroffen met een VEX-record, tegenover onderdrukt zonder.
• Tijd van build tot eigenaar: hoe lang een nieuwe bevinding wacht voordat iemand eigenaar wordt.
• Het percentage duplicaten over tools heen.

Een steekproef van 50 bevindingen die u in een middag doet. Kies willekeurig 50 open bevindingen. Noteer bij elke bevinding of het component in de release wordt geleverd, of een andere tool of repository dezelfde bevinding meldt, of de match klopt, of de kwetsbaarheid in uw product te misbruiken is, of er een fix bestaat en wie eigenaar is. De tellingen vertellen u met welke stap u begint. Herhaal dezelfde steekproef een kwartaal later. Wij noemen geen benchmarks uit de branche voor deze cijfers, omdat geen primaire bron er een onderbouwt.

Waar CRACI past

CRACI werkt aan stap 1 en 2, de build-gate in stap 3 en een deel van stap 4 en 5, voor software die in GitHub Actions wordt gebouwd.

• De inventaris. CRACI vervangt uw GitHub-hosted runners en legt de pakketten vast die elke job daadwerkelijk heeft binnengehaald, met een PURL per component en een volledigheidsstatus per SBOM. Elk component in een CRACI-SBOM zat in de build. Die nauwkeurigheid gaat over de componenten van de SBOM; een gematchte CVE kan uw product nog steeds niet raken. Daarvoor is VEX er, en CRACI ondersteunt VEX.
• Eén bevinding, veel builds. Bevindingen worden over builds en repositories heen gebundeld, en gemonitorde SBOM's worden doorlopend opnieuw beoordeeld zodra nieuwe kwetsbaarheden worden gepubliceerd.
• Gates. Policy gates kunnen een build in realtime stoppen op basis van bevindingen, ook een build die een specifieke CVE bevat.
• Triage en toewijzing. Securityteams triëren bevindingen in CRACI en sturen elke bevinding naar het team dat verantwoordelijk is voor de fix.
• Meldingen. CRACI brengt de betrokken mensen op de hoogte van een kwetsbaarheid en de ernst ervan.

CRACI biedt geen reachability-analyse, SAST of MTTR-dashboards. Zie kwetsbaarheden volgen voor de volledige functionaliteit, of bekijk wat uw builds daadwerkelijk bevatten.

Wanneer CRACI niet het antwoord is

• Het grootste deel van uw ruis bestaat uit SAST-bevindingen in uw eigen code. Dat is een kwestie van SAST-tuning.
• Uw backlog bestaat vooral uit echte, misbruikbare bevindingen in geleverde code. Dat is een probleem van herstelcapaciteit, geen ruisprobleem.
• U hebt runtimecontext uit productieworkloads nodig. Een CNAPP of runtime-securitytool geeft daar antwoord op.

Voor het bredere plan, zie wat u automatiseert wanneer het aantal CVE's blijft stijgen, en de live cijfers op trends in CVE-publicaties.

Kwetsbaarheidsruis verminderen: veelgestelde vragen

Hoe verminder ik het aantal kwetsbaarheidsmeldingen?

Schrap ze bij de bron, in deze volgorde: laat de inventaris overeenkomen met wat u levert, dedupliceer bevindingen op package URL, versie en CVE, lever minder afhankelijkheden, voeg context over misbruikbaarheid toe zoals VEX, KEV en EPSS, en stuur wat overblijft door naar een eigenaar volgens een vastgelegd beleid. Prioriteer daarna.

Waarom meldt onze scanner duizenden kwetsbaarheden, en welke doen ertoe?

Meestal omdat hij componenten meldt die u niet levert, dezelfde CVE één keer per tool en per repository meldt, en sommige matches verkeerd raadt. De bevindingen die ertoe doen, zitten in componenten die uw release daadwerkelijk bevat, zijn in uw product te misbruiken en worden bekend of waarschijnlijk misbruikt.

Hoe dedupliceer ik bevindingen uit meerdere securitytools?

Geef elke bevinding de sleutel package URL, versie en CVE, en tel één bevinding per geleverd artefact. Bundel over repositories heen, zodat een gedeelde library één beslissing is. Wijs daarna elk soort signaal toe aan één tool, zodat twee scanners niet langer hetzelfde melden.

Moeten we kwetsbaarheden zonder fix onderdrukken?

Niet stilzwijgend. Neem een expliciete beslissing: accepteer het risico met een schriftelijke reden en een vervaldatum, mitigeer het, of vervang het component. Bekijk het opnieuw zodra er een fix verschijnt. Onderdrukken zonder reden en vervaldatum is verborgen schuld.

Is een kwetsbaarheid die al een jaar niemand heeft gerepareerd nog steeds ruis?

Niet per se. Leeftijd zegt niets over risico. Als het component wordt geleverd en de kwetsbaarheid te misbruiken is, is er een beslissing en een eigenaar nodig. Raakt ze uw product niet, leg dat dan vast als VEX-verklaring, zodat ze niet steeds terugkomt. Hoe dan ook hoort ze niet open te blijven staan zonder beslissing.

Hoe zorg ik dat developers securitybevindingen niet meer negeren?

Geef elke bevinding een eigenaar, de context om ernaar te handelen en een deadline uit een vastgelegd beleid, en lever haar daar waar het team al werkt. Haal eerst de ruis weg: developers stoppen met het lezen van een kanaal waarin de meeste bevindingen er niet toe doen.

Wat is een goed aantal openstaande kwetsbaarheden?

Er is geen betrouwbare benchmark, en het ruwe aantal is de verkeerde maatstaf. Volg bevindingen per geleverde release, het aandeel waarop is gehandeld, het aandeel dat met een vastgelegde reden is gesloten, en hoe lang bekende misbruikte kwetsbaarheden openstaan in geleverde software.