Rostoucímu objemu dotazů neutečete nabíráním lidí a triáž nemůžete zrychlovat donekonečna. PSIRT škáluje tak, že na většinu otázek „týká se nás to?“ odpovídá z dat zaznamenaných při buildu každé verze a že odpověď zveřejní dřív, než se zákazníci zeptají. Nejdražším krokem je dnes ptát se vývojářů, co je v produktu. Přesuňte tento krok do doby buildu a většina dotazů se změní ve vyhledání, které uzavře podpora.
Tento článek předpokládá, že PSIRT už provozujete; pokud ho teprve zakládáte, začněte článkem co je PSIRT a jak ho vybudovat. Níže najdete, proč se objem změnil, kam v obvyklém procesu mizí čas a co změnit, v jakém pořadí.
Proč se objem změnil
Nárůst je strukturální, ne špatné čtvrtletí. Na stejnou frontu tlačí najednou čtyři věci.
Více CVE. Program CVE zveřejnil v roce 2024 39 718 záznamů CVE a v roce 2025 47 801. V roce 2026 počet překonal celoroční výsledek roku 2025 dlouho před koncem roku; naše živé trendy ve zveřejňování CVE ho sledují den po dni. Aktualizace prognózy zranitelností na rok 2026 od FIRST (15. června 2026) zvýšila odhad pro tento rok na zhruba 66 000 CVE a příčinu pojmenovala přímo: AI dokáže najít výrazně více chyb než lidští analytici a „omezením už není objevování, ale lidská kapacita ověřovat, koordinovat a záplatovat“. PSIRT je právě touto lidskou kapacitou.
Zákazníci skenují váš produkt. Zákazníci spouštějí skenery proti vašim image, firmwaru a zařízením a každý nález přeposílají jako tiket. Většina těchto nálezů je šum skenerů týkající se komponent, které nedodáváte, nebo verzí, které zasaženy nejsou, a ten šum se stává vaším příjmem. Stranu skenerů pokrývá článek Omezení šumu zranitelností.
Regulace přidává lhůty. Od 11. září 2026 platí oznamovací povinnosti podle unijního Cyber Resilience Act. Aktivně zneužívaná zranitelnost v produktu prodávaném v EU vyžaduje včasné varování do 24 hodin od chvíle, kdy se o ní výrobce dozví.
Menší pomoc od NVD. 15. dubna 2026 převedl NIST databázi National Vulnerability Database na obohacování podle rizika: přednost mají CVE z katalogu KEV od CISA, software používaný federální vládou a kritický software podle EO 14028, a ostatní jsou označeny „Lowest Priority - not scheduled for immediate enrichment“. Méně CVE přichází s daty CPE, takže párování podle názvu produktu se zhoršuje právě ve chvíli, kdy objem roste.
| Faktor | Co dělá s frontou PSIRT |
|---|---|
| Objem CVE, objevování s pomocí AI | Každý měsíc více CVE třetích stran k posouzení u každého produktu |
| Skenování ze strany zákazníků | Více dotazů na každé CVE, mnoho o komponentách, které nedodáváte |
| Hlášení podle CRA | 24hodinová lhůta u aktivně zneužívaných zranitelností |
| Méně obohacování v NVD | Více ruční práce při přiřazování CVE k produktům, kterých se týká |
Kam mizí čas: obvyklý průběh vyřizování dotazů
Stejný proces slýcháme od týmů pro bezpečnost produktů znovu a znovu. Dvoučlenný PSIRT u výrobce hardwaru nám ho popsal takto: zákazník se zeptá podpory, podpora předá otázku přes CRM týmu PSIRT, případ skončí v trackeru PSIRT, PSIRT prověří produkty, na které se zákazníci ptají nejčastěji, pak otázku předá vývojářům a čeká.
Vezměme jeden ilustrativní dotaz. Zákazník přepošle report ze skeneru, který uvádí 40 CVE pro firmware ve verzi X. Podpora otevře případ a přiloží report, ale ne přesný build, který zákazník používá. PSIRT zkontroluje, která ze 40 CVE už posoudil, najde tucet neposouzených a zeptá se odpovědného vývojového týmu, zda jsou dané komponenty ve verzi X. Vývojáři musí najít zdrojový kód verze X, zjistit, které verze závislostí do ní vstoupily, a odpovědět. Čísla jsou vymyšlená; podoba procesu ne.
Samotná analýza zabírá čas jen zřídka. Dva skryté náklady jsou:
- Stejné CVE se prověřuje znovu pro každého zákazníka, který se zeptá. Když odpověď žije ve vlákně e-mailů, další zákazník začíná prověřování od začátku.
- „Nejdřív nejčastěji poptávané produkty“ nechává dlouhý chvost bez odpovědi. Starší produkty, které jsou stále v provozu, se nikdy nezkontrolují, a právě tam často leží riziko: starší komponenty, méně aktualizací, méně lidí, kteří si pamatují, jak byly sestaveny.
Příjem: oddělte otázky od hlášení
Hlášení zranitelnosti od výzkumníka a otázka zákazníka „týká se nás to?“ jsou různá práce a potřebují různé cesty. FIRST PSIRT Services Framework s neuspořádanými vstupy už počítá: PSIRT by měl „očekávat, že bude zranitelnosti dostávat různými kanály a v různé kvalitě“ (dílčí funkce 2.1.1.1). Jeho oblast služeb triáže jde dál: „Organizace, které dostávají velký objem hlášení zranitelností, mohou zvážit provedení úvodní triáže k ověření hlášení před vytvořením případů.“ Berte to jako svolení neotevírat případ PSIRT pro každý dotaz.
Rozdělte dotazy už na podpoře do tří cest:
| Zákazník se ptá na | Cesta | Kdo odpovídá |
|---|---|---|
| Zveřejněné CVE v komponentě třetí strany, které jste už posoudili | Odpověď ze zveřejněného prohlášení VEX nebo bezpečnostního upozornění; bez případu PSIRT | Podpora |
| Zveřejněné CVE, které jste ještě neposoudili | Jeden případ PSIRT na CVE, ne na zákazníka; každý dotaz se k němu připojí | PSIRT, pak podpora odpoví všem připojeným |
| Novou zranitelnost ve vašem vlastním kódu | Hlášení zranitelnosti: celý proces koordinovaného zveřejňování zranitelností | PSIRT |
Aby podpora zvládla první cestu, potřebuje dvě věci: prohledávatelný seznam posouzených CVE pro každý produkt a verzi a šablony odpovědí. Článek Jak odpovídat zákazníkům po útoku na dodavatelský řetězec obsahuje šablony, které si můžete upravit.
Při příjmu zaznamenejte produkt a přesnou verzi, kterou zákazník používá. Bez verze je každá odpověď „záleží na tom“ a případ se vrátí.
Prioritizujte podle expozice, ne jen podle popularity
„Nejdřív nejčastěji poptávané produkty“ je rozumná heuristika. Potřebuje ale druhou osu. Ponechte popularitu (instalovaná základna, tržby, jak často se ptá podpora) a přidejte expozici: je produkt stále podporovaný, je v typických nasazeních dostupný z internetu a je CVE v katalogu KEV od CISA nebo vysoko v EPSS? Signály podrobně rozebírá průvodce prioritizací zranitelností.
| Nízká expozice | Vysoká expozice | |
|---|---|---|
| Velká instalovaná základna | Odpověď z inventáře; zveřejnění VEX pro nezasažené verze | Prověřit nejdřív; bezpečnostní upozornění a oprava v nejkratší lhůtě |
| Malá instalovaná základna | Odpověď z inventáře na vyžádání; žádná proaktivní práce | Nevynechávat: odpověď z inventáře, pak rozhodnutí o opravě nebo o oznámení náhradního řešení |
Smyslem matice je levý sloupec a spodní řádek. Dlouhý chvost dostane odpověď z dat, ne z prověřování, na které nikdo nemá čas.
Podle CRA rozhoduje doba podpory, kterou jste pro každý produkt deklarovali, o tom, kterým starším produktům stále dlužíte odpovědi a bezpečnostní aktualizace (co CRA požaduje).
Úzkým hrdlem je předání vývojářům
Tato část je pro vedoucího vývoje, ke kterému přicházejí eskalace od PSIRT.
Lhůty PSIRT jsou veřejné: čeká zákazník, regulátor nebo datum zveřejnění. Lhůty vývoje obvykle veřejné nejsou, takže rozdíl pohltí PSIRT. Kritický problém předaný v pondělí bez odpovědi do úterý nechává dva dny do termínu veřejné odpovědi.
PSIRT posílá vývojářům dvě různé otázky a jen jedna z nich by vývojáře měla potřebovat:
- „Je komponenta v produktu?“ je otázka na data. Měla by se zodpovědět ze záznamu, ne tak, že člověk čte soubory buildu.
- „Dokážete to opravit do data X?“ je otázka na práci. Ta patří vývojářům.
Framework FIRST říká, jak první otázku vývojářům ze stolu sejmout. Funkce 2.3.5 žádá, aby PSIRT „zavedly automatizované kanály, které budou zjištěná oznámení o zranitelnostech třetích stran distribuovat přímo vývojovým týmům zasažených produktů“, aby se bezpečnostní upozornění třetích stran zpracovávala ve vývojovém procesu a PSIRT jich ručně řešil méně.
Dohodněte se s vývojáři na třech věcech:
- Vlastník pro každý produkt. U velkých výrobců je náprava rozložena mezi produktové týmy; distribuovaný model frameworku existuje proto, že umožňuje škálovat poslání PSIRT prostřednictvím vývojářů, kteří produkty vlastní.
- Cílové doby reakce podle závažnosti, sepsané, a to pro opravu, ne pro prověření.
- Co se stane, když se cíl nesplní. Funkce 4.2.4 žádá „proces formálního přijetí rizika u všech zranitelností, které nebyly napraveny v časových požadavcích interních SLA“. Riziko podepíše někdo s pravomocí; nezůstane jen tak otevřené.
Tempo oprav se liší. Jeden tým vydá záplatu přes noc, jiný potřebuje šestiměsíční upgrade platformy. Bezpečnostní upozornění musí říct, o který případ jde, aby si zákazníci mohli naplánovat další kroky.
Udělejte z „týká se nás to?“ vyhledání: SBOM pro každou dodanou verzi
Toto je změna, která odstraní nejvíc práce. Funkce FIRST 2.3.1, inventář komponent produktu, ho označuje za „nezbytný pro rychlou identifikaci produktů zasažených zděděnými zranitelnostmi“. Úrovně vyspělosti PSIRT řadí registr produktů s mapováním závislostí na střední úroveň a monitorování zranitelností komponent produktu na pokročilou.
Inventář ubere práci jen tehdy, když obstojí i při velkém objemu. Každý z následujících požadavků má svůj důvod:
- Jedna SBOM pro každou dodanou verzi, ne pro repozitář a ne z výchozí větve. Zákazníci používají verze, ne větve.
- Převzatá z buildu, který vydání vytvořil. Pozdější nový build nebo sken dnešního repozitáře popisují jiný software (SBOM z doby buildu).
- Včetně tranzitivních a skrytých závislostí. Zranitelný balíček je jen zřídka ten, který jste přidali sami (tranzitivní závislosti), a instalační skripty, základní image a obnovené cache přinášejí komponenty, které neuvádí žádný lockfile.
- Signál úplnosti. Částečný záznam považovaný za úplný vede k sebejistým, ale chybným odpovědím „netýká se“.
- Uchovávaná, dokud je verze podporována. Záznam o verzi starší tří let je přesně ten, který budete potřebovat, až si nikdo nebude pamatovat, jak byla sestavena.
- SBOM od dodavatelů pro nakoupené komponenty, aby byl software třetích stran ve stejném inventáři jako váš vlastní.
- Průběžně znovu párovaná se zveřejňováním nových CVE, místo opětovného skenování, když se někdo zeptá.
Praktický příklad. Je zveřejněno nové CVE v široce používané kompresní knihovně. Bez inventáře se PSIRT ptá každého produktového týmu, odpovědi přicházejí po kapkách celé dny a nejstarší produkty se nikdy nezkontrolují. S inventářem vrátí jediný dotaz zasažené produkty a verze a k tomu první a poslední build, který zranitelnou verzi obsahoval. To je okno expozice, na které se zákazníci zeptají hned potom; článek Týká se nás CVE? ukazuje, jak ho určit pro jednotlivý případ.
Nejtěžší to mají portfolia embedded produktů a Yocto. Skenery, které čtou hotový image firmwaru, musí odhadovat, co do něj bylo zkompilováno, a týmům, se kterými mluvíme, selhaly testy proof of concept se skenery na produktech postavených na Yocto. Záznam buildu během jeho běhu odhadování odstraní (buildy Yocto na CRACI).
Když pak zákazník požádá o samotnou SBOM v určitém formátu, podívejte se na odpovídání na žádosti zákazníků o SBOM.
Výstupní strana: bezpečnostní upozornění a VEX, které odpoví dřív, než se kdo zeptá
Nejlevnější dotaz je ten, který nikdy nepřijde.
- Zveřejňujte „netýká se“ jako VEX, aby skenery zákazníků přestaly CVE hlásit, a „týká se“ a „opraveno“ zveřejňujte jako bezpečnostní upozornění s přesnými verzemi.
- Udělejte to strojově čitelné. Dílčí funkce FIRST 5.3.2.3 navrhuje, aby PSIRT „zvážily zveřejňování bezpečnostních upozornění ve strojově čitelném formátu, jako je Common Security Advisory Framework (CSAF)“, aby je zákazníci mohli zpracovávat vlastními nástroji. Průvodce CSAF popisuje, jak přejít od webových stránek a kanálů RSS k CSAF.
- Připravte podporu před zveřejněním. Funkce 5.3.4: „Poskytnutí předběžného důvěrného oznámení a častých dotazů k připravovaným bezpečnostním upozorněním připraví ty, kterých se na ně mohou po zveřejnění ptát.“ Podpora pak může odpovídat hned v den zveřejnění.
- Doručujte, nejen vyvěšujte. Dílčí funkce 5.4.1.3 uvádí, že nízká návštěvnost stránek s bezpečnostními upozorněními „může vaši strategii přivést k proaktivnímu oznamování“. Kanály a oznámení se dostanou i k zákazníkům, kteří stránku s upozorněním nikdy nenavštíví.
CRA z části z toho dělá povinnost. Článek 14(8) požaduje, aby výrobce poté, co se dozví o aktivně zneužívané zranitelnosti nebo závažném incidentu, informoval dotčené uživatele „a případně všechny uživatele“, a to „případně ve strukturovaném, strojově čitelném formátu, který lze snadno automaticky zpracovat“. Nařízení žádný formát neurčuje.
Co automatizovat a v jakém pořadí
Každý krok odstraní určitý druh práce; metrika ukáže, zda se to podařilo.
| Krok | Práce, kterou odstraní | Metrika, která ukáže úspěch |
|---|---|---|
| 1. Inventář pro každou verzi převzatý z buildu | Otázka „co v tom je?“ na vývojáře | Počet žádostí o prověření vývojáři za měsíc klesá |
| 2. Průběžné párování nových CVE s každou podporovanou verzí | Opětovné skenování na vyžádání | Doba od zveřejnění CVE do rozhodnutí „týká se“ nebo „netýká se“ |
| 3. Jeden případ na CVE s připojenými dotazy | Zdvojená prověřování | Počet dotazů na případ roste, počet případů na CVE zůstává jeden |
| 4. Automatické směrování zasažených nálezů odpovědnému týmu (FIRST 2.3.5) | Ruční předávání | Doba od rozhodnutí do potvrzení vlastníkem |
| 5. Prohledávatelná knihovna zveřejněných prohlášení VEX a bezpečnostních upozornění | Zapojení PSIRT do opakovaných otázek | Podíl dotazů uzavřených podporou |
| 6. Strojově čitelné zveřejňování (CSAF) | Zákazníci žádající o to, co si jejich nástroje mohly samy stáhnout | Počet dotazů na zveřejněné bezpečnostní upozornění klesá |
| 7. Pomoc AI při psaní bezpečnostních upozornění a odpovědí | Čas na psaní | Doba od rozhodnutí do zveřejnění bezpečnostního upozornění |
AI je na konci záměrně. Nad zaznamenanými daty píše návrhy dobře, ale nikdy by neměla být zdrojem rozhodnutí „týká se“.
Některé věci by se automatizovat neměly: úsudek „netýká se“ a určení závažnosti zůstávají na člověku, s přiloženými důkazy. Automatizace rozhoduje o tom, jak rychle ten člověk důkazy dostane.
Metriky, které ukazují, že PSIRT škáluje
- Podíl dotazů zodpovězených bez případu PSIRT.
- Doba od zveřejnění CVE do rozhodnutí „týká se“ nebo „netýká se“, pro každý produkt.
- Počet žádostí o prověření vývojáři za měsíc. Měl by klesat.
- Míra včasné nápravy podle závažnosti; dílčí funkce frameworku 4.4.2.4 ji definuje jako to, jak dobře produktové týmy dodržují dohodnutou dobu od hlášení po opravu.
- Pokrytí verzí, které stále podporujete, prohlášeními VEX a bezpečnostními upozorněními.
Oborové benchmarky pro tyto metriky neuvádíme. Žádný primární zdroj, kterému věříme, je nezveřejňuje.
Kam patří CRACI
CRACI pokrývá kroky 1 a 2 a části kroků 4 a 5 pro software sestavovaný v GitHub Actions. Vaše buildy běží na runnerech CRACI a CRACI během běhu zaznamenává, co každý job skutečně stáhl: přímé a tranzitivní závislosti, balíčky nainstalované skripty a balíčky obnovené z cache CI. SBOM každého jobu nese stav úplnosti, takže částečný záznam se nikdy nezamění za úplný.
CRACI uchovává historii buildů, takže když je zveřejněno nové CVE, vidíte, které buildy obsahovaly zranitelnou závislost a odkdy, a to tak daleko do minulosti, jak sahá vaše doba uchovávání. Monitorované SBOM se průběžně znovu vyhodnocují, nálezy se agregují napříč buildy a repozitáři a lze přidat SBOM od dodavatelů, takže nakoupené komponenty se monitorují vedle vašich vlastních buildů. CRACI upozorní příslušné lidi na novou zranitelnost a její závažnost. Pohled inventáře ukazuje, které verze softwaru jsou nasazené ve kterých produktech, a bezpečnostní týmy v CRACI provedou triáž každého nálezu a předají ho týmu, který vlastní opravu. CRACI podporuje VEX. Podívejte se na CRACI pro PSIRT a sledování zranitelností.
Zjistěte, které z vašich dodaných verzí obsahují CVE.
Kdy CRACI není řešením
- Vaším úzkým hrdlem je příjem a správa případů, tedy část od CRM k trackeru. CRACI není nástroj pro správu případů ani pro zveřejňování bezpečnostních upozornění; pro tuto polovinu potřebujete nástroj pro správu případů (srovnání nástrojů pro PSIRT).
- Vaše produkty se nesestavují v GitHub Actions na runnerech s Linuxem. Dnes je podporovaným CI GitHub Actions; GitLab CI a Jenkins jsou v plánu vývoje, bez data.
- Potřebujete binární analýzu nebo analýzu firmwaru u produktů, které jste sami nesestavili. To dělají nástroje pro analýzu výstupu (srovnání nástrojů pro bezpečnost embedded).
- Potřebujete analýzu dosažitelnosti, abyste mohli doložit „netýká se“. CRACI ji nenabízí.
Časté dotazy
Jak škálovat PSIRT bez nabírání lidí?
Přestaňte opakovaně prověřovat stejnou otázku. Zaznamenejte, co každá dodaná verze obsahuje, už při jejím buildu, průběžně s tím párujte nová CVE, rozhodněte jednou za CVE a rozhodnutí zveřejněte jako VEX nebo bezpečnostní upozornění, na které může podpora odkázat. PSIRT pak řeší skutečně otevřené případy a vývojáři jsou žádáni o opravu, ne o prověřování.
Jak by měl PSIRT vyřizovat dotazy zákazníků „týká se nás to?“?
Berte je jako samostatný proud příjmu, oddělený od hlášení zranitelností. Na otázky k CVE, které jste už posoudili, odpovídá podpora ze zveřejněných materiálů. CVE, které jste ještě neposoudili, dostane jeden případ PSIRT, ke kterému se připojí každý dotaz zákazníka. Celým procesem zveřejňování prochází jen nová zranitelnost ve vašem vlastním kódu.
Co říká FIRST PSIRT Services Framework o objemu a automatizaci?
Počítá s hlášeními „různými kanály a v různé kvalitě“, při vysokém objemu připouští triáž před vytvořením případů, inventář komponent produktu označuje za „nezbytný pro rychlou identifikaci zasažených produktů“ a žádá automatizované kanály, které posílají oznámení o zranitelnostech třetích stran přímo vývojovým týmům zasažených produktů (funkce 2.3.5).
Co by měl PSIRT automatizovat nejdřív?
Inventář pro každou verzi převzatý z buildu a potom průběžné párování nových CVE s každou podporovanou verzí. Tyto dva kroky odstraní nejvíce opakované práce: otázku „co v tom je?“ na vývojáře a opětovné skenování na vyžádání. Deduplikace případů, směrování, prohledávatelná knihovna VEX a bezpečnostních upozornění a zveřejňování v CSAF přicházejí potom.
Jak dosáhnout toho, aby vývojáři odpovídali na otázky PSIRT včas?
Klaďte vývojářům méně otázek. Na otázku „je komponenta v produktu?“ odpovězte ze záznamu buildu a vývojářům posílejte jen „dokážete to opravit do tohoto data?“. Dohodněte vlastníka pro každý produkt, cílové doby reakce podle závažnosti pro opravu a formální přijetí rizika, když se cíl nesplní.
Proč je SBOM pro každé vydání pro PSIRT důležitá?
Zákazníci používají konkrétní verze, často staré. SBOM výchozí větve neřekne nic o verzi X z doby před dvěma lety. Jedna SBOM pro každou dodanou verzi, zaznamenaná z buildu, který ji vytvořil, a uchovávaná po dobu podpory, umožňuje PSIRT odpovídat za každou verzi, která je stále v provozu, včetně okna expozice.
Chtějí zákazníci VEX, nebo bezpečnostní upozornění?
Obojí, pro různé stavy. VEX říká skenerům zákazníků, která CVE se produktu netýkají, takže nálezy přestanou. Bezpečnostní upozornění říkají lidem, co je zasaženo, co je opraveno a co dělat. Když zveřejníte obojí, pokud možno strojově čitelně, odpovíte na většinu otázek dřív, než je někdo položí.
