Så minskar du bruset i sårbarhetshanteringen

Var sårbarhetsbruset kommer ifrån

Ta en backlog och sortera den efter var varje fynd kom ifrån. Siffrorna nedan är illustrativa, inte ett riktmärke, men kategorierna är de som team hittar när de tar ett stickprov ur sin egen backlog.

Fyndets källa	Av 1 000 fynd (illustrativt)	Steget som tar bort det
Komponenter du inte levererar: poster i lockfiler och manifest, byggarlager, utvecklings- och testverktyg	300	1. Gör inventeringen rätt
Samma CVE rapporterad av flera verktyg, eller en gång per repo	250	2. Räkna varje fynd en gång
Felaktiga träffar: kollisioner i CPE-namn, bakåtporteringar i distributioner	80	1. Gör inventeringen rätt
Verkliga fynd som inte kan utnyttjas i din produkt	150	4. Lägg till sammanhang om utnyttjande
Verkliga fynd som ännu saknar åtgärd	70	5. Ett policybeslut med utgångsdatum
Fynd utan ansvarig	50	5. Fördela till en ansvarig
Kvar att rangordna och åtgärda	100	Prioritering

En distinktion gör resten av sidan enklare. Vissa av fynden är falska positiva: fyndet är fel, eftersom komponenten inte finns där eller versionen inte berörs. Andra är brus: fyndet är rätt men ändrar inte vad du gör den här veckan. De kräver olika lösningar, och att blanda ihop dem är hur team slutar med att undertrycka verkliga fynd eller bråka om felaktiga.

Falskt positivt: fyndet är fel	Brus: rätt, men inte brådskande
Komponenten finns inte i det du levererar	Den sårbara koden kan inte nås eller utlösas i din produkt
Träffen är fel: en CPE-kollision, eller en bakåtporterad fix som versionsnumret döljer	Det finns ännu ingen åtgärd, eller så är produkten intern och inte exponerad
Lös det genom att rätta inventeringen och matchningen	Lös det med sammanhang, ett dokumenterat beslut och en ansvarig

Steg 1. Få inventeringen att stämma med det du levererar

Det här är den enskilt största spaken, eftersom varje senare steg multiplicerar inventeringens fel. En komponent som listas men aldrig levereras ger ett fynd i varje skanner, varje repo och varje release.

• Registrera från bygget. Bygg inventeringen utifrån vad releasebygget faktiskt använde, inte utifrån manifest eller en skanning av den färdiga artefakten. En SBOM från bygget innehåller det som jobbet hämtade, inklusive det som ingen lockfile listar.
• Identifiera komponenter med PURL:er. En paket-URL som pkg:npm/[email protected] anger ekosystem, paket och version exakt. Att matcha mot säkerhetsmeddelanden som är nycklade på PURL, som ekosystemens meddelanden i OSV, tar bort de felaktiga träffar som uppstår när en CPE gissas utifrån ett produktnamn.
• Använd distributionsmedveten matchning för OS-paket. Debian och andra distributioner bakåtporterar säkerhetsfixar till den version de levererade i stället för att uppgradera, så versionsnumret kan se äldre ut än fixen uppströms. Matcha mot distributionens egen säkerhetstracker, inte mot versionsintervall uppströms.
• Följ fullständigheten. Vet när inventeringen inte kunde se något, i stället för att anta att den är fullständig. En saknad komponent är värre än en brusig: den ger inget fynd alls.

Genomräknat exempel. En Node.js-tjänsts lockfile innehåller [email protected], ett bibliotek för glob-matchning som test- och byggverktyg är beroende av. En skanning av lockfilen rapporterar CVE-2024-4067, en överbelastningsattack via reguljära uttryck som åtgärdades i 4.0.8. Releasejobbet installerar bara produktionsberoenden, med npm ci --omit=dev, så micromatch kommer aldrig in i bygget som levereras. En registrering av det bygget innehåller den inte, och fyndet når aldrig backloggen. CVE:n är verklig; för den här produkten är fyndet ett falskt positivt.

Steg 2. Räkna varje fynd en gång

Samma CVE kommer från SCA-verktyget, containerskannern och SBOM-plattformen, och en gång till för varje repo som använder biblioteket. Deduplicera på en nyckel: paket-URL, version och CVE. Till exempel är pkg:npm/[email protected] med CVE-2024-45296 ett fynd, oavsett hur många verktyg som rapporterar det.

• Räkna ett fynd per levererad artefakt, inte ett per skanner.
• Sammanställ över byggen och repon, så att en CVE i ett delat bibliotek blir ett beslut som tillämpas överallt, inte fyrtio ärenden.
• Konsolidera överlappande skannrar. En enkel regel: beroendefynd kommer från en SCA- eller SBOM-källa, avbildsfynd från en containerskanner och fynd i din egen kod från ett SAST-verktyg. Om två verktyg rapporterar samma signal, behåll det som ligger närmast det som levereras (SAST vs SCA).

