Haavoittuvuuksien automaattinen korjaus löydöksestä korjaukseen

Mitä haavoittuvuuksien automaattinen korjaus tarkoittaa

Haavoittuvuuksien korjaaminen tarkoittaa tunnetun haavoittuvuuden poistamista ohjelmistostasi: haavoittuvan paketin päivittämistä, paikkauksen asentamista tai komponentin vaihtamista. Automaattinen korjaus antaa työn mekaanisen osan ohjelmiston hoidettavaksi. Se lukee löydöksen, selvittää, mikä versio korjaa sen, muuttaa manifestia, lukitustiedostoa (lockfile) tai koodia ja ehdottaa muutosta, useimmiten pull requestina.

Kolmansien osapuolten riippuvuuksissa, joissa suurin osa nykyaikaisen koodikannan tunnetuista haavoittuvuuksista on, silmukka näyttää samalta kaikissa työkaluissa:

1. Inventaario. Tiedä, mitkä paketit missäkin versioissa ovat kussakin toimittamassasi tuotteessa.
2. Täsmäytys. Tarkista inventaario tietoturvatiedotteita vasten, ja jatka tarkistamista, kun uusia julkaistaan.
3. Priorisointi. Päätä, mikä korjataan ensin, vakavuuden, hyödyntämisen ja altistumisen perusteella.
4. Korjaus. Valitse korjattu versio, päivitä se ja mukauta koodi, jos päivitys rikkoo jotain.
5. Varmistus. Buildaa ja testaa muutos ja varmista sitten, että korjattu versio on se, joka todella toimitettiin.
6. Kirjaus. Pidä kirjaa siitä, mihin haavoittuvuus vaikutti, milloin se korjattiin ja missä julkaisussa.

Automaatio on vahvimmillaan vaiheissa 2, 4 ja 6, joissa työ on toistuvaa. Heikoimmillaan se on silloin, kun syötteet ovat väärin, ja kaiken muun syöte on vaihe 1.

Neljä automaattisen korjauksen tyyppiä

Lähestymistapa	Mitä se tekee	Esimerkkejä	Missä se pysähtyy
Riippuvuuksien päivitysbotit	Avaavat pull requesteja, jotka nostavat haavoittuvan riippuvuuden korjattuun versioon	Dependabot security updates, Renovate	Toimivat repositorion manifestien ja lukitustiedostojen pohjalta; rikkova päivitys vaatii silti ihmisen mukauttamaan koodia
SCA-työkalujen korjaus-PR:t	Avaavat päivitys-PR:iä kaupallisen SCA-työkalun löydöksistä	Snyk, Black Duck, Aikido, Endor Labs	Kattavuus vaihtelee: osa työkaluista korjaa vain suorat riippuvuudet, osa lisää paikkauksia tai backportteja
Tekoälyn koodikorjaukset	Generoivat löydökselle koodimuutoksen, usein staattisen analyysin hälytykselle	GitHub Copilot Autofix	Epädeterministisiä ehdotuksia, jotka on tarkistettava; katso tekoälyavusteinen korjaus
Infrastruktuurin automaattinen korjaus	Peruu virheellisen konfiguraation tai paikkaa palvelimen, kun sääntö laukeaa	Pilven tietoturvatilan ja päätelaitteiden työkalut	Kattaa käynnissä olevan infrastruktuurin, ei toimittamasi ohjelmiston sisäisiä riippuvuuksia

Kolme ensimmäistä korjaavat kaikki toimittamaasi koodia, ja niillä kaikilla on yksi yhteinen oletus: että lista haavoittuvista paketeista, joita ne korjaavat, on oikea lista.

Jokainen korjaus nojaa inventaarioon

Korjaustyökalu voi korjata vain haavoittuvuudet, joista se tietää, ja se tietää niistä, jotka sen inventaariossa ovat. Useimmat inventaariot kootaan jälkikäteen tiedostoista: manifesteista, lukitustiedostoista, asennetuista paketeista tai valmiista konttikuvasta. Tällainen kokoaminen ohittaa asioita ennustettavilla tavoilla.

