Näin vähennät kohinaa haavoittuvuuksien hallinnassa

Mistä haavoittuvuuskohina tulee

Ota yksi backlog ja lajittele se sen mukaan, mistä kukin löydös on peräisin. Alla olevat luvut ovat havainnollistavia, eivät vertailuarvoja, mutta luokat ovat niitä, jotka tiimit löytävät ottaessaan näytteen omasta backlogistaan.

Löydöksen lähde	1 000 löydöksestä (esimerkki)	Vaihe, joka poistaa sen
Komponentit, joita et toimita: lukitustiedostojen ja manifestien merkinnät, builder-kerrokset, kehitys- ja testityökalut	300	1. Korjaa inventaario
Sama CVE usean työkalun raportoimana tai kerran repositoriota kohden	250	2. Laske jokainen löydös kerran
Väärät osumat: CPE-nimien törmäykset, jakeluiden takaisinporttaukset	80	1. Korjaa inventaario
Todelliset löydökset, joita ei voi hyödyntää tuotteessasi	150	4. Lisää hyödynnettävyyden konteksti
Todelliset löydökset, joihin ei vielä ole korjausta	70	5. Määräaikainen käytäntöpäätös
Löydökset ilman omistajaa	50	5. Ohjaa omistajalle
Jäljelle jää järjestettäväksi ja korjattavaksi	100	Priorisointi

Yksi erottelu helpottaa sivun loppuosaa. Osa näistä löydöksistä on vääriä positiivisia (false positive): löydös on väärä, koska komponenttia ei ole tai versio ei ole haavoittuva. Osa on kohinaa: löydös on oikea, mutta se ei muuta sitä, mitä teet tällä viikolla. Ne vaativat eri korjaukset, ja niiden sekoittaminen saa tiimit vaientamaan todellisia löydöksiä tai kiistelemään vääristä.

Väärä positiivinen: löydös on väärä	Kohina: oikea, mutta ei kiireellinen
Komponentti ei ole siinä, mitä toimitat	Haavoittuvaan koodiin ei voi päästä tai sitä ei voi laukaista tuotteessasi
Osuma on väärä: CPE-törmäys tai takaisinportattu korjaus, jonka versionumero kätkee	Korjausta ei vielä ole, tai tuote on sisäinen eikä altistu
Korjaa se oikaisemalla inventaario ja osumien haku	Korjaa se kontekstilla, kirjatulla päätöksellä ja omistajalla

Vaihe 1. Tee inventaariosta vastaava sitä, mitä toimitat

Tämä on suurin yksittäinen vipu, koska jokainen myöhempi vaihe moninkertaistaa inventaarion virheet. Komponentti, joka on listattu mutta jota ei koskaan toimiteta, tuottaa löydöksen jokaisessa skannerissa, jokaisessa repositoriossa ja jokaisessa julkaisussa.

• Tallenna buildista. Rakenna inventaario siitä, mitä julkaisubuildi todella käytti, älä manifesteista tai valmiin artefaktin skannauksesta. Buildin aikana tallennettu SBOM sisältää sen, mitä jobi haki, myös sen, mitä mikään lukitustiedosto ei luettele.
• Tunnista komponentit PURL-tunnisteilla. Package URL, kuten pkg:npm/[email protected], nimeää ekosysteemin, paketin ja version tarkasti. PURL-avaimilla tunnistettujen tietoturvatiedotteiden, kuten OSV:n ekosysteemitiedotteiden, käyttäminen poistaa väärät osumat, jotka syntyvät CPE:n arvaamisesta tuotenimen perusteella.
• Käytä käyttöjärjestelmäpaketeille jakelutietoista osumien hakua. Debian ja muut jakelut takaisinporttaavat tietoturvakorjaukset toimittamaansa versioon päivittämisen sijaan, joten versionumero voi näyttää vanhemmalta kuin upstreamin korjaus. Vertaa jakelun omaan tietoturvaseurantaan, älä upstreamin versioalueisiin.
• Seuraa kattavuutta. Tiedä, milloin inventaario ei pystynyt näkemään jotain, sen sijaan että oletat sen olevan täydellinen. Puuttuva komponentti on pahempi kuin kohiseva: se ei tuota löydöstä lainkaan.

