CVE:iden korjaus: tietoturvatiedotteesta korjattuun, toimitettuun buildiin

CVE:n korjausprosessi

CVE:n korjaaminen poistaa julkisesti ilmoitetun haavoittuvuuden ohjelmistosta, jota käytät tai toimitat. Omassa koodissasi se tarkoittaa paikkausta. Avoimen lähdekoodin riippuvuuksissa, joista useimmat tyypillisen tuotteen CVE:t ovat peräisin, se tarkoittaa siirtymistä versioon, jossa haavoittuvuus on korjattu. Kummassakin tapauksessa vaiheet ovat samat:

1. Löydä jokainen tuote, buildi ja julkaisu, joka sisältää kyseisen paketin ja version.
2. Arvioi, koskeeko haavoittuvuus sinua ja kuinka vakavasti.
3. Priorisoi suhteessa kaikkeen muuhun avoimeen.
4. Korjaa päivittämällä, paikkaamalla, korvaamalla tai, jos korjausta ei ole, lieventämällä.
5. Varmista, että korjattu versio on se, jonka uusi buildi todella sisältää.
6. Kirjaa, mitä asia koski, mitä päätit ja milloin korjaus toimitettiin.

Vaihe 1: löydä jokainen buildi, jota asia koskee

Ensimmäinen kysymys tietoturvatiedotteen jälkeen on, missä paketti on. Siihen vastaaminen lähdekoodirepositorioista on hidasta, ja vastaus on usein väärä: lukitustiedoston versio, buildin ratkaisema versio ja julkaistun konttikuvan versio voivat kaikki poiketa toisistaan. Transitiiviset riippuvuudet ja paketit, jotka buildi lataa paketinhallinnan ohi, eivät näy manifesteissa lainkaan.

Luotettava vastaus saadaan kunkin julkaisun SBOM:sta, jota verrataan tietoturvatiedotteisiin jatkuvasti. Jos tuo SBOM on tallennettu buildin aikana, se listaa sen, mitä buildi todella käytti, joten vertailu kertoo, mitkä toimitetut buildit sisältävät haavoittuvan version, eikä vain sitä, missä repositorioissa se mainitaan.

Vaihe 2: priorisoi vakavuuden ja hyödyntämisen perusteella

Pelkkä vakavuus nostaa liian monta haavoittuvuutta kiireellisiksi. Useimmat tiimit yhdistävät kolme signaalia:

Signaali	Mitä se kertoo	Julkaisija
CVSS	Kuinka vakava haavoittuvuus on, jos sitä hyödynnetään, asteikolla 0–10	FIRST (standardi); NVD ja toimittajat julkaisevat pisteitä
EPSS	Arvioitu todennäköisyys hyödyntämiselle seuraavan 30 päivän aikana	FIRST
KEV	Tiedetäänkö haavoittuvuutta hyödynnettävän todellisissa hyökkäyksissä	CISA:n Known Exploited Vulnerabilities -luettelo

Lisää sitten oma kontekstisi: toimitetaanko kyseinen paketti asiakkaille vai ajetaanko sitä vain testijobissa, ja käytetäänkö haavoittuvaa funktiota ylipäätään. Tunnetusti hyödynnetty haavoittuvuus toimitettavassa paketissa nousee listan kärkeen. Haavoittuvuuksien priorisointi tekee näistä signaaleista menetelmän.

Korjausten aikataulut

• CISA BOD 26-04. 10.6.2026 alkaen Yhdysvaltain liittovaltion virastot määrittävät kunkin määräajan neljän kysymyksen perusteella: onko kohde julkisesti näkyvissä, onko haavoittuvuus KEV-luettelossa, voiko hyödyntämisen automatisoida, ja antaako se osittaisen vai täydellisen hallinnan. Vastaukset vaihtelevat 3 päivästä, pahimmissa tapauksissa forensisen triagen kanssa, korjaamiseen seuraavan järjestelmäpäivityksen yhteydessä. Se korvasi BOD 22-01:n, joka antoi kaksi viikkoa useimmille KEV- merkinnöille.
• EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA). Valmistajien on käsiteltävä ja korjattava haavoittuvuudet viipymättä, myös tietoturvapäivitysten avulla (liite I, osa II). 11.9.2026 alkaen tuotteen aktiivisesti hyödynnetty haavoittuvuus käynnistää myös raportointiajan: ennakkovaroitus 24 tunnin kuluessa, ilmoitus 72 tunnin kuluessa ja loppuraportti 14 päivän kuluessa siitä, kun korjaus on saatavilla.
• Oma käytäntösi. Useimmat tietoturvaohjelmat asettavat sisäiset tavoitteet vakavuuden mukaan. Olivatpa ne mitä tahansa, voit saavuttaa ne vain, jos vaihe 1 on nopea.

Vaihe 3: valitse korjaus

Vaihtoehto	Milloin sitä käytetään
Päivitä	Korjattu versio on olemassa. Suosi pienintä päivitystä, joka sisältää korjauksen, jotta rikkovia muutoksia on vähemmän.
Päivitä ylempi riippuvuus	Haavoittuva paketti on transitiivinen. Suoran riippuvuuden uudempi julkaisu tuo usein korjauksen mukanaan.
Pakota versio	Ylempi riippuvuus ei ole julkaissut korjausta. Pakota transitiivinen versio npm:n overrides-, Yarnin resolutions- tai pnpm.overrides-asetuksella ja testaa se.
Paikkaa tai takaporttaa	Et voi vielä siirtyä korjattuun pääversioon. Tuo upstream-korjaus käyttämääsi versioon.
Korvaa	Pakettia ei ylläpidetä tai siitä löytyy jatkuvasti CVE:itä. Siirry vaihtoehtoon.
Lievennä ja dokumentoi	Korjausta ei vielä ole, tai haavoittuvuus ei koske tuotettasi. Vähennä altistusta ja kirjaa arvio, esimerkiksi VEX-lausuntona.

