Slik skalerer du et PSIRT: Håndter «er vi berørt?» når spørsmålene mangedobles

Du kan ikke ansette deg ut av et voksende antall henvendelser, og du kan ikke triagere stadig raskere i all evighet. Et PSIRT skalerer ved å besvare de fleste «er vi berørt?»-spørsmål ut fra data det registrerte da hver versjon ble bygget, og ved å publisere svaret før kundene spør. Det dyre steget i dag er å spørre utviklingsavdelingen hva et produkt inneholder. Flytt det steget til byggetidspunktet, så blir de fleste henvendelser oppslag som kundestøtte kan lukke.

Dette innlegget forutsetter at du allerede driver et PSIRT; hvis du skal opprette et, begynn med hva et PSIRT er og hvordan du bygger et. Nedenfor: hvorfor volumet har endret seg, hvor tiden går i den vanlige prosessen, og hva du bør endre, i rekkefølge.

Hvorfor volumet har endret seg

Økningen er strukturell, ikke et dårlig kvartal. Fire ting presser på den samme køen samtidig.

Flere CVE-er. CVE-programmet publiserte 39 718 CVE-poster i 2024 og 47 801 i 2025. I 2026 passerte antallet hele 2025-totalen lenge før året var omme; våre løpende trender for CVE-publisering følger det dag for dag. FIRSTs oppdaterte sårbarhetsprognose for 2026 (15. juni 2026) hevet anslaget for året til rundt 66 000 CVE-er og sa rett ut hva årsaken er: KI kan finne betydelig flere feil enn menneskelige analytikere, og «begrensningen er ikke lenger å oppdage; det er den menneskelige kapasiteten til å verifisere, koordinere og patche». Et PSIRT er den menneskelige kapasiteten.

Kundene skanner produktet ditt. Kunder kjører skannere mot imagene, fastvaren og enhetene dine og videresender hvert funn som en sak. De fleste av funnene er skannerstøy om komponenter du ikke leverer, eller versjoner som ikke er berørt, og støyen blir mottaket ditt. Redusere sårbarhetsstøy dekker skannersiden.

Regelverket legger til frister. Siden 11. september 2026 har rapporteringspliktene i EUs Cyber Resilience Act gjeldt. En aktivt utnyttet sårbarhet i et produkt som selges i EU, krever et tidlig varsel innen 24 timer etter at produsenten ble kjent med den.

Mindre hjelp fra NVD. 15. april 2026 gikk NIST over til risikobasert berikelse i National Vulnerability Database: CVE-er i CISAs KEV-katalog, programvare som brukes av den føderale statsforvaltningen og kritisk programvare etter EO 14028 kommer først, og resten merkes «Lowest Priority - not scheduled for immediate enrichment». Færre CVE-er kommer med CPE-data, så matching på produktnavn blir dårligere akkurat når volumet øker.

Drivkraft	Hva den gjør med PSIRT-ets kø
CVE-volum, KI-assistert oppdagelse	Flere CVE-er i tredjepartskomponenter å vurdere per produkt, hver måned
Kunder som skanner	Flere henvendelser per CVE, mange om komponenter du ikke leverer
CRA-rapportering	En 24-timersfrist for aktivt utnyttede sårbarheter
Mindre berikelse i NVD	Mer manuelt arbeid for å koble en CVE til produktene den berører

Hvor tiden går: henvendelsesprosessen slik den vanligvis fungerer

Vi hører om den samme prosessen fra produktsikkerhetsteam igjen og igjen. Et PSIRT på to personer hos en maskinvareleverandør beskrev den slik for oss: En kunde spør kundestøtte, kundestøtte sender spørsmålet videre til PSIRT-et via CRM-systemet, saken havner i PSIRT-ets saksoppfølgingssystem, PSIRT-et undersøker produktene kundene spør mest om, og gir så spørsmålet videre til utviklingsavdelingen og venter.

Ta en illustrerende henvendelse. En kunde videresender en skannerrapport som lister 40 CVE-er mot fastvareversjon X. Kundestøtte åpner en sak og legger ved rapporten, men ikke det nøyaktige bygget kunden kjører. PSIRT-et sjekker hvilke av de 40 det allerede har vurdert, finner et dusin det ikke har vurdert, og spør utviklingsteamet som eier produktet om komponentene finnes i versjon X. Utviklingsteamet må finne kildekoden til versjon X, finne ut hvilke avhengighetsversjoner som gikk inn i den, og svare. Tallene er oppdiktet; mønsteret er det ikke.

