Näin hallitset kasvavia CVE-määriä, kun tiimisi on pieni

Mikä muuttui: CVE-luvut

Alla olevat luvut tulevat CVE-ohjelman omista tietueista, ja ne päivitetään joka päivä sivullamme CVE-julkaisujen trendit. Tilannekuva otettu 12.11.2026 UTC:

• 47 801 tietuetta julkaistiin vuonna 2025, 20 % enemmän kuin edellisenä vuonna.
• 95 494 tietuetta on julkaistu tähän mennessä vuonna 2026, 303 päivässä, +131 % verrattuna vuoden 2025 päivätahtiin.
• 155 päivässä on luokiteltu tasolle High tai Critical.
• 17 % kaikista tietueista vuodesta 2020 lähtien on ilman CVSS-pistemäärää, sekä tunnisteen myöntäjän että CISAn täydennysten osalta. Kattavuus on parantunut: vuonna 2026 osuus on 6 %.
• 505 organisaatiota myönsi nämä tietueet, ja 20 suurinta vastaa niistä 75 %.

• High tai Critical
• Muut vakavuustasot ja pisteyttämättömät

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

Kunakin vuonna julkaistujen tietueiden päivittäinen keskiarvo; * merkitsee kuluvaa vuotta tähän päivään asti. Lähde: CVE-ohjelman cvelistV5-tietueet, tilannekuva 12.11.2026 UTC. Suodata kuukauden, vakavuuden ja myöntäjän mukaan: CVE-julkaisujen trendit.

Kyse ei ole yhdestä huonosta neljänneksestä. Määrä on kasvanut joka vuosi vuodesta 2020, ja useat rakenteelliset muutokset pitävät sen kasvussa:

• Enemmän myöntäjiä, jotka myöntävät laajemmin. Linux-ytimen projektista tuli CVE Numbering Authority helmikuussa 2024. Sen dokumentoidun käytännön mukaan CVE myönnetään jokaiselle virhekorjaukselle, joka saattaa olla haavoittuvuus, kun korjaus päätyy vakaaseen ytimeen, koska hyödynnettävyys ei usein ole selvää korjauksen tullessa. Pelkästään ytimen CNA on julkaissut sen jälkeen 18 221 tietuetta.
• Tekoälyavusteinen löytäminen. Marraskuussa 2024 Googlen Project Zero ja DeepMind raportoivat, että niiden Big Sleep -agentti oli löytänyt SQLitestä hyödynnettävän muistiturvallisuusvirheen ennen kuin se päätyi julkaisuun, ja ne uskovat sen olleen ensimmäinen julkinen esimerkki siitä, että tekoälyagentti teki näin laajasti käytetyssä ohjelmistossa. Tällaiset työkalut kasvattavat sitä, kuinka paljon yksi tutkija voi löytää.
• NVD ei enää pysty täydentämään kaikkea. NISTin mukaan National Vulnerability Databaseen kertyi vuoden 2024 alusta lähtien jonoa täydentämättömistä CVE:istä, eikä sitä saatu purettua ilmoitusten määrän kasvaessa. Huhtikuussa 2026 se siirtyi riskiperusteiseen malliin: CISAn Known Exploited Vulnerabilities -luettelon CVE:t sekä liittovaltion tai kriittisten ohjelmistojen CVE:t täydennetään ensin, ja loput merkitään sellaisiksi, joiden täydentämistä ei ole aikataulutettu välittömästi. Prosessi, joka nojaa yhden tietokannan tietoihin haavoittuvista tuotteista, joutuu nyt odottamaan tai jää paitsi.
• Vähemmän aikaa reagoida. Mandiant mittasi keskimääräiseksi ajaksi hyödyntämiseen 63 päivää vuosina 2018 ja 2019. Sen M-Trends 2026 -raportti arvioi vuodelle 2025 miinus seitsemän päivää: hyödyntäminen alkaa nyt tavallisesti ennen kuin korjaus julkaistaan.
• Sääntelyn määräajat. EU:n kyberkestävyyssäädöksen (Cyber Resilience Act) mukaan valmistajat ilmoittavat aktiivisesti hyödynnetystä haavoittuvuudesta ennakkovaroituksella 24 tunnin kuluessa, ilmoituksella 72 tunnin kuluessa ja loppuraportilla 14 päivän kuluessa korjauksen saatavuudesta (mitä CRA vaatii). Määräaika on sama kolmen hengen tiimille kuin kolmensadan hengen tiimille.

Mikään tästä ei tarkoita, että ohjelmistot olisivat muuttumassa turvattomammiksi. Se tarkoittaa, että asioiden määrä, joita tiimin on tarkasteltava, kasvaa joka vuosi, mutta tiimi ei kasva.

Mikä pienen tiimin prosessissa pettää

Kasvavat määrät eivät riko haavoittuvuuksien hallintaa siksi, että korjattavia haavoittuvuuksia olisi enemmän. Ne rikkovat sen, koska jokainen käsin tehtävä vaihe toistuu jokaisen CVE:n kohdalla.

Käsin tehtävä vaihe	Miksi se pettää nykyisillä määrillä
Inventaarion kokoaminen käsin	Taulukko tai ennen auditointia tehty SBOM on vanhentunut seuraavan julkaisun jälkeisenä päivänä.
Syötteen lukeminen	Kun High- tai Critical-tietueita tulee 155 päivässä, kukaan ei pysy perässä.
Kysymys kehittäjille: ”käytämmekö X:ää?”	Sama kysymys jokaisesta CVE:stä samoille kiireisille ihmisille. Kysymys on pullonkaula.
Yksi tiketti per CVE per repositorio	Jaetun kirjaston CVE:stä tulee kymmeniä päällekkäisiä tikettejä, jotka hukuttavat työjonon.
Jokaiselle asiakkaalle vastaaminen erikseen	Kyselyt kasvavat asiakaskunnan mukana, eivät haavoittuvuuksien määrän mukana.
Dokumentit PDF:nä tai wikissä	Asiakkaiden työkalut eivät pysty vertaamaan PDF:ää inventaarioonsa, joten jokainen lukija kysyy uudelleen.
Määräajat, jotka eivät jousta	Aika hyödyntämiseen lyhenee, kun taas käsin tehtävä prosessi hidastuu määrien kasvaessa.

Inventaario. Useimmat tiimit, jotka pitävät komponenttiluetteloa käsin, päivittävät sen ennen auditointia tai asiakkaan kyselylomaketta. Näiden välillä se kuvaa ohjelmistoa, jota ei enää toimiteta. Jokainen CVE-kysymys alkaa silloin sen selvittämisellä, mitä julkaisu sisälsi.

Syöte. Tietoturvatiedotteiden lukeminen on vaihe, josta tiimit aloittavat, ja ensimmäinen, joka romahtaa. Kuulemme tiimeistä, jotka tekevät sen yhä käsin, mukaan lukien yksi, jossa haavoittuvuusskannaus tarkoittaa ihmisiä lukemassa CVE-foorumeita. Se toimii siihen päivään asti, kun se ei toimi, eikä siitä päivästä tule mitään merkkiä.

Kysymys kehittäjille. ”Käytämmekö tätä kirjastoa, ja mitä versiota?” keskeyttää kehittäjän jokaisen CVE:n kohdalla, joka saattaa koskea tuotetta. Eräs kahden hengen tuoteturvallisuustiimi kertoi meille, että sen työ on napin painamista pelkästään perässä pysymiseksi, eikä aikaa jää prosessin parantamiseen.

Tiketit. Kun jaetussa kirjastossa on CVE ja jokainen repositorio avaa oman tikettinsä, työjono laskee saman päätöksen monta kertaa. Tiimit oppivat ohittamaan työjonon ja missaavat sitten tiketin, jolla oli merkitystä.

Asiakasvastaukset. Laajasti uutisoidun haavoittuvuuden tai toimitusketjuhyökkäyksen jälkeen asiakkaat kysyvät: ”koskeeko tämä meitä?”. Jokaiselle erikseen vastaaminen vie eniten aikaa juuri sinä päivänä, kun sitä on vähiten.

Dokumentit. PDF-lausunto tai wikisivu vaatii, että ihminen lukee sen asiakkaan päässä. Asiakkaiden skannerit ja yhä useammin myös viranomaiset odottavat SBOM:eja, VEX:iä ja tietoturvatiedotteita muodoissa, joita kone pystyy vertaamaan.

Määräajat. 24 tunnin kuluessa vaadittava ennakkovaroitus tai ennen korjausta ilmestyvä hyödyntäminen ei odota, että jono purkautuu.

Mitä automatisoida, missä järjestyksessä

Jokainen vaihe poistaa työtä seuraavalta, joten järjestys on tärkeämpi kuin työkalujen valinta.

1. Tiedä, mitä toimitat. SBOM jokaisesta buildista tekee kysymyksestä ”koskeeko tämä meitä?” haun.
2. Vertaa jatkuvasti, useampaan kuin yhteen lähteeseen. Uudet CVE:t tarkistetaan jokaista tallennettua SBOM:ia vasten, joten kenenkään ei tarvitse lukea syötettä.
3. Karsi kohina. Löydökset asioista, joita et toimita, ja päällekkäisyydet eivät koskaan päädy ihmiselle.
4. Tee triage puoliautomaattisesti. Tiedot täytetään valmiiksi; ihminen tekee päätöksen.
5. Tee kaikesta koneluettavaa. Jokainen päätös tehdään kerran ja jokainen lukija käyttää sitä uudelleen.
6. Vastaa kerran, julkisesti. Kysely, jota ei koskaan tule, ei maksa mitään.

1. Generoi SBOM jokaisesta buildista automaattisesti

Mitä se korvaa: taulukon ja kysymyksen kehittäjille. Buildin aikana generoitu SBOM kuvaa sitä, mitä buildi todella käytti, ja kun säilytät sellaisen jokaisesta toimitetusta versiosta, pystyt vastaamaan viime vuoden julkaisusta yhtä hyvin kuin main-haarasta. Asiakkaat ajavat vanhoja versioita; inventaariosi on katettava ne.

Vähimmäisversio: CI:ssä generoitu SBOM jokaisesta julkaisubuildista, tallennettuna julkaisuartefaktin viereen. Parempi: SBOM, joka on tallennettu itse buildista eikä päätelty lukitustiedostoista (lockfile) jälkikäteen, jolloin myös paketinhallinnan ohi haetut komponentit ovat siinä mukana (buildin aikana tallennetut SBOM:t, SBOM-automaatio).

Kustannus: päivä tai kaksi putkityötä vähimmäisversiota varten, sen jälkeen ei mitään julkaisua kohden. Merkki siitä, että se toimii: voit luetella minkä tahansa julkaisun komponentit kysymättä keneltäkään.

2. Vertaa jatkuvasti useisiin haavoittuvuuslähteisiin

Mitä se korvaa: syötteen lukemisen. Vertailu on koneen työtä: jokainen uusi CVE jokaista tallennettua SBOM:ia vasten, ei vain juuri ajetun buildin SBOM:ia. Vanha julkaisu, joka oli puhdas toimitushetkellä, on haavoittuvainen sinä päivänä, kun jollekin sen komponentille julkaistaan CVE.

Yksi lähde ei riitä. NVD:n täydennysjono tarkoittaa, että tieto haavoittuvista tuotteista voi tulla myöhässä tai ei lainkaan. Ekosysteemien tietoturvatiedotteet, kuten GitHub Advisory Database ja OSV, ovat usein nopeampia ja kertovat, mitkä pakettiversiot ovat haavoittuvia ekosysteemin omin termein. ENISAn EU Vulnerability Database tuo EU-kontekstin.

Vähimmäisversio: ajastettu jobi, joka skannaa jokaisen tallennetun SBOM:n päivittäin koostettua lähdettä vasten ja raportoi uudet osumat. Merkki siitä, että se toimii: saat tietää julkaisun olevan haavoittuva ennen kuin asiakas kertoo sen sinulle. Katso haavoittuvuuksien seuranta nähdäksesi, miltä tämä näyttää CRACI:ssa.

3. Karsi kohina ennen kuin kukaan katsoo

Mitä se korvaa: merkityksettömien löydösten käsin tehtävän läpikäynnin. Suurin osa kohinasta syntyy jo alkupäässä: inventaarioista, jotka luettelevat asioita, joita et toimita, useista työkaluista, jotka raportoivat saman CVE:n, ja riippuvuuksista, joita kukaan ei tarvitse. Korjaa inventaario, laske jokainen löydös kerran package URLin (PURL), version ja CVE:n perusteella, toimita vähemmän riippuvuuksia, ja lisää sitten hyödynnettävyyskonteksti lähteistä CISA KEV, EPSS ja VEX. Näin vähennät haavoittuvuuskohinaa käy nämä keinot läpi yksi kerrallaan. Merkki siitä, että se toimii: löydökset toimitettua julkaisua kohden vähenevät, ja syyt on kirjattu.

4. Tee triage puoliautomaattisesti

Mitä se korvaa: sen, että ihminen kokoaa tiedot jokaisesta löydöksestä. Jaa työ tarkasti:

• Automaattisesti: vakavuus, tiedetäänkö sitä hyödynnettävän, mitkä tuotteet ja versiot sisältävät komponentin, vastuutiimi, ehdotettu prioriteetti ja määräpäivä.
• Ihminen: päätös. Korjaa, lievennä, hyväksy päättymispäivällä tai merkitse ei-haavoittuvaksi perustelulla.

Mitä ei ole turvallista automatisoida: löydöksen sulkeminen ei-haavoittuvana ilman kirjattua syytä. Se on tukahduttamista, ja se palaa vastaan auditoinnissa tai tietoturvapoikkeamassa. Järjestyssäännöt käsitellään sivulla haavoittuvuuksien priorisointi.

Vähimmäisversio: 15 minuuttia päivässä valmiiksi järjestetyn ja täytetyn jonon parissa. Merkki siitä, että se toimii: jokaisella päätöksellä on kirjattu syy, eikä mikään odota, että joku selvittää jotain.

5. Tee kaikesta koneluettavaa

Mitä se korvaa: PDF:t, wikisivut ja sähköpostit, jotka ihmisen on luettava. Julkaise SBOM:t CycloneDX- tai SPDX-muodossa (CycloneDX vs. SPDX), ei-haavoittuva-päätökset VEX-muodossa ja tietoturvatiedotteet CSAF-muodossa. Asiakkaiden skannerit ja viranomaiset voivat silloin käsitellä niitä ilman ihmistä, joten jokainen päätös tehdään kerran ja jokainen kysyjä käyttää sitä uudelleen.

Vähimmäisversio pienelle tiimille: SBOM:t ja VEX pyynnöstä pysyvästä sijainnista; CSAF, kun asiakkaat alkavat pyytää sitä. Merkki siitä, että se toimii: asiakkaiden työkalut lakkaavat merkitsemästä sitä, mihin olet jo vastannut.

6. Vastaa kerran, julkisesti

Mitä se korvaa: yhden sähköpostiketjun asiakasta kohden. Julkaise tietoturvatiedote tai tilasivu jokaisesta merkittävästä CVE:stä haavoittuvine ja korjattuine versioineen, ja pidä vastauspohja, joka linkittää siihen. Opas kysymykseen ”koskeeko tämä CVE meitä?” vastaamiseen näyttää, miten vastaus selvitetään, ja näin vastaat asiakkaille toimitusketjuhyökkäyksen jälkeen sisältää vastauspohjia. Halvin kysely on se, jota ei koskaan tule. Merkki siitä, että se toimii: useimpiin kyselyihin vastataan linkillä.

Sitten korjaa

Automaattiset riippuvuuspäivitysten pull requestit pitävät rutiinityön liikkeessä; niputa ne viikoittain tai julkaisuittain, jotta katselmointi pysyy hallittavana. Yhden ylävirran paketin päivittäminen poistaa usein kerralla useita haavoittuvia transitiivisia riippuvuuksia, ja se on halvempaa kuin jokaisen paikkaaminen erikseen (automaattinen haavoittuvuuksien korjaus). Estä sitten tunnetusti haavoittuvien komponenttien paluu käytäntöporteilla, jotka estävät buildin.

Suunnitelma tiimin koon mukaan

Tunnit ovat havainnollistavia arvioita suunnittelun tueksi, eivät vertailulukuja.

	Yksi henkilö osa-aikaisesti	2–5 hengen tietoturva- tai PSIRT-toiminto	Suurempi tiimi
Automatisoi ensin	Vaiheet 1 ja 2: SBOM jokaisesta buildista ja jatkuva vertailu	Vaiheet 1–3, sitten ohjaus omistajille vaiheessa 4	Kaikki kuusi, käytäntöportit jokaisessa putkessa
Jää käsin tehtäväksi	Päätös jokaisesta High- tai Critical-löydöksestä; asiakasvastaukset pohjasta	Päätökset, VEX-perustelut, tietoturvatiedotteet merkittävistä CVE:istä	Päätökset, poikkeukset ja itse prosessi
Viikoittainen aika, havainnollistava	2–4 tuntia	4–8 tuntia henkilöä kohden	Määräytyy päätösten määrästä, ei syötteestä

Jos sinulla on jo PSIRT, sama järjestys pätee; koko prosessimalli on kuvattu sivulla haavoittuvuuksien hallinnan elinkaari, ja PSIRTin skaalaaminen käsittelee asiakaskyselyt, jotka moninkertaistuvat jokaisen CVE:n myötä.

Mistä tiedät, että se toimii

• Aika CVE:n julkaisusta tilaan ”haavoittuva” tai ”ei haavoittuva” tuotetta kohden.
• Julkaistun materiaalin avulla vastattujen asiakaskyselyiden osuus.
• Löydökset toimitettua julkaisua kohden, ei skannausta kohden.
• Niiden päätösten osuus, joilla on kirjattu syy.
• Haavoittuvuustyöhön viikossa käytetyt tunnit ja se, vähenevätkö ne.

Mittaa ensin oma lähtötasosi. Näille ei ole luotettavia toimialan vertailulukuja, emmekä esitä sellaisia.

Palkata, ostaa vai muuttaa prosessia?

• Palkkaa, kun työ on haavoittuvuuksien korjaamista omassa koodissasi tai asiakkaille näkyvää tietoturvatyötä, joka vaatii harkintaa.
• Osta työkaluja vaiheisiin, jotka toistuvat jokaisen CVE:n kohdalla: vaiheet 1, 2, 3 ja 5.
• Muuta prosessia omistajuuden ja määräaikojen osalta: kuka päättää ja mihin mennessä.

Ole rehellinen viimeisen suhteen. Työkalu ilman omistajaa tuottaa kojelaudan, jota kukaan ei lue.

Mihin CRACI sopii

CRACI automatisoi vaiheet 1 ja 2 sekä osia vaiheista 3 ja 4 ohjelmistoille, jotka rakennetaan GitHub Actionsissa. Se korvaa GitHubin ylläpitämät runnerisi, ja jokaisen jobin aikana se tallentaa paketit, jotka jobi todella haki, mukaan lukien CI-välimuisteista palautetut paketit ja piilossa olevat riippuvuudet, joita mikään lukitustiedosto ei luettele.

• SBOM jokaisesta buildista. Jokaisen jobin SBOM tunnistaa jokaisen komponentin PURLilla ja sisältää kattavuustilan, joten tiedät, kun jotain ei voitu nähdä. Buildihistoria säilyttää jokaisen aiemman buildin SBOM:ineen, joten näet, missä buildeissa oli haavoittuva riippuvuus, suora tai transitiivinen.
• Jatkuva vertailu. Valvotut SBOM:t arvioidaan jatkuvasti uudelleen, ja löydökset kootaan kaikista buildeista ja repositorioista, joten jaetun kirjaston CVE näkyy yhtenä ongelmana, ei neljänäkymmenenä.
• Ilmoitukset ja portit. CRACI ilmoittaa asianosaisille haavoittuvuudesta ja sen vakavuudesta, ja käytäntöportit voivat pysäyttää buildin reaaliajassa, myös buildin, joka sisältää tietyn CVE:n.
• Triage ja ohjaus. Tietoturvatiimit tekevät löydösten triagen CRACI:ssa ja ohjaavat kunkin tiimille, joka vastaa korjauksesta.
• Koneluettavat SBOM:t. SBOM:t viedään CycloneDX- tai SPDX-muodossa, ja CRACI tukee VEX:iä.

CRACI ei julkaise tietoturvatiedotteita, ei tarjoa reachability-analyysia eikä skannaa omaa koodiasi. Se veloittaa vain build-minuuteista: $0.002 vCPU-minuutilta ($0.004 oletusarvoiselle 2 vCPU:n runnerille), mitattuna sekunneittain, ilman kuukausimaksua, ilman SBOM-kohtaista maksua ja tällä hetkellä ilman lisenssimaksua. Katso hinnoittelu.

Automatisoi kaksi ensimmäistä vaihetta jo tänään: aja buildisi CRACI:lla. Otamme jokaisen tiimin käyttöön henkilökohtaisesti ennen yleistä saatavuutta.

Milloin CRACI ei ole vastaus

• Ohjelmistoasi ei rakenneta GitHub Actionsissa. GitLab CI ja Jenkins ovat tiekartalla.
• Altistuksesi on pääosin infrastruktuurissa: palvelimissa, päätelaitteissa ja pilvikonfiguraatiossa. Infrastruktuurin haavoittuvuuksien hallinnan työkalut sopivat paremmin.
• Integroit kolmannen osapuolen laiteohjelmistoa, jota et itse rakenna. Binäärianalyysityökalut sopivat paremmin.
• Työjonosi koostuu enimmäkseen todellisista, hyödynnettävistä löydöksistä omassa koodissasi. Se on korjauskapasiteetin ongelma, ei automaation ongelma.

Haavoittuvuuksien hallinnan automaatio: usein kysytyt kysymykset

Miksi CVE:itä on nyt niin paljon enemmän?

Yhä useampi organisaatio myöntää CVE:itä, ja osa myöntää niitä laajasti: Linux-ytimestä tuli CVE Numbering Authority vuonna 2024, ja se myöntää CVE:n jokaiselle virhekorjaukselle, joka saattaa olla haavoittuvuus. Tekoälyavusteiset työkalut löytävät enemmän virheitä tutkijaa kohden. Vuonna 2025 julkaistiin 47 801 tietuetta, ja vuonna 2026 tahti on 303 päivässä. Suuntaus on jatkunut vuosia.

Miten pieni tiimi pysyy uusien CVE:iden tahdissa?

Olemalla lukematta niitä. Generoi SBOM jokaisesta buildista, vertaa uudet CVE:t automaattisesti jokaiseen tallennettuun SBOM:iin, karsi kohina ja anna ihmisten tehdä vain jäljelle jääviä koskevat päätökset. Pieni tiimi pysyy tahdissa poistamalla vaiheet, jotka toistuvat jokaisen CVE:n kohdalla, ei tekemällä työtä nopeammin.

Mitä haavoittuvuuksien hallinnassa pitäisi automatisoida ensin?

Inventaario: CI:ssä generoitu SBOM jokaisesta julkaisubuildista, tallennettuna julkaisun yhteyteen. Jokainen myöhempi vaihe riippuu siitä, ja se tekee kysymyksestä ”koskeeko tämä meitä?” haun eikä kysymystä kehittäjille. Jatkuva vertailu noita SBOM:eja vasten tulee toisena.

Tarvitsemmeko tietoturvatiimin haavoittuvuuksien käsittelyyn?

Ei alussa. Yksi henkilö, joka omistaa prosessin osa-aikaisesti, pystyy pyörittämään sitä, jos inventaario, vertailu ja kohinan vähentäminen on automatisoitu. Nimetty omistaja ja määräajat ovat tärkeämpiä kuin tiimi. Palkkaa, kun työstä tulee oman koodin korjaamista tai asiakkaille näkyvää tietoturvatyötä.

Mistä tiedämme, mitkä uudet CVE:t koskevat tuotettamme?

Säilytä SBOM jokaisesta toimitetusta versiosta ja tarkista ne kaikki uudelleen aina, kun uusia CVE:itä julkaistaan, useampaa kuin yhtä haavoittuvuuslähdettä vasten. CVE koskee sinua, kun se vastaa komponenttia ja versiota, jonka todella toimitat. Hyödynnettävyyskonteksti ja VEX kertovat sitten, onko sillä merkitystä.

Mitä ”koneluettava” tarkoittaa SBOM:ien, VEX:n ja tietoturvatiedotteiden kohdalla, ja miksi sillä on merkitystä?

Se tarkoittaa standardoitua rakenteista muotoa, jonka työkalu pystyy jäsentämään: CycloneDX tai SPDX SBOM:eille, VEX ei-haavoittuva-lausunnoille, CSAF tietoturvatiedotteille. Asiakkaan skanneri voi verrata niitä inventaarioonsa ilman, että kukaan lukee niitä, joten kerran tekemääsi päätöstä käyttää uudelleen jokainen asiakas ja työkalu.

Kuinka suuren osan triagesta voi automatisoida turvallisesti?

Tietojen kokoamisen: vakavuus, hyödyntämistila, mitkä tuotteet ja versiot sisältävät komponentin, omistaja, ehdotettu prioriteetti ja määräpäivä. Itse päätöksen pitäisi jäädä ihmiselle. Älä koskaan sulje löydöstä ei-haavoittuvana automaattisesti ilman kirjattua syytä.

Kuinka paljon aikaa meillä on reagoida kriittiseen CVE:hen?

Vähemmän kuin useimmat prosessit olettavat. Mandiantin M-Trends 2026 arvioi keskimääräiseksi ajaksi hyödyntämiseen vuonna 2025 miinus seitsemän päivää, mikä tarkoittaa hyödyntämistä ennen kuin korjausta on olemassa. EU:n kyberkestävyyssäädöksen (Cyber Resilience Act) mukaan aktiivisesti hyödynnetystä haavoittuvuudesta on annettava ennakkovaroitus 24 tunnin kuluessa. Aseta oma määräaikasi vakavuuden ja hyödyntämisen mukaan ja mittaa sitä vasten.