• Paketit, joita tiedostot eivät ilmoita. Buildin lataamat työkalut, peruskuvat, lisäosat ja kaikki skriptin asentama eivät koskaan näy lukitustiedostossa, joten niille ei koskaan avata korjaus-PR:ää.
• Versiot, jotka eroavat lukitustiedostosta. Buildi voi ratkaista eri version kuin sen, jonka skanneri lukee, etenkin jos lukitustiedostoa ei ole tallennettu versionhallintaan. Väärään versioon perustuva korjaus on itsevarma väärä vastaus.
• Välimuistista palautetut paketit. Välimuistissa oleva riippuvuus ei enää käy rekisterissä, joten se, mitä buildi käytti, voi laahata jäljessä siitä, mitä repositorio sanoo.

Ratkaisu on lähteä liikkeelle siitä, mitä buildi todella käytti. Buildin aikana tallennettu SBOM kirjataan buildin ajon aikana, joten se luettelee paketit, jotka jobi haki, transitiiviset mukaan lukien, eikä sitä, mitä manifestin mukaan pitäisi tarvita. Korjaus, joka lähtee siitä, korjaa sen, mikä toimitetaan.

Mitä automatisoida ja mitä pitää itsellä

Useimmat tiimit, joilla korjaaminen toimii, jakavat sen näin:

• Automatisoi löytäminen ja täsmäytys. Uusia tietoturvatiedotteita julkaistaan joka päivä. Jokaisen toimitetun buildin tarkistaminen niitä vasten käsin ei skaalaudu, ja juuri tällaisessa työssä ohjelmisto on hyvä.
• Automatisoi ehdotus. Korjatun version valitseminen ja muutoksen avaaminen on mekaanista. Ryhmittele toisiinsa liittyvät päivitykset, jotta tarkastajat näkevät yhden pull requestin kahdenkymmenen sijaan.
• Ehdollista yhdistäminen testeillä. Yhdistä automaattisesti patch-tason tietoturvapäivitykset, jotka testisarja kattaa. Jätä rikkovat päivitykset ja kaikki testikattavuutta vailla oleva ihmiselle.
• Jätä harkintaa vaativat ratkaisut ihmisille. Se, vaikuttaako haavoittuvuus tuotteeseesi lainkaan, ja se, kannattaako riskialtis päivitys tehdä tällä viikolla, ovat päätöksiä. Kirjaa ne, esimerkiksi VEX-lausuntona, jotta samaa kysymystä ei kysytä kahdesti.

Miten arvioida korjaustyökalua

Ennen kuin luotat työkaluun, joka avaa pull requesteja repositorioihisi, kysy:

1. Mistä sen haavoittuvuuslista tulee: repositorion tiedostoista, skannatusta kuvasta vai itse buildista?
2. Korjaako se transitiiviset riippuvuudet vai vain ilmoittamasi suorat riippuvuudet?
3. Miten se valitsee korjatun version: pienin paikattu versio, uusin vai kiinnittämäsi versio?
4. Buildataanko ja testataanko korjaus ennen kuin näet sen, vai ajetaanko se ensimmäistä kertaa pull requestissa?
5. Voiko se ryhmitellä ja ajastaa päivitykset, jotta tarkastajat eivät huku niihin?
6. Kirjaako se, mihin julkaisuihin haavoittuvuus vaikutti ja milloin kukin korjaus toimitettiin?

Missä CRACI on mukana tänään

CRACI ajaa GitHub Actions -jobisi omilla runnereillaan ja tallentaa paketit, jotka kukin jobi todella haki, transitiiviset riippuvuudet ja välimuistista palautetut paketit mukaan lukien, ja jokaiselle jobille kattavuustilan. Tämä kirjaus on inventaario, josta korjaustyönkulun pitäisi lähteä liikkeelle.