Selve analysen er sjelden det som tar tid. To skjulte kostnader er:

1. Den samme CVE-en undersøkes på nytt for hver kunde som spør. Når svaret ligger i en e-posttråd, starter undersøkelsen på nytt for neste kunde.
2. «Mest etterspurte produkter først» lar den lange halen stå ubesvart. Eldre produkter som fortsatt er i bruk, blir aldri sjekket, og det er ofte der risikoen er: eldre komponenter, færre oppdateringer, færre som husker hvordan de ble bygget.

Mottak: skill spørsmål fra rapporter

En forskers sårbarhetsrapport og en kundes «er vi berørt?» er forskjellig arbeid, og de trenger forskjellige løp. FIRST PSIRT Services Framework regner allerede med rotete innspill: Et PSIRT bør «regne med å motta sårbarheter gjennom ulike kanaler og i varierende kvalitet» (underfunksjon 2.1.1.1). Tjenesteområdet for triage går lenger: «Der organisasjoner mottar et stort volum av sårbarhetsrapporter, kan de vurdere å utføre en innledende triage for å validere rapportene før saker opprettes.» Ta det som en tillatelse til ikke å åpne en PSIRT-sak for hver henvendelse.

Del henvendelsene i tre løp allerede hos kundestøtte:

Kunden spør om	Løp	Hvem svarer
En publisert CVE i en tredjepartskomponent du allerede har vurdert	Svar ut fra den publiserte VEX-erklæringen eller advisoryen; ingen PSIRT-sak	Kundestøtte
En publisert CVE du ikke har vurdert ennå	Én PSIRT-sak per CVE, ikke per kunde; knytt hver henvendelse til den	PSIRT-et, deretter svarer kundestøtte alle tilknyttede
En ny sårbarhet i din egen kode	En sårbarhetsrapport: hele prosessen for koordinert sårbarhetsavsløring	PSIRT-et

Kundestøtte trenger to ting for å håndtere det første løpet: en søkbar liste over vurderte CVE-er per produkt og versjon, og svarmaler. Slik svarer du kunder etter et leverandørkjedeangrep har maler du kan tilpasse.

Registrer produktet og den nøyaktige versjonen kunden kjører, allerede ved mottak. Uten versjonen blir hvert svar «det kommer an på», og saken kommer tilbake.

Prioriter etter eksponering, ikke bare popularitet

«Mest etterspurte produkter først» er en fornuftig tommelfingerregel. Den trenger en akse til. Behold populariteten (installert base, omsetning, hvor ofte kundestøtte spør) og legg til eksponering: Støttes produktet fortsatt, er det eksponert mot internett i typiske installasjoner, og står CVE-en i CISAs KEV-katalog eller høyt på EPSS? Veiledningen om prioritering av sårbarheter går grundig gjennom signalene.

	Lav eksponering	Høy eksponering
Stor installert base	Svar ut fra inventaret; publiser VEX for versjoner som ikke er berørt	Undersøk først; advisory og retting med kortest frist
Liten installert base	Svar ut fra inventaret ved forespørsel; ikke noe proaktivt arbeid	Ikke hopp over den: svar ut fra inventaret, avgjør deretter om det blir en retting eller et varsel om tiltak

Poenget med matrisen er venstre kolonne og nederste rad. Den lange halen får et svar fra data, ikke fra en undersøkelse ingen har tid til.

Etter CRA er det støtteperioden du har oppgitt for hvert produkt, som avgjør hvilke eldre produkter du fortsatt skylder svar og sikkerhetsoppdateringer for (hva CRA krever).

Overleveringen til utviklingsavdelingen er flaskehalsen

Denne delen er for utviklingslederen som mottar PSIRT-ets eskaleringer.

PSIRT-ets frister er offentlige: En kunde, en myndighet eller en dato for avsløring venter. Utviklingsavdelingens frister er det vanligvis ikke, så PSIRT-et tar av for differansen. Et kritisk problem som overleveres en mandag og fortsatt er ubesvart tirsdag, gir to dager igjen før det offentlige svaret skal ut.

PSIRT-et sender utviklingsavdelingen to forskjellige spørsmål, og bare det ene burde trenge utviklingsavdelingen:

• «Finnes komponenten i produktet?» er et dataspørsmål. Det bør besvares ut fra en registrering, ikke av en person som leser byggefiler.
• «Kan dere rette det innen dato X?» er et arbeidsspørsmål. Det hører hjemme hos utviklingsavdelingen.

