szeptember 11-én kezdődik a digitális elemeket tartalmazó termékek gyártóinak egyik legkorábbi operatív kötelezettsége a Cyber Resilience Act (CRA) alapján: az aktívan kihasznált sebezhetőségeket és a súlyos biztonsági incidenseket az új központi bejelentési platformon kell bejelenteni. Ez több egy új megfelelési határidőnél. Néhány órán belül össze kell vezetni a termékazonosítást, az érintett piacokat, a műszaki értékelést és az intézkedéseket.
Egy digitális termékútlevél vagy QR-kóddal összekapcsolt termékoldal segíthet az eszköz egyértelmű hozzárendelésében, valamint abban, hogy a felhasználókat később értesítsék egy frissítésről. Ez azonban sem nem a jogszabály szerinti bejelentési csatorna, sem nem a bizalmas exploitadatok megfelelő tárolási helye. A gyártóknak ezért már most el kell különíteniük három adatútvonalat: a hatósági bejelentést, a nyilvános termékinformációt és a belső frissítési előzményeket.
Az új aktualitás: a július 27-i és 31-i iránymutatások
Az Európai Bizottság közzétette első átfogó CRA-iránymutatását 2026. július 27-én. Többek között a bejelentési kötelezettségekkel, a kockázatértékeléssel, a támogatási időszakokkal és a lényeges változtatásokkal foglalkozik. Az iránymutatás nem kötelező erejű, de 67 példával pontosítja, hogyan alkalmazhatják a vállalatok a rendeletet a gyakorlatban.
Négy nappal később, július 31-én az ENISA frissítette a Single Reporting Platformra vonatkozó információit. Itt már megtalálható a tervezett folyamat, a tervezett beviteli mezők és a regisztrációra vonatkozó útmutatás. A platformnak 2026. szeptember 11-ig működőképessé kell válnia; a Bizottság tájékoztatása szerint a funkcionális és biztonsági tesztek már zajlanak.
Az időbeli ütemezés fontos: a CRA fő kötelezettségei alapvetően 2027. december 11-től alkalmazandók. A bejelentési kötelezettségeket tartalmazó 14. cikk azonban már 2026. szeptember 11-től hatályos. Ezt egyaránt megerősíti a 2024/2847/EU rendelet 71. cikke, valamint a Bizottság CRA-bejelentési eljárásról szóló, július 31-én frissített áttekintése.
Három adatterület egy túlterhelt termékútlevél helyett
A CRA-bejelentés és a nyilvános termékoldal eltérő célokat szolgál. Ha mindkettőt egyetlen adatkészletben képezik le, fennáll annak a veszélye, hogy az incidenscsapat számára túl kevés információ áll rendelkezésre, vagy túl sok érzékeny részlet kerül a nyilvános webre.
1. Bizalmas bejelentés az SRP, a CSIRT és az ENISA részére
A Single Reporting Platform a jogszabály szerinti belépési csatorna. Két eseménytípust kell bejelenteni: az aktívan kihasznált sebezhetőséget, amelynél megbízható bizonyítékok állnak rendelkezésre a jogosulatlan kihasználásra, valamint a súlyos incidenst, amely az adatok vagy funkciók rendelkezésre állását, hitelességét, integritását vagy bizalmasságát érinti.
A bejelentés nem csupán a termék megnevezését tartalmazza. Az ENISA többek között az érintett tagállamokat, az első értékelést, a már megtett ellenintézkedéseket, a lehetséges felhasználói intézkedéseket és az információ érzékenységét is felsorolja mezőként. A későbbi szakaszok a súlyossági fokot, a hatásokat, a támadóra vonatkozó információkat és a biztonsági frissítés műszaki részleteit is tartalmazhatják. Az ilyen információk nem valók automatikusan egy szabadon elérhető DPP-oldalra.
2. Nyilvános termék- és biztonsági információ
A nyilvános adatútvonal más kérdésekre ad választ: Melyik termékkel és verzióval rendelkezem? Továbbra is támogatott? Elérhető biztonsági frissítés? Mit kell konkrétan tennem felhasználóként? Erre alkalmas lehet egy QR-kód vagy más adathordozó mögött elérhető stabil termékoldal.
A nyilvános oldal csak jóváhagyott információkat jelenítsen meg: az érintett modell- és verziótartományokat, az elérhető biztonságos verziót, a telepítési útmutatót, a támogatási elérhetőséget és a közzététel időpontját. Az exploit részletei, a belső észlelési szabályok, a javítatlan támadási utak és a személyes incidensadatok a védett eljárásban maradnak. A nyilvános figyelmeztetésről nem a QR-kód dönt: a CRA 17. cikke alapján a koordináló CSIRT tájékoztathatja a nyilvánosságot, illetve erre kérheti a gyártót, ha ez a megelőzéshez vagy a visszaszorításhoz szükséges.
3. Belső frissítési és bizonyítéktörténet
A harmadik útvonal a nyomon követhető munkadokumentáció. Összekapcsolja a termékazonosítót, a hardver- és szoftververziót, a szoftverjegyzéket, a tudomásszerzés időpontját, a triázsdöntéseket, a bejelentési szinteket, a javítás jóváhagyását és a nyilvános közlést. Ennek az előzménynek verzióznia kell a módosításokat, nem pedig csendben felülírnia a korábbi értékeléseket.
Egy DPP-üzemeltetés számára ez a különbség központi jelentőségű: a nyilvános nézet az aktuálisan jóváhagyott állapotot mutatja, a belső előzmény pedig bizonyítja, hogyan jött létre. Aki már eseményalapon kezeli a termékadatokat, ugyanazt az elvet alkalmazhatja, mint a DPP-frissítéseknél és webhookoknál: egy esemény további folyamatokat indít el, de minden fogadó csak a szerepéhez kijelölt mezőket kapja meg.
A CRA-óra a tudomásszerzéssel indul
A 14. cikk lépcsőzetes határidőkkel dolgozik. Aktívan kihasznált sebezhetőség esetén indokolatlan késedelem nélkül, legkésőbb a tudomásszerzéstől számított 24 órán belül korai figyelmeztetés szükséges. Ezt 72 órán belül részletesebb sebezhetőségi bejelentés követi. A zárójelentésnek legkésőbb 14 nappal azután kell rendelkezésre állnia, hogy egy korrekciós vagy kockázatcsökkentő intézkedés elérhetővé vált.
Súlyos biztonsági incidens esetén szintén 24 óra áll rendelkezésre a korai figyelmeztetésre, és 72 óra az incidens bejelentésére. A zárójelentés a 72 órás bejelentést követő egy hónapon belül készül el. A határidők tehát nem egy CVE közzétételétől és nem a következő rendes kiadástól, hanem attól az időponttól futnak, amikor a gyártó tudomást szerzett az esetről.
A gyakorlatban egyértelmű folyamat javasolt:
- A támogatástól, monitorozásból, kutatásból vagy az ellátási láncból érkező bejelentés rögzítése időbélyeggel.
- A termék és a verzió feloldása stabil belső termékazonosítóra.
- A kihasználás, illetve az incidens súlyosságának értékelése az illetékes csapat által.
- A 24 órás adatkészlet előállítása a megerősített minimális adatokból, majd benyújtása az SRP-n keresztül.
- A műszaki ismeretek kiegészítése a 72 órás szintig az eredeti állapot megőrzésével.
- A javítás, a felhasználói intézkedés és a nyilvános tájékoztatás külön-külön történő jóváhagyása.
- A zárójelentés és a belső előzmény összekapcsolása.
Ezt a láncot szeptember előtt gyakorlatként végig kell játszani. Az ENISA rámutat, hogy a szervezetek automatizálhatják belső folyamataikat és adatbázisaikat, a platform azonban induláskor nem kínál majd API-t. Ezért reálisabb egy export- és négyszemközti ellenőrzési folyamat, mint egy ellenőrizetlen közvetlen integráció.
Egy közös termékazonosító, de elkülönített hozzáférési jogok
Az elkülönítés nem jelenti három egymással össze nem kapcsolt másolat kezelését. Jobb megközelítés egy közös, megváltoztathatatlan termékreferencia szerepköralapú nézetekkel.
Legalább a következő hozzárendeléseknek rendelkezésre kell állniuk:
- belső termékazonosító, valamint modell-, tétel- vagy sorozatazonosító;
- hardver-, firmware- és szoftververzió;
- azok a tagállamok, amelyekben az érintett kivitel elérhető volt;
- a biztonsági értékelés állapota és a tudomásszerzés időpontja;
- hivatkozások a 24 és 72 órás bejelentésre, valamint a zárójelentésre;
- jóváhagyott felhasználói intézkedés és biztonságos célverzió;
- a nyilvános termékoldal közzétételi állapota.
Az engedélyezést mezőszinten kell kialakítani. Az incidenscsapatnak és a CRA-felelősöknek a teljes dokumentációra szükségük van. A támogatásnak és az értékesítésnek jóváhagyott cselekvési útmutatóra van szüksége. A felhasználók csak a nyilvános bejelentést látják. A QR-kód ideális esetben csupán egy stabil termékcímet továbbít; a mögötte álló platform az állapot és a szerepkör alapján dönti el, mely információt szolgáltatja.
Mit kell a gyártóknak szeptemberig tesztelniük?
Egy hasznos tesztesethez nincs szükség valódi sebezhetőségre. Válasszanak egy hálózatba kapcsolt terméket, egy érintett firmware-verziót és három tagállamot. Szimulálják a tudomásszerzést egy munkanapon, és ellenőrizzék:
- Meg tudja erősíteni a csapat 24 órán belül a terméklefedettséget és a minimális adatokat?
- Egyértelmű, hogy ki férjen hozzá képviselőként az SRP-hez EU Loginen keresztül?
- Kiegészíthetők a 72 órás információk anélkül, hogy bizalmas részletek nyilvánosságra kerülnének?
- A javítás jóváhagyása ellenőrzött felhasználói tájékoztatást eredményez minden szükséges nyelven?
- Stabil marad a nyilvános URL, ha a verzió és az intézkedések változnak?
- Nyomon követhető, hogy ki, mikor és melyik állapotot hagyta jóvá?
Az utóbbi ponthoz következetes, verziózott adatkezelés segít. A qr3 folyamatos DPP-frissítésről szóló cikke bemutatja az alapelvet: az identitás változatlan marad, miközben a szakmai adatokat ellenőrzötten vezetik tovább. A CRA-folyamatban ehhez szigorúbb bizalmassági és jóváhagyási réteg társul.
Összegzés: a termékútlevél elosztó, nem bejelentési hely
Az új iránymutatások működés közben is értelmezhetővé teszik a szeptemberi határidőt. A gyártóknak nem kell bizalmas sebezhetőségi adatbázist építeniük a digitális termékútlevelükbe. Ehelyett megbízható átmenetre van szükségük három egyértelműen elkülönített terület között: hatósági bejelentés, belső bizonyítékok és jóváhagyott felhasználói információ.
Egy közös termékazonosító összetartja ezeket a területeket. A szerepkörök, a jóváhagyások és a verziózás megakadályozza, hogy bizalmas részletek kerüljenek ki, vagy hogy a felhasználók túl későn értesüljenek egy elérhető intézkedésről. A QR-kód továbbra is hasznos, de tudatosan észrevétlen marad: tartósan a megfelelő termékkörnyezethez vezet. A tényleges CRA-megfelelés a mögötte álló folyamatokban jön létre.