Steg 3. Leverera mindre

Varje beroende som du inte levererar är en källa till fynd som du aldrig behöver hantera.

• Ta bort oanvända beroenden. De flesta projekt bär på några paket som inget längre importerar.
• Uppgradera paketet som drar in de sårbara. Express 4.19.2 låser [email protected] och [email protected], som har CVE-2024-45590 och CVE-2024-45296. Du kan inte uppdatera dem var för sig utan overrides. Express 4.20.0, som släpptes i september 2024, är beroende av de åtgärdade versionerna, så en uppgradering rensar båda (transitiva beroenden).
• Använd minimala basavbilder. Slim- och distroless-avbilder innehåller färre operativsystemspaket, så färre säkerhetsmeddelanden gäller. Containerskanning tar upp spakarna som är specifika för avbilder.
• Lås och uppdatera medvetet. Lockfiler och digests gör inventeringen stabil mellan byggen.
• Blockera byggen som innehåller en känd sårbar version. En policygrind som stoppar bygget håller ett sårbart bibliotek ute innan det blir ett fynd som någon måste triagera.

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

Steg 4. Lägg till sammanhang om utnyttjande

Det som återstår efter steg 1 till 3 är verkligt. Sammanhanget avgör vad av det som är brådskande.

• VEX. Registrera ”inte berörd” en gång, med en motivering, som ett VEX-uttalande, och återanvänd det över releaser och kunder. När kunder skickar vidare sina egna skanningar av din produkt besvarar samma poster dem: se skala upp ett PSIRT och, för svarsmallar, hur du svarar kunder efter en attack mot leveranskedjan.
• Nåbarhet, där dina verktyg erbjuder det, visar om din kod kan anropa den sårbara funktionen. Det hjälper, inom vissa gränser (nåbarhetsanalys).
• Signaler om utnyttjande. CISA KEV anger att en sårbarhet utnyttjas i det vilda; EPSS uppskattar hur sannolikt utnyttjande är de kommande 30 dagarna.
• Exponering. En produkt som är exponerad mot internet går före ett internt verktyg på ett privat nätverk.

Steg 5. Fördela fynd till en ansvarig, med en policy

• Skriv trösklar som policy. Sätt trösklar för allvarlighetsgrad och utnyttjande per produkt eller repo i en policy, inte som ett dashboardfilter som en person har lagt på.
• Utse ansvariga per repo eller team, så att varje fynd har någon som beslutar.
• Besluta uttryckligen om ”ingen åtgärd tillgänglig”: acceptera med ett utgångsdatum, mildra eller byt ut komponenten. Ett fynd utan åtgärd ska inte ligga öppet utan beslut.

Utvecklare ignorerar fynd av fyra skäl: ingen ansvarig, inget sammanhang, ingen tidsgräns eller fel kanal. Team vi pratar med beskriver hur utvecklingen stängt av skannrar för att resultatet var för brusigt att läsa. Åtgärda varje skäl: en ansvarig per repo, sammanhanget från steg 4 bifogat, ett förfallodatum från policyn och leverans där teamet redan arbetar.

Brusreducering kontra att dölja risk

En mindre backlog är bara bättre om den krympte av rätt skäl.

• Undertryckning utan skäl och utgångsdatum är dold skuld. Den kommer tillbaka vid en revision eller en incident, när ingen längre minns varför.
• Golv för allvarlighetsgrad döljer felaktiga fynd i stället för att ta bort dem. ”Inget under CVSS 7” får ett falskt positivt på CVSS 6 att försvinna och lämnar kvar ett på CVSS 9.
• Varje beslut att inte åtgärda behöver dokumenteras. Kunder frågar efter det, och det gör även regelverk som EU:s Cyber Resilience Act, som förväntar sig att tillverkare hanterar sårbarheter under hela produktens supportperiod.

Så mäter du det

• Fynd per levererad release, inte per skanning.
• Andelen fynd som hanteras: åtgärdade, mildrade eller beslutade.
• Stängda som inte berörda med en VEX-post, jämfört med undertryckta utan.
• Tid från bygge till ansvarig: hur länge ett nytt fynd väntar innan någon tar ansvar för det.
• Andelen dubbletter mellan verktyg.

Ett stickprov på 50 fynd som du kan göra på en eftermiddag. Välj 50 öppna fynd slumpmässigt. Notera för varje fynd om komponenten levereras i releasen, om ett annat verktyg eller repo rapporterar samma fynd, om träffen är korrekt, om det kan utnyttjas i din produkt, om det finns en åtgärd och vem som är ansvarig. Siffrorna visar vilket steg du ska börja med. Gör samma stickprov igen ett kvartal senare. Vi citerar inga branschriktmärken för de här siffrorna, eftersom ingen primärkälla stöder något.