FIRST-rammeverket sier hvordan du tar det første spørsmålet bort fra utviklingsavdelingens bord. Funksjon 2.3.5 ber PSIRT-er om å «etablere automatiserte kanaler som distribuerer identifiserte sårbarhetsvarsler fra tredjeparter direkte til utviklingsteamene for berørte produkter», slik at advisories fra tredjeparter håndteres i utviklingsprosessen og PSIRT-et behandler færre av dem for hånd.

Avtal tre ting med utviklingsavdelingen:

1. En eier per produkt. Hos store leverandører er utbedringen spredt over produktteamene; rammeverkets distribuerte modell finnes fordi den lar PSIRT-oppdraget skalere gjennom utviklerne som eier produktene.
2. Responsmål per alvorlighetsgrad, skrevet ned, for rettingen og ikke for undersøkelsen.
3. Hva som skjer når et mål ikke nås. Funksjon 4.2.4 ber om «en prosess for formell risikoaksept for alle sårbarheter som ikke er utbedret innenfor tidskravene i de interne SLA-ene». Noen med myndighet signerer risikoen; den blir ikke bare liggende åpen.

Tempoet på rettinger varierer. Ett team leverer en patch over natten, et annet trenger en plattformoppgradering på seks måneder. Advisoryen må si hvilken av delene, så kundene kan planlegge.

Gjør «er vi berørt?» til et oppslag: en SBOM for hver levert versjon

Dette er endringen som fjerner mest arbeid. FIRST-funksjon 2.3.1, inventaret over produktkomponenter, kaller det «avgjørende for raskt å identifisere berørte produkter ved arvede sårbarheter». Modenhetsnivåene for PSIRT plasserer et produktregister med kartlegging av avhengigheter på mellomnivået og overvåking av sårbarheter i produktkomponenter på det avanserte nivået.

Et inventar fjerner bare arbeid hvis det holder under volum. Hvert krav nedenfor har en grunn:

• Én SBOM per levert versjon, ikke per repositorium og ikke av standardgrenen. Kundene kjører versjoner, ikke grener.
• Tatt fra bygget som produserte utgivelsen. Et nytt bygg senere, eller en skanning av dagens repositorium, beskriver annen programvare (SBOM-er fra byggetidspunktet).
• Transitive og skjulte avhengigheter inkludert. Den sårbare pakken er sjelden en du la til selv (transitive avhengigheter), og installasjonsskript, base-images og gjenopprettede cacher bringer inn komponenter ingen lockfile lister opp.
• Et signal om fullstendighet. En delvis registrering som behandles som en fullstendig, gir selvsikre «ikke berørt»-svar som er feil.
• Tatt vare på så lenge versjonen støttes. Registreringen for en versjon fra tre år tilbake er den du kommer til å trenge når ingen husker hvordan den ble bygget.
• Leverandør-SBOM-er for innkjøpte komponenter, så tredjepartsprogramvare ligger i det samme inventaret som din egen.
• Matchet på nytt fortløpende når nye CVE-er publiseres, i stedet for skannet på nytt når noen spør.

Et konkret eksempel. En ny CVE publiseres i et mye brukt komprimeringsbibliotek. Uten inventaret spør PSIRT-et hvert produktteam, svarene drypper inn over flere dager, og de eldste produktene blir aldri sjekket. Med inventaret gir én spørring de berørte produktene og versjonene, pluss det første og det siste bygget som inneholdt den sårbare versjonen. Det er eksponeringsvinduet kundene spør om etterpå; er vi berørt av en CVE? viser hvordan du fastslår det for ett enkelt tilfelle.

Porteføljer med innebygde systemer og Yocto har det vanskeligst. Skannere som leser et ferdig fastvare-image, må gjette hva som ble kompilert inn i det, og team vi snakker med, har sett proof of concept-forsøk med skannere feile på Yocto-baserte produkter. Å registrere bygget mens det kjører, unngår gjettingen (Yocto-bygg på CRACI).

Når en kunde så ber om selve SBOM-en, i et bestemt format, se hvordan du svarer på kunders SBOM-forespørsler.

Utgangssiden: advisories og VEX som svarer før noen spør

Den billigste henvendelsen er den som aldri kommer.