Esimerkki. Node.js-palvelun lukitustiedostossa (lockfile) on [email protected], glob-hakujen kirjasto, josta testi- ja build-työkalut riippuvat. Lukitustiedoston skannaus raportoi CVE-2024-4067:n, säännöllisen lausekkeen palvelunestohaavoittuvuuden, joka on korjattu versiossa 4.0.8. Julkaisujobi asentaa vain tuotantoriippuvuudet komennolla npm ci --omit=dev, joten micromatch ei koskaan päädy toimitettavaan buildiin. Tuon buildin tallenne ei sisällä sitä, eikä löydös koskaan päädy backlogiin. CVE on todellinen; tämän tuotteen osalta löydös on väärä positiivinen.

Vaihe 2. Laske jokainen löydös kerran

Sama CVE tulee SCA-työkalusta, konttiskannerista ja SBOM-alustasta, ja vielä kerran jokaisesta repositoriosta, joka käyttää kirjastoa. Deduplikoi yhdellä avaimella: package URL, versio ja CVE. Esimerkiksi pkg:npm/[email protected] ja CVE-2024-45296 on yksi löydös, raportoipa sen kuinka moni työkalu tahansa.

• Laske yksi löydös toimitettua artefaktia kohden, ei skanneria kohden.
• Kokoa löydökset buildien ja repositorioiden yli, jotta jaetun kirjaston CVE on yksi kaikkialla sovellettava päätös eikä neljäkymmentä tikettiä.
• Karsi päällekkäiset skannerit. Yksinkertainen sääntö: riippuvuuslöydökset tulevat yhdestä SCA- tai SBOM-lähteestä, kuvalöydökset yhdestä konttiskannerista ja oman koodisi löydökset yhdestä SAST-työkalusta. Jos kaksi työkalua raportoi saman signaalin, pidä se, joka on lähempänä toimitettavaa (SAST vs. SCA).

Vaihe 3. Toimita vähemmän

Jokainen riippuvuus, jota et toimita, on löydösten lähde, jota sinun ei koskaan tarvitse käsitellä.

• Poista käyttämättömät riippuvuudet. Useimmissa projekteissa on muutama paketti, jota mikään ei enää tuo.
• Päivitä paketti, joka tuo haavoittuvat mukanaan. Express 4.19.2 kiinnittää [email protected]:n ja [email protected]:n, joissa ovat CVE-2024-45590 ja CVE-2024-45296. Niitä ei voi päivittää erikseen ilman overrideja. Syyskuussa 2024 julkaistu Express 4.20.0 riippuu korjatuista versioista, joten yksi päivitys poistaa molemmat (transitiiviset riippuvuudet).
• Käytä minimaalisia pohjakuvia. Slim- ja distroless-kuvissa on vähemmän käyttöjärjestelmäpaketteja, joten tietoturvatiedotteita koskee niitä vähemmän. Konttiskannaus käsittelee kuvakohtaiset vivut.
• Kiinnitä ja päivitä harkiten. Lukitustiedostot ja digestit pitävät inventaarion vakaana buildien välillä.
• Estä buildit, jotka sisältävät tunnetusti haavoittuvan version. Buildin pysäyttävä käytäntöportti pitää haavoittuvan kirjaston poissa ennen kuin siitä tulee löydös, jolle kenenkään on tehtävä triage.

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

Vaihe 4. Lisää hyödynnettävyyden konteksti

Vaiheiden 1–3 jälkeen jäljelle jäävä on todellista. Konteksti ratkaisee, mikä siitä on kiireellistä.

• VEX. Kirjaa "not affected" kerran, perusteluineen, VEX-lausuntona ja käytä sitä uudelleen julkaisuissa ja asiakkaille. Kun asiakkaat välittävät omia skannauksiaan tuotteestasi, samat tallenteet vastaavat niihin: katso PSIRTin skaalaaminen ja vastauspohjat oppaasta miten vastata asiakkaille toimitusketjuhyökkäyksen jälkeen.
• Reachability-analyysi, jos työkalusi tarjoavat sitä, näyttää, voiko koodisi kutsua haavoittuvaa funktiota. Siitä on apua tietyissä rajoissa (reachability-analyysi).
• Hyödyntämissignaalit. CISA KEV kertoo, että haavoittuvuutta hyödynnetään aktiivisesti; EPSS arvioi, kuinka todennäköistä hyödyntäminen on seuraavien 30 päivän aikana.
• Altistuminen. Internetiin näkyvä tuote menee yksityisverkon sisäisen työkalun edelle.

Vaihe 5. Ohjaa löydökset omistajalle käytännön mukaan

• Kirjaa raja-arvot käytännöksi. Aseta vakavuuden ja hyödynnettävyyden raja-arvot tuote- tai repositoriokohtaisesti käytäntöön, ei yhden ihmisen asettamaksi näkymän suodattimeksi.
• Nimeä omistajat repositorion tai tiimin mukaan, jotta jokaisella löydöksellä on joku, joka päättää.
• Päätä "korjausta ei ole" -tapaukset eksplisiittisesti: hyväksy määräajalla, lievennä tai korvaa komponentti. Löydös, jolle ei ole korjausta, ei saa jäädä auki ilman päätöstä.

Kehittäjät sivuuttavat löydöksiä neljästä syystä: ei omistajaa, ei kontekstia, ei määräaikaa tai väärä kanava. Tiimit, joiden kanssa puhumme, kertovat kehitystiimien sammuttaneen skannereita, koska tuloste oli liian kohinaista luettavaksi. Korjaa jokainen syy: omistaja repositoriota kohden, vaiheen 4 konteksti mukaan, määräaika käytännöstä ja toimitus sinne, missä tiimi jo työskentelee.

Kohinan vähentäminen vs. riskin piilottaminen

Pienempi backlog on parempi vain, jos se pieneni oikeista syistä.

• Vaientaminen ilman syytä ja määräaikaa on piilovelkaa. Se palaa auditoinnissa tai tietoturvapoikkeamassa, eikä kukaan enää muista miksi.
• Vakavuusrajat piilottavat väärät löydökset poistamatta niitä. "Ei mitään alle CVSS 7:n" saa CVSS 6:n väärän positiivisen katoamaan ja jättää CVSS 9:n väärän positiivisen paikalleen.
• Jokainen päätös jättää korjaamatta tarvitsee kirjauksen. Asiakkaat kysyvät sitä, ja niin kysyy myös sääntely, kuten EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA), joka edellyttää valmistajien käsittelevän haavoittuvuudet koko tuotteen tukiajan.

Miten sitä mitataan

• Löydökset toimitettua julkaisua kohden, ei skannausta kohden.
• Niiden löydösten osuus, joille tehtiin jotain: korjattiin, lievennettiin tai päätettiin.
• Suljettu "not affected" -tilaan VEX-kirjauksella verrattuna ilman kirjausta vaiennettuihin.
• Aika buildista omistajalle: kuinka kauan uusi löydös odottaa ennen kuin joku ottaa sen omakseen.
• Kaksoiskappaleiden osuus työkalujen välillä.

50 löydöksen otos, jonka teet iltapäivässä. Valitse satunnaisesti 50 avointa löydöstä. Kirjaa kustakin, toimitetaanko komponentti julkaisussa, raportoiko toinen työkalu tai repositorio saman löydöksen, onko osuma oikea, onko se hyödynnettävissä tuotteessasi, onko korjausta olemassa ja kuka sen omistaa. Määrät kertovat, mistä vaiheesta aloittaa. Tee sama otos uudelleen neljännesvuoden kuluttua. Emme esitä näille luvuille toimialan vertailuarvoja, koska mikään primäärilähde ei tue sellaista.

Mihin CRACI sopii

CRACI toimii vaiheissa 1 ja 2, vaiheen 3 build-portissa sekä osassa vaiheita 4 ja 5 GitHub Actionsissa buildatulle ohjelmistolle.

• Inventaario. CRACI korvaa GitHubin ylläpitämät runnerisi ja tallentaa paketit, jotka kukin jobi todella haki, PURL-tunnisteen kanssa komponenttia kohden ja kattavuustilan SBOM:ia kohden. Jokainen CRACI:n SBOM:n komponentti oli buildissa. Tämä tarkkuus koskee SBOM:n komponentteja; osuman saanut CVE voi silti olla vaikuttamatta tuotteeseesi. Sitä varten on VEX, ja CRACI tukee VEX:iä.
• Yksi löydös, monta buildia. Löydökset kootaan buildien ja repositorioiden yli, ja valvotut SBOM:t arvioidaan jatkuvasti uudelleen, kun uusia haavoittuvuuksia julkaistaan.
• Portit. Käytäntöportit voivat pysäyttää buildin reaaliajassa löydösten perusteella, myös buildin, joka sisältää tietyn CVE:n.
• Triage ja ohjaus. Tietoturvatiimit tekevät löydöksille triagen CRACI:ssa ja ohjaavat kunkin korjauksesta vastaavalle tiimille.
• Ilmoitukset. CRACI ilmoittaa asianomaisille henkilöille haavoittuvuudesta ja sen vakavuudesta.

CRACI ei tarjoa reachability-analyysiä, SAST:ia tai MTTR-näkymiä. Katso koko ominaisuus sivulta haavoittuvuuksien seuranta tai katso, mitä buildisi oikeasti sisältävät.

Milloin CRACI ei ole vastaus

• Suurin osa kohinastasi on oman koodisi SAST-löydöksiä. Se on SAST-työkalun säätöongelma.
• Backlogisi koostuu enimmäkseen todellisista, hyödynnettävistä löydöksistä toimitetussa koodissa. Se on korjauskapasiteetin ongelma, ei kohinaongelma.
• Tarvitset ajonaikaista kontekstia tuotantokuormista. Siihen vastaa CNAPP- tai ajonaikaisen tietoturvan työkalu.

Laajemman suunnitelman löydät sivulta mitä automatisoida, kun CVE-määrät kasvavat, ja ajantasaiset luvut sivulta CVE-julkaisujen trendit.

Haavoittuvuuskohinan vähentäminen: usein kysytyt kysymykset

Miten vähennän haavoittuvuushälytysten määrää?

Karsi ne lähteellä tässä järjestyksessä: tee inventaariosta vastaava sitä, mitä toimitat, deduplikoi löydökset package URL:n, version ja CVE:n perusteella, toimita vähemmän riippuvuuksia, lisää hyödynnettävyyden konteksti, kuten VEX, KEV ja EPSS, ja ohjaa jäljelle jäävät omistajalle kirjatun käytännön mukaan. Priorisoi sitten.

Miksi skannerimme raportoi tuhansia haavoittuvuuksia, ja mitkä niistä ovat tärkeitä?

Yleensä siksi, että se raportoi komponentteja, joita et toimita, raportoi saman CVE:n kerran työkalua ja repositoriota kohden ja arvaa osan osumista väärin. Tärkeät ovat komponenteissa, jotka julkaisusi todella sisältää, ovat hyödynnettävissä tuotteessasi ja joita tiedetään tai todennäköisesti hyödynnetään.

Miten deduplikoin useiden tietoturvatyökalujen löydökset?

Avainna jokainen löydös package URL:n, version ja CVE:n perusteella ja laske yksi löydös toimitettua artefaktia kohden. Kokoa repositorioiden yli, jotta jaettu kirjasto on yksi päätös. Anna sitten kukin signaalityyppi yhdelle työkalulle, jotta kaksi skanneria lakkaa raportoimasta samaa asiaa.

Pitäisikö haavoittuvuudet, joihin ei ole korjausta, vaientaa?

Ei hiljaa. Tee eksplisiittinen päätös: hyväksy riski kirjatulla perusteella ja määräajalla, lievennä sitä tai korvaa komponentti. Palaa asiaan, kun korjaus ilmestyy. Vaientaminen ilman syytä ja määräaikaa on piilovelkaa.

Onko haavoittuvuus, jota kukaan ei ole korjannut vuoteen, yhä kohinaa?

Ei välttämättä. Ikä ei kerro mitään riskistä. Jos se toimitetaan ja on hyödynnettävissä, se tarvitsee päätöksen ja omistajan. Jos se ei vaikuta tuotteeseesi, kirjaa se VEX-lausunnoksi, jotta se lakkaa palaamasta. Kummassakaan tapauksessa sen ei pitäisi jäädä auki ilman päätöstä.

Miten saan kehittäjät lopettamaan tietoturvalöydösten sivuuttamisen?

Anna jokaiselle löydökselle omistaja, konteksti toimimiseen ja määräaika kirjatusta käytännöstä, ja toimita se sinne, missä tiimi jo työskentelee. Poista kohina ensin: kehittäjät lakkaavat lukemasta kanavaa, jossa suurimmalla osalla löydöksistä ei ole merkitystä.

Mikä on hyvä määrä avoimia haavoittuvuuksia?

Luotettavaa vertailuarvoa ei ole, ja raakamäärä on väärä mittari. Seuraa löydöksiä toimitettua julkaisua kohden, niiden osuutta, joille tehtiin jotain, kirjatulla perusteella suljettujen osuutta ja sitä, kuinka kauan tunnetusti hyödynnetyt haavoittuvuudet pysyvät auki toimitetussa ohjelmistossa.