Sådan reducerer du støjen fra sårbarhedsfund

Hvor støjen fra sårbarhedsfund kommer fra

Tag én backlog, og sortér den efter, hvor hvert fund kom fra. Tallene nedenfor er illustrative, ikke et benchmark, men kategorierne er dem, teams finder, når de tager en stikprøve af deres egen backlog.

Kilden til fundet	Af 1.000 fund (illustrativt)	Trinnet, der fjerner det
Komponenter, du ikke leverer: poster i lockfiles og manifester, builder-lag, udviklings- og testværktøjer	300	1. Få inventaret til at stemme
Den samme CVE rapporteret af flere værktøjer eller én gang pr. repository	250	2. Tæl hvert fund én gang
Forkerte match: navnekollisioner i CPE, backports i distributioner	80	1. Få inventaret til at stemme
Ægte fund, der ikke kan udnyttes i dit produkt	150	4. Tilføj kontekst om udnyttelighed
Ægte fund, der endnu ikke har en rettelse	70	5. En politisk beslutning med udløbsdato
Fund uden ejer	50	5. Fordel til en ejer
Tilbage at rangere og rette	100	Prioritering

Én skelnen gør resten af siden lettere. Nogle af disse fund er falske positiver: Fundet er forkert, fordi komponenten ikke er der, eller versionen ikke er berørt. Andre er støj: Fundet er korrekt, men ændrer ikke, hvad du gør i denne uge. De kræver forskellige løsninger, og når de blandes sammen, ender teams med at undertrykke ægte fund eller diskutere forkerte.

Falsk positiv: fundet er forkert	Støj: korrekt, men ikke akut
Komponenten er ikke i det, du leverer	Den sårbare kode kan ikke nås eller udløses i dit produkt
Matchet er forkert: en CPE-kollision eller en backportet rettelse, som versionsnummeret skjuler	Der findes endnu ingen rettelse, eller produktet er internt og ikke eksponeret
Løs det ved at rette inventaret og matchningen	Løs det med kontekst, en registreret beslutning og en ejer

Trin 1. Få inventaret til at matche det, du leverer

Det er det største enkeltstående håndtag, fordi hvert senere trin mangedobler inventarets fejl. En komponent, der er listet, men aldrig leveret, giver et fund i hver scanner, hvert repository og hver release.

• Registrér fra buildet. Byg inventaret ud fra det, release-buildet faktisk brugte, ikke ud fra manifester eller en scanning af det færdige artefakt. En build-time SBOM indeholder det, jobbet hentede, også det, ingen lockfile lister.
• Identificér komponenter med PURL'er. En package URL som pkg:npm/[email protected] angiver økosystem, pakke og version præcist. Matchning mod advisories med PURL-nøgler, som økosystemernes advisories i OSV, fjerner de forkerte match, der opstår, når man gætter en CPE ud fra et produktnavn.
• Brug distributionsbevidst matchning til styresystempakker. Debian og andre distributioner backporter sikkerhedsrettelser til den version, de leverede, i stedet for at opgradere, så versionsnummeret kan se ældre ud end upstream-rettelsen. Match mod distributionens egen security tracker, ikke mod upstream-versionsintervaller.
• Følg fuldstændigheden. Vid, hvornår inventaret ikke kunne se noget, i stedet for at gå ud fra, at det er komplet. En manglende komponent er værre end en støjende: Den giver slet intet fund.

Gennemregnet eksempel. En Node.js-services lockfile indeholder [email protected], et bibliotek til glob-matchning, som test- og buildværktøjer afhænger af. En scanning af lockfilen rapporterer CVE-2024-4067, en denial of service via regulære udtryk, der er rettet i 4.0.8. Release-jobbet installerer kun produktionsafhængigheder med npm ci --omit=dev, så micromatch kommer aldrig ind i det build, der leveres. En registrering af det build indeholder den ikke, og fundet når aldrig backloggen. CVE'en er ægte; for dette produkt er fundet en falsk positiv.

Trin 2. Tæl hvert fund én gang

Den samme CVE kommer fra SCA-værktøjet, container-scanneren og SBOM-platformen, og én gang mere for hvert repository, der bruger biblioteket. Fjern dubletter på én nøgle: package URL, version og CVE. For eksempel er pkg:npm/[email protected] med CVE-2024-45296 ét fund, uanset hvor mange værktøjer der rapporterer det.

• Tæl ét fund pr. leveret artefakt, ikke ét pr. scanner.
• Saml på tværs af builds og repositories, så en CVE i et delt bibliotek er én beslutning, der gælder overalt, ikke fyrre tickets.
• Konsolidér overlappende scannere. En enkel regel: Fund i afhængigheder kommer fra én SCA- eller SBOM-kilde, fund i images fra én container-scanner, fund i din egen kode fra ét SAST-værktøj. Hvis to værktøjer rapporterer det samme signal, så behold det, der ligger tættest på det, der leveres (SAST vs SCA).