• Publiser «ikke berørt» som VEX, så kundenes skannere slutter å flagge CVE-en, og publiser «berørt» og «rettet» som advisories med nøyaktige versjoner.
• Gjør det maskinlesbart. FIRST-underfunksjon 5.3.2.3 foreslår at PSIRT-er «vurderer å publisere advisories i et maskinlesbart format som Common Security Advisory Framework (CSAF)», så kundene kan ta dem inn med egne verktøy. CSAF-veiledningen viser hvordan du går fra nettsider og RSS-feeder til CSAF.
• Orienter kundestøtte før du publiserer. Funksjon 5.3.4: «Å gi forhåndsvarsel og en FAQ, konfidensielt, for kommende advisories forbereder dem som kan bli spurt om dem ved publisering.» Da kan kundestøtte svare samme dag.
• Send ut, ikke bare legg ut. Underfunksjon 5.4.1.3 påpeker at få sidevisninger på advisories «kan få deg til å legge om strategien mot proaktiv varsling». Feeder og varsler når kunder som aldri besøker en advisory-side.

CRA gjør deler av dette til en plikt. Artikkel 14(8) krever at produsenten, etter å ha blitt kjent med en aktivt utnyttet sårbarhet eller en alvorlig hendelse, informerer de berørte brukerne «og, der det er hensiktsmessig, alle brukere», og gjør det «der det er hensiktsmessig, i et strukturert, maskinlesbart format som lett kan behandles automatisk». Forordningen nevner ikke noe format.

Hva du bør automatisere, i rekkefølge

Hvert steg fjerner en type arbeid; måltallet viser om det gjorde det.

Steg	Arbeid det fjerner	Måltall som viser at det virket
1. Et inventar per versjon fra bygget	Spørsmålet «hva er i den?» til utviklingsavdelingen	Antall forespørsler om undersøkelser til utvikling per måned faller
2. Fortløpende matching av nye CVE-er mot hver støttet versjon	Ny skanning ved forespørsel	Tid fra publisering av CVE-en til en beslutning om berørt eller ikke berørt
3. Én sak per CVE, med henvendelsene knyttet til den	Dobbeltundersøkelser	Henvendelser per sak øker, saker per CVE holder seg på én
4. Automatisk ruting av berørte funn til teamet som eier produktet (FIRST 2.3.5)	Manuelle overleveringer	Tid fra beslutning til at en eier bekrefter den
5. Et søkbart bibliotek over publiserte VEX-erklæringer og advisories	PSIRT-ets involvering i gjentatte spørsmål	Andel henvendelser som lukkes av kundestøtte
6. Maskinlesbar publisering (CSAF)	Kunder som ber om det verktøyene deres kunne ha hentet	Henvendelser per publisert advisory faller
7. KI-assistanse til utkast av advisories og svar	Skrivetid	Tid fra beslutning til publisert advisory

KI kommer sist av en grunn. Den skriver gode utkast på toppen av registrerte data, og den skal aldri være kilden til beslutningen om at noe er «berørt».

Noe bør ikke automatiseres: Vurderingen av «ikke berørt» og fastsettelsen av alvorlighetsgrad blir hos en person, med dokumentasjonen vedlagt. Automatisering avgjør hvor raskt den personen får dokumentasjonen.

Måltall som viser at PSIRT-et skalerer

• Andelen henvendelser som besvares uten en PSIRT-sak.
• Tid fra publisering av en CVE til en beslutning om berørt eller ikke berørt, per produkt.
• Forespørsler om undersøkelser til utviklingsavdelingen per måned. Antallet bør falle.
• Andel utbedringer i tide per alvorlighetsgrad; rammeverkets underfunksjon 4.4.2.4 definerer det som hvor godt produktteamene overholder den avtalte tiden fra rapport til retting.
• VEX- og advisory-dekning av versjonene du fortsatt støtter.

Vi oppgir ingen bransjereferanser for disse. Ingen primærkilde vi stoler på, publiserer noen.

Der CRACI passer inn

CRACI dekker steg 1 og 2, og deler av steg 4 og 5, for programvare bygget i GitHub Actions. Byggene dine kjører på CRACIs runnere, og CRACI registrerer hva hver jobb faktisk hentet inn mens den kjørte: direkte og transitive avhengigheter, pakker installert av skript og pakker gjenopprettet fra CI-cacher. SBOM-en til hver jobb har en fullstendighetsstatus, så en delvis registrering aldri forveksles med en fullstendig.

