A kiberrezilienciáról szóló rendelet: 2026. szeptember 11. valódi határidő
A legtöbb uniós rendelet ad egy megfelelési dátumot és egy türelmi időszakot, amely alatt mindenki csendben megszervezi magát. A kiberrezilienciáról szóló rendelet mást tesz. Az első kemény kötelezettsége egy 24 órás bejelentési óra, és 2026. szeptember 11-én indul.
Egy 24 órás órát nem lehet szakaszosan bevezetni. Vagy létezik a folyamat aznap, vagy elmulasztja a határidőt.
Mi a CRA
A 2024/2847 rendelet kiberbiztonsági követelményeket állapít meg az uniós piacon forgalmazott digitális elemeket tartalmazó termékekre. Ez a kifejezés sokkal többet fed le, mint amire először gondolunk: minden szoftver- vagy hardvertermék, valamint a hozzájuk tartozó távoli adatfeldolgozási megoldások, amelyek rendeltetésszerű vagy észszerűen előre látható használata közvetlen vagy közvetett adatkapcsolatot foglal magában.
A csatlakoztatott eszközök a hatály alá tartoznak. Ahogy a kereskedelmi szoftverek nagy része, az operációs rendszerek, böngészők, mobilalkalmazások, firmware és más termékekben lévő komponensek is.
A rendeletet 2024 novemberében tették közzé, és szakaszosan alkalmazandó:
- 2026. június 11.: a megfelelőségértékelő szervezetek kötelezettségei.
- 2026. szeptember 11.: az aktívan kihasznált sebezhetőségek és a súlyos incidensek bejelentési kötelezettségei.
- 2027. december 11.: teljes alkalmazás, beleértve az alapvető kiberbiztonsági követelményeket, a CE-jelölést, a műszaki dokumentációt és a szoftverösszetevő-jegyzéket.
A középső dátum az, amire tervezni kell, mert az érkezik először, és mert olyan képességektől függ, amelyek talán nincsenek meg.
Mi történik 2026. szeptember 11-én
Ettől a dátumtól a gyártóknak be kell jelenteniük:
Az aktívan kihasznált sebezhetőségeket a digitális elemeket tartalmazó termékeikben, és
a súlyos incidenseket, amelyek e termékek biztonságát érintik.
A bejelentés az ENISA által üzemeltetett egységes CRA bejelentési platformon keresztül megy a gyártó fő telephelye szerinti tagállamban kijelölt CSIRT-hez, amely aztán megosztja más érintett CSIRT-ekkel és az ENISA-val.
Az ütemezés:
- 24 órán belül a tudomásszerzéstől: korai figyelmeztetés.
- 72 órán belül: teljes bejelentés, beleértve a megtett javító vagy enyhítő intézkedéseket.
- 14 napon belül azután, hogy elérhetővé válik egy javító intézkedés: végleges jelentés az aktívan kihasznált sebezhetőségről.
- Egy hónapon belül: végleges jelentés a súlyos incidensről.
Huszonnégy óra a tudomásszerzéstől, nem a megerősítéstől, nem a javítástól. Ha a terméke egy komponensében lévő sebezhetőséget szombaton élesben kihasználnak, az óra szombaton ketyeg.
Miért nehezebb ez, mint amilyennek látszik
Maga a bejelentési kötelezettség egy űrlap. A nehézség mindabban van, amit előtte készen kell tartani.
Tudnia kell, mi van a termékében
Ahhoz, hogy bejelentse, hogy a termékében lévő sebezhetőséget aktívan kihasználják, tudnia kell, hogy a sebezhető komponens a termékében van. Egy több száz tranzitív függőséggel rendelkező modern alkalmazásnál ezt ember nem tudja fejből megválaszolni.
Ezért építenek a csapatok most szoftverösszetevő-jegyzék folyamatokat, több mint egy évvel a 2027. decemberi formális SBOM-követelmény előtt. Az SBOM nem a cél. A cél az, hogy órákon belül meg tudja válaszolni az „érint minket?" kérdést, és az SBOM teszi a kérdést megválaszolhatóvá.
A kellemetlen az, hogy ez az évekkel ezelőtt kiszállított termékekre is vonatkozik. Ha vannak támogatott eszközei a terepen 2022-ben épített firmware-rel egy olyan függőségi fából, amelyet senki nem rögzített, ennek rekonstruálása valódi munka.
Figyelnie kell
A tudomásszerzés indítja az órát, és aktív, nem véletlenszerű tudomásszerzést várnak. Ez azt jelenti, hogy figyelni kell a sebezhetőségi hírfolyamokat, feliratkozni a komponensei tájékoztatóira, követni az ismert kihasznált sebezhetőségek katalógusait, és rendelkezni olyan csatornával, ahol biztonsági kutatók elérhetik és választ kaphatnak.
Kell egy döntési útvonal
Valakinek bármely órában tudnia kell eldönteni, hogy egy incidens eléri-e a küszöböt, és elindult-e az óra. Megnevezett szerep és eszkalációs útvonal nélkül az első órák azzal telnek, hogy kiderítsék, ki hozhatja meg a döntést.
Az életciklusuk végén lévő függőségek kockázattá válnak
Ha a termékében lévő komponens már nem kap biztonsági frissítéseket, a kihasználás esetén továbbra is Öné a bejelentési kötelezettség, és nincs feljebbi javítás, amire mutathatna. Az életciklusuk végén lévő függőségek átvizsgálása a felkészülés egyik leghasznosabb lépése, mert a válasz néha saját átfutási idejű migrációt kényszerít ki.
Mit hoz a teljes alkalmazás 2027 decemberében
A 2027. decemberi kötelezettségek a nagyobb program, és jóval korábban el kell kezdeni őket.
Beépített és alapértelmezett biztonság. A termékeket úgy kell tervezni, fejleszteni és gyártani, hogy kockázatalapon megfelelő kiberbiztonsági szintet biztosítsanak. Nincs alapértelmezett jelszó. Biztonságos konfiguráció alapból. A támadási felület minimalizálása. Az adatok védelme átvitel közben és nyugalmi állapotban.
Sebezhetőségkezelés. Dokumentált folyamat, amely lefedi az azonosítást, javítást, tesztelést, terjesztést és közzétételt. A biztonsági frissítéseket késedelem nélkül és díjmentesen kell nyújtani, olyan támogatási időszakon át, amely tükrözi a termék várható élettartamát, ahol öt év gyakori viszonyítási pont.
Szoftverösszetevő-jegyzék. Géppel olvasható formátumban, legalább a legfelső szintű függőségeket lefedve, és naprakészen tartva.
Műszaki dokumentáció és megfelelőségértékelés. A legtöbb termék önértékelést végez. A fontos és kritikus kategóriák, amelyek közé tartoznak például a jelszókezelők, a VPN-ek, az operációs rendszerek és az ipari vezérlőrendszerek, harmadik fél bevonását igénylik.
CE-jelölés. A fizikai jelölés digitális megfelelője, amellyel megfelelőséget nyilvánít.
Összehangolt sebezhetőség-közzétételi szabályzat. Közzétéve, működő kapcsolattartási ponttal.
Ki tartozik valójában a hatály alá
Néhány határeset folyamatosan visszatér.
A szabad és nyílt forráskódú szoftver, amelyet kereskedelmi tevékenységen kívül fejlesztenek, nagyrészt kívül esik. A rendelet bevezeti a nyílt forráskódú szoftvergondnok fogalmát könnyebb kötelezettségekkel. De ha nyílt forráskódot kereskedelmi célra hasznosít, vagy eladott termékben szállít, a termékkötelezettségek az Önéi.
A szolgáltatásként nyújtott szoftver általában kívül esik a CRA-n, és inkább a NIS2 alá tartozik, bár a digitális elemeket tartalmazó termék szerves részét képező távoli adatfeldolgozási megoldásokat behúzza. Ha az eszköze a működéséhez a felhő-háttérrendszerére támaszkodik, az a háttérrendszer a termékkel együtt utazik.
Az importőrök és forgalmazók is viselnek kötelezettségeket. Ha harmadik fél termékét saját néven vagy védjeggyel hozza az uniós piacra, gyártóként kezelik.
A máshol már szabályozott termékeket, például az orvostechnikai eszközöket, járműveket és repüléstechnikai berendezéseket, saját keretrendszereikben kezelik.
A hatályra vonatkozó kérdések valóban nem triviálisak, és ez az a pont, ahol egy óra a jogászokkal hónapokat spórol a rossz irányba tartó fejlesztésből.
Mit tennénk a hátralévő időben
Ha a hatály alá tartozik és most kezd, ez a sorrend működik:
Először hozza létre a termékleltárt. Mi van valójában az uniós piacon? Beleértve a terepen még jelen lévő régi verziókat, a fehér címkés változatokat és a más nevében forgalmazott termékeket. Ez a lista általában hosszabb, mint bárki várná.
Ezután építse be az SBOM-generálást a CI-be. Generáljon SBOM-ot minden buildnél, CycloneDX vagy SPDX formátumban, tárolja a kiadási artefaktum mellett, és tartsa lekérdezhetőnek. A lényeg, hogy meg tudja kérdezni: „mely kiszállított kiadásaink tartalmazzák ezt a könyvtárat?", és perceken belül választ kapjon.
Ezután kösse be a sebezhetőségfigyelést. Táplálja az SBOM-adatokat egy szkennerbe, amely figyeli a tájékoztatókat és az ismert kihasznált sebezhetőségek katalógusait, a riasztásokat pedig irányítsa olyan csatornára, amelyet valaki olvas.
Ezután írja meg az incidenskezelési forgatókönyvet. Ki nyilvánít, ki értékel, ki jelent, ki kommunikál. Megnevezett emberek, helyettesek és munkaidőn kívüli elérhetőségek. Utána gyakorolja egyszer egy hamis tájékoztatóval. A gyakorlaton derül ki, hogy az a személy, akinél a bejelentési platform belépési adatai vannak, szabadságon van.
Ezután tegyen közzé sebezhetőség-közzétételi szabályzatot. Egy security.txt fájl, egy figyelt cím és egy megadott válaszidő. Ez egy délutánnyi munka, és ez a különbség aközött, hogy egy kutatótól vagy egy újságírótól értesül a problémáról.
Végül kezdje el a 2027. decemberi munkát. A biztonságos alapértelmezések, a frissítési mechanizmusok, a támogatási időszakról szóló döntések és a dokumentáció architektúrakérdések, nem papírmunka. A 2026-ban tervezett termékek 2028-ban is a piacon lesznek.
Az átfedés, amelyet senki nem használ ki
A CRA és más rendszerek között jelentős átfedés van, és a legtöbb cég mindegyiket külön kezeli, ami pazarlás.
A CRA-hoz épített SBOM a NIS2 ellátásilánc-kérdéseinek nagy részére válaszol. Az incidenskezelési forgatókönyv átfed a NIS2 24 órás korai figyelmeztetésével és a GDPR 72 órás incidensbejelentésével. A sebezhetőségkezelési folyamatok közvetlenül táplálják az ügyfelek biztonsági kérdőíveit és a nagyvállalati beszerzést.
Építse meg ezt egyszer platformképességként. Az alternatíva három csapat, amely ugyanazon eszközleltár három változatát építi.
Hol kapjon segítséget
Az EU-ba értékesítő cégeknek építünk és tartunk karban szoftvert, ami egyre inkább azt jelenti, hogy azt az ellátásilánc-átláthatóságot és frissítési infrastruktúrát építjük, amelyet a CRA feltételez. Ha azt vizsgálja, a hatály alá tartozik-e, vagy a szeptemberi dátum a naptárban van, de nincs figyelés, írjon az office@c9group.dev címre.
Örökölt rendszerek karbantartására vonatkozó szolgáltatásunk gyakran a kiindulópont, mert a legrosszabb függőségi átláthatóságú termékek általában a legrégebbiek. A tágabb szabályozási képet az EU digitális megfelelési útmutatónk 2026 tartalmazza.
Mérnökök vagyunk, nem jogászok. A hatályra és besorolásra vonatkozó döntések a jogászaira tartoznak, mi pedig az általuk adott válasz szerint építünk.