Trin 3. Lever mindre

Hver afhængighed, du ikke leverer, er en kilde til fund, du aldrig skal håndtere.

• Fjern ubrugte afhængigheder. De fleste projekter slæber rundt på et par pakker, som intet importerer længere.
• Opgradér den pakke, der trækker de sårbare ind. Express 4.19.2 låser [email protected] og [email protected], som har CVE-2024-45590 og CVE-2024-45296. Du kan ikke opdatere dem for sig uden overrides. Express 4.20.0, udgivet i september 2024, afhænger af de rettede versioner, så én opgradering fjerner begge (transitive afhængigheder).
• Brug minimale base images. Slim- og distroless-images indeholder færre styresystempakker, så færre advisories gælder. Container-scanning dækker de håndtag, der er specifikke for images.
• Lås versioner, og opdatér bevidst. Lockfiles og digests gør inventaret stabilt mellem builds.
• Blokér builds, der indeholder en kendt sårbar version. En policy gate, der stopper buildet, holder et sårbart bibliotek ude, før det bliver et fund, som nogen skal triagere.

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

Trin 4. Tilføj kontekst om udnyttelighed

Det, der er tilbage efter trin 1 til 3, er ægte. Konteksten afgør, hvad af det der haster.

• VEX. Registrér "ikke berørt" én gang, med en begrundelse, som en VEX-erklæring, og genbrug den på tværs af releases og kunder. Når kunder videresender deres egne scanninger af dit produkt, besvarer de samme registreringer dem: se at skalere et PSIRT og, for svarskabeloner, sådan svarer du kunder efter et forsyningskædeangreb.
• Reachability, hvor dine værktøjer tilbyder det, viser, om din kode kan kalde den sårbare funktion. Det hjælper, inden for visse grænser (reachability-analyse).
• Signaler om udnyttelse. CISA KEV fortæller, at en sårbarhed udnyttes i praksis; EPSS anslår, hvor sandsynlig udnyttelse er inden for de næste 30 dage.
• Eksponering. Et produkt, der vender ud mod internettet, rangerer over et internt værktøj på et privat netværk.

Trin 5. Fordel fund til en ejer, med en politik

• Skriv tærskler som politik. Sæt tærskler for alvorlighed og udnyttelighed pr. produkt eller repository i en politik, ikke som et dashboard-filter, én person har sat.
• Udpeg ejere pr. repository eller team, så hvert fund har nogen, der beslutter.
• Beslut "ingen rettelse tilgængelig" eksplicit: acceptér med en udløbsdato, afbød, eller erstat komponenten. Et fund uden rettelse bør ikke stå åbent uden en beslutning.

Udviklere ignorerer fund af fire grunde: ingen ejer, ingen kontekst, ingen frist eller den forkerte kanal. Teams, vi taler med, beskriver, at udviklingsafdelingen slår scannere fra, fordi outputtet var for støjende til at læse. Løs hver grund: en ejer pr. repository, konteksten fra trin 4 vedhæftet, en frist fra politikken og levering der, hvor teamet allerede arbejder.

Støjreduktion vs. at skjule risiko

En mindre backlog er kun bedre, hvis den skrumpede af de rigtige grunde.

• Undertrykkelse uden en begrundelse og en udløbsdato er skjult gæld. Den kommer tilbage ved en audit eller en hændelse, når der ikke er nogen tilbage, som husker hvorfor.
• Alvorlighedsgulve skjuler forkerte fund i stedet for at fjerne dem. "Intet under CVSS 7" får en falsk positiv på CVSS 6 til at forsvinde og lader en på CVSS 9 blive stående.
• Hver beslutning om ikke at rette kræver en registrering. Kunderne beder om den, og det gør regler som EU's Cyber Resilience Act også, der forventer, at producenter håndterer sårbarheder i hele produktets supportperiode.

Sådan måler du det

• Fund pr. leveret release, ikke pr. scanning.
• Andelen af fund, der handles på: rettet, afbødet eller besluttet.
• Lukket som ikke berørt med en VEX-registrering, over for undertrykt uden.
• Tid fra build til ejer: hvor længe et nyt fund venter, før nogen ejer det.
• Andelen af dubletter på tværs af værktøjer.

En stikprøve på 50 fund, du kan tage på en eftermiddag. Vælg 50 åbne fund tilfældigt. Notér for hvert fund, om komponenten leveres i releasen, om et andet værktøj eller repository rapporterer det samme fund, om matchet er korrekt, om det kan udnyttes i dit produkt, om der findes en rettelse, og hvem der ejer det. Optællingerne fortæller dig, hvilket trin du skal starte med. Tag den samme stikprøve igen et kvartal senere. Vi citerer ikke branchebenchmarks for disse tal, fordi ingen primær kilde understøtter et.

