Slik reduserer du støy i sårbarhetshåndteringen

Hvor støyen i sårbarhetsfunn kommer fra

Ta én backlog og sorter den etter hvor hvert funn kom fra. Tallene nedenfor er illustrative, ikke referansetall, men kategoriene er de samme som team finner når de tar stikkprøver av sin egen backlog.

Kilden til funnet	Av 1 000 funn (illustrativt)	Steget som fjerner det
Komponenter du ikke leverer: oppføringer i lockfile og manifest, builder-lag, utviklings- og testverktøy	300	1. Få oversikten riktig
Den samme CVE-en rapportert av flere verktøy, eller én gang per repositorium	250	2. Tell hvert funn én gang
Feil treff: CPE-navnekollisjoner, backporter i distribusjoner	80	1. Få oversikten riktig
Ekte funn som ikke kan utnyttes i produktet ditt	150	4. Legg til kontekst om utnyttbarhet
Ekte funn som ennå ikke har noen retting	70	5. En policybeslutning med utløpsdato
Funn uten eier	50	5. Rut til en eier
Igjen å rangere og rette	100	Prioritering

Ett skille gjør resten av siden enklere. Noen av disse funnene er falske positiver: Funnet er feil, fordi komponenten ikke er der eller versjonen ikke er berørt. Andre er støy: Funnet er riktig, men endrer ikke hva du gjør denne uken. De trenger ulike løsninger, og når de blandes sammen, ender team opp med å undertrykke ekte funn eller krangle om feil funn.

Falsk positiv: funnet er feil	Støy: riktig, men ikke presserende
Komponenten finnes ikke i det du leverer	Den sårbare koden kan ikke nås eller utløses i produktet ditt
Treffet er feil: en CPE-kollisjon, eller en backportert retting som versjonsnummeret skjuler	Det finnes ingen retting ennå, eller produktet er internt og ikke eksponert
Løs det ved å rette opp oversikten og matchingen	Løs det med kontekst, en dokumentert beslutning og en eier

Steg 1. Sørg for at oversikten stemmer med det du leverer

Dette er det største enkeltgrepet, fordi hvert senere steg mangedobler feilene i oversikten. En komponent som er oppført, men aldri levert, gir et funn i hver skanner, hvert repositorium og hver utgivelse.

• Registrer fra bygget. Bygg oversikten fra det utgivelsesbygget faktisk brukte, ikke fra manifester eller en skanning av den ferdige artefakten. En SBOM fra byggetidspunktet inneholder det jobben hentet, også det ingen lockfile lister opp.
• Identifiser komponenter med PURL-er. En pakke-URL som pkg:npm/[email protected] angir økosystem, pakke og versjon nøyaktig. Matching mot sikkerhetsvarsler med PURL som nøkkel, som økosystemvarslene i OSV, fjerner de feile treffene som oppstår når en CPE gjettes ut fra et produktnavn.
• Bruk distribusjonsbevisst matching for OS-pakker. Debian og andre distribusjoner backporterer sikkerhetsrettinger til versjonen de leverte i stedet for å oppgradere, så versjonsnummeret kan se eldre ut enn rettingen oppstrøms. Match mot distribusjonens egen sikkerhetstracker, ikke mot versjonsintervaller oppstrøms.
• Følg med på fullstendigheten. Vit når oversikten ikke kunne se noe, i stedet for å anta at den er fullstendig. En manglende komponent er verre enn en støyende: Den gir ikke noe funn i det hele tatt.

Gjennomgått eksempel. Lockfilen til en Node.js-tjeneste inneholder [email protected], et bibliotek for glob-matching som test- og byggeverktøy er avhengige av. En skanning av lockfilen rapporterer CVE-2024-4067, en tjenestenekt via regulære uttrykk som er rettet i 4.0.8. Utgivelsesjobben installerer bare produksjonsavhengigheter, med npm ci --omit=dev, så micromatch kommer aldri inn i bygget som leveres. En registrering av det bygget inneholder den ikke, og funnet når aldri backloggen. CVE-en er ekte; for dette produktet er funnet en falsk positiv.

Steg 2. Tell hvert funn én gang

Den samme CVE-en kommer fra SCA-verktøyet, containerskanneren og SBOM-plattformen, og én gang til for hvert repositorium som bruker biblioteket. Dedupliser på én nøkkel: pakke-URL, versjon og CVE. For eksempel er pkg:npm/[email protected] med CVE-2024-45296 ett funn, uansett hvor mange verktøy som rapporterer det.

• Tell ett funn per levert artefakt, ikke ett per skanner.
• Samle på tvers av bygg og repositorier, så en CVE i et delt bibliotek er én beslutning som gjelder overalt, ikke førti saker.
• Konsolider overlappende skannere. En enkel regel: Avhengighetsfunn kommer fra én SCA- eller SBOM-kilde, image-funn fra én containerskanner, funn i din egen kode fra ett SAST-verktøy. Hvis to verktøy rapporterer det samme signalet, behold det som ligger nærmest det som leveres (SAST vs. SCA).

