A kiberrezilienciáról szóló jogszabály: építse be a kötelezettségeket a termékfejlesztésbe

A kiberrezilienciáról szóló jogszabály (Cyber Resilience Act, CRA) a hatálya alá tartozó, digitális elemeket tartalmazó termékek életciklusába építi be a kiberbiztonsági kötelezettségeket. Egy CTO számára a gyakorlati feladat az, hogy összekapcsolja azt, amit a fejlesztés megépít, kiad és karbantart, azokkal a bizonyítékokkal, amelyek e kötelezettségek teljesítésének igazolásához szükségesek.

Ennek a kapcsolatnak termék- és verziószinten kell működnie. Egy vállalati szintű biztonsági szabályzat nem magyarázza meg, hogy egy adott kiadás biztonságos alapbeállításokkal rendelkezik-e, milyen függőségeket tartalmaz, vagy hogyan kapják meg az ügyfelek a biztonsági frissítést. Egy „javítva” állapotú sérülékenységi jegy nem állapítja meg, mely támogatott verziók maradnak kitettek.

A hasznos kiindulópont ezért egy termékéletciklus-modell: hatály, biztonsági követelmények, kiadási bizonyítékok, sérülékenységkezelés, támogatási vállalások és elszámoltatható döntések. Ezt a modellt építse be a fejlesztésbe, ahelyett hogy egy értékelés előtt külön állítaná össze.

A kontrollok kiosztása előtt határozza meg a termék határát

A CRA a hatálya alá tartozó, digitális elemeket tartalmazó termékekre vonatkozik, beleértve az érintett hardvereket és szoftvereket. Nem minden SaaS-szolgáltatásra vonatkozó általános szabály. Egy hosztolt szolgáltatás és egy ügyfeleknek terjesztett szoftver eltérő elemzést igényelhet, és a termék szerves részét képező távoli adatfeldolgozást is meg kell vizsgálni.

Kiindulási referenciaként használja az Európai Bizottság CRA-útmutatását, majd tisztázza a termékspecifikus jogi kérdéseket. A következtetést rögzítse, ahelyett hogy egy csapat informális feltevésére hagyatkozna.

Minden szóba jöhető termékhez állapítsa meg:

• Mit kapnak az ügyfelek: hardvert, telepített szoftvert, letölthető komponenseket vagy ezek kombinációját.
• Mely távoli adatfeldolgozási funkciók szükségesek ahhoz, hogy a termék ellássa a funkcióit.
• Hogyan kerül a termék az uniós piacra, és melyik jogalany forgalmazza.
• Az Ön gazdasági szereplői szerepét: gyártó, importőr, forgalmazó vagy más releváns szerep.
• Az alkalmazandó kivételeket, a termékspecifikus jogszabályokat és a nyílt forráskóddal kapcsolatos szempontokat.
• A termékkategóriát és az abból eredő megfelelőségértékelési követelményeket.

A nyílt forráskód különös gondosságot igényel. A kereskedelmi tevékenységen kívül biztosított szoftverek kezelése nem jelenti azt, hogy egy kereskedelmi gyártó figyelmen kívül hagyhatja a termékébe beágyazott nyílt forráskódú komponenseket. Különböztesse meg a felső szintű (upstream) közreműködő helyzetét az Ön által forgalmazott termékért viselt felelősségétől.

A mérnöki eredmény egy rövid hatálynyilvántartás legyen architektúraábrával, termékazonosítókkal, az érintett kereskedelmi jogalanyokkal, feltevésekkel és egy jóváhagyott következtetéssel. Nevezze meg azt a személyt, aki felelős a következtetés újbóli megnyitásáért, ha a funkcionalitás vagy a terjesztés megváltozik.

Például egy letölthető felügyeleti alkalmazásra és a hozzá tartozó hosztolt analitikai szolgáltatásra nem kell automatikusan egyetlen, differenciálatlan hatálydöntést hozni. Azonosítsa, mely funkciók működnek helyben, melyek függenek a szolgáltatástól, és hogy a távoli adatfeldolgozás a termék határán belülre tartozik-e. Ez a megkülönböztetés hatással van a kockázatértékelésre, a függőségi nyilvántartásokra és az incidensek felelősségére.