CRACI tar vare på byggehistorikken, så når en ny CVE publiseres, ser du hvilke bygg som inneholdt den sårbare avhengigheten, og siden når, så langt tilbake som oppbevaringstiden din rekker. Overvåkede SBOM-er vurderes på nytt fortløpende, funn samles på tvers av bygg og repositorier, og leverandør-SBOM-er kan legges til, så innkjøpte komponenter overvåkes sammen med dine egne bygg. CRACI varsler de relevante personene om en ny sårbarhet og alvorlighetsgraden. Inventarvisningen viser hvilke programvareversjoner som er rullet ut til hvilke produkter, og sikkerhetsteam triagerer hvert funn i CRACI og sender det til teamet som eier rettingen. CRACI støtter VEX. Se CRACI for PSIRT-er og sårbarhetssporing.

Se hvilke av de leverte versjonene dine som inneholder en CVE.

Når CRACI ikke er svaret

• Flaskehalsen din er mottak og saksbehandling, delen fra CRM til saksoppfølgingssystem. CRACI er ikke et verktøy for saksbehandling eller publisering av advisories; du trenger et saksverktøy for den halvdelen (PSIRT-verktøy sammenlignet).
• Produktene dine bygges ikke i GitHub Actions på Linux-runnere. GitHub Actions er den støttede CI-en i dag; GitLab CI og Jenkins står på veikartet, uten dato.
• Du trenger binær- eller fastvareanalyse av produkter du ikke har bygget selv. Det er det verktøy for analyse av ferdige artefakter gjør (sikkerhetsverktøy for innebygde systemer sammenlignet).
• Du trenger reachability-analyse for å argumentere for «ikke berørt». CRACI tilbyr ikke det.

Ofte stilte spørsmål

Hvordan skalerer du et PSIRT uten å ansette?

Slutt å undersøke det samme spørsmålet gang på gang. Registrer hva hver levert versjon inneholder når den bygges, match nye CVE-er mot det fortløpende, avgjør én gang per CVE, og publiser beslutningen som VEX eller en advisory som kundestøtte kan vise til. Da jobber PSIRT-et med de sakene som virkelig er åpne, og utviklingsavdelingen blir bedt om å rette, ikke om å undersøke.

Hvordan bør et PSIRT håndtere «er vi berørt?»-henvendelser fra kunder?

Behandle dem som en egen mottaksstrøm, atskilt fra sårbarhetsrapporter. Kundestøtte svarer på spørsmål om CVE-er du allerede har vurdert, ut fra publisert materiale. En CVE du ikke har vurdert ennå, får én PSIRT-sak, med hver kundehenvendelse knyttet til den. Bare en ny sårbarhet i din egen kode går gjennom hele avsløringsprosessen.

Hva sier FIRST PSIRT Services Framework om volum og automatisering?

Det regner med rapporter «gjennom ulike kanaler og i varierende kvalitet», tillater triage før saker opprettes når volumet er høyt, kaller et inventar over produktkomponenter «avgjørende for raskt å identifisere berørte produkter», og ber om automatiserte kanaler som sender sårbarhetsvarsler fra tredjeparter rett til utviklingsteamene for berørte produkter (funksjon 2.3.5).

Hva bør et PSIRT automatisere først?

Inventaret per versjon tatt fra bygget, deretter fortløpende matching av nye CVE-er mot hver støttet versjon. De to fjerner mest gjentatt arbeid: spørsmålet «hva er i den?» til utviklingsavdelingen og den nye skanningen ved forespørsel. Sammenslåing av dobbeltsaker, ruting, et søkbart bibliotek over VEX og advisories og CSAF-publisering kommer etterpå.

Hvordan får du utviklingsavdelingen til å svare PSIRT-et i tide?

Still utviklingsavdelingen færre spørsmål. Besvar «finnes komponenten i produktet?» ut fra byggeregistreringen, og send utviklingsavdelingen bare «kan dere rette det innen denne datoen?». Avtal en eier per produkt, responsmål per alvorlighetsgrad for rettingen og en formell risikoaksept når et mål ikke nås.

Hvorfor betyr en SBOM per utgivelse noe for et PSIRT?

Kundene kjører bestemte versjoner, ofte gamle. En SBOM av standardgrenen sier ingenting om versjon X fra to år tilbake. Én SBOM per levert versjon, registrert fra bygget som produserte den og tatt vare på i støtteperioden, er det som lar et PSIRT svare for hver versjon som fortsatt er i bruk, inkludert eksponeringsvinduet.

Vil kundene ha VEX eller advisories?

Begge, for ulike statuser. VEX forteller kundenes skannere hvilke CVE-er som ikke berører et produkt, så funnene forsvinner. Advisories forteller folk hva som er berørt, hva som er rettet og hva de skal gjøre. Når du publiserer begge, maskinlesbart der du kan, besvarer du de fleste spørsmål før de blir stilt.