CRACI arvioi seuratut SBOM:t jatkuvasti uudelleen, joten kun uusi tietoturvatiedote julkaistaan, näet, mihin toimitettuihin buildeihin se vaikuttaa kaikissa repositorioissasi. Tietoturvatiimit luokittelevat jokaisen löydöksen ja lähettävät sen korjauksesta vastaavalle tiimille, ja CRACI tukee VEX:iä sen kirjaamiseen, miten haavoittuvuus vaikuttaa tuotteeseesi. Seuraavan buildin SBOM näyttää sitten, onko korjattu versio se, jota buildi todella käytti. Sivu haavoittuvuuksien seuranta kertoo koko ominaisuudesta.

EU:n kyberkestävyyssäädöksen (Cyber Resilience Act, CRA) mukaan valmistajien on käsiteltävä ja korjattava haavoittuvuudet viipymättä, myös tietoturvapäivitysten avulla. Kirjaus siitä, mitä kukin buildi sisälsi ja milloin kukin korjaus toimitettiin, on näyttö, jota tämä prosessi tarvitsee.

Haavoittuvuuksien automaattinen korjaus: usein kysytyt kysymykset

Mitä on haavoittuvuuksien automaattinen korjaus?

Haavoittuvuuksien automaattinen korjaus on ohjelmisto, joka tekee haavoittuvuuslöydöksestä korjauksen ilman, että ihmisen tarvitsee tehdä taustatyötä: se selvittää korjatun version, muuttaa manifestia, lukitustiedostoa tai koodia ja ehdottaa muutosta, yleensä pull requestina. Ihminen tai tiimin luottama käytäntö päättää silti, mitä yhdistetään.

Mitä eroa on haavoittuvuuden korjaamisella ja lieventämisellä?

Korjaaminen poistaa haavoittuvuuden, esimerkiksi päivittämällä korjattuun versioon tai asentamalla paikkauksen. Lieventäminen pienentää riskiä, kun haavoittuvuus on vielä olemassa, esimerkiksi poistamalla haavoittuvan ominaisuuden käytöstä tai estämällä hyökkäyspolun. Lieventäminen antaa lisäaikaa, korjaaminen sulkee löydöksen.

Voiko haavoittuvuuksien korjaamisen automatisoida kokonaan?

Osittain. Haavoittuvien buildien löytäminen, tietoturvatiedotteiden täsmäyttäminen ja versionnoston ehdottaminen ovat mekaanisia ja automatisoituvat hyvin. Sen päättäminen, onko rikkova päivitys turvallinen tai vaikuttaako haavoittuvuus tuotteeseesi lainkaan, vaatii yhä harkintaa. Useimmat tiimit automatisoivat ehdotuksen ja jättävät yhdistämisen ihmiselle, jota testit tukevat.

Korjaako Dependabot haavoittuvuuksia automaattisesti?

Dependabot security updates avaa pull requesteja, jotka päivittävät haavoittuvan riippuvuuden pienimpään paikattuun versioon niistä hälytyksistä, joita GitHub nostaa repositoriosi riippuvuusgraafista. Se on automaattista korjausta sille, mitä manifestit ja lukitustiedostot ilmoittavat. CRACI vs. Dependabot kertoo, missä ilmoitettu ja toimitettu eroavat.

Mitä haavoittuvuuksien korjaustyökalulta kannattaa vaatia?

Sitä, mistä sen haavoittuvuuslista tulee, käsitteleekö se transitiiviset riippuvuudet, miten se valitsee korjausversion, buildataanko ja testataanko korjaus ennen kuin näet sen ja kirjaako se, mitä korjattiin ja milloin. Viimeinen on tärkeä auditoinneille ja CRA:lle, joka edellyttää valmistajien korjaavan haavoittuvuudet viipymättä.