Steg 3. Lever mindre

Hver avhengighet du ikke leverer, er en kilde til funn du aldri trenger å håndtere.

• Fjern ubrukte avhengigheter. De fleste prosjekter drar på noen pakker som ingenting importerer lenger.
• Oppgrader pakken som drar inn de sårbare. Express 4.19.2 låser [email protected] og [email protected], som har CVE-2024-45590 og CVE-2024-45296. Du kan ikke oppdatere dem alene uten overrides. Express 4.20.0, utgitt i september 2024, er avhengig av de rettede versjonene, så én oppgradering fjerner begge (transitive avhengigheter).
• Bruk minimale base-images. Slim- og distroless-images inneholder færre operativsystempakker, så færre sikkerhetsvarsler gjelder. Containerskanning dekker grepene som er spesifikke for images.
• Lås versjoner og oppdater bevisst. Lockfiler og digester gjør oversikten stabil mellom bygg.
• Blokker bygg som inneholder en kjent sårbar versjon. En policy gate som stopper bygget, holder et sårbart bibliotek ute før det blir et funn noen må triagere.

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

Steg 4. Legg til kontekst om utnyttbarhet

Det som er igjen etter steg 1 til 3, er ekte. Konteksten avgjør hva av det som haster.

• VEX. Dokumenter «ikke berørt» én gang, med en begrunnelse, som en VEX-erklæring, og gjenbruk den på tvers av utgivelser og kunder. Når kunder videresender sine egne skanninger av produktet ditt, besvarer de samme registreringene dem: se slik skalerer du et PSIRT og, for svarmaler, slik svarer du kunder etter et leverandørkjedeangrep.
• Reachability, der verktøyene dine tilbyr det, viser om koden din kan kalle den sårbare funksjonen. Det hjelper, innenfor visse grenser (reachability-analyse).
• Signaler om utnyttelse. CISA KEV forteller at en sårbarhet utnyttes i praksis; EPSS anslår hvor sannsynlig utnyttelse er de neste 30 dagene.
• Eksponering. Et produkt som er eksponert mot internett, rangeres over et internt verktøy på et privat nettverk.

Steg 5. Rut funn til en eier, med en policy

• Skriv terskler som policy. Sett terskler for alvorlighetsgrad og utnyttbarhet per produkt eller repositorium i en policy, ikke som et dashbordfilter én person har satt.
• Tildel eiere per repositorium eller team, så hvert funn har noen som bestemmer.
• Ta et eksplisitt valg når det ikke finnes noen retting: aksepter med utløpsdato, begrens risikoen, eller bytt ut komponenten. Et funn uten retting skal ikke bli liggende åpent uten en beslutning.

Utviklere ignorerer funn av fire grunner: ingen eier, ingen kontekst, ingen frist, eller feil kanal. Team vi snakker med, beskriver at utviklerne skrudde av skannere fordi resultatene var for støyende til å leses. Løs hver grunn: en eier per repositorium, konteksten fra steg 4 vedlagt, en frist fra policyen, og levering der teamet allerede jobber.

Støyreduksjon vs. skjult risiko

En mindre backlog er bare bedre hvis den krympet av de riktige grunnene.

• Undertrykking uten begrunnelse og utløpsdato er skjult gjeld. Den kommer tilbake i en revisjon eller en hendelse, når ingen lenger husker hvorfor.
• Gulv for alvorlighetsgrad skjuler feil funn i stedet for å fjerne dem. «Ingenting under CVSS 7» får en falsk positiv på CVSS 6 til å forsvinne og lar en på CVSS 9 bli stående.
• Hver beslutning om å ikke rette trenger en dokumentasjon. Kundene ber om det, og det gjør også regelverk som EUs Cyber Resilience Act, som forventer at produsenter håndterer sårbarheter gjennom hele produktets støtteperiode.

Slik måler du det

• Funn per levert utgivelse, ikke per skanning.
• Andelen funn det handles på: rettet, begrenset eller avgjort.
• Lukket som ikke berørt med en VEX-erklæring, sammenlignet med undertrykt uten.
• Tid fra bygg til eier: hvor lenge et nytt funn venter før noen eier det.
• Andelen duplikater på tvers av verktøy.

En stikkprøve på 50 funn som du kan gjennomføre på en ettermiddag. Velg 50 åpne funn tilfeldig. For hvert funn noterer du om komponenten leveres i utgivelsen, om et annet verktøy eller repositorium rapporterer det samme funnet, om treffet er riktig, om det kan utnyttes i produktet ditt, om det finnes en retting og hvem som eier det. Tallene viser hvilket steg du bør begynne med. Gjenta den samme stikkprøven et kvartal senere. Vi oppgir ingen bransjetall for disse målene, fordi ingen primærkilde støtter noen.

