EU CRA 2026 sérülékenység-bejelentési felkészültségi útmutató

2026 szeptemberének egyik hétfő reggelén 08:17 van. Anna, egy gyorsan növekvő európai SaaS-vállalat CISO-ja, még mindig az előző heti igazgatósági ülésen gondolkodik. A vezérigazgató feltette azt a kérdést, amelyet most minden biztonsági vezető hall: „Ha már felkészültünk a NIS2-re, és fintech ügyfeleink folyamatosan DORA-val kapcsolatos kérdéseket tesznek fel, mit változtat a Cyber Resilience Act?”

A válasz ezután megérkezik a postaládájába.

Egy független kutató távolról kihasználható sérülékenységet jelent a vállalat egyik összekapcsolt termékében használt firmware-frissítési komponensben. Az üzenet tartalmaz egy PoC-t, egy függőség nevét, valamint figyelmeztetést arra, hogy hasonló kihasználást már megfigyeltek éles környezetben.

Perceken belül mindenki más választ vár. A CTO azt kérdezi, valós-e a sérülékenység. A jogi terület azt kérdezi, kiváltódott-e az EU Cyber Resilience Act szerinti jelentéstétel. A termékcsapat azt kérdezi, mely verziók érintettek. A CISO azt kérdezi, szerepel-e a függőség bármely SBOM-ban. Az értékesítés azt kérdezi, szükségük van-e a pénzügyi szektorbeli ügyfeleknek DORA szerinti bizonyítékokra. A megfelelőségi vezető megnyitja az ISO 27001 kockázati nyilvántartást, és talál benne sérülékenységkezelési folyamatot, de nem talál egyértelmű döntési útvonalat a termékhez kapcsolódó jelentéstételhez.

Ez a CRA-ra való felkészülés valódi problémája. A legtöbb szervezet nem nulláról indul. Már rendelkezik incidenskezelési szabályzatokkal, javításkezelési rutinokkal, biztonságos fejlesztési gyakorlattal, beszállítói felülvizsgálatokkal, sérülékenységvizsgáló eszközökkel és ISO 27001 bizonyítékokkal. A CRA azonban nem az elszigetelt dokumentumokat jutalmazza. Gyors, igazolható munkafolyamatot követel meg, amely egyszerre öt kérdésre tud választ adni:

1. Aktívan kihasznált sérülékenységről vagy a termékbiztonságot érintő súlyos incidensről van szó?
2. Mely termékek, verziók, ügyfelek, függőségek és beszállítók érintettek?
3. Mely hatóságot, ügyfelet vagy szerződéses címzettet kell értesíteni, és mikor?
4. Milyen bizonyíték igazolja, hogy az elsődleges értékelés, a kockázatcsökkentés és a közzététel kontrollált módon történt?
5. Hogyan van ez összhangban az ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF és auditelvárásokkal?

A válasz nem egy külön „CRA-mappa”. A válasz az, hogy a CRA szerinti sérülékenység-bejelentést be kell építeni az IBIR-be, a koordinált sérülékenység-feltárási folyamatba, az SBOM-fegyelembe, a beszállítói irányításba és az incidenskezelési bizonyítékláncba, amelyekre az érett kiberbiztonsági irányításhoz egyébként is szükség van.

Miért változtatja meg az EU Cyber Resilience Act a jelentéstételi modellt

Az EU Cyber Resilience Act, az (EU) 2024/2847 rendelet, a termékbiztonságot a megfelelés főáramába emeli. Az EU piacán forgalomba hozott, digitális elemeket tartalmazó termékekre alkalmazandó, ideértve többek között az összekapcsolt eszközöket, szoftvereket, firmware-eket, beágyazott rendszereket és vállalati szoftvertermékeket.

A CISO-k, termékbiztonsági vezetők és megfelelőségi csapatok számára legfontosabb működési változás 2026. szeptember 11-én kezdődik. A CRA Article 14 szakaszos jelentéstételt ír elő az aktívan kihasznált sérülékenységekre és a digitális elemeket tartalmazó termékek biztonságát érintő súlyos incidensekre. Gyakorlati értelemben a gyártóknak fel kell készülniük a következőkre:

A pontos jogi értékelést mindig megfelelően képzett jogi tanácsadónak kell elvégeznie, de a működési tanulság egyértelmű. Az első 24–72 óra minőségét az határozza meg, milyen előkészületek történtek hónapokkal korábban.

Ha az SBOM-ok hiányosak, ha a CVD-postaládát informálisan figyelik, ha a beszállítói szerződések nem írnak elő sérülékenységi értesítést, vagy ha az incidenskezelési szabályzat nem különbözteti meg a terméksérülékenységre vonatkozó jelentéstételt az adatvédelmi vagy működési incidensektől, a jogi határidő gyorsabban fog haladni, mint a bizonyítékkezelési folyamat.

Használja az ISO/IEC 27001:2022-t a CRA-felkészülés irányítási vázaként

Az ISO/IEC 27001:2022 nem helyettesíti a CRA szerinti jogi megfelelést, de a legjobb irányítási rendszeri vázat adja ahhoz, hogy a CRA-kötelezettségeket beépítsük a napi irányításba.

A 4.1–4.4 pontok előírják, hogy a szervezet megértse a belső és külső környezetét, az érdekelt feleket, a követelményeket, a más szervezetekkel fennálló kapcsolódási pontokat és az IBIR alkalmazási területét ISO/IEC 27001:2022. A CRA-ra való felkészüléshez ez azt jelenti, hogy az IBIR alkalmazási területének azonosítania kell a digitális elemeket tartalmazó termékeket, a termék-életciklushoz kapcsolódó felelősségeket, a hosztolt komponenseket, a buildfolyamatokat, a nyílt forráskódú függőségeket, a beszállítókat, a felhasználókat, az importőröket, a forgalmazókat, a szabályozott ügyfeleket és az érintett hatóságokat.

A 6.1.1–6.1.3 pontok kockázatértékelést és kockázatkezelést írnak elő, ideértve a kockázattulajdonosokat, következményeket, valószínűséget, kezelési döntéseket, az alkalmazhatósági nyilatkozatot és a fennmaradó kockázat elfogadását. A CRA szerinti jelentéstételt ebben a folyamatban termékbiztonsági kockázati forgatókönyvként kell kezelni, nem pedig sürgősségi jogértelmezési gyakorlatként.

Az ISO/IEC 27002:2022 ISO/IEC 27002:2022 ezt követően biztosítja a gyakorlati kontrollstruktúrát. A CRA szerinti sérülékenység-bejelentés szempontjából a legfontosabb kontrollok:

A Zenith Controls: The Cross-Compliance Guide keretében a Clarysec az ISO/IEC 27002:2022 8.8 kontrollját, a technikai sérülékenységek kezelését megelőző kontrollként térképezi fel, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást. Attribútumai az Identify és Protect kiberbiztonsági fogalmakhoz igazodnak, működési képességként pedig a fenyegetés- és sérülékenységkezelést jelölik meg.

Ez a keretezés fontos. A CRA szerinti jelentéstétel nem pusztán a hatóságok értesítéséről szól. Annak igazolásáról is szól, hogy a jelentés beérkezése előtt már létezett megelőző sérülékenységkezelési képesség.

Építse a működési modellt a CVD, az SBOM és a jelentéstételi határidők köré

A hiteles CRA szerinti sérülékenységi munkafolyamat azelőtt kezdődik, hogy egy kutató kapcsolatba lépne Önnel. Azzal kezdődik, hogy a szervezet képes sérülékenységi bejelentéseket fogadni, azokat ellenőrizni, az érintett komponenseket azonosítani, a kihasználást értékelni, a kockázatcsökkentést koordinálni, a felhasználókkal kommunikálni és a bizonyítékokat megőrizni.

Az első építőelem egy nyilvános sérülékenység-bejelentési csatorna. A Clarysec Coordinated Vulnerability Disclosure Policy szabályzatának végrehajtási követelmények 6.1 pontja kimondja:

Nyilvános bejelentési csatornák: A szervezetnek egyértelmű csatornát kell fenntartania a sérülékenységek bejelentésére, például külön biztonsági kapcsolattartói e-mail címet (például security@company.com) vagy webes űrlapot. Ezt az információt a vállalati weboldal biztonsági oldalán közzé kell tenni a szervezet PGP nyilvános kulcsával együtt, hogy a bejelentések titkosítottan benyújthatók legyenek.

Ez egy gyakori audithibát kezel. Sok vállalat állítja, hogy fogad sérülékenységi bejelentéseket, de a bejelentési út rejtett, nincs kijelölt felelőse, vagy általános támogatási sorba kerül. CRA-körülmények között a bejelentési csatorna a jogi tudomásszerzés, a súlyosságértékelés és a bizonyítékrögzítés kiváltó pontjává válik.

A második építőelem az elsődleges értékelés. A Coordinated Vulnerability Disclosure Policy végrehajtási követelmények 6.4 pontja kimondja:

Elsődleges értékelés és visszaigazolás: A bejelentés beérkezésekor a VRT köteles azt rögzíteni, és 2 munkanapon belül visszaigazolást küldeni a bejelentőnek egy nyomonkövetési hivatkozás hozzárendelésével. A VRT köteles előzetes súlyosságértékelést végezni, például CVSS-pontozás alkalmazásával, és a problémát – szükség esetén az IT- és fejlesztőcsapatok támogatásával – 5 munkanapos célhatáridőn belül ellenőrizni. A kritikus sérülékenységeket, például a távoli kódfuttatást vagy jelentős adatsértést lehetővé tevő hibákat, gyorsított eljárásban kell kezelni.

A CRA-ra való felkészüléshez ezt az elsődleges értékelési bejegyzést olyan mezőkkel kell bővíteni, amelyek támogatják a jogi jelentéstételi döntést:

A harmadik építőelem az SBOM-fegyelem. A Clarysec Secure Development Policy szabályzatának irányítási követelmények 5.4 pontja kimondja:

A nyílt forráskódú vagy harmadik féltől származó kód használatát jóvá kell hagyni, nyomon kell követni, és a következők útján kell ellenőrizni: 5.4.1 Szoftverösszetétel-elemzés (SCA) 5.4.2 Licencfelülvizsgálat (GPL, MIT, BSD stb.) 5.4.3 Ismert sérülékenységek vizsgálata (CVE-k, OSS Index stb.)

Kisebb szervezetek esetében a Clarysec Application Security Requirements Policy - SME szabályzata, a szabályzat végrehajtásának követelményei 6.4.2 pontja ugyanezt az elvárást gyakorlati formában rögzíti:

Minden felhasznált külső komponensről nyilvántartást kell vezetnie a fejlesztőnek vagy az IT-szolgáltatónak, beleértve:

Ez a komponensnyilvántartás lesz az SBOM-alapú sérülékenységkezelési reagálás minimális bizonyítékkészlete. Kapcsolnia kell a komponens nevét, verzióját, forrását, beszállítóját vagy adattárát, licencét, termékverzióját, builddátumát és sérülékenységvizsgálati állapotát. Amikor CVE, kutatói bejelentés vagy beszállítói értesítés érkezik, a csapatnak órákon belül választ kell tudnia adni erre: „Mely kiadott termékek tartalmazzák ezt a komponenst?”

Képezze le a CRA, NIS2, DORA és GDPR követelményeit egyetlen értesítési döntési mátrixba

A Cyber Resilience Act nem elszigetelten fog működni. Egyetlen terméksérülékenység CRA szerinti jelentéstételt, NIS2 incidensértékelést, DORA szerinti ügyfélbizonyíték-kötelezettségeket, GDPR szerinti személyesadat-sértési értékelést és szerződéses értesítési kötelezettségeket is kiválthat.

