Du kan inte anställa dig ur en växande mängd förfrågningar, och du kan inte triagera snabbare för evigt. Ett PSIRT skalar genom att besvara de flesta ”är vi drabbade?”-frågor med data som registrerades när varje version byggdes, och genom att publicera svaret innan kunderna frågar. Det dyra steget i dag är att fråga utvecklingsavdelningen vad en produkt innehåller. Flytta det steget till byggtiden, så blir de flesta förfrågningar uppslag som supporten kan stänga.
Det här inlägget förutsätter att du redan driver ett PSIRT; om du håller på att bygga upp ett, börja med vad ett PSIRT är och hur du bygger ett. Nedan: varför volymen har förändrats, vart tiden tar vägen i det vanliga flödet och vad du ska ändra, i tur och ordning.
Varför volymen har förändrats
Ökningen är strukturell, inte ett dåligt kvartal. Fyra saker trycker på samma kö samtidigt.
Fler CVE:er. CVE-programmet publicerade 39 718 CVE-poster 2024 och 47 801 under 2025. Under 2026 passerade antalet hela 2025 års total långt innan året var slut; vår liveöversikt över CVE-publiceringar följer det dag för dag. FIRST:s uppdaterade sårbarhetsprognos för 2026 (15 juni 2026) höjde uppskattningen för året till omkring 66 000 CVE:er och angav orsaken rakt ut: AI kan hitta betydligt fler brister än mänskliga analytiker, och ”begränsningen är inte längre att upptäcka; det är den mänskliga förmågan att verifiera, samordna och patcha”. Ett PSIRT är den mänskliga förmågan.
Kunderna skannar din produkt. Kunder kör skannrar mot dina avbilder, din firmware och dina enheter och skickar vidare varje fynd som ett ärende. De flesta av fynden är skannerbrus om komponenter du inte levererar eller versioner som inte är berörda, och bruset blir din mottagning. Minska sårbarhetsbruset tar upp skannersidan.
Regelverk lägger till klockor. Sedan den 11 september 2026 gäller rapporteringsskyldigheterna i EU:s Cyber Resilience Act. En aktivt utnyttjad sårbarhet i en produkt som säljs i EU kräver en tidig varning inom 24 timmar från att tillverkaren fått kännedom om den.
Mindre hjälp från NVD. Den 15 april 2026 gick NIST över till riskbaserad berikning i National Vulnerability Database: CVE:er i CISA:s KEV-katalog, programvara som används av den federala förvaltningen och kritisk programvara enligt EO 14028 kommer först, och resten markeras ”Lowest Priority - not scheduled for immediate enrichment” (lägsta prioritet, inte schemalagd för omedelbar berikning). Färre CVE:er kommer med CPE-data, så matchning på produktnamn blir sämre precis när volymen ökar.
| Drivkraft | Vad den gör med PSIRT:s kö |
|---|---|
| CVE-volym, AI-stödd upptäckt | Fler CVE:er från tredje part att bedöma per produkt, varje månad |
| Kundernas skanningar | Fler förfrågningar per CVE, många om komponenter du inte levererar |
| CRA-rapportering | En 24-timmarsklocka för aktivt utnyttjade sårbarheter |
| Mindre berikning i NVD | Mer manuellt arbete för att koppla en CVE till produkterna den rör |
Vart tiden tar vägen: förfrågningsflödet som det oftast ser ut
Vi hör samma flöde från produktsäkerhetsteam gång på gång. Ett PSIRT på två personer hos en hårdvaruleverantör beskrev det för oss så här: en kund frågar supporten, supporten skickar frågan till PSIRT via CRM-systemet, ärendet hamnar i PSIRT:s ärendesystem, PSIRT utreder de produkter som kunderna frågar mest om, lämnar sedan över frågan till utvecklingen och väntar.
Ta en förfrågan som exempel. En kund skickar vidare en skannerrapport som listar 40 CVE:er mot firmwareversion X. Supporten öppnar ett ärende och bifogar rapporten, men inte det exakta bygge som kunden kör. PSIRT kontrollerar vilka av de 40 som redan har bedömts, hittar ett dussin som inte har det och frågar det ansvariga utvecklingsteamet om komponenterna finns i version X. Utvecklingen måste hitta källkoden för version X, ta reda på vilka beroendeversioner som ingick och svara. Siffrorna är påhittade; mönstret är det inte.
Själva analysen är sällan det som tar tid. Två dolda kostnader är:
- Samma CVE utreds på nytt för varje kund som frågar. När svaret finns i en e-posttråd börjar nästa kund om utredningen från början.
- ”De mest efterfrågade produkterna först” lämnar den långa svansen obesvarad. Äldre produkter som fortfarande används kontrolleras aldrig, och det är ofta där risken finns: äldre komponenter, färre uppdateringar, färre personer som minns hur de byggdes.
Mottagning: skilj frågor från rapporter
En forskares sårbarhetsrapport och en kunds ”är vi drabbade?” är olika arbeten, och de behöver olika vägar. FIRST PSIRT Services Framework räknar redan med rörig indata: ett PSIRT bör ”räkna med att ta emot sårbarheter via olika kanaler och av varierande kvalitet” (delfunktion 2.1.1.1). Tjänsteområdet för triage går längre: ”Där organisationer tar emot en stor mängd sårbarhetsrapporter kan de överväga att göra en första triage för att validera rapporterna innan ärenden skapas.” Se det som ett tillstånd att inte öppna ett PSIRT-ärende för varje förfrågan.
Dela upp förfrågningarna hos supporten i tre vägar:
| Kunden frågar om | Väg | Vem svarar |
|---|---|---|
| En publicerad CVE i en tredjepartskomponent som du redan har bedömt | Svara utifrån det publicerade VEX-uttalandet eller säkerhetsmeddelandet; inget PSIRT-ärende | Supporten |
| En publicerad CVE som du ännu inte har bedömt | Ett PSIRT-ärende per CVE, inte per kund; koppla varje förfrågan till det | PSIRT, sedan svarar supporten alla kopplade kunder |
| En ny sårbarhet i din egen kod | En sårbarhetsrapport: hela processen för samordnat offentliggörande av sårbarheter | PSIRT |
Supporten behöver två saker för att arbeta med den första vägen: en sökbar lista över bedömda CVE:er per produkt och version, och svarsmallar. Hur du svarar kunder efter en attack mot leveranskedjan har mallar som du kan anpassa.
Registrera produkten och den exakta version som kunden kör redan vid mottagningen. Utan versionen blir varje svar ”det beror på”, och ärendet kommer tillbaka.
Prioritera efter exponering, inte bara popularitet
”De mest efterfrågade produkterna först” är en rimlig tumregel. Den behöver en andra axel. Behåll populariteten (installerad bas, intäkter, hur ofta supporten frågar) och lägg till exponering: stöds produkten fortfarande, är den nåbar från internet i typiska driftsättningar, och finns CVE:n i CISA:s KEV-katalog eller ligger den högt i EPSS? Guiden om prioritering av sårbarheter går igenom signalerna på djupet.
| Låg exponering | Hög exponering | |
|---|---|---|
| Stor installerad bas | Svara utifrån inventeringen; publicera VEX för versioner som inte berörs | Utred först; säkerhetsmeddelande och rättning med kortast tidsfrist |
| Liten installerad bas | Svara utifrån inventeringen på begäran; inget proaktivt arbete | Hoppa inte över den: svara utifrån inventeringen och besluta sedan om en rättning eller ett meddelande om mitigering |
Poängen med matrisen är den vänstra kolumnen och den nedersta raden. Den långa svansen får ett svar utifrån data, inte från en utredning som ingen har tid med.
Enligt CRA avgör den supportperiod som du har angett för varje produkt vilka äldre produkter du fortfarande är skyldig svar och säkerhetsuppdateringar för (vad CRA kräver).
Överlämningen till utvecklingen är flaskhalsen
Det här avsnittet är för den utvecklingschef som tar emot PSIRT:s eskaleringar.
PSIRT:s tidsfrister är offentliga: en kund, en tillsynsmyndighet eller ett datum för offentliggörande väntar. Utvecklingens tidsfrister är det oftast inte, så PSIRT får ta glappet. Ett kritiskt problem som lämnas över en måndag utan svar på tisdagen lämnar två dagar innan det offentliga svaret ska komma.
PSIRT skickar två olika frågor till utvecklingen, och bara en av dem borde behöva utvecklingen:
- ”Finns komponenten i produkten?” är en datafråga. Den bör besvaras utifrån en registrering, inte av en person som läser byggfiler.
- ”Kan ni rätta det till datum X?” är en arbetsfråga. Den hör hemma hos utvecklingen.
FIRST-ramverket beskriver hur du tar bort den första frågan från utvecklingens bord. Funktion 2.3.5 ber PSIRT att ”upprätta automatiserade kanaler för att distribuera identifierade sårbarhetsaviseringar från tredje part direkt till utvecklingsteamen för de berörda produkterna”, så att säkerhetsmeddelanden från tredje part hanteras i utvecklingsprocessen och PSIRT hanterar färre av dem för hand.
Kom överens med utvecklingen om tre saker:
- En ägare per produkt. Hos stora leverantörer är åtgärdsarbetet spritt över produktteamen; ramverkets distribuerade modell finns eftersom den låter PSIRT-uppdraget skala genom de utvecklare som äger produkterna.
- Svarsmål per allvarlighetsgrad, nedskrivna, för rättningen snarare än för utredningen.
- Vad som händer när ett mål missas. Funktion 4.2.4 kräver ”en process för formell riskacceptans för alla sårbarheter som inte åtgärdats inom tidskraven i de interna SLA:erna”. Någon med befogenhet skriver under på risken; den blir inte bara liggande öppen.
Takten för rättningar varierar. Ett team levererar en patch över natten, ett annat behöver en plattformsuppgradering på sex månader. Säkerhetsmeddelandet måste säga vilket, så att kunderna kan planera.
Gör ”är vi drabbade?” till ett uppslag: en SBOM för varje levererad version
Det här är förändringen som tar bort mest arbete. FIRST-funktion 2.3.1, inventeringen av produktkomponenter, kallar den ”nödvändig för att snabbt identifiera berörda produkter vid ärvda sårbarheter”. Mognadsnivåerna för PSIRT placerar ett produktregister med kartläggning av beroenden på mellannivån och bevakning av sårbarheter i produktkomponenter på den avancerade nivån.
En inventering tar bara bort arbete om den håller när volymen ökar. Varje krav nedan finns där av en anledning:
- En SBOM per levererad version, inte per repo och inte av standardgrenen. Kunder kör versioner, inte grenar.
- Tagen från bygget som producerade releasen. Ett senare ombygge, eller en skanning av dagens repo, beskriver en annan programvara (SBOM:er från byggtiden).
- Transitiva och dolda beroenden inkluderade. Det sårbara paketet är sällan ett som du själv har lagt till (transitiva beroenden), och installationsskript, basavbilder och återställda cachar drar in komponenter som ingen lockfil listar.
- En signal om fullständighet. En ofullständig registrering som behandlas som fullständig ger säkra svar om ”inte berörd” som är fel.
- Sparad så länge versionen stöds. Registreringen för en version från tre år sedan är den du kommer att behöva när ingen minns hur den byggdes.
- Leverantörers SBOM:er för inköpta komponenter, så att programvara från tredje part finns i samma inventering som din egen.
- Matchad på nytt löpande när nya CVE:er publiceras, i stället för omskannad när någon frågar.
Ett genomräknat exempel. En ny CVE publiceras i ett vanligt komprimeringsbibliotek. Utan inventeringen frågar PSIRT varje produktteam, svaren droppar in under flera dagar och de äldsta produkterna kontrolleras aldrig. Med den returnerar en enda fråga de berörda produkterna och versionerna, plus det första och det sista bygget som innehöll den sårbara versionen. Det är exponeringsfönstret som kunderna frågar om härnäst; är vi drabbade av en CVE? visar hur du fastställer det i ett enskilt fall.
Inbyggda system och Yocto-portföljer har det svårast. Skannrar som läser en färdig firmwareavbild måste gissa vad som kompilerades in i den, och team som vi pratar med har sett proof of concept med skannrar misslyckas på Yocto-baserade produkter. Att registrera bygget medan det körs gör gissningen onödig (Yocto-byggen på CRACI).
När en kund sedan ber om själva SBOM:en, i ett visst format, se besvara kunders SBOM-förfrågningar.
Utdatasidan: säkerhetsmeddelanden och VEX som svarar innan någon frågar
Den billigaste förfrågan är den som aldrig kommer.
- Publicera ”inte berörd” som VEX, så att kundernas skannrar slutar flagga CVE:n, och publicera ”berörd” och ”åtgärdad” som säkerhetsmeddelanden med exakta versioner.
- Gör det maskinläsbart. FIRST-delfunktion 5.3.2.3 föreslår att PSIRT ”överväger att publicera säkerhetsmeddelanden i ett maskinläsbart format som Common Security Advisory Framework (CSAF)”, så att kunderna kan läsa in dem med sina egna verktyg. CSAF-guiden beskriver hur du går från webbsidor och RSS-flöden till CSAF.
- Informera supporten innan du publicerar. Funktion 5.3.4: ”Att i förväg ge konfidentiell avisering och vanliga frågor om kommande säkerhetsmeddelanden förbereder dem som kan få frågor om dem vid publiceringen.” Supporten kan då svara samma dag.
- Skicka ut, publicera inte bara. Delfunktion 5.4.1.3 noterar att få sidvisningar på säkerhetsmeddelanden ”kan styra din strategi mot proaktiv avisering”. Flöden och aviseringar når kunder som aldrig besöker en sida med säkerhetsmeddelanden.
CRA gör en del av detta till en skyldighet. Artikel 14(8) kräver att tillverkaren, efter att ha fått kännedom om en aktivt utnyttjad sårbarhet eller en allvarlig incident, informerar de berörda användarna ”och, i förekommande fall, alla användare”, och gör det ”i förekommande fall i ett strukturerat, maskinläsbart format som lätt kan behandlas automatiskt”. Förordningen anger inget format.
Vad du ska automatisera, i tur och ordning
Varje steg tar bort en sorts arbete; mätvärdet visar om det gjorde det.
| Steg | Arbete som försvinner | Mätvärde som visar att det fungerade |
|---|---|---|
| 1. En inventering per version från bygget | Frågan ”vad finns i den?” till utvecklingen | Antalet utredningsförfrågningar till utvecklingen per månad minskar |
| 2. Löpande matchning av nya CVE:er mot varje version som stöds | Omskanning på begäran | Tid från publicering av CVE:n till beslut om berörd eller inte berörd |
| 3. Ett ärende per CVE, med förfrågningarna kopplade | Dubbla utredningar | Förfrågningar per ärende ökar, ärenden per CVE stannar på ett |
| 4. Automatisk dirigering av berörda fynd till det ansvariga teamet (FIRST 2.3.5) | Manuella överlämningar | Tid från beslut till att en ägare bekräftar det |
| 5. Ett sökbart bibliotek med publicerade VEX-uttalanden och säkerhetsmeddelanden | PSIRT:s inblandning i återkommande frågor | Andelen förfrågningar som supporten stänger |
| 6. Maskinläsbar publicering (CSAF) | Kunder som frågar efter det deras verktyg kunde ha hämtat | Förfrågningar per publicerat säkerhetsmeddelande minskar |
| 7. AI-stöd för att skriva utkast till säkerhetsmeddelanden och svar | Skrivtid | Tid från beslut till publicerat säkerhetsmeddelande |
AI kommer sist av en anledning. Den skriver bra utkast utifrån registrerade data, och den ska aldrig vara källan till beslutet om ”berörd”.
Vissa saker bör inte automatiseras: bedömningen ”inte berörd” och beslutet om allvarlighetsgrad ligger kvar hos en person, med underlaget bifogat. Automatiseringen avgör hur snabbt den personen får underlaget.
Mätvärden som visar att PSIRT skalar
- Andelen förfrågningar som besvaras utan ett PSIRT-ärende.
- Tid från publicering av en CVE till beslut om berörd eller inte berörd, per produkt.
- Utredningsförfrågningar till utvecklingen per månad. Antalet bör minska.
- Andelen åtgärder i tid per allvarlighetsgrad; ramverkets delfunktion 4.4.2.4 definierar det som hur väl produktteamen håller den överenskomna tiden från rapport till rättning.
- Täckningen av VEX och säkerhetsmeddelanden för de versioner som du fortfarande stöder.
Vi anger inga branschjämförelser för dessa. Ingen primärkälla som vi litar på publicerar någon.
Var CRACI passar in
CRACI täcker steg 1 och 2, och delar av steg 4 och 5, för programvara som byggs i GitHub Actions. Dina byggen körs på CRACI:s runners, och CRACI registrerar vad varje jobb faktiskt drog in medan det kördes: direkta och transitiva beroenden, paket som installeras av skript och paket som återställs från CI-cachar. Varje jobbs SBOM har en fullständighetsstatus, så att en ofullständig registrering aldrig misstas för en fullständig.
CRACI sparar bygghistoriken, så när en ny CVE publiceras ser du vilka byggen som innehöll det sårbara beroendet, och sedan när, så långt tillbaka som din lagring räcker. Bevakade SBOM:er utvärderas löpande på nytt, fynd sammanställs över byggen och repon, och leverantörers SBOM:er kan läggas till så att inköpta komponenter bevakas tillsammans med dina egna byggen. CRACI aviserar berörda personer om en ny sårbarhet och dess allvarlighetsgrad. Inventeringsvyn visar vilka programvaruversioner som är driftsatta i vilka produkter, och säkerhetsteam triagerar varje fynd i CRACI och skickar det till teamet som äger åtgärden. CRACI har stöd för VEX. Se CRACI för PSIRT och spårning av sårbarheter.
Se vilka av dina levererade versioner som innehåller en CVE.
När CRACI inte är svaret
- Din flaskhals är mottagning och ärendehantering, delen från CRM till ärendesystem. CRACI är inte ett verktyg för ärendehantering eller publicering av säkerhetsmeddelanden; för den halvan behöver du ett ärendeverktyg (PSIRT-verktyg jämförda).
- Dina produkter byggs inte i GitHub Actions på Linux-runners. GitHub Actions är den CI som stöds i dag; GitLab CI och Jenkins finns på färdplanen, utan datum.
- Du behöver binär- eller firmwareanalys av produkter som du inte har byggt själv. Det är vad verktyg för analys av utdata gör (säkerhetsverktyg för inbyggda system jämförda).
- Du behöver nåbarhetsanalys för att argumentera för ”inte berörd”. CRACI erbjuder det inte.
Vanliga frågor
Hur skalar man ett PSIRT utan att anställa?
Sluta utreda samma fråga gång på gång. Registrera vad varje levererad version innehåller när den byggs, matcha nya CVE:er mot det löpande, besluta en gång per CVE och publicera beslutet som VEX eller ett säkerhetsmeddelande som supporten kan hänvisa till. PSIRT arbetar då med de ärenden som verkligen är öppna, och utvecklingen ombeds rätta, inte utreda.
Hur bör ett PSIRT hantera kunders förfrågningar om ”är vi drabbade?”?
Behandla dem som ett eget mottagningsflöde, skilt från sårbarhetsrapporter. Supporten besvarar frågor om CVE:er som du redan har bedömt utifrån publicerat material. En CVE som du ännu inte har bedömt får ett PSIRT-ärende, med varje kundförfrågan kopplad till det. Bara en ny sårbarhet i din egen kod går igenom hela processen för offentliggörande.
Vad säger FIRST PSIRT Services Framework om volym och automatisering?
Det räknar med rapporter ”via olika kanaler och av varierande kvalitet”, tillåter triage innan ärenden skapas när volymen är hög, kallar en inventering av produktkomponenter ”nödvändig för att snabbt identifiera berörda produkter” och efterfrågar automatiserade kanaler som skickar sårbarhetsaviseringar från tredje part direkt till utvecklingsteamen för berörda produkter (funktion 2.3.5).
Vad bör ett PSIRT automatisera först?
Inventeringen per version tagen från bygget, sedan löpande matchning av nya CVE:er mot varje version som stöds. De två tar bort mest upprepat arbete: frågan ”vad finns i den?” till utvecklingen och omskanningen på begäran. Deduplicering av ärenden, dirigering, ett sökbart bibliotek med VEX och säkerhetsmeddelanden samt publicering i CSAF kommer därefter.
Hur får man utvecklingen att besvara PSIRT:s frågor i tid?
Ställ färre frågor till utvecklingen. Besvara ”finns komponenten i produkten?” utifrån registreringen från bygget, och skicka bara ”kan ni rätta det till det här datumet?” till utvecklingen. Kom överens om en ägare per produkt, svarsmål per allvarlighetsgrad för rättningen och en formell riskacceptans när ett mål missas.
Varför spelar en SBOM per release roll för ett PSIRT?
Kunder kör specifika versioner, ofta gamla. En SBOM av standardgrenen säger ingenting om version X från för två år sedan. En SBOM per levererad version, registrerad från bygget som producerade den och sparad under supportperioden, är det som gör att ett PSIRT kan svara för varje version som fortfarande används, inklusive exponeringsfönstret.
Vill kunderna ha VEX eller säkerhetsmeddelanden?
Båda, för olika statusar. VEX talar om för kundernas skannrar vilka CVE:er som inte berör en produkt, så att fynden upphör. Säkerhetsmeddelanden talar om för människor vad som är berört, vad som är åtgärdat och vad de ska göra. Att publicera båda, maskinläsbart där det går, besvarar de flesta frågor innan de ställs.