Hvor CRACI passer ind

CRACI arbejder med trin 1 og 2, build-gaten i trin 3 og dele af trin 4 og 5 for software, der bygges i GitHub Actions.

• Inventaret. CRACI erstatter dine GitHub-hostede runnere og registrerer de pakker, hvert job faktisk hentede, med en PURL pr. komponent og en fuldstændighedsstatus pr. SBOM. Hver komponent i en CRACI-SBOM var i buildet. Den præcision gælder SBOM'ens komponenter; en matchet CVE kan stadig være en, der ikke berører dit produkt. Det er det, VEX er til for, og CRACI understøtter VEX.
• Ét fund, mange builds. Fund samles på tværs af builds og repositories, og overvågede SBOM'er genvurderes løbende, efterhånden som nye sårbarheder offentliggøres.
• Gates. Policy gates kan stoppe et build i realtid på grund af fund, også et build, der indeholder en bestemt CVE.
• Triage og tildeling. Sikkerhedsteams triagerer fund i CRACI og sender hvert fund til det team, der ejer rettelsen.
• Notifikationer. CRACI giver de relevante personer besked om en sårbarhed og dens alvorlighed.

CRACI tilbyder ikke reachability-analyse, SAST eller MTTR-dashboards. Se sårbarhedssporing for hele funktionen, eller se, hvad dine builds faktisk indeholder.

Når CRACI ikke er svaret

• Det meste af din støj er SAST-fund i din egen kode. Det er et problem med tuning af SAST.
• Din backlog består mest af ægte, udnyttelige fund i leveret kode. Det er et problem med kapacitet til afhjælpning, ikke et støjproblem.
• Du har brug for runtime-kontekst fra produktionsworkloads. Et CNAPP- eller runtime-sikkerhedsværktøj besvarer det.

For den bredere plan, se hvad du bør automatisere, når CVE-tallene bliver ved med at stige, og de live tal under tendenser i CVE-offentliggørelser.

Mindre støj fra sårbarhedsfund: ofte stillede spørgsmål

Hvordan reducerer jeg antallet af sårbarhedsalarmer?

Skær dem væk ved kilden, i rækkefølge: Få inventaret til at matche det, du leverer, fjern dubletter efter package URL, version og CVE, lever færre afhængigheder, tilføj kontekst om udnyttelighed som VEX, KEV og EPSS, og fordel resten til en ejer efter en skrevet politik. Prioritér derefter.

Hvorfor rapporterer vores scanner tusindvis af sårbarheder, og hvilke betyder noget?

Som regel fordi den rapporterer komponenter, du ikke leverer, rapporterer den samme CVE én gang pr. værktøj og repository og gætter forkert på nogle match. Dem, der betyder noget, er i komponenter, din release faktisk indeholder, kan udnyttes i dit produkt og vides eller forventes at blive udnyttet.

Hvordan fjerner jeg dubletter blandt fund fra flere sikkerhedsværktøjer?

Giv hvert fund en nøgle ud fra package URL, version og CVE, og tæl ét fund pr. leveret artefakt. Saml på tværs af repositories, så et delt bibliotek er én beslutning. Giv derefter hver type signal til ét værktøj, så to scannere holder op med at rapportere det samme.

Skal vi undertrykke sårbarheder, der ikke har nogen rettelse?

Ikke i det stille. Træf en eksplicit beslutning: Acceptér risikoen med en skrevet begrundelse og en udløbsdato, afbød den, eller erstat komponenten. Tag den så op igen, når der kommer en rettelse. En undertrykkelse uden begrundelse og udløbsdato er skjult gæld.

Er en sårbarhed, som ingen har rettet i et år, stadig støj?

Ikke nødvendigvis. Alder siger intet om risiko. Hvis den leveres og kan udnyttes, kræver den en beslutning og en ejer. Hvis den ikke berører dit produkt, så registrér det som en VEX-erklæring, så den holder op med at vende tilbage. Under alle omstændigheder bør den ikke stå åben uden en beslutning.

Hvordan får jeg udviklere til at holde op med at ignorere sikkerhedsfund?

Giv hvert fund en ejer, konteksten til at handle på det og en frist fra en skrevet politik, og lever det der, hvor teamet allerede arbejder. Fjern støjen først: Udviklere holder op med at læse en kanal, hvor de fleste fund ikke betyder noget.

Hvad er et godt antal åbne sårbarheder?

Der findes intet pålideligt benchmark, og det rå antal er det forkerte mål. Følg fund pr. leveret release, andelen, der handles på, andelen, der lukkes med en registreret begrundelse, og hvor længe kendte udnyttede sårbarheder står åbne i leveret software.