A NIS2 Article 21 előírja, hogy az alapvető és fontos szervezetek megfelelő technikai, működési és szervezeti intézkedéseket vezessenek be. Ezek az intézkedések magukban foglalják a kockázatelemzést, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a biztonságos beszerzést, fejlesztést és karbantartást, a sérülékenységkezelést és -feltárást, az eredményesség értékelését, a kiberhigiéniát, a kriptográfiát, a HR-biztonságot, a hozzáférés-szabályozást, az eszközkezelést, a többtényezős hitelesítést és a biztonságos kommunikációt.

A NIS2 Article 23 szakaszos incidensjelentési modellt határoz meg: korai figyelmeztetés a tudomásszerzéstől számított 24 órán belül, incidensértesítés 72 órán belül, közbenső frissítések kérés esetén, valamint végleges jelentés legkésőbb az incidensértesítést követő egy hónapon belül. A NIS2 Article 20 emellett vezető testületi elszámoltathatóságot hoz létre a kiberbiztonsági kockázatkezelési intézkedések jóváhagyására és felügyeletére.

A DORA 2025. január 17-től alkalmazandó, és egységes uniós digitális működési reziliencia-keretrendszert hoz létre a pénzügyi szervezetek számára. SaaS-szolgáltatók, szoftverbeszállítók és IKT-beszállítók esetében a DORA gyakran ügyfélszerződéseken keresztül jelenik meg. A pénzügyi szektorbeli ügyfél lehet a DORA által szabályozott szervezet, de az Ön sérülékenységkezelése, SBOM-bizonyítékai, incidenstámogatása, auditálási jogai és értesítési vállalásai szükségesek lehetnek ahhoz, hogy az ügyfél teljesítse saját kötelezettségeit.

A GDPR egy újabb ágat ad hozzá. Ha a sérülékenység vagy incidens személyes adatok véletlen vagy jogellenes megsemmisítését, elvesztését, megváltoztatását, jogosulatlan közlését vagy azokhoz való hozzáférést okoz, személyesadat-sértési értékelés szükséges. A GDPR Article 5 tartalmazza a sértetlenséget, bizalmasságot és elszámoltathatóságot is, ami azt jelenti, hogy a szervezetnek képesnek kell lennie döntéshozatalának igazolására.

A Clarysec Incident Response Policy szabályzata, a szabályzat végrehajtásának követelményei 6.4.1 pontja már támogatja ezt a több szabályozási rezsimre kiterjedő értékelést:

Ha egy incidens személyes adatok vagy más szabályozott adatok igazolt vagy valószínű kitettségét eredményezi, a jogi területnek és a DPO-nak értékelnie kell a következők alkalmazhatóságát: 6.4.1.1 GDPR Article 33 (72 órás értesítés a felügyeleti hatóság felé) 6.4.1.2 GDPR Article 34 (érintettek értesítése, ha magas kockázat áll fenn) 6.4.1.3 NIS2 Article 23 (értesítés az incidensről való tudomásszerzéstől számított 24 órán belül) 6.4.1.4 DORA Article 17 (súlyos IKT-vonatkozású incidensek jelentése)

A CRA-ra való felkészüléshez ezt a forgatókönyvet ki kell bővíteni a CRA Article 14 szerinti jelentéstételi értékeléssel az aktívan kihasznált sérülékenységekre és a termékbiztonságot érintő súlyos incidensekre.

Az egységes döntési mátrix megakadályozza, hogy a csapatok különálló, egymásnak ellentmondó jelentéstételi forgatókönyveket futtassanak:

KKV-k esetében a Clarysec Incident Response Policy - SME szabályzata, az irányítási követelmények 5.3.2 pontja ugyanezt az elvet egyszerűbb formában adja meg:

A reagálási határidőket, ideértve az adat-helyreállítási és értesítési kötelezettségeket, dokumentálni kell, és össze kell hangolni a jogi követelményekkel, például a GDPR 72 órás személyesadat-sértési értesítési követelményével.

A CRA-ra való felkészülés ezt az elvet egyszerűen kiterjeszti a személyesadat-sértési értesítésről a terméksérülékenységre és a termékbiztonsági incidensekre vonatkozó jelentéstételre.