Az aktuális végrehajtási dátumokból induljon ki

A Bizottság a bejelentési kötelezettségekre 2026. szeptember 11-ét, a CRA fő követelményeire pedig 2027. december 11-ét jelöli meg. 2026. október 7-én a bejelentési dátum már elmúlt. A bejelentésre való felkészültséget aktuális működési követelményként kezelje, ne a megfelelőségre való felkészülésig elhalasztott feladatként.

Tartson láthatóan két munkafolyamatot:

A fő alkalmazási dátum előtt forgalomba hozott termékeknél figyelmet kell fordítani az átmeneti rendelkezésekre és a jelentős módosításokra. Ne feltételezze, hogy egy régebbi termék csak azért nem releváns a bejelentés szempontjából, mert az eredeti kiadása 2027 decembere előtt történt.

Vezessen dátummal ellátott jogi követelménynyilvántartást. Az eseményküszöbök, a lépcsőzetes bejelentési határidők, a címzettek és a benyújtási eljárások tekintetében ellenőrizze az aktuális jogszabályszöveget és a hivatalos végrehajtási útmutatást. Ne helyettesítse a CRA-specifikus folyamatot egy általános incidenskezelési sablonnal.

Alakítsa a biztonsági követelményeket tervezési és kiadási kritériumokká

A CRA alapvető követelményei a termékbiztonsági tulajdonságokra és a sérülékenységkezelésre terjednek ki. Megvalósításuknak a termék kiberbiztonsági kockázatértékelését kell követnie, nem egy architekturális kontextus nélkül alkalmazott univerzális ellenőrzőlistát.

Induljon ki abból, hogyan okozhat kárt a termék. Írja le a felhasználókat, a telepítési környezeteket, a kitett interfészeket, a privilegizált műveleteket, az érzékeny adatokat és az előrelátható visszaéléseket. Vegye figyelembe az ügyfél működési feltevéseit is: egy ipari hálózatra telepített berendezés kitettsége és helyreállítási korlátai mások, mint egy asztali segédprogramé.

Egy gyakorlati fenyegetésmodellezési gyakorlat támogathatja ezt a munkát; az OWASP fenyegetésmodellezési útmutatója bevált megközelítést kínál. Az eredménynek a fenyegetéseket konkrét követelményekhez, megvalósítási döntésekhez és tesztekhez kell kapcsolnia.

Nézzük meg, hogyan válnak tesztelhetővé az ismert követelmények:

Ezek gyakorlati megvalósítási példák, nem helyettesítik az alkalmazandó követelményeket. A relevanciát és az elégségességet a kockázatértékelés alapján határozza meg.

A funkciófejlesztéshez adjon biztonsági elfogadási kritériumokat. Egy új adminisztrációs API érkezzen hitelesítési, jogosultságkezelési, bemenetkezelési és naplózási döntésekkel együtt – ne annak ígéretével, hogy a biztonsági csapat majd később megvizsgálja. Vizsgálja felül a fenyegetési modellt, amikor távoli interfészt, privilegizált komponenst vagy új bizalmi határt ad hozzá.

A kiadási jóváhagyásnak azonosítania kell a megoldatlan sérülékenységeket, azok kihasználhatóságát, az érintett konfigurációkat és a kezelést. Alkalmazza a CRA azon követelményét, hogy a termékeket ismert, kihasználható sérülékenységek nélkül kell forgalmazni, figyelembe véve a kockázatértékelést és az alkalmazandó alapvető követelményeket; egy kockázat rögzítése vagy elfogadása önmagában nem teljesíti ezt a követelményt. Egy szkennereredmény önmagában nem hozhatja meg ezt a döntést: az elérhetőség, az előfeltételek és a termék viselkedése is számít. Fordítva: egy alacsony numerikus súlyossági pontszám nem elégséges ok arra, hogy figyelmen kívül hagyjon egy olyan sérülékenységet, amely az Ön telepítési modelljében súlyos következményekkel jár.