Suurimman osan tästä vaiheesta voi automatisoida version valinnasta pull requestin avaamiseen. Automatisoitu haavoittuvuuksien korjaus kertoo, mitä kannattaa automatisoida ja mitä jättää ihmiselle.

Vaihe 4: yhdistetty korjaus ei ole toimitettu korjaus

Pull request yhdistettiin, joten CVE on suljettu. Ei välttämättä. Korjaus on repositoriossa, mutta buildi palauttaa vanhentuneen välimuistin, peruskuva sisältää yhä vanhan paketin, tai julkaisuhaara ei koskaan saanut muutosta. Tiketin mukaan asia on korjattu, vaikka tuote toimittaa yhä haavoittuvaa versiota.

Sulje silmukka toisesta päästä: tarkista seuraavan buildin SBOM ja varmista, että haavoittuva versio on poissa. Kun tuo SBOM tallentaa sen, mitä buildi todella haki, myös välimuisteista palautetut paketit, tarkistus vastaa kysymykseen, jota asiakas, auditoija ja viranomainen todella kysyvät.

Miten CRACI tukee CVE:iden korjaamista

• Löydä. CRACI tallentaa paketit, jotka kukin GitHub Actions -jobi haki, mukaan lukien transitiiviset riippuvuudet ja välimuisteista palautetut paketit, ja arvioi valvotut SBOM:t jatkuvasti uudelleen. Organisaationäkymät kokoavat löydökset buildien ja repositorioiden yli, joten näet, mitä buildeja uusi CVE koskee.
• Osoita. Tietoturvatiimit tekevät jokaiselle löydökselle triagen ja ohjaavat sen korjauksesta vastaavalle tiimille. CRACI tukee VEX:iä sen kirjaamiseen, miten haavoittuvuus vaikuttaa tuotteeseesi.
• Varmista. Jokainen uusi buildi saa oman SBOM:nsa kattavuustilan kanssa, joten voit varmistaa, että korjattu versio on se, jota buildi käytti.
• Raportoi. CRA:n alaisista aktiivisesti hyödynnetyistä haavoittuvuuksista CRACI valmistelee ilmoitusten sisällön, ja valmistajan henkilö toimittaa ne keskitetyn raportointialustan (Single Reporting Platform) kautta.

Koko ominaisuuden kuvauksen löydät sivulta haavoittuvuuksien seuranta.

CVE:iden korjaus: usein kysytyt kysymykset

Mitä CVE:n korjaaminen on?

CVE:n korjaaminen tarkoittaa julkisesti ilmoitetun, CVE-tunnisteella yksilöidyn haavoittuvuuden poistamista ohjelmistosta, jota käytät tai toimitat. Riippuvuudessa se tarkoittaa yleensä päivittämistä versioon, jossa haavoittuvuus on korjattu. Omassa koodissasi se tarkoittaa paikkausta.

Miten priorisoin, mitkä CVE:t korjataan ensin?

Yhdistä vakavuus näyttöön hyödyntämisestä. CVSS kuvaa, kuinka paha haavoittuvuus on, EPSS arvioi, kuinka todennäköisesti sitä hyödynnetään seuraavan 30 päivän aikana, ja CISA:n Known Exploited Vulnerabilities -luettelo listaa ne, joita jo hyödynnetään. Tunnetusti hyödynnetty haavoittuvuus toimittamassasi paketissa nousee kärkeen.

Kuinka nopeasti CVE:t on korjattava?

Se riippuu siitä, kuka kysyy. CISA:n Binding Operational Directive 26-04 antaa Yhdysvaltain liittovaltion virastoille aikaa 3 päivästä seuraavaan järjestelmäpäivitykseen sen mukaan, onko haavoittuvuus KEV-luettelossa, onko kohde julkisesti näkyvissä, voiko hyödyntämisen automatisoida ja kuinka paljon hallintaa se antaa hyökkääjälle. EU:n kyberkestävyyssäädös edellyttää, että valmistajat korjaavat haavoittuvuudet viipymättä, ja 11.9.2026 alkaen tuotteen aktiivisesti hyödynnetty haavoittuvuus käynnistää 24 tunnin raportointiajan.

Entä jos korjattua versiota ei vielä ole?

Lievennä ja dokumentoi. Poista kyseinen ominaisuus käytöstä, estä hyökkäyspolku tai vaihda komponentti, jos voit, ja kirjaa arviosi, esimerkiksi VEX-lausuntona. Seuraa sitten korjattua julkaisua ja korjaa, kun se tulee.

Miten korjaan CVE:n transitiivisessa riippuvuudessa?

Kokeile ensin päivittää suora riippuvuus, joka tuo sen mukanaan, koska uudempi julkaisu sisältää usein korjauksen. Jos sellaista ei vielä ole, useimmat paketinhallintatyökalut antavat pakottaa transitiivisen paketin version: overrides npm:ssä, resolutions Yarnissa, pnpm.overrides pnpm:ssä. Testaa tulos, koska ylempää pakettia ei ole rakennettu sitä versiota vasten.