A beszállítói bizonyíték ma már termékbiztonsági bizonyíték

Sok CRA szempontjából releváns sérülékenység a saját kódbázison kívülről fog származni. Eredhet nyílt forráskódú csomagokból, firmware-modulokból, SDK-kból, hosztolt alkalmazásprogramozási interfészekből, buildeszközökből, felhőszolgáltatásokból, alvállalkozásba adott komponensekből vagy upstream könyvtárakból. Ezért a beszállítói irányítás a CRA-ra való felkészülés központi eleme.

Az ISO 27001:2022 8.1 pontja előírja, hogy a szervezetek szabályozzák az IBIR szempontjából releváns, külső fél által biztosított folyamatokat, termékeket vagy szolgáltatásokat. Az ISO/IEC 27002:2022 5.21 kontrollja, az információbiztonság kezelése az IKT-ellátási láncban, adja ehhez a kontrollhorgonyt.

A Zenith Controls keretében a Clarysec az 5.21 kontrollt megelőző kontrollként térképezi fel, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást. Működési képessége a beszállítói kapcsolatok biztonsága, területei pedig az irányítás, az ökoszisztéma és a védelem. A lényeg egyszerű: a beszállítói kontrollok nem beszerzési papírmunkát jelentenek. Ezek ökoszisztéma-védelmi kontrollok.

A Clarysec Third-Party and Supplier Security Policy - SME szabályzata, az irányítási követelmények 5.3 pontja meghatározza a szerződéses alapot:

A szerződéseknek kötelező záradékokat kell tartalmazniuk a következőkre vonatkozóan:

Vállalati programok esetében a Zenith Blueprint: An Auditor’s 30-Step Roadmap, a Controls in Action szakasz 23. lépése, a szervezeti kontrollok 5.19–5.37, az ISO/IEC 27002:2022 5.20 kontrollját, az információbiztonság kezelését a beszállítói megállapodásokban, így magyarázza:

A beszállítókba vetett bizalom nem alapulhat feltételezéseken. Szerződésben kell rögzíteni.

A CRA-ra való felkészüléshez a beszállítói megállapodásoknak olyan termékbiztonsági záradékokat kell tartalmazniuk, amelyek támogatják a gyors sérülékenységkezelési reagálást:

A DORA ugyanezt az irányt erősíti. A pénzügyi szervezeteknek kezelniük kell az IKT-val kapcsolatos harmadikféli kockázatot, fenn kell tartaniuk az IKT-szolgáltatási szerződések nyilvántartását, értékelniük kell a kritikusságot, kellő gondosságot kell alkalmazniuk, kezelniük kell a koncentrációs kockázatot, szerződéses védelmi intézkedéseket kell meghatározniuk, biztosítaniuk kell az auditálási jogokat és kilépési terveket kell készíteniük. Ha szoftvert vagy IKT-szolgáltatást értékesít pénzügyi szervezeteknek, számítson arra, hogy az ügyfelek megkérdezik: a sérülékenység-bejelentési és SBOM-folyamat képes-e támogatni DORA szerinti incidens-, reziliencia- és harmadikféli bizonyítékaikat.

A Clarysec CRA-felkészülési munkafolyamata

A Clarysec segíti ügyfeleit abban, hogy a CRA szerinti jelentéstételt ISO 27001:2022-vel összhangban álló IBIR-en belül, gyakorlati munkafolyamatként vezessék be.

1. Adja hozzá a CRA-kötelezettségeket az IBIR követelménynyilvántartásához

Kezdje az ISO 27001:2022 4.1–4.4 pontjaival. Frissítse a szervezeti kontextust, az érdekelt feleket és a hatályt úgy, hogy azok tartalmazzák a digitális elemeket tartalmazó termékeket, az EU piaci kitettséget, a felhasználókat, importőröket, forgalmazókat, szabályozókat, CSIRT-eket, beszállítókat és szabályozott ügyfeleket.