Hvor CRACI passer inn

CRACI jobber med steg 1 og 2, byggporten i steg 3 og deler av steg 4 og 5, for programvare som bygges i GitHub Actions.

• Oversikten. CRACI erstatter de GitHub-hostede runnerne dine og registrerer pakkene hver jobb faktisk hentet inn, med en PURL per komponent og en fullstendighetsstatus per SBOM. Hver komponent i en SBOM fra CRACI var med i bygget. Den nøyaktigheten gjelder komponentene i SBOM-en; en matchet CVE kan likevel la være å berøre produktet ditt. Det er det VEX er til for, og CRACI støtter VEX.
• Ett funn, mange bygg. Funn samles på tvers av bygg og repositorier, og overvåkede SBOM-er vurderes på nytt fortløpende etter hvert som nye sårbarheter publiseres.
• Gates. Policy gates kan stoppe et bygg i sanntid på grunnlag av funn, også et bygg som inneholder en bestemt CVE.
• Triage og tildeling. Sikkerhetsteam triagerer funn i CRACI og sender hvert funn til teamet som eier rettingen.
• Varsler. CRACI varsler de relevante personene om en sårbarhet og alvorlighetsgraden.

CRACI tilbyr ikke reachability-analyse, SAST eller MTTR-dashbord. Se sårbarhetssporing for hele funksjonen, eller se hva byggene dine faktisk inneholder.

Når CRACI ikke er svaret

• Det meste av støyen din er SAST-funn i din egen kode. Det er et spørsmål om å finjustere SAST.
• Backloggen din består for det meste av ekte, utnyttbare funn i levert kode. Det er et problem med kapasitet til å rette, ikke et støyproblem.
• Du trenger kjøretidskontekst fra produksjonsarbeidslaster. Et CNAPP- eller kjøretidssikkerhetsverktøy svarer på det.

For den større planen, se hva du bør automatisere når antallet CVE-er fortsetter å øke, og de ferske tallene på trender i CVE-publisering.

Redusere støy fra sårbarheter: ofte stilte spørsmål

Hvordan reduserer jeg antallet sårbarhetsvarsler?

Kutt dem ved kilden, i rekkefølge: Sørg for at oversikten stemmer med det du leverer, dedupliser funn etter pakke-URL, versjon og CVE, lever færre avhengigheter, legg til kontekst om utnyttbarhet som VEX, KEV og EPSS, og rut det som er igjen til en eier etter en skriftlig policy. Prioriter deretter.

Hvorfor rapporterer skanneren vår tusenvis av sårbarheter, og hvilke betyr noe?

Som regel fordi den rapporterer komponenter du ikke leverer, rapporterer den samme CVE-en én gang per verktøy og repositorium, og gjetter feil på noen treff. De som betyr noe, finnes i komponenter utgivelsen din faktisk inneholder, kan utnyttes i produktet ditt, og er kjent eller sannsynlig utnyttet.

Hvordan dedupliserer jeg funn fra flere sikkerhetsverktøy?

Gi hvert funn nøkkelen pakke-URL, versjon og CVE, og tell ett funn per levert artefakt. Samle på tvers av repositorier, så et delt bibliotek blir én beslutning. Gi deretter hver type signal til ett verktøy, så to skannere slutter å rapportere det samme.

Bør vi undertrykke sårbarheter som ikke har noen retting?

Ikke i det stille. Ta en eksplisitt beslutning: aksepter risikoen med en skriftlig begrunnelse og en utløpsdato, begrens den, eller bytt ut komponenten. Se på den igjen når en retting kommer. En undertrykking uten begrunnelse og utløpsdato er skjult gjeld.

Er en sårbarhet som ingen har rettet på et år, fortsatt støy?

Ikke nødvendigvis. Alder sier ingenting om risiko. Hvis den leveres og kan utnyttes, trenger den en beslutning og en eier. Hvis den ikke berører produktet ditt, dokumenter det som en VEX-erklæring, så den slutter å komme tilbake. Uansett skal den ikke bli liggende åpen uten en beslutning.

Hvordan får jeg utviklerne til å slutte å ignorere sikkerhetsfunn?

Gi hvert funn en eier, konteksten som trengs for å handle, en frist fra en skriftlig policy, og lever det der teamet allerede jobber. Fjern støyen først: Utviklere slutter å lese en kanal der de fleste funnene ikke betyr noe.

Hva er et godt antall åpne sårbarheter?

Det finnes ingen pålitelige referansetall, og råtallet er feil mål. Følg med på funn per levert utgivelse, andelen det handles på, andelen som lukkes med en dokumentert begrunnelse, og hvor lenge kjent utnyttede sårbarheter står åpne i levert programvare.