Var CRACI passar in

CRACI arbetar med steg 1 och 2, byggspärren i steg 3 och delar av steg 4 och 5, för programvara som byggs i GitHub Actions.

• Inventeringen. CRACI ersätter dina GitHub-hostade runners och registrerar paketen som varje jobb faktiskt drog in, med en PURL per komponent och en fullständighetsstatus per SBOM. Varje komponent i en SBOM från CRACI fanns i bygget. Den träffsäkerheten gäller SBOM:ens komponenter; en matchad CVE kan ändå sakna påverkan på din produkt. Det är det VEX är till för, och CRACI har stöd för VEX.
• Ett fynd, många byggen. Fynden sammanställs över byggen och repon, och bevakade SBOM:er utvärderas om kontinuerligt när nya sårbarheter publiceras.
• Grindar. Policygrindar kan stoppa ett bygge i realtid baserat på fynd, även ett bygge som innehåller en specifik CVE.
• Triage och tilldelning. Säkerhetsteam triagerar fynd i CRACI och skickar varje fynd till teamet som äger åtgärden.
• Notifieringar. CRACI meddelar berörda personer om en sårbarhet och dess allvarlighetsgrad.

CRACI erbjuder inte nåbarhetsanalys, SAST eller MTTR-dashboards. Se sårbarhetsbevakning för hela funktionen, eller se vad dina byggen faktiskt innehåller.

När CRACI inte är svaret

• Det mesta av ditt brus är SAST-fynd i din egen kod. Det är ett problem med att finjustera SAST.
• Din backlog består mest av verkliga, utnyttjbara fynd i levererad kod. Det är ett problem med kapaciteten att åtgärda, inte ett brusproblem.
• Du behöver körtidssammanhang från produktionsarbetslaster. Ett CNAPP- eller körtidssäkerhetsverktyg svarar på det.

För den större planen, se vad du ska automatisera när CVE-volymerna fortsätter att växa, och de aktuella siffrorna i Trender i CVE-publicering.

Minska sårbarhetsbruset: vanliga frågor

Hur minskar jag antalet sårbarhetslarm?

Skär bort dem vid källan, i ordning: få inventeringen att stämma med det du levererar, deduplicera fynd per paket-URL, version och CVE, leverera färre beroenden, lägg till sammanhang om utnyttjande som VEX, KEV och EPSS, och fördela det som återstår till en ansvarig enligt en skriftlig policy. Prioritera sedan.

Varför rapporterar vår skanner tusentals sårbarheter, och vilka spelar roll?

Oftast för att den rapporterar komponenter du inte levererar, rapporterar samma CVE en gång per verktyg och repo, och gissar fel på vissa träffar. De som spelar roll finns i komponenter som din release faktiskt innehåller, kan utnyttjas i din produkt och är kända för eller sannolika att utnyttjas.

Hur deduplicerar jag fynd från flera säkerhetsverktyg?

Nyckla varje fynd på paket-URL, version och CVE, och räkna ett fynd per levererad artefakt. Sammanställ över repon så att ett delat bibliotek blir ett beslut. Ge sedan varje typ av signal till ett verktyg, så att två skannrar slutar rapportera samma sak.

Ska vi undertrycka sårbarheter som saknar åtgärd?

Inte i tysthet. Fatta ett uttryckligt beslut: acceptera risken med ett skriftligt skäl och ett utgångsdatum, mildra den eller byt ut komponenten. Ta sedan upp den igen när en åtgärd dyker upp. En undertryckning utan skäl och utgångsdatum är dold skuld.

Är en sårbarhet som ingen har åtgärdat på ett år fortfarande brus?

Inte nödvändigtvis. Åldern säger ingenting om risken. Om den levereras och kan utnyttjas behöver den ett beslut och en ansvarig. Om den inte påverkar din produkt, registrera det som ett VEX-uttalande så att den slutar komma tillbaka. Oavsett vilket ska den inte ligga öppen utan beslut.

Hur får jag utvecklare att sluta ignorera säkerhetsfynd?

Ge varje fynd en ansvarig, sammanhanget som behövs för att agera, en tidsgräns från en skriftlig policy, och leverera det där teamet redan arbetar. Ta bort bruset först: utvecklare slutar läsa en kanal där de flesta fynd inte spelar någon roll.

Vad är ett bra antal öppna sårbarheter?

Det finns inget tillförlitligt riktmärke, och det råa antalet är fel mått. Följ fynd per levererad release, andelen som hanteras, andelen som stängs med ett dokumenterat skäl och hur länge kända utnyttjade sårbarheter förblir öppna i levererad programvara.