Hozzon létre követelménynyilvántartási bejegyzéseket a CRA szerinti sérülékenység-bejelentésre, a CRA szerinti súlyos termékbiztonsági incidensjelentésre, a NIS2 szerinti incidensértesítésre, a DORA szerinti ügyféltámogatási kötelezettségekre, a GDPR szerinti személyesadat-sértési értékelésre, a szerződéses incidensértesítésre, a CVD-vállalásokra és a kutatói kommunikációra.

Ez visszakövethető utat ad az auditoroknak a külső kötelezettségtől a belső kontrollig.

2. Hozzon létre terméksérülékenységi bejelentő űrlapot

A bejelentő űrlap alapja a Coordinated Vulnerability Disclosure Policy legyen. Rögzítenie kell a bejelentő azonosítási adatait, biztonságos elérhetőségeit, a termékverziót, modult, környezetet, PoC-t, reprodukciós lépéseket, kihasználási állapotot, lehetséges adatkitettséget, szolgáltatási hatást, SBOM-komponensegyezést, CVSS vagy azzal egyenértékű súlyosságot, tulajdonost, nyomonkövetési hivatkozást és szabályozási ellenőrzőpontot.

Az űrlapnak automatikusan jegyet kell létrehoznia a sérülékenységkezelési reagálási sorban. Emellett el kell indítania az értesítési döntési időzítőt, még akkor is, ha a végső válasz az, hogy „nem bejelentésköteles”.

3. Kapcsolja össze az SBOM-adatokat a kiadásokkal

Minden kiadott termékverzióhoz SBOM-ot vagy azzal egyenértékű komponensnyilvántartást kell fenntartani. A minimálisan hasznos bizonyíték tartalmazza a komponens nevét, verzióját, forrását, licencét, beszállítóját vagy adattárát, termékverzióját, builddátumát és sérülékenységvizsgálati állapotát.

A Secure Development Policy és az Application Security Requirements Policy - SME biztosítja a szabályzati alapot az SCA-hoz, a komponens-felülvizsgálathoz és a külső komponensnyilvántartásokhoz.

4. Őrizze meg a bizonyítékokat az első naptól

Minden CRA-releváns sérülékenységi jegynek meg kell őriznie:

• Eredeti bejelentés
• Visszaigazolási időbélyeg
• Elsődleges értékelési jegyzetek
• CVSS vagy azzal egyenértékű súlyossági indokolás
• SBOM-egyezési eredmények
• Kihasználási értékelés
• Naplók, indikátorok és forenzikus pillanatképek
• Beszállítói kommunikáció
• Kockázatelfogadás, ha a kockázatcsökkentés késik
• Javítási terv, kiadási megjegyzések és tesztelési bizonyítékok
• Ügyfél- és hatósági értesítési döntések
• Végleges jelentés bemenetei és levont tanulságok

Ez összhangban van az ISO 27001:2022 8.1 pontjával, amely a folyamatok tervezett működésének bizonyításához elegendő dokumentált információt ír elő, valamint a 8.2 és 8.3 pontokkal, amelyek dokumentált kockázatértékelési és kockázatkezelési eredményeket követelnek meg.

5. Teszteljen valószerű függőségi forgatókönyvvel

Futtasson asztali gyakorlatot szimulált, aktívan kihasznált függőségi sérülékenységgel. Vonja be a mérnöki, biztonsági, jogi, adatvédelmi, termék-, kommunikációs, beszállítókezelési és ügyfélkapcsolati csapatokat. A tesztnek igazolnia kell, hogy a szervezet képes az érintett verziók azonosítására, a kihasználás értékelésére, értesítési döntés meghozatalára, beszállítók megkeresésére, felhasználói útmutatás elkészítésére és bizonyítékok megőrzésére.

Hogyan fogják az auditorok tesztelni a CRA szerinti sérülékenység-bejelentési felkészültséget

A CRA-felkészültségi felülvizsgálat ritkán korlátozódik CRA-ellenőrzőlistára. Különböző auditorok ugyanazt a bizonyítékot különböző keretrendszereken keresztül fogják vizsgálni.