A kiadási nyilvántartásnak össze kell kapcsolnia a jóváhagyott forráskód-revíziót, a buildterméket, a függőségi leltárt, a teszteredményeket és a biztonsági döntést. Így az értékelés reprodukálható, ha egy ügyfél vagy hatóság később egy konkrét verzióról érdeklődik.

Tegye a komponensek átvilágítását a buildfolyamat részévé

A harmadik féltől származó komponensek olyan kötelezettségeket teremtenek, amelyeket nem lehet egy upstream biztonsági értesítés továbbításával teljesíteni. Értenie kell, mit adott ki, érintett-e, és hogyan tudja javítani.

A CRA a sérülékenységkezelési követelmények között szoftverösszetevő-jegyzékre (SBOM) vonatkozó követelményt is tartalmaz: általánosan használt, géppel olvasható formátumban, amely legalább a legfelső szintű függőségeket lefedi. Gyakorlati ajánlásként rögzítsen mélyebb függőségi információkat is, ahol a buildeszközei megbízható eredményeket tudnak előállítani. A tranzitív függőségek gyakran meghatározzák a kitettséget.

Egy SBOM csak akkor hasznos, ha egy valódi termékbuildnek felel meg. Kapcsolja a kiadásazonosítóhoz és a buildhez, és különböztesse meg a kiadott komponenseket a csak fejlesztéshez használt eszközöktől. Adott esetben vegye fel a firmware-t, az operációs rendszer csomagjait, a mellékelt könyvtárakat és a kereskedelmi komponenseket is; egy csomagkezelői export ezek közül többet is kihagyhat.

A komponensek felülvizsgálatát olyan kérdések köré építse, amelyek mérnöki döntéseket változtatnak meg:

• Karbantartják-e a komponenst, és összeegyeztethető-e a támogatott élettartama a miénkkel?
• Hozzájutunk-e időben a sérülékenységi információkhoz és a biztonsági frissítésekhez?
• Van-e hozzáférésünk a forráskódhoz, szállítói javítási útvonalunk vagy helyettesítési stratégiánk?
• Bevezet-e a komponens privilegizált végrehajtást vagy új külső kapcsolatot?
• Karbantartható-e a termék akkor is, ha a szállító megszünteti a komponens támogatását?

A kereskedelmi komponenseknél a beszerzésnek meg kell határoznia a biztonsági kapcsolattartókat, az értesítési megállapodásokat és a javításokhoz való hozzáférést. A szállítói időzítésnek teret kell hagynia az Ön saját értékelési és bejelentési kötelezettségeinek. A termék gyártójának akkor is szüksége van belső eszkalációs útvonalra, ha egy szállítói válasz hiányos.

A nyílt forráskódú függőségeknél őrizze meg az eredetre vonatkozó információkat és egy reális karbantartási tervet. Az, hogy egy tároló nyilvánosan elérhető, nem bizonyítja, hogy valaki a támogatási időszak alatt kompatibilis javítást fog készíteni.

A támogatási időszakot és a frissítési mechanizmust együtt tervezze meg

A támogatás üzleti következményekkel járó mérnöki vállalás. A CRA általában legalább ötéves támogatási időszakot ír elő, kivéve, ha a termék várható használati ideje rövidebb. Az alkalmazandó időszakot a rendelet kritériumai alapján határozza meg, ahelyett hogy egy önkényes dátumot választana az ütemtervhez igazodva.

Rögzítse az indoklást, közölje az ügyfelekkel az előírt támogatási információkat, és kapcsolja azokat a karbantartott termékverziókhoz. A támogatási vállalásnak a biztonsági frissítések szállításának képességére kell kiterjednie, nem csupán egy ügyfélszolgálati cím fenntartására.

Mielőtt jóváhagyná egy termék támogatási tervét, kérdezze meg, képes-e:

• A régebbi támogatott ágakat karbantartott eszközláncokkal újraépíteni.
• Biztonsági frissítéseket biztonságosan előállítani, hitelesíteni és terjeszteni.
• A javításokat az összes támogatott hardveren és telepítési konfiguráción tesztelni.
• Az aláírókulcsokat karbantartani, és egy kulcskompromittálódásból biztonságosan helyreállni.
• Az ügyfeleknek szóló frissítési és biztonsági információkat elérhetően tartani.
• Kezelni azokat a függőségeket, amelyek upstream támogatása az Önénél korábban ér véget.

A biztonsági frissítéseket a támogatási időszak alatt általában díjmentesen kell biztosítani, a rendelet rendelkezéseinek megfelelően. Az ebben az időszakban kiadott minden biztonsági frissítésnek a kiadásától számított legalább tíz évig vagy a támogatási időszak hátralévő részében – amelyik hosszabb – elérhetőnek kell maradnia. A biztonsági javításokat a funkciófejlesztéstől elkülönítve tervezze, hogy az ügyfeleket ne kényszerítse szükségtelenül nem kapcsolódó funkcionális változtatásokra.

Ne csak a hibátlan forgatókönyvet tesztelje. A megszakadt telepítés, az elégtelen tárhely, a lejárt hitelesítő adatok és a sikertelen ellenőrzés egy érvényes javítást is rendelkezésre állási problémává változtathat. Döntse el, milyen helyreállítási mechanizmusokra van szükség a termék kockázati profiljához.

A támogatás végén az ügyfélkommunikációnak és a belső nyilvántartásoknak összhangban kell lenniük. Ne hagyjon olyan letöltési oldalt, amely folyamatos biztonsági karbantartásra utal, ha a termékregiszter szerint a vállalás már megszűnt.

Olyan bejelentési forgatókönyvet építsen, amely kibírja a bizonytalanságot

Egy hétköznapi sérülékenységi megállapítás, egy aktívan kihasznált sérülékenység és egy súlyos biztonsági incidens nem felcserélhető. A CRA szerinti bejelentési folyamathoz a releváns kiváltó esemény dokumentált értékelésére van szükség – nem minden szkennerriasztás automatikus bejelentésére, és nem is mindennek az automatikus elvetésére egy befejezett igazságügyi vizsgálat hiányában.

A forgatókönyv a beérkezéssel kezdődjön. A kutatóknak, az ügyfélszolgálatnak, a szállítóknak és a fejlesztőcsapatoknak ismert útvonalra van szükségük a termékbiztonsági funkcióhoz. Őrizze meg az eredeti bejelentést, és rögzítse, mikor váltak ismertté a releváns információk; ne állítsa vissza a tudomásszerzés időbélyegét, amikor egy jegy csapatot vált.

A potenciálisan bejelentendő eseményekhez gyűjtse össze:

• A termékazonosítókat és az érintett támogatott verziókat.
• A kihasználás vagy az incidens hatásának bizonyítékait, a megbízhatósággal és a bizonytalanságokkal együtt.
• Az ismert támadási feltételeket, az érintett funkciókat és a telepítési feltevéseket.
• Az elérhető kockázatcsökkentő intézkedéseket és a korrekciós intézkedések állapotát.
• A kiváltó esemény értékelését, a bejelentés felelősét és az alkalmazandó határidő-számításokat.
• A benyújtott bejelentéseket, a visszaigazolásokat, a későbbi frissítéseket és az ügyfélkommunikációt.

A lépcsőzetes értesítési határidőket, a zárójelentésre vonatkozó követelményeket, a címzetteket és az aktuális bejelentési eljárást hivatalos forrásokból ellenőrizze. Az aktívan kihasznált sérülékenységekre és a súlyos incidensekre eltérő bejelentési részletek vonatkoznak; egyetlen átmásolt határidőmező nem elég.

Jelöljön ki egy elsődleges bejelentési felelőst és egy helyettest, akiknek jogkörük van a fejlesztés, a jogi terület és az ügyfélkommunikáció koordinálására. Előre biztosítsa a hozzáférést az alkalmazandó bejelentési mechanizmushoz. A jogi felülvizsgálatnak a bejelentési időablakon belül elérhetőnek kell lennie, és nem válhat korlátlan jóváhagyási sorrá.

Gyakorolja be a folyamatot hiányos információkkal. Egy hasznos gyakorlat egy hiteles kihasználási bejelentéssel, egy bizonytalan érintettverzió-listával és egy elérhetetlen komponensszállítóval indul. A csapatnak képesnek kell lennie időben, dokumentáltan döntést hozni a bejelentésről, miközben a vizsgálat folytatódik.

A CRA szerinti bejelentés nem helyettesíti a többi alkalmazandó kötelezettséget. Egy termékkel kapcsolatos esemény az adatvédelmi jog vagy egy ügyfélszerződés szerinti értékelést is szükségessé tehet. Hangolja össze ezeket az értékeléseket, de őrizze meg az eltérő kiváltó eseményeiket, címzettjeiket és döntési nyilvántartásaikat.

Az értékelési terv kiválasztása előtt erősítse meg a besorolást

A termék besorolása befolyásolja az elérhető megfelelőségértékelési eljárást. Ne feltételezze, hogy minden csatlakoztatott termékhez ugyanaz a külső értékelés kell, vagy hogy minden gyártó támaszkodhat belső értékelésre.

Az alkalmazandó kategóriát a termék funkciói, valamint a rendelet fogalommeghatározásai és mellékletei alapján határozza meg. Ezután erősítse meg a megengedett eljárást, beleértve a harmonizált szabványokkal, elismert specifikációkkal, tanúsítási rendszerekkel vagy harmadik fél általi értékeléssel kapcsolatos feltételeket.

A szabványokkal kapcsolatos tervezéshez kifejezett függőségi nyilvántartásra van szükség: mely hivatkozások alkalmazandók, mi az aktuális állapotuk, és mi változik, ha egy várt eljárás nem érhető el. Kerülje, hogy a kiadási terv a szabványokra vagy az értékelési kapacitásra vonatkozó, meg nem erősített feltevéstől függjön.

A funkcionalitás változásakor vizsgálja felül a besorolást. A biztonságkezelési vagy hálózatvezérlési képességek hozzáadása befolyásolhatja az elemzést, de egy funkció neve önmagában nem határoz meg kategóriát. Értékelje a tényleges funkciót, és dokumentálja a következtetést.

A besorolást, a választott eljárást és a megfelelőségi eredményeket tartsa összekapcsolva a műszaki dokumentációval. A CE-jelölésnek és az EU-megfelelőségi nyilatkozatnak az alkalmazandó eljárást kell követnie; nem helyettesítik a mögöttes követelmények megvalósítását.

Tartson fenn olyan bizonyítékcsomagot, amely meg tud magyarázni egy kiadást

A műszaki dokumentációnak a terméket és a biztonsági döntései mögötti érvelést is le kell írnia. A termék változásai során őrizze meg a kockázatértékeléseket és a dokumentációt, és alkalmazza a releváns nyilvántartásokra a jogszabályban előírt megőrzési követelményeket.

Egy hasznos termékbizonyíték-csomag tartalmazza a hatálydöntést, az architektúrát, a kockázatértékelést, a biztonsági követelményeket, a komponensinformációkat, az ellenőrzési eredményeket, a sérülékenységkezelési eljárásokat, a támogatás indoklását és a megfelelőségi nyilvántartásokat. Minden elemhez felelős és azonosítható verzió szükséges.

E nyilvántartások összekapcsolásához használjon stabil azonosítókat. Egy sérülékenységi nyilvántartásnak meg kell magyaráznia az érintett verziókat, a kitettséget, a kezelést, a kiadást és a szükséges kommunikációt. A verziókontextus nélküli „javítva” hiányosan hagyja a termékbizonyítékokat.

A meglévő IBIR-folyamatok hasznos irányítási, beszállítói és biztonságos fejlesztési bizonyítékokat szolgáltathatnak. Az ISO 27001 azonban egy meghatározott hatókörű információbiztonsági irányítási rendszerre vonatkozik; a tanúsítás nem igazolja egy adott termék CRA-megfelelőségét. Használja fel újra a releváns bizonyítékokat, de ne kezelje a keretrendszer-megfeleltetéseket jogi egyenértékűségként.

Gyakorlati példa: függőségi hiba egy támogatott berendezésben

Vegyünk egy szemléltető gyártót, amely hálózatra csatlakoztatott berendezést forgalmaz az EU-ban. Tegyük fel, hogy a hatályt és a besorolást már felülvizsgálták, két kiadási ág továbbra is támogatott, és egy mellékelt könyvtárról azt jelentik, hogy máshol aktívan kihasználják.

Az első feladat nem az upstream biztonsági közlemény lezárása. A fejlesztés azonosítja, mely berendezésbuildek tartalmazzák a sérülékeny könyvtárat, és elérhető-e az érintett funkció. Az SBOM szerint mindkét ág tartalmazza, de a konfigurációelemzés eltérő kitettséget mutat. Ezt a megkülönböztetést alátámasztó bizonyítékokkal együtt rögzítik.

A termékbiztonsági felelős ezután értékeli, hogy a rendelkezésre álló tények teljesítik-e az alkalmazandó CRA szerinti bejelentési kiváltó eseményt. Az egyik telepítési konfigurációval kapcsolatos bizonytalanságot rögzítik; ez nem indokolja, hogy a döntés felelőse megnevezetlen maradjon. A bejelentési forgatókönyv megadja az aktuális értesítési szakaszokat és eljárást.

A fejlesztés minden érintett ághoz átmeneti kockázatcsökkentést és javított buildet készít. A tesztek lefedik a sérülékeny útvonalat, a normál működést és a hitelesített frissítés telepítését. Ha az egyik ágon nem használható az upstream javítás, a csapat rögzíti az alternatív kezelést és a maradványkockázatot, ahelyett hogy a teljes terméket javítottnak jelölné.

Az ügyfélkommunikáció megnevezi az érintett verziókat, az azonnali védelmi lépéseket és a frissítés beszerzésének módját. A nyilvánosságra hozatal időzítését az alkalmazandó sérülékenységkezelési követelményekkel és az esetleges indokolt biztonsági szempontokkal hangolják össze.

Az elkészült nyilvántartás összekapcsolja a biztonsági közleményt, az érintett buildek elemzését, a bejelentési döntést, a szükség szerinti benyújtásokat, a javítási commitokat, a teszteredményeket, a kiadási buildtermékeket és a kommunikációt. Egy felülvizsgáló most már rekonstruálni tudja a mérnöki reagálást és a megfelelési döntést is.

Kezdjen egy termékkel és egy teljes bizonyítéklánccal

Válasszon ki egy reprezentatív támogatott terméket, és kövesse végig egy közelmúltbeli kiadását és egy sérülékenységét az életcikluson. A hiányzó verziókapcsolatok, a tisztázatlan támogatási vállalások és a hozzáférhetetlen bejelentési eljárások gyorsan láthatóvá válnak. Minden hiányosságot alakítson felelőshöz rendelt feladattá, majd terjessze ki a modellt a teljes portfólióra.

A Secani a követelmények, bizonyítékok, felelősök, feladatok és felülvizsgálati döntések összekapcsolásával támogathatja ezt a bizonyítéki munkafolyamatot. A buildek, kiadások és sérülékenységek operatív forrásai továbbra is a fejlesztőeszközök maradnak; a compliance-munkatér ezeket a nyilvántartásokat az alkalmazandó kötelezettséghez kapcsolja. A megfeleltetésekhez és következtetésekhez tartsa kifejezetten emberi jóváhagyáshoz kötöttnek a döntést, és MI-támogatott tervezetek használatakor őrizze meg a források nyomon követhetőségét.

A közvetlen következő lépés a bejelentési forgatókönyv tesztelése. Ezzel párhuzamosan írja elő, hogy a következő termékkiadáshoz kapcsolódjon hatálydöntés, aktuális kockázatértékelés, komponensleltár és biztonsági jóváhagyás. Ez megismételhető mérnöki gyakorlatot teremt, miközben a megfelelőségre való felkészülés halad.