Kasvavasta kyselymäärästä ei selviä rekrytoimalla, eikä triagea (luokittelu ja priorisointi) voi nopeuttaa loputtomiin. PSIRT-tiimi skaalautuu, kun se vastaa useimpiin ”koskeeko tämä meitä?” -kysymyksiin datalla, joka tallennettiin kunkin version buildin aikana, ja julkaisee vastauksen ennen kuin asiakkaat kysyvät. Kallein vaihe tänään on kysyä kehitykseltä, mitä tuote sisältää. Siirrä se vaihe buildin aikaan, niin useimmista kyselyistä tulee hakuja, jotka tuki voi sulkea.
Tämä kirjoitus olettaa, että sinulla on jo PSIRT-tiimi; jos olet perustamassa sellaista, aloita aiheesta mikä PSIRT on ja miten sellainen rakennetaan. Alla: miksi määrä muuttui, mihin aika kuluu tavallisessa putkessa ja mitä muuttaa, järjestyksessä.
Miksi määrä muuttui
Kasvu on rakenteellista, ei huono vuosineljännes. Neljä asiaa painaa samaa jonoa yhtä aikaa.
Enemmän CVE:itä. CVE-ohjelma julkaisi 39 718 CVE-tietuetta vuonna 2024 ja 47 801 vuonna 2025. Vuonna 2026 määrä ohitti vuoden 2025 koko vuoden lukeman selvästi ennen vuoden loppua; CVE-julkaisujen reaaliaikaiset trendimme seuraavat sitä päivä päivältä. FIRSTin vuoden 2026 haavoittuvuusennusteen päivitys (15.6.2026) nosti vuoden arvion noin 66 000 CVE:hen ja totesi syyn suoraan: tekoäly löytää huomattavasti enemmän aukkoja kuin ihmisanalyytikot, ja ”rajoite ei ole enää löytäminen vaan ihmisten kyky todentaa, koordinoida ja paikata”. PSIRT-tiimi on juuri tuo ihmisten kyky.
Asiakkaat skannaavat tuotettasi. Asiakkaat ajavat skannereita konttikuviesi, laiteohjelmistojesi ja laitteidesi päällä ja välittävät jokaisen löydöksen tikettinä. Useimmat löydökset ovat skannerin kohinaa komponenteista, joita et toimita, tai versioista, joita asia ei koske, ja kohinasta tulee vastaanottosi. Haavoittuvuuskohinan vähentäminen käsittelee skannerien puolta.
Sääntely tuo määräaikoja. EU:n kyberkestävyyssäädöksen (Cyber Resilience Act) raportointivelvoitteita on sovellettu 11.9.2026 alkaen. EU:ssa myytävän tuotteen aktiivisesti hyödynnetystä haavoittuvuudesta on annettava ennakkovaroitus 24 tunnin kuluessa siitä, kun valmistaja on saanut siitä tiedon.
Vähemmän apua NVD:ltä. NIST siirsi 15.4.2026 National Vulnerability Databasen riskiperusteiseen rikastamiseen: CISA:n KEV-luettelon CVE:t, liittovaltion käyttämät ohjelmistot ja EO 14028:n kriittiset ohjelmistot tulevat ensin, ja loput merkitään ”Lowest Priority - not scheduled for immediate enrichment”. Yhä harvempi CVE saapuu CPE-tietojen kanssa, joten tuotenimen perusteella yhdistäminen heikkenee juuri, kun määrä kasvaa.
| Ajuri | Mitä se tekee PSIRT-tiimin jonolle |
|---|---|
| CVE-määrä, tekoälyavusteinen löytäminen | Enemmän kolmansien osapuolten CVE:itä arvioitavaksi tuotetta kohden joka kuukausi |
| Asiakkaiden skannaukset | Enemmän kyselyjä CVE:tä kohden, monet komponenteista, joita et toimita |
| CRA-raportointi | 24 tunnin määräaika aktiivisesti hyödynnetyille haavoittuvuuksille |
| Vähemmän NVD-rikastamista | Enemmän käsityötä CVE:n yhdistämisessä tuotteisiin, joita se koskee |
Mihin aika kuluu: kyselyputki sellaisena kuin se yleensä toimii
Kuulemme saman putken tuoteturvallisuustiimeiltä yhä uudelleen. Laitetoimittajan kahden hengen PSIRT-tiimi kuvasi sen meille näin: asiakas kysyy tukipalvelusta, tuki ohjaa kysymyksen PSIRT-tiimille CRM:n kautta, tapaus päätyy PSIRT-tiimin seurantajärjestelmään, PSIRT tutkii tuotteet, joista asiakkaat kysyvät eniten, ja antaa sitten kysymyksen kehitykselle ja odottaa.
Otetaan yksi havainnollistava kysely. Asiakas välittää skanneriraportin, joka listaa 40 CVE:tä laiteohjelmistoversiota X vastaan. Tuki avaa tapauksen ja liittää raportin, mutta ei tarkkaa buildia, jota asiakas ajaa. PSIRT tarkistaa, mitkä 40:stä se on jo arvioinut, löytää tusinan, joita se ei ole, ja kysyy omistavalta kehitystiimiltä, ovatko komponentit versiossa X. Kehityksen on löydettävä version X lähdekoodi, selvitettävä, mitkä riippuvuusversiot siihen menivät, ja vastattava. Luvut ovat keksittyjä; kuvio ei ole.
Itse analyysi vie harvoin aikaa. Kaksi piilokustannusta ovat:
- Sama CVE selvitetään uudelleen jokaiselle kysyvälle asiakkaalle. Kun vastaus on sähköpostiketjussa, seuraava asiakas aloittaa selvityksen alusta.
- ”Eniten kysytyt tuotteet ensin” jättää pitkän hännän vastaamatta. Kentällä yhä olevia vanhempia tuotteita ei koskaan tarkisteta, ja juuri niissä riski usein on: vanhemmat komponentit, vähemmän päivityksiä, vähemmän ihmisiä, jotka muistavat, miten ne rakennettiin.
Vastaanotto: erota kysymykset raporteista
Tutkijan haavoittuvuusraportti ja asiakkaan ”koskeeko tämä meitä?” ovat eri työtä, ja ne tarvitsevat eri polut. FIRST PSIRT Services Framework odottaa jo valmiiksi sekavaa syötettä: PSIRT-tiimin pitäisi ”odottaa saavansa haavoittuvuuksia eri kanavien kautta ja vaihtelevan laatuisina” (alatoiminto 2.1.1.1). Sen triagepalvelualue menee pidemmälle: ”Kun organisaatiot saavat suuren määrän haavoittuvuusraportteja, ne voivat harkita alustavaa triagea raporttien validoimiseksi ennen tapausten luomista.” Pidä sitä lupana olla avaamatta PSIRT-tapausta jokaisesta kyselystä.
Jaa kyselyt tukipalvelussa kolmeen polkuun:
| Asiakas kysyy | Polku | Kuka vastaa |
|---|---|---|
| Julkaistusta CVE:stä kolmannen osapuolen komponentissa, jonka olet jo arvioinut | Vastaa julkaistun VEX-lausunnon tai tietoturvatiedotteen perusteella; ei PSIRT-tapausta | Tuki |
| Julkaistusta CVE:stä, jota et ole vielä arvioinut | Yksi PSIRT-tapaus CVE:tä kohden, ei asiakasta kohden; liitä jokainen kysely siihen | PSIRT, sitten tuki vastaa kaikille liitetyille |
| Uudesta haavoittuvuudesta omassa koodissasi | Haavoittuvuusraportti: koko koordinoidun haavoittuvuuksien julkistamisen prosessi | PSIRT |
Ensimmäisen polun hoitamiseen tuki tarvitsee kaksi asiaa: haettavan listan arvioiduista CVE:istä tuote- ja versiokohtaisesti sekä vastauspohjat. Miten vastata asiakkaille toimitusketjuhyökkäyksen jälkeen sisältää pohjia, joita voit muokata.
Kirjaa vastaanotossa tuote ja tarkka versio, jota asiakas ajaa. Ilman versiota jokainen vastaus on ”riippuu”, ja tapaus palaa takaisin.
Priorisoi altistumisen, ei vain suosion mukaan
”Eniten kysytyt tuotteet ensin” on järkevä nyrkkisääntö. Se tarvitsee toisen akselin. Säilytä suosio (asennuskanta, liikevaihto, kuinka usein tuki kysyy) ja lisää altistuminen: onko tuote yhä tuettu, onko se tyypillisissä käyttöönotoissa internetiin näkyvä, ja onko CVE CISA:n KEV-luettelossa tai korkealla EPSS-pisteissä? Haavoittuvuuksien priorisointi -opas käsittelee signaalit perusteellisesti.
| Matala altistuminen | Korkea altistuminen | |
|---|---|---|
| Suuri asennuskanta | Vastaa inventaariosta; julkaise VEX versioille, joita asia ei koske | Selvitä ensin; tietoturvatiedote ja korjaus lyhimmällä määräajalla |
| Pieni asennuskanta | Vastaa inventaariosta pyydettäessä; ei ennakoivaa työtä | Älä ohita: vastaa inventaariosta ja päätä sitten korjauksesta tai lieventämisilmoituksesta |
Matriisin pointti on vasen sarake ja alarivi. Pitkä häntä saa vastauksen datasta, ei selvityksestä, johon kenelläkään ei ole aikaa.
Kyberkestävyyssäädöksen alaisuudessa kullekin tuotteelle ilmoittamasi tukiaika ratkaisee, mihin vanhempiin tuotteisiin olet yhä velkaa vastauksia ja tietoturvapäivityksiä (mitä CRA vaatii).
Luovutus kehitykselle on pullonkaula
Tämä osio on kehitysjohtajalle, joka vastaanottaa PSIRT-tiimin eskalaatiot.
PSIRT-tiimin määräajat ovat julkisia: asiakas, viranomainen tai julkistamispäivä odottaa. Kehityksen määräajat eivät yleensä ole, joten PSIRT kantaa eron. Maanantaina luovutettu kriittinen ongelma, johon ei ole vastausta tiistaihin mennessä, jättää kaksi päivää ennen kuin julkinen vastaus on annettava.
PSIRT lähettää kehitykselle kaksi eri kysymystä, ja vain toisen pitäisi vaatia kehitystä:
- ”Onko komponentti tuotteessa?” on datakysymys. Siihen pitäisi vastata tallenteesta, ei niin, että ihminen lukee build-tiedostoja.
- ”Voitteko korjata sen päivään X mennessä?” on työkysymys. Se kuuluu kehitykselle.
FIRST-viitekehys kertoo, miten ensimmäinen kysymys otetaan pois kehityksen pöydältä. Toiminto 2.3.5 pyytää PSIRT-tiimejä ”perustamaan automaattiset kanavat tunnistettujen kolmansien osapuolten haavoittuvuusilmoitusten jakamiseen suoraan haavoittuvien tuotteiden kehitystiimeille”, jotta kolmansien osapuolten tietoturvatiedotteet käsitellään kehitysprosessissa ja PSIRT käsittelee niistä harvempia käsin.
Sovi kehityksen kanssa kolmesta asiasta:
- Omistaja tuotetta kohden. Suurilla toimittajilla korjaaminen on hajautettu tuotetiimeille; viitekehyksen hajautettu malli on olemassa, koska sen ansiosta PSIRT-tehtävä skaalautuu tuotteet omistavien insinöörien kautta.
- Vakavuuskohtaiset vasteajat kirjallisesti, korjaukselle eikä selvitykselle.
- Mitä tapahtuu, kun tavoite ylittyy. Toiminto 4.2.4 edellyttää ”prosessia muodolliselle riskin hyväksymiselle kaikille haavoittuvuuksille, joita ei ole korjattu sisäisten SLA-aikavaatimusten puitteissa”. Joku, jolla on valtuudet, allekirjoittaa riskin; se ei vain jää auki.
Korjaustahti vaihtelee. Yksi tiimi toimittaa paikkauksen yön yli, toinen tarvitsee kuuden kuukauden alustapäivityksen. Tietoturvatiedotteen on kerrottava, kumpi, jotta asiakkaat voivat suunnitella.
Tee ”koskeeko tämä meitä?” -kysymyksestä haku: SBOM jokaisesta toimitetusta versiosta
Tämä muutos poistaa eniten työtä. FIRSTin toiminto 2.3.1, tuotekomponenttien inventaario, kutsuu sitä ”välttämättömäksi, jotta perittyjen haavoittuvuuksien koskemat tuotteet tunnistetaan nopeasti”. PSIRT-kypsyystasot sijoittavat tuoterekisterin riippuvuuksien kartoituksineen keskitasolle ja tuotekomponenttien haavoittuvuuksien seurannan edistyneelle tasolle.
Inventaario poistaa työtä vain, jos se kestää suuria määriä. Jokaiselle alla olevalle vaatimukselle on syynsä:
- Yksi SBOM jokaista toimitettua versiota kohden, ei repositoriota kohden eikä oletushaarasta. Asiakkaat ajavat versioita, eivät haaroja.
- Otettu buildista, joka tuotti julkaisun. Myöhempi uudelleenbuildi tai tämän päivän repositorion skannaus kuvaa eri ohjelmistoa (buildin aikana tallennetut SBOM:t).
- Transitiiviset ja piilossa olevat riippuvuudet mukana. Haavoittuva paketti on harvoin sellainen, jonka lisäsit itse (transitiiviset riippuvuudet), ja asennusskriptit, pohjakuvat ja palautetut välimuistit tuovat komponentteja, joita mikään lukitustiedosto ei listaa.
- Kattavuussignaali. Osittainen tallenne, jota kohdellaan täydellisenä, tuottaa varmoja ”ei koske” -vastauksia, jotka ovat vääriä.
- Säilytetään niin kauan kuin versiota tuetaan. Kolmen vuoden takaisen version tallenne on juuri se, jota tarvitset, kun kukaan ei muista, miten se rakennettiin.
- Toimittajien SBOM:t ostetuille komponenteille, jotta kolmansien osapuolten ohjelmistot ovat samassa inventaariossa kuin omasi.
- Yhdistetään uudelleen jatkuvasti, kun uusia CVE:itä julkaistaan, sen sijaan että skannattaisiin uudelleen, kun joku kysyy.
Esimerkki. Laajasti käytetystä pakkauskirjastosta julkaistaan uusi CVE. Ilman inventaariota PSIRT kysyy jokaiselta tuotetiimiltä, vastauksia tihkuu päivien ajan, eikä vanhimpia tuotteita tarkisteta koskaan. Sen kanssa yksi kysely palauttaa haavoittuvat tuotteet ja versiot sekä ensimmäisen ja viimeisen buildin, joka sisälsi haavoittuvan version. Se on altistumisikkuna, josta asiakkaat kysyvät seuraavaksi; koskeeko CVE meitä? näyttää, miten se selvitetään yksittäisessä tapauksessa.
Sulautettujen järjestelmien ja Yocton tuoteportfolioilla on vaikeinta. Valmista laiteohjelmistokuvaa lukevien skannerien on arvattava, mitä siihen käännettiin, ja tiimeillä, joiden kanssa puhumme, skannerien proof of concept -kokeilut ovat epäonnistuneet Yocto-pohjaisissa tuotteissa. Buildin tallentaminen sen aikana välttää arvailun (Yocto-buildit CRACI:lla).
Kun asiakas sitten pyytää itse SBOM:ia tietyssä muodossa, katso asiakkaiden SBOM-pyyntöihin vastaaminen.
Lähtöpuoli: tietoturvatiedotteet ja VEX, jotka vastaavat ennen kuin kukaan kysyy
Halvin kysely on se, jota ei koskaan tule.
- Julkaise ”ei koske” VEX-muodossa, jotta asiakkaiden skannerit lakkaavat merkitsemästä CVE:tä, ja julkaise ”koskee” ja ”korjattu” tietoturvatiedotteina tarkkoine versioineen.
- Tee siitä koneluettavaa. FIRSTin alatoiminto 5.3.2.3 ehdottaa, että PSIRT-tiimit ”harkitsevat tietoturvatiedotteiden julkaisemista koneluettavassa muodossa, kuten Common Security Advisory Framework (CSAF)”, jotta asiakkaat voivat käyttää niitä omilla työkaluillaan. CSAF-opas kertoo, miten siirrytään verkkosivuista ja RSS-syötteistä CSAF:iin.
- Perehdytä tuki ennen julkaisua. Toiminto 5.3.4: ”Etukäteen annettu luottamuksellinen ilmoitus ja usein kysytyt kysymykset tulevista tietoturvatiedotteista valmistavat niitä, joilta niistä saatetaan kysyä julkaisun yhteydessä.” Tuki voi silloin vastata samana päivänä.
- Työnnä, älä vain julkaise. Alatoiminto 5.4.1.3 toteaa, että tietoturvatiedotteiden vähäiset sivunkatselut ”voivat ohjata strategiaasi kohti ennakoivaa ilmoittamista”. Syötteet ja ilmoitukset tavoittavat asiakkaat, jotka eivät koskaan käy tietoturvatiedotesivulla.
Kyberkestävyyssäädös tekee osasta tätä velvollisuuden. Sen 14 artiklan 8 kohta edellyttää, että valmistaja saatuaan tiedon aktiivisesti hyödynnetystä haavoittuvuudesta tai vakavasta poikkeamasta ilmoittaa asiasta sen vaikutuksen kohteena oleville käyttäjille ”ja tarvittaessa kaikille käyttäjille” ja tekee sen ”tarvittaessa jäsennellyssä, koneluettavassa muodossa, joka on helposti automaattisesti käsiteltävissä”. Asetus ei nimeä muotoa.
Mitä automatisoida, järjestyksessä
Jokainen vaihe poistaa yhden työlajin; mittari näyttää, poistiko se.
| Vaihe | Työ, jonka se poistaa | Mittari, joka näyttää sen toimineen |
|---|---|---|
| 1. Versiokohtainen inventaario buildista | ”Mitä siinä on?” -kysymys kehitykselle | Kehitykselle tehtyjen selvityspyyntöjen määrä kuukaudessa laskee |
| 2. Uusien CVE:iden jatkuva yhdistäminen jokaiseen tuettuun versioon | Uudelleenskannaus pyynnöstä | Aika CVE:n julkaisusta koskee- tai ei koske -päätökseen |
| 3. Yksi tapaus CVE:tä kohden, kyselyt liitettyinä | Päällekkäiset selvitykset | Kyselyjä tapausta kohden enemmän, tapauksia CVE:tä kohden yhä yksi |
| 4. Koskevien löydösten automaattinen ohjaus omistavalle tiimille (FIRST 2.3.5) | Manuaaliset luovutukset | Aika päätöksestä siihen, että omistaja kuittaa sen |
| 5. Haettava kirjasto julkaistuista VEX-lausunnoista ja tietoturvatiedotteista | PSIRT-tiimin osallistuminen toistuviin kysymyksiin | Tuen sulkemien kyselyjen osuus |
| 6. Koneluettava julkaiseminen (CSAF) | Asiakkaat kysyvät sitä, minkä heidän työkalunsa olisivat voineet hakea | Kyselyjä julkaistua tietoturvatiedotetta kohden vähemmän |
| 7. Tekoälyavusteinen tietoturvatiedotteiden ja vastausten luonnostelu | Kirjoitusaika | Aika päätöksestä julkaistuun tietoturvatiedotteeseen |
Tekoäly tulee viimeisenä syystä. Se luonnostelee hyvin tallennetun datan päällä, eikä sen pitäisi koskaan olla ”koskee”-päätöksen lähde.
Joitakin asioita ei pidä automatisoida: ”ei koske” -arvio ja vakavuuden määrittäminen jäävät ihmiselle, näyttö liitettynä. Automaatio ratkaisee, kuinka nopeasti tuo ihminen saa näytön.
Mittarit, jotka näyttävät PSIRT-tiimin skaalautuvan
- Ilman PSIRT-tapausta vastattujen kyselyjen osuus.
- Aika CVE:n julkaisusta koskee- tai ei koske -päätökseen, tuotekohtaisesti.
- Kehitykselle tehdyt selvityspyynnöt kuukaudessa. Määrän pitäisi laskea.
- Korjausten oikea-aikaisuus vakavuuden mukaan; viitekehyksen alatoiminto 4.4.2.4 määrittelee sen sillä, kuinka hyvin tuotetiimit pitävät sovitun ajan raportista korjaukseen.
- VEX- ja tietoturvatiedotekattavuus versioille, joita yhä tuet.
Emme esitä näille alan vertailulukuja. Mikään luotettavana pitämämme ensisijainen lähde ei julkaise sellaisia.
Mihin CRACI sopii
CRACI kattaa vaiheet 1 ja 2 sekä osia vaiheista 4 ja 5 ohjelmistoille, jotka rakennetaan GitHub Actionsissa. Buildisi ajetaan CRACI:n runnereilla, ja CRACI tallentaa ajon aikana, mitä kukin jobi todella haki: suorat ja transitiiviset riippuvuudet, skriptien asentamat paketit ja CI-välimuisteista palautetut paketit. Jokaisen jobin SBOM:ssa on kattavuustila, joten osittaista tallennetta ei koskaan erehdytä pitämään täydellisenä.
CRACI säilyttää buildihistorian, joten kun uusi CVE julkaistaan, näet, mitkä buildit sisälsivät haavoittuvan riippuvuuden ja mistä lähtien, niin kauas taaksepäin kuin säilytysaikasi ulottuu. Seurattuja SBOM:ja arvioidaan jatkuvasti uudelleen, löydökset kootaan buildeista ja repositorioista, ja toimittajien SBOM:eja voi lisätä, jotta ostettuja komponentteja seurataan omien buildiesi rinnalla. CRACI ilmoittaa asianomaisille henkilöille uudesta haavoittuvuudesta ja sen vakavuudesta. Inventaarionäkymä näyttää, mitkä ohjelmistoversiot ovat käytössä missäkin tuotteessa, ja tietoturvatiimit tekevät jokaiselle löydökselle triagen CRACI:ssa ja ohjaavat sen korjauksen omistavalle tiimille. CRACI tukee VEX:iä. Katso CRACI PSIRT-tiimeille ja haavoittuvuuksien seuranta.
Katso, mitkä toimittamistasi versioista sisältävät CVE:n.
Milloin CRACI ei ole vastaus
- Pullonkaulasi on vastaanotto ja tapausten hallinta, CRM:stä seurantajärjestelmään -osuus. CRACI ei ole tapausten hallinnan tai tietoturvatiedotteiden julkaisun työkalu; tarvitset tapaustyökalun tuohon puoliskoon (PSIRT-työkalut vertailussa).
- Tuotteitasi ei rakenneta GitHub Actionsissa Linux-runnereilla. GitHub Actions on tuettu CI tänään; GitLab CI ja Jenkins ovat tiekartalla ilman päivämäärää.
- Tarvitset binääri- tai laiteohjelmistoanalyysin tuotteista, joita et ole itse rakentanut. Sitä tekevät lopputulosta analysoivat työkalut (sulautettujen järjestelmien tietoturvatyökalut vertailussa).
- Tarvitset reachability-analyysin ”ei koske” -perusteluun. CRACI ei tarjoa sitä.
Usein kysytyt kysymykset
Miten PSIRT-tiimiä skaalataan ilman rekrytointia?
Lopeta saman kysymyksen selvittäminen yhä uudelleen. Tallenna buildin aikana, mitä jokainen toimitettu versio sisältää, yhdistä uudet CVE:t siihen jatkuvasti, päätä kerran CVE:tä kohden ja julkaise päätös VEX-muodossa tai tietoturvatiedotteena, johon tuki voi viitata. PSIRT käsittelee silloin todella avoimia tapauksia, ja kehitykseltä pyydetään korjausta, ei selvitystä.
Miten PSIRT-tiimin pitäisi käsitellä asiakkaiden ”koskeeko tämä meitä?” -kyselyjä?
Käsittele niitä erillisenä vastaanottovirtana haavoittuvuusraporteista. Tuki vastaa jo arvioimiasi CVE:itä koskeviin kysymyksiin julkaistun materiaalin perusteella. CVE, jota et ole vielä arvioinut, saa yhden PSIRT-tapauksen, johon jokainen asiakaskysely liitetään. Vain uusi haavoittuvuus omassa koodissasi kulkee koko julkistamisprosessin läpi.
Mitä FIRST PSIRT Services Framework sanoo määristä ja automaatiosta?
Se odottaa raportteja ”eri kanavien kautta ja vaihtelevan laatuisina”, sallii triagen ennen tapausten luomista, kun määrä on suuri, kutsuu tuotekomponenttien inventaariota ”välttämättömäksi haavoittuvien tuotteiden nopeaksi tunnistamiseksi” ja pyytää automaattisia kanavia, jotka lähettävät kolmansien osapuolten haavoittuvuusilmoitukset suoraan haavoittuvien tuotteiden kehitystiimeille (toiminto 2.3.5).
Mitä PSIRT-tiimin pitäisi automatisoida ensin?
Buildista otetun versiokohtaisen inventaarion ja sen jälkeen uusien CVE:iden jatkuvan yhdistämisen jokaiseen tuettuun versioon. Nämä kaksi poistavat eniten toistuvaa työtä: ”mitä siinä on?” -kysymyksen kehitykselle ja uudelleenskannauksen pyynnöstä. Tapausten yhdistäminen, ohjaus, haettava VEX- ja tietoturvatiedotekirjasto sekä CSAF-julkaiseminen tulevat sen jälkeen.
Miten saat kehityksen vastaamaan PSIRT-tiimin kysymyksiin ajallaan?
Kysy kehitykseltä vähemmän. Vastaa kysymykseen ”onko komponentti tuotteessa?” buildin tallenteesta ja lähetä kehitykselle vain ”voitteko korjata sen tähän päivään mennessä?”. Sovi omistaja tuotetta kohden, vakavuuskohtaiset vasteajat korjaukselle ja muodollinen riskin hyväksyminen, kun tavoite ylittyy.
Miksi julkaisukohtainen SBOM on PSIRT-tiimille tärkeä?
Asiakkaat ajavat tiettyjä versioita, usein vanhoja. Oletushaaran SBOM ei kerro mitään kahden vuoden takaisesta versiosta X. Yksi SBOM jokaista toimitettua versiota kohden, tallennettuna sen tuottaneesta buildista ja säilytettynä tukiajan, antaa PSIRT-tiimin vastata jokaisesta kentällä yhä olevasta versiosta, altistumisikkuna mukaan lukien.
Haluavatko asiakkaat VEX:iä vai tietoturvatiedotteita?
Molempia, eri tiloille. VEX kertoo asiakkaiden skannereille, mitkä CVE:t eivät koske tuotetta, joten löydökset loppuvat. Tietoturvatiedotteet kertovat ihmisille, mitä asia koskee, mikä on korjattu ja mitä tehdä. Kun julkaiset molemmat, koneluettavina missä voit, useimpiin kysymyksiin on vastattu ennen kuin niitä kysytään.