A Zenith Controls keretében a Clarysec az ISO/IEC 27002:2022 5.24 kontrollját, az információbiztonsági incidenskezelés tervezését és előkészítését helyesbítő kontrollként térképezi fel, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást. A Respond és Recover funkciókhoz igazodik, működési képességei pedig az irányítás és az információbiztonsági eseménykezelés.

Ez a kontroll képezi a hidat a sérülékenység felfedezése és a szabályozói jelentéstétel között.

A NIST CSF 2.0 különösen hasznos igazgatósági szintű kommunikációs rétegként. GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND és RECOVER funkciói segítenek elmagyarázni, hogyan illeszkedik a terméksérülékenység-bejelentés a vállalati kiberbiztonsági irányításba, ahelyett, hogy mérnöki kivételként jelenne meg.

Gyakori CRA-felkészülési hiányosságok, amelyeket 2026 előtt rendezni kell

A Clarysec ismétlődően ugyanazokat a hiányosságokat látja.

Az első a CVD jelentéstétel nélkül. A vállalat rendelkezik biztonsági e-mail címmel vagy security.txt fájllal, de nincs belső út a kutatói bejelentéstől a jogi értesítési értékelésig.

A második az SBOM felelősség nélkül. A mérnöki terület képes SBOM-ot generálni build közben, de senki sem felel a kiadott termékek pontosságáért, és senki sem magyarázza el, hogyan táplálják az SBOM-megállapítások a sérülékenységkezelési reagálást.

A harmadik az ISO-tanúsítvány termékkör nélkül. Az IBIR lefedi a vállalati IT-t és a SaaS-működést, de nem fedi le a beágyazott szoftvert, firmware-t, termékfrissítési infrastruktúrát, buildfolyamatokat vagy sérülékenység-feltárást.

A negyedik a sérülékenységi záradékok nélküli beszállítói szerződés. A beszerzés előírja a bizalmasságot és az adatvédelmet, de nem írja elő a sérülékenységi értesítést, a komponensek átláthatóságát, az incidenstámogatást, a koordinált közzétételt vagy az auditbizonyítékot.

Az ötödik az incidenskezelés terméksérülékenységi logika nélkül. Az incidenskezelési terv lefedi a zsarolóvírust, az adathalászatot és a személyesadat-sértéseket, de nem fedi le az aktívan kihasznált terméksérülékenységeket, amelyek esetén az ügyfélrendszerek már a gyártó saját környezetének kompromittálódása előtt kockázatnak lehetnek kitéve.

A hatodik a DORA ügyfélbizonyítékok manuális kezelése. Az értékesítés vagy az ügyfélsiker-csapat esetről esetre válaszol a pénzügyi szektorbeli kérdőívekre, miközben a biztonsági terület nem rendelkezik szabványos bizonyítékcsomaggal, amely bemutatja a sérülékenységkezelést, az SBOM-irányítást, az incidenstámogatást és a beszállítói kontrollokat.

Mindegyik hiányosság javítható. Mindegyik drágává válik, ha éles sérülékenység során derül ki.

90 napos CRA sérülékenység-bejelentési felkészültségi ellenőrzőlista

Használja a következő 90 napot igazolható alap létrehozására:

• Azonosítsa az EU piacán forgalomba hozott vagy elérhetővé tett, digitális elemeket tartalmazó termékeket.
• Frissítse az IBIR alkalmazási területét és az érdekelt felek elemzését a CRA érintettjeinek bevonásával.
• Adja hozzá a CRA Article 14 szerinti jelentéstételi értékelést a jogi és szabályozási követelménynyilvántartáshoz.
• Tegyen közzé és felügyeljen biztonságos sérülékenység-bejelentési csatornát.
• Hozzon létre sérülékenységkezelési reagáló csoportot jogi, termék-, mérnöki, biztonsági és kommunikációs szerepkörökkel.
• Tartson fenn SBOM-okat vagy komponensnyilvántartásokat a kiadott termékverziókhoz.
• Kapcsolja össze az SCA-eredményeket a sérülékenységi jegyekkel és termékkiadásokkal.
• Adjon aktív kihasználási és súlyos termékincidens-kritériumokat az elsődleges értékelési űrlapokhoz.
• Hozzon létre kombinált CRA, NIS2, DORA, GDPR és szerződéses értesítési döntési mátrixot.
• Frissítse a beszállítói szerződéseket sérülékenységi értesítési, SBOM-, incidenstámogatási és közzétételi koordinációs záradékokkal.
• Tartson fenn javítási naplókat és helyesbítő intézkedési bizonyítékokat.
• Tesztelje a munkafolyamatot szimulált, aktívan kihasznált függőségi sérülékenységgel.
• Mutassa be az eredményeket a vezetőségnek hiányosságokkal, maradványkockázatokkal és helyesbítő intézkedési felelősökkel együtt.
• Adja hozzá a bizonyítékcsomagot a belső audithoz és a vezetőségi átvizsgáláshoz.

A Clarysec Vulnerability and Patch Management Policy - SME szabályzata, a szabályzat végrehajtásának követelményei 6.2.1 pontja támogatja a megfigyelési alapot:

Az IT-funkciónak a sérülékenységeket a következők használatával kell nyomon követnie:

Ugyanez a szabályzat, az irányítási követelmények 5.4.1 pontja hozzáadja az auditnyomot:

Javítási naplót kell fenntartani, és azt auditok és incidenskezelési tevékenységek során felül kell vizsgálni

Ez a javítási napló a CRA szerinti végleges jelentés egyik legfontosabb bizonyítékává válhat. Igazolja a feltárást, a priorizálást, a helyesbítő intézkedést, a tesztelést és a lezárást.

Tegye eseménytelenné 2026 szeptemberét

A legjobb CRA szerinti jelentéstételi esemény nem azért könnyű, mert a sérülékenység egyszerű. Azért könnyű, mert a szervezet már előre begyakorolta a munkafolyamatot.

2026 szeptembere előtt a Clarysec segíthet abban, hogy a sérülékenység-bejelentést auditra kész rendszerré alakítsa azáltal, hogy a meglévő ISO 27001:2022 IBIR-t, CVD-folyamatot, SBOM-képességet, beszállítói záradékokat és incidenskezelési forgatókönyveket összeveti a CRA, NIS2, DORA, GDPR és NIST CSF elvárásaival.

Kezdje célzott CRA sérülékenység-bejelentési felkészültségi értékeléssel. A Clarysec felülvizsgálja szabályzatait, SBOM-bizonyítékait, beszállítói szerződéseit, sérülékenységi jegyeit, incidenskezelési forgatókönyveit és auditnyomát. Ezután a Zenith Blueprint és a Zenith Controls segítségével gyakorlati helyesbítő intézkedési ütemtervet készítünk, nem elméleti megfelelési dossziét.

Ha már használ Clarysec szabályzatokat, a CRA szerinti jelentéstételhez igazítjuk őket. Ha nem, segítünk bevezetni a megfelelő szabályzatkészletet, beleértve szükség szerint a Coordinated Vulnerability Disclosure Policy, Secure Development Policy, Incident Response Policy, Vulnerability and Patch Management Policy - SME, Application Security Requirements Policy - SME és Third-Party and Supplier Security Policy - SME szabályzatokat.

2026 szeptembere elég közel van a tervezéshez, és elég távol a fegyelmezett felkészüléshez. Azok a szervezetek, amelyek most lépnek, az első 24 órában nem azt fogják kérdezni: „Ki felel ezért a sérülékenységért?” Már rendelkezni fognak a válasszal, a bizonyítékokkal és a jelentéstételi útvonallal.

Vegye fel a kapcsolatot a Clarysec-kel CRA sérülékenység-bejelentési felkészültségi értékelés ütemezéséhez, és alakítsa a szabályozási összetettséget igazolható termékbiztonsági előnnyé.