Haavoittuvuuksien priorisointi: miten päätät, mitä korjata ensin

Miksi pelkkä vakavuus ei toimi

Oletuksena lajitellaan CVSS:n mukaan ja edetään kriittisistä alaspäin. Se tuntuu objektiivisalta, ja se epäonnistuu kolmesta syystä:

• CVSS mittaa vakavuutta, ei riskiä. Se kuvaa, kuinka paha haavoittuvuus olisi, jos sitä hyödynnettäisiin. Se ei kerro, hyödyntääkö sitä kukaan tai onko sillä merkitystä tuotteessasi.
• Liian suuri osa listasta on kiireellistä. Moni julkaistu CVE saa korkean tai kriittisen pistemäärän, joten CVSS:n mukaan lajiteltu jono nostaa satoja löydöksiä kärkeen eikä tarjoa keinoa valita niiden välillä.
• Lista on vain yhtä hyvä kuin inventaario. Lukitustiedostoa lukeva skanneri raportoi kehitysriippuvuuksia, joita ei koskaan toimiteta, ja ohittaa paketit, jotka buildi latasi paketinhallinnan ohi. Molemmat vääristävät järjestystä jo ennen kuin se alkaa.

Priorisointi lisää puuttuvat kysymykset: hyödynnetäänkö haavoittuvuutta, kuinka todennäköisesti sitä hyödynnetään ja mitä sinulle tapahtuu, jos sitä hyödynnetään. Järjestys kuitenkin vain järjestää edessään olevan listan, joten karsi ensin kohina: löydökset komponenteista, joita et toimita, kaksoiskappaleet ja löydökset, joilla ei ole omistajaa.

Signaalit

Signaali	Kysymys, johon se vastaa	Lähde
CVSS	Kuinka vakava se on, jos sitä hyödynnetään? Pisteet 0–10.	FIRST (standardi); NVD ja toimittajat julkaisevat pisteet
EPSS	Kuinka todennäköistä hyödyntäminen on seuraavien 30 päivän aikana? Todennäköisyys 0–1.	FIRST, päivittyy päivittäin, maksuton
CISA KEV	Hyödynnetäänkö sitä jo todellisissa hyökkäyksissä?	CISA:n Known Exploited Vulnerabilities -luettelo
SSVC	Kun huomioidaan hyödyntäminen, vaikutus ja tehtäväsi, mitä sinun pitäisi tehdä: seurata, tarkastella vai toimia?	CERT/CC:n ja CISA:n päätöspuut
Oma kontekstisi	Toimitetaanko haavoittuva versio? Onko se altistettu? Kuinka tärkeä tuote on? Onko korjausta?	Inventaariosi, arkkitehtuurisi ja omaisuusrekisterisi

Julkiset signaalit kuvaavat haavoittuvuutta. Vain oma kontekstisi kuvaa riskiäsi, ja juuri sen useimmat tiimit saavat epäluotettavimmasta lähteestä.

Käytännöllinen priorisointimenetelmä

Useimmat ohjelmat päätyvät jonkinlaiseen versioon näistä tasoista. Aseta aikataulut sen mukaan, mitä käytäntösi ja asiakkaasi vaativat.

1. Korjaa heti: tunnetusti hyödynnetty, toimittamassasi ohjelmistossa. Kaikki KEV-listalla olevat tai muuten näytön mukaan hyödynnetyt haavoittuvuudet, jotka ovat julkaistussa buildissa. Vertailun vuoksi: CISA:n BOD 26-04 antaa Yhdysvaltain liittovaltion virastoille vain 3 päivää KEV-merkinnälle julkisesti altistetussa järjestelmässä.
2. Korjaa seuraavaksi: todennäköisesti hyödynnettävä ja vakava. Korkea EPSS-pistemäärä yhdistettynä korkeaan tai kriittiseen CVSS:ään toimitetussa ja altistetussa komponentissa. Valitse EPSS-kynnys, jolla jono pysyy sellaisena, että tiimisi oikeasti ehtii purkaa sen.
3. Korjaa rutiinisti: kaikki muu, mikä toimitetaan. Kokoa ne säännöllisiin riippuvuuspäivityksiin sen sijaan, että käsittelisit jokaista löydöstä poikkeamana.
4. Dokumentoi: ei vaikutusta. Haavoittuva paketti on mukana, mutta haavoittuvaa koodia ei käytetä, tai komponenttia ei toimiteta. Kirjaa perustelut VEX-lausuntona, jotta sama löydös ei palaa tarkasteltavaksi ja jotta kysyvät asiakkaat näkevät syyn.

Järjestä sitten jatkuvasti uudelleen. Tasolla kolme ollut haavoittuvuus voi siirtyä tasolle yksi yhdessä yössä, kun se lisätään KEV-luetteloon tai sen EPSS-pistemäärä nousee jyrkästi.

Haavoittuvuudet, joita et koskaan pääse priorisoimaan

Jokainen priorisointimenetelmä järjestää edessään olevat löydökset. Haavoittuva paketti, jota skanneri ei koskaan nähnyt, ei tuota löydöstä, joten se ei koskaan saa CVSS-pisteitä, EPSS-pisteitä eikä KEV-osumaa. Sitä ei priorisoida alas. Sitä ei priorisoida lainkaan, ja se toimitetaan silti.

Näin käy useammin kuin uskoisi, koska useimmat skannerit päättelevät ohjelmistosi sisällön tiedostoista: lukitustiedostosta, manifesteista tai buildin tuotoksesta. Kaikki, mitä buildi hakee mutta mikään lukitustiedosto ei luettele, on piilotettu riippuvuus, ja tiedostoihin perustuvat työkalut ohittavat sen:

• Asennuskoukut. npm:n preinstall- ja postinstall-skriptien lataama koodi, reitti, jota Shai-Hulud-mato käytti.
• Build-skriptit. Esimerkiksi Rustin build-skriptit, jotka lataavat koodia buildin aikana.
• Pohjakuvat. Konttibuildin pohjakuva ja sen käyttöjärjestelmäkerrokset.
• Välimuistit. CI-välimuistista palautetut paketit, joita ei asennettu lukitustiedostosta.

Tuotoksen skannaaminen jälkikäteen ei sulje aukkoa. Valmis binääri, varsinkin käännetty koodi kuten Rust, jättää skannerin arvailemaan, mitä siihen meni. Ja koska buildit eivät oletuksena ole toistettavia, saman commitin buildaaminen myöhemmin uudelleen ei takaa samoja riippuvuuksia.

Buildin aikana tallennettu SBOM lähtee liikkeelle toisesta päästä. CRACI ajaa GitHub Actions -jobisi ja näkee jokaiseen buildiin tulevan liikenteen, joten se tallentaa jokaisen paketin, jonka jobi todella haki, piilotetut riippuvuudet mukaan lukien. Jokaisessa SBOM:ssa on kattavuustila, joka kertoo, milloin jotain ei voitu nähdä. Käytännössä CRACI on löytänyt haavoittuvia paketteja, joita Snyk ja Aikido eivät raportoineet, koska niiden skannauksista puuttuivat kyseiset komponentit. Juuri näitä löydöksiä priorisointimenetelmä ei koskaan pääse järjestämään.

Konteksti: osa, jota skannerit eivät voi pisteyttää puolestasi

Toimitetaanko haavoittuva versio todella?

Tämä kysymys poistaa eniten kohinaa. Testikehys lukitustiedostossa, paketti, joka on kiinnitetty haarassa, josta ei koskaan julkaista, konttivaihe, joka heitetään pois: mikään niistä ei päädy asiakkaille. Buildin aikana tallennettu SBOM vastaa kysymykseen sen perusteella, mitä julkaisubuildi todella käytti, eikä sen perusteella, mitä repositorio ilmoittaa.

Mitkä julkaisut sisältävät sen, ja mistä lähtien?

Löydös tuotteessa, jota toimitat asiakkaille ja jonka jokainen julkaisu viime keväästä lähtien on altistunut, menee saman löydöksen edelle sisäisessä työkalussa. Altistusjakson tunteminen kertoo myös, mitä sinun on julkistettava.

Voidaanko haavoittuvaan koodiin päästä?

Reachability-analyysi (reachability analysis) selvittää, voiko koodisi kutsua riippuvuuden haavoittuvaa funktiota. Useat SCA-työkalut tarjoavat sitä, ja se siirtää tehokkaasti saavuttamattomat löydökset listan loppupäähän. Pidä sitä yhtenä syötteenä: se näkee vain koodipolut, joita analyysi pystyy seuraamaan, eikä saavutettava funktio ole sama asia kuin hyödynnettävä.

Onko se altistettu, ja onko korjausta?

Internetiin näkyvä palvelu menee yksityisverkossa ajettavan eräajon edelle. Haavoittuvuus, johon on korjattu versio, on halvempi sulkea kuin sellainen, joka vaatii lievennyskeinon. Molemmat muuttavat järjestystä, eivät sitä, käsitelläänkö asia.

Riskiperusteinen haavoittuvuuksien hallinta

Riskiperusteinen haavoittuvuuksien hallinta on saman ajatuksen nimi ohjelman tasolla: järjestä hyödyntämisnäytön, todennäköisyyden, vakavuuden ja liiketoimintakontekstin mukaan, mittaa, kuinka nopeasti riskialttiimmat löydökset suljetaan, ja hyväksy, että vähäriskiset löydökset voivat jäädä avoimiksi. Mittarit muuttuvat samalla. Avoimien haavoittuvuuksien kokonaismäärän sijaan seuraa, kuinka monta tunnetusti hyödynnettyä haavoittuvuutta on avoinna toimitetussa ohjelmistossa ja kuinka kauan ne pysyvät avoimina.

Haavoittuvuuksien priorisointityökalut

Kolmenlaiset työkalut tekevät nykyään suurimman osan järjestämisestä:

• Infrastruktuurin haavoittuvuuksien hallinta-alustat, kuten Tenable, Qualys ja Rapid7, pisteyttävät palvelimia, päätelaitteita ja pilviresursseja omilla riskiluokituksillaan, jotka perustuvat hyödyntämistietoon.
• SCA- ja sovellustietoturvatyökalut, kuten Snyk, Endor Labs ja Semgrep, järjestävät riippuvuuslöydöksiä, ja useat niistä reachability-analyysin avulla.
• Avoimen lähdekoodin työkalut, kuten Grype, joka raportoi EPSS- ja KEV-tiedot löydöstensä mukana, ja Dependency-Track, joka analysoi SBOM:eja jatkuvasti.

Haavoittuvuuksien hallintatyökalut vertailussa käy ne läpi yksi kerrallaan.

Miten CRACI tukee priorisointia

CRACI aloittaa sieltä, missä järjestys useimmiten menee pieleen: inventaariosta. Se ajaa GitHub Actions -jobisi ja tallentaa paketit, jotka kukin jobi todella haki, mukaan lukien transitiiviset riippuvuudet, välimuisteista palautetut paketit ja piilotetut riippuvuudet, joita mikään lukitustiedosto ei luettele.

• Löydökset siitä, mitä toimitettiin. Seurattavat SBOM:t arvioidaan jatkuvasti uudelleen, ja organisaatiotason näkymät kokoavat löydökset buildien ja repositorioiden yli. Jokainen paketti näyttää tietoturvatiedotteensa vakavuuksineen sekä paketit, jotka tuovat sen mukanaan.
• Altistusjakso. Buildihistoria näyttää, mitkä aiemmat buildit sisälsivät haavoittuvan riippuvuuden, suoran tai transitiivisen, joten tiedät, mihin julkaisuihin se vaikutti ja kuinka kauan.
• Triage ja ohjaus. Tietoturvatiimit tekevät löydösten triagen (luokittelun ja priorisoinnin) ja ohjaavat kunkin löydöksen tiimille, joka omistaa korjauksen. CRACI tukee VEX:iä sen kirjaamiseen, ettei haavoittuvuus koske tuotettasi.
• Portit. Käytäntöportit voivat estää buildin löydösten perusteella, myös buildin, joka sisältää tietyn CVE:n.

CRACI ei tarjoa reachability-analyysiä. Jos tarvitset eniten juuri sitä signaalia, valitse jokin sitä tarjoavista SCA-työkaluista. Koko ominaisuus on kuvattu sivulla haavoittuvuuksien seuranta.

Haavoittuvuuksien priorisointi: usein kysytyt kysymykset

Mitä haavoittuvuuksien priorisointi on?

Haavoittuvuuksien priorisointi on sen päättämistä, mitkä tunnetut haavoittuvuudet korjataan ensin, mitkä voivat odottaa ja mitkä eivät koske sinua lainkaan. Se järjestää löydökset sen mukaan, kuinka todennäköisesti niitä hyödynnetään ja kuinka paljon vahinkoa se aiheuttaisi ympäristössäsi, eikä pelkän vakavuuden mukaan.

Miten haavoittuvuuksia priorisoidaan?

Aloita tarkasta inventaariosta, jotta järjestät haavoittuvuuksia ohjelmistossa, joka todella toimitetaan. Nosta ensimmäiseksi kaikki CISA:n Known Exploited Vulnerabilities -luettelossa olevat, ja järjestä loput hyödyntämisen todennäköisyyden (EPSS) ja vakavuuden (CVSS) mukaan kontekstisi perusteella mukautettuna: altistus, tuotteen tärkeys ja se, onko korjausta. Kirjaa ne, jotka eivät koske sinua, VEX-lausuntoina.

Riittääkö CVSS haavoittuvuuksien priorisointiin?

Ei. CVSS mittaa, kuinka vakava haavoittuvuus on, ei sitä, kuinka todennäköisesti sitä hyödynnetään tai kuinka paljon sillä on sinulle merkitystä. Pelkästään CVSS:n mukaan järjestäminen merkitsee suuren osan backlogista korkeaksi tai kriittiseksi, eikä useimpia näistä haavoittuvuuksista koskaan hyödynnetä.

Mitä riskiperusteinen haavoittuvuuksien hallinta on?

Riskiperusteinen haavoittuvuuksien hallinta järjestää ja korjaa haavoittuvuudet sen riskin mukaan, jonka ne aiheuttavat organisaatiollesi, yhdistäen hyödyntämisnäytön, todennäköisyyden, vakavuuden ja liiketoimintakontekstin sen sijaan, että ne käytäisiin läpi CVSS-pisteiden tai iän mukaan.

Mitä eroa on EPSS:llä ja KEV:llä?

EPSS on ennuste: arvioitu todennäköisyys sille, että CVE:tä hyödynnetään seuraavien 30 päivän aikana. KEV on kirjaus: CISA:n luettelo haavoittuvuuksista, joiden hyödyntämisestä todellisissa hyökkäyksissä on näyttöä. KEV-merkintä on tosiasia; EPSS-pistemäärä on todennäköisyys. Käytä ensin KEV:iä ja järjestä kaikki muu EPSS:n avulla.

Korvaako reachability-analyysi priorisoinnin?

Ei, se on yksi syöte lisää. Reachability-analyysi tarkistaa, voiko koodisi kutsua riippuvuuden haavoittuvaa funktiota. Se poistaa löydökset, joita ei voi laukaista, mutta se ei kerro mitään hyödyntämisen todennäköisyydestä, ja se kattaa vain koodin, jota analyysi pystyy seuraamaan.