CRA 2026: termékbiztonsági dokumentáció ISO 27001 alapon

Egy hálózatba kapcsolt eszközöket gyártó vállalat péntek délutáni megbeszélésre hívja információbiztonsági vezetőjét, Mariát. Az értékesítés éppen megszerzett egy európai disztribúciós megállapodást. A jogi terület azt kérdezi, hogy a vállalat képes-e alátámasztani a Cyber Resilience Act szerinti megfelelést. A mérnökség szerint a biztonságos fejlesztés „nagyrészt lefedett”, mert van kód-felülvizsgálat, SAST és javításkezelés. A beszerzés szerint a beszállítók „titoktartási megállapodás hatálya alatt állnak”. A termékcsapatoknál a firmware-függőségek az egyik eszközben, a felhő API-nyilvántartások egy másikban, a sérülékenységi jegyek pedig a Jira rendszerben találhatók. A megfelelési terület rendelkezik ISO/IEC 27001:2022 tanúsítási bizonyítékokkal, de ezek a vállalati ISMS köré szerveződnek, nem az EU piacán forgalomba hozott egyes termékek köré.

Ekkor hangzik el a kényelmetlen kérdés: „Ha egy uniós hatóság, ügyfél, megfelelőségértékelő szervezet vagy jelentős disztribútor 2026-ban bekéri a termékbiztonsági dokumentációt, elő tudjuk állítani egy héten belül?”

Sok szoftverbeszállító, okoseszköz-gyártó és hálózatba kapcsolt szolgáltatást nyújtó szervezet esetében az őszinte válasz: nem. Nem azért, mert nincsenek biztonsági kontrollok, hanem mert a termékbiztonsági bizonyítékok szétszórtan találhatók. A biztonságos fejlesztés nyilvántartásai a mérnökségnél vannak. Az SBOM-ok buildenként készülnek, de nincs felettük irányítás. A koordinált sérülékenység-feltárás weboldalként létezik, de nem mindig kapcsolódik a befogadáshoz, az előszűréshez, a javításokhoz, a tájékoztatókhoz és a forgalomba hozatal utáni felügyelethez. A beszállítói biztonság a beszerzési szerződésekben van elrejtve. Az incidensbejelentés a biztonsági üzemeltetéshez tartozik, míg a megfelelőségi dokumentáció a termékmegfeleléshez.

Az EU Cyber Resilience Act megváltoztatja a működési modellt. A termék-kiberbiztonság többé nem csupán bevált gyakorlat vagy szerződéses ígéret. Életcikluson átívelő bizonyítási kötelezettséggé válik. A szervezeteknek képesnek kell lenniük bemutatni, hogyan épülnek be a kiberbiztonsági követelmények a tervezésbe, fejlesztésbe, kiadásba, sérülékenységkezelésbe, frissítésekbe és a termék piacra kerülése utáni felügyeletbe.

Itt válik az ISO/IEC 27001:2022 különösen hasznossá, ha megfelelően alkalmazzák. Önmagában nem terméktanúsítási rendszer, de az ISMS, valamint a kockázatkezelési, eszközkezelési, beszállítói, biztonságos fejlesztési, sérülékenységkezelési és incidenskezelési kontrolljai biztosíthatják a CRA termékbiztonsági dokumentáció gerincét. A cél nem egy újabb megfelelési siló létrehozása. A cél a meglévő ISMS termékszintű bizonyítékrendszerré alakítása.

Ahogy a Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap a 2. fázis 8. lépésében, a bizonyítékarchitektúra kapcsán fogalmaz:

„A bizonyítékokat nem az auditciklus végén kell összegyűjteni. Be kell őket tervezni a kontrollba, felelőshöz kell rendelni őket, a folyamatnak időbélyeggel kell ellátnia őket, és újra felhasználhatónak kell lenniük minden olyan kötelezettségnél, amely ugyanazt a kérdést más nyelven teszi fel.”

Ez a mondat ragadja meg a CRA-ra való felkészültség lényegét. A kérdés nem csupán az, hogy „van-e biztonságos fejlesztésünk?”. A kérdés az, hogy „tudjuk-e igazolni a biztonságos fejlesztést, a komponensek ismeretét, a sérülékenységkezelést és a forgalomba hozatal utáni felügyeletet erre a termékre, erre a verzióra, erre a kiadásra és erre a piacra?”.

A CRA termékbiztonsági dokumentáció élő bizonyítékrendszer

A CRA termékbiztonsági dokumentációt nem szabad statikus PDF-ként kezelni, amely egyszer elkészül a kiadás előtt, majd feledésbe merül. Olyan strukturált dossziénak kell lennie, amely a koncepciótól a támogatás megszűnéséig bemutatja a termék biztonsági történetét.

Egy hasznos dokumentáció ismerteti:

1. Mi a termék, és milyen rendeltetéssel használható.
2. Milyen szoftvert, firmware-t, felhőszolgáltatásokat és harmadik féltől származó függőségeket tartalmaz.
3. Milyen kiberbiztonsági kockázatokat értékeltek.
4. Milyen biztonsági követelményeket alkalmaztak.
5. Hogyan történt a biztonságos fejlesztés.
6. Hogyan fogadják, szűrik elő, javítják és teszik közzé a sérülékenységeket.
7. Hogyan történik a biztonságos frissítések kézbesítése.
8. Hogyan kontrollálják a beszállítókat és a nyílt forráskódú komponenseket.
9. Hogyan eszkalálják az incidenseket és az aktívan kihasznált sérülékenységeket.
10. Hogyan felügyelik a terméket a piaci forgalomba hozatalt követően.

Egy információbiztonsági vezető számára ez ISMS-bizonyítékkezelési kihívás. A termékmegfelelési vezető számára műszaki dokumentáció. A mérnökség számára DevSecOps és kiadásirányítás. A felsővezetők számára piacra jutási és felelősségi kockázatkezelés.

Hiba ezeket külön munkafolyamatként kezelni. A jobb modell egy olyan termékszintű bizonyítékdokumentáció létrehozása, amely leképezi az ISO/IEC 27001:2022 és ISO/IEC 27002:2022 kontrollokra, majd ugyanazokat a bizonyítékokat szükség szerint NIS2, DORA, GDPR, NIST és COBIT 2019 követelményekre is átképezi.

A Clarysec Zenith Controls: The Cross-Compliance Guide ezt kontroll–bizonyíték–auditor láncként írja le:

„Egy több megfelelési keretrendszert kiszolgáló bizonyítékdokumentációnak minden kötelezettséget le kell képeznie a működő kontrollra, az ismétlődő bizonyítékobjektumra, az elszámoltatható felelősre és arra az auditori nézőpontra, amelyből azt majd megkérdőjelezik.”

Erre a fegyelemre van szükség a CRA-felkészüléshez. A termékbiztonsági dokumentáció nem puszta mappa. Fordítási réteg a termékmérnökség, a biztonsági irányítás, a megfelelőségértékelés és az ügyfélbizonyosság között.

Először a termékbizonyítékok gerincét kell felépíteni

A dokumentációnak egységes struktúrára van szüksége, mielőtt a csapatok elkezdenek nyilvántartásokat feltölteni. Egyértelmű gerinc nélkül a bizonyítékok képernyőképek, exportok és szabályzati PDF-ek halmazává válnak, amelyet egyetlen auditor sem tud követni.

CRA-felkészültségi workshopokon a Clarysec jellemzően az alábbi termékbiztonsági dokumentációs struktúrát ajánlja azoknak a szervezeteknek, amelyek már működtetnek ISO/IEC 27001:2022 ISMS-t.

Ez a táblázat nem váltja ki a jogszabályi műszaki dokumentációs kötelezettségeket. Működési modellt ad az üzletnek ezek igazolására.

A Zenith Blueprint 1. fázisának 3. lépése a hatály és a határok meghatározására összpontosít. CRA esetén ez a lépés termékspecifikussá válik. Határozza meg a termékcsaládot, a szoftververziókat, a telepítési feltételezéseket, a felhasználói szerepköröket, a kapcsolt szolgáltatásokat, a frissítési csatornákat és a támogatási időszakot. Ha az ISMS hatálya „vállalati SaaS és eszközkezelési platform”, a CRA-dokumentációnak akkor is egy szűkebb kérdésre kell választ adnia: „Melyik digitális elemeket tartalmazó termék kerül az EU piacára, és mi tartozik bele ebbe a termékbe?”

A biztonságos fejlesztést termékszintű nyilvántartásokra kell leképezni

A termékbiztonsági dokumentáció központi eleme a tervezésbe épített biztonság bizonyítása. Az ISO/IEC 27001:2022 biztosítja az irányítási rendszert. Az ISO/IEC 27002:2022 olyan kontrollokon keresztül ad megvalósítási útmutatást, mint az A.8.25 Biztonságos fejlesztési életciklus, az A.8.27 Biztonságos rendszerarchitektúra és mérnöki alapelvek, az A.8.28 Biztonságos kódolás és az A.8.29 Biztonsági tesztelés fejlesztés és átvétel során.

A lényegi változás az általános biztonságos fejlesztési állításokról a kiadásspecifikus nyilvántartásokra való átállás. Az, hogy „végzünk kód-felülvizsgálatot”, nem elegendő. A dokumentációnak meg kell mutatnia, melyik kiadást vizsgálták felül, milyen kockázatokat vettek figyelembe, mely biztonsági tesztek teljesültek, mely sérülékenységeket fogadták el vagy javították ki, és ki hagyta jóvá a kiadást.

A Clarysec Enterprise Biztonságos fejlesztési szabályzat célja ennek a bizonyítékláncnak a kikényszerítése. A 6.1 pont, Biztonságos fejlesztési életciklus követelményei, így rendelkezik:

„Minden termék- vagy szolgáltatáskiadáshoz dokumentált bizonyítékot kell fenntartani a biztonsági követelményekről, a tervfelülvizsgálatról, a biztonságos kódolási tevékenységekről, a biztonsági tesztelésről, a sérülékenységek javítására vonatkozó döntésekről és a kiadás jóváhagyásáról az éles bevezetés előtt.”

Ez a pont azért hasznos a CRA szempontjából, mert a biztonságos fejlesztést ismételhető bizonyítékmintává alakítja. Az auditornak nem kell kikövetkeztetnie, hogy megtörtént-e a biztonságos fejlesztés. Megvizsgálhatja a kiadási nyilvántartást.

Egy intelligens termosztát, orvosi IoT-eszköz, ipari érzékelő vagy SaaS-kapcsolt termék esetében a biztonságos fejlesztési bizonyítékoknak tartalmazniuk kell:

• Az azonosított kockázatokhoz leképezett termékbiztonsági követelményeket.
• Fenyegetésmodellt vagy visszaélési eset elemzést a termékre és a kapcsolt szolgáltatásokra.
• Architektúra-felülvizsgálatot, beleértve a bizalmi határokat és a külső interfészeket.
• Biztonságos kódolási szabványt, valamint a fejlesztői tudomásulvétel vagy képzés igazolását.
• SAST, DAST, szoftverösszetétel-elemzés, titokvizsgálat és firmware-elemzés eredményeit, ahol alkalmazható.
• Helyesbítő intézkedési jegyeket a magas kockázatú megállapításokra.
• Kockázatelfogadási nyilvántartásokat üzleti és biztonsági jóváhagyással.
• Kiadási kapu ellenőrzőlistát, amely igazolja a biztonsági kritériumok teljesülését.
• Kriptográfiai aláírási és frissítési sértetlenségi bizonyítékokat.
• A támogatási időszakra és az életciklus végére vonatkozó feltételezéseket.

Más szabványok is erősítik a módszert. Az ISO/IEC 27005 támogatja e nyilvántartások kockázatalapú megközelítését. Az ISO/IEC 27017 hasznos, ha felhőszolgáltatások képezik a termék-ökoszisztéma részét. Az ISO/IEC 27035 támogatja az incidenskezelést. Az ISO/IEC 29147 és az ISO/IEC 30111 különösen releváns a sérülékenység-feltárás és sérülékenységkezelés szempontjából. Az ISO/IEC 27036 a beszállítói biztonságot támogatja, ami fontos, ha a termék kiszervezett szoftvert, beágyazott modulokat, menedzselt felhőszolgáltatásokat vagy harmadik féltől származó könyvtárakat tartalmaz.

A Zenith Controls rendszerben a CRA biztonságos fejlesztési bizonyítékait jellemzően olyan ISO/IEC 27002:2022 kontrolltémák köré képezik le, mint az információbiztonság a projektmenedzsmentben, a biztonságos fejlesztési életciklus, a biztonságos kódolás, a biztonsági tesztelés, a változáskezelés és a technikai sérülékenységek kezelése. Az útmutató ezeket az eszköznyilvántartáshoz és a beszállítói kontrollokhoz is kapcsolja, mert egyetlen biztonságos fejlesztési folyamat sem teljes, ha a szervezet nem tudja azonosítani azokat a komponenseket, amelyeket szállít.

Az SBOM-ot szabályozott termékbizonyítékként kell kezelni

A Software Bill of Materials gyakran technikai artefaktumként jelenik meg. A CRA-ra való felkészültség szempontjából termékbizonyítékként kell kezelni.

Egy hasznos SBOM megmutatja, milyen komponensek vannak a termékben, mely verziókat használják, honnan származnak, milyen licencek vonatkoznak rájuk, mely sérülékenységek érintik őket, és mely kiadások tartalmazzák őket. Firmware- és beágyazott termékek esetén ez magában foglalhat operációsrendszer-csomagokat, bootloadereket, könyvtárakat, illesztőprogramokat, konténereket, harmadik féltől származó modulokat és a termék működéséhez szükséges felhőoldali függőségeket.

A probléma az, hogy sok szervezet előállít SBOM-okat, de nem irányítja őket. Egy build pipeline előállíthat SPDX- vagy CycloneDX-fájlt, de senki nem ellenőrzi a teljességét. A biztonsági eszközök jelezhetnek sérülékenységeket, de az eredmények nem kapcsolódnak a termékverziókhoz. A beszerzés jóváhagyhat egy beszállítót, de a beszállító komponenslistáját nem egyeztetik össze a kiadott termékkel.

A Clarysec Enterprise Eszközkezelési szabályzat az 5.2 pontban, Információk és kapcsolódó eszközök nyilvántartása, ezt az irányítási hiányosságot kezeli:

„Az információs vagyonelemeket és a kapcsolódó technológiai komponenseket azonosítani kell, tulajdonost kell hozzájuk rendelni, szükség szerint osztályozni kell őket, és olyan nyilvántartásban kell fenntartani, amely támogatja a kockázatértékelést, a sérülékenységkezelést, a változáskezelést és az auditbizonyítékokat.”

CRA esetén ez a pont termékspecifikussá válik. Az SBOM a kapcsolódó technológiai komponensek nyilvántartásának része. Szüksége van tulajdonosra, megőrzési szabályra, ellenőrzési folyamatra és sérülékenységkezelési kapcsolatra.

Egy gyakorlati SBOM-bizonyítékszabály egyszerű: minden kiadott termékverziónak rendelkeznie kell jóváhagyott komponensnyilvántartással, amely összekapcsolható a kiadási artefaktummal. Ha a szervezet nem tudja összekötni az SBOM-ot a pontos firmware-képpel, alkalmazáscsomaggal, konténer-digesttel vagy SaaS-kiadással, az SBOM gyenge bizonyíték.

Ha kettőnél több sor nem teljesül, a probléma általában nem az SBOM-eszköz. A probléma az irányítás. A termékbiztonsági dokumentációnak ISMS helyesbítő intézkedésként kell rögzítenie ezt, mert a CRA-bizonyítékok gyengesége egyben ISO/IEC 27001:2022 kontrollhatékonysági probléma is.

A CVD-t össze kell kapcsolni a sérülékenységkezeléssel és a kiadásirányítással

A koordinált sérülékenység-feltárás a CRA-ra való felkészültség egyik legláthatóbb területe, mert külső kutatók, ügyfelek és hatóságok közvetlenül tesztelhetik. Egy sérülékenység-feltárási oldal vagy security.txt fájl közzététele hasznos, de csak a bejárati ajtó. A termékbiztonsági dokumentációnak bizonyítania kell, hogy a háttérfolyamatok működnek.

Egy igazolható CVD- és sérülékenységkezelési bizonyítékhalmaznak tartalmaznia kell:

• Nyilvános bejelentési csatornát és benyújtási útmutatót.
• Kutatói visszaigazolási folyamatot.
• Előszűrési kritériumokat, beleértve a súlyosság és kihasználhatóság értékelését.
• Termékhatás-elemzést.
• Helyesbítő intézkedési felelősséget és célhatáridőket.
• Ügyfél-tájékoztató és frissítési kommunikációs sablonokat.
• Bizonyítékot a biztonságos javításfejlesztésről és tesztelésről.
• Koordinált közzétételi nyilvántartásokat, ahol alkalmazható.
• Tanulságokat és ismétlődő sérülékenységi trendek elemzését.

A Clarysec Enterprise Sérülékenységkezelési szabályzat 6.3 pontja, Sérülékenységek befogadása, előszűrése és helyesbítő intézkedése, így rendelkezik:

„A bejelentett sérülékenységeket naplózni kell, értékelni kell az érintett eszközök és termékek szempontjából, kockázat és kihasználhatóság alapján priorizálni kell, elszámoltatható tulajdonoshoz kell rendelni, és a helyesbítő intézkedésen, ellenőrzésen, kommunikáción és lezáráson keresztül nyomon kell követni.”

Ez a pont összekapcsolja a CVD-t az SBOM-mal, az eszköznyilvántartással, a mérnökségi jegyekkel, a kiadáskezeléssel és a forgalomba hozatal utáni felügyelettel. Ez az a pont is, amelyet az auditorok természetes módon tesztelni fognak: mutassák be a befogadási nyilvántartást, az érintett termékeket, az előszűrést, a javítást, az ügyfélkommunikációt és a lezárást.

A meglévő Információbiztonsági incidenskezelési szabályzatot ki kell terjeszteni azokra a terméksérülékenységekre is, amelyek incidenssé válnak vagy külső bejelentést igényelnek. Az ISO/IEC 27002:2022 A.5.24 az incidenskezelés tervezését és előkészítését, az A.5.25 az információbiztonsági események értékelését és az azokkal kapcsolatos döntést, az A.5.26 az információbiztonsági incidensekre adott választ, az A.5.27 pedig az incidensekből való tanulást fedi le.

A Zenith Controls a sérülékenységkezelést megelőző és helyesbítő jelleggel egyaránt kezeli. A megelőző oldal magában foglalja a nyilvántartást, a biztonságos fejlesztést, a beszállítói felügyeletet és a biztonságos konfigurációt. A helyesbítő oldal magában foglalja az észlelést, az előszűrést, a javítások telepítését, a kommunikációt és az incidenseszkalációt. Ez a különbségtétel azért fontos, mert a forgalomba hozatal utáni sérülékenységkezelés a termék-életciklus kötelezettségének része, nem utólagos kiegészítés.

A beszállítói bizonyíték a rejtett gyenge pont

A termékbiztonsági dokumentációt gyakran ott fogják a legkeményebben megkérdőjelezni, ahol a gyártó másokra támaszkodik. Ide tartoznak a beágyazott modulok, a kiszervezett firmware-fejlesztés, a white-label komponensek, a felhőhoszting, a mobil SDK-k, a fizetési szolgáltatások, a kriptográfiai könyvtárak és a menedzselt támogatási szolgáltatók.

A tipikus hibaminta a szerződéses absztrakció. A gyártó azt mondja: „Ezért a beszállítónk felel.” Termékbiztonsági vizsgálat alatt ez nem elegendő. A szervezetnek be kell mutatnia, hogy a beszállítói kockázatot azonosították, a biztonsági követelményeket kommunikálták, a bizonyítékokat összegyűjtötték, a sérülékenységeket koordinálták, és a változásokat kontrollálták.

A Clarysec Enterprise Harmadik fél és beszállítói biztonsági szabályzat 7.1 pontja, Beszállítói biztonsági követelmények, így rendelkezik:

„Azokat a beszállítókat, amelyek információs rendszereket, termékeket vagy szolgáltatásokat fejlesztenek, üzemeltetnek, feldolgoznak, támogatnak, vagy ezekre lényes hatást gyakorolnak, kockázat alapján értékelni kell, és olyan biztonsági követelmények alá kell vonni, amelyek kiterjednek a hozzáférésre, a sérülékenységkezelésre, az incidensbejelentésre, az alvállalkozásba adásra, a folytonosságra és a bizonyítékok rendelkezésre bocsátására.”

CRA szempontból a „termékekre lényeges hatást gyakorolnak” kifejezés kritikus. Ha egy beszállítói komponens sérülékenységet vezethet be, megzavarhatja a frissítéseket, ügyféladatokat tehet ki vagy veszélyeztetheti az eszköz sértetlenségét, akkor helye van a termékbiztonsági dokumentációban.

Ugyanez a szabályzat az SBOM szerződéses kikötését is támogathatja. A 7.3 pont így rendelkezik:

„Minden olyan harmadik féltől származó szoftverkomponens, könyvtár vagy operációs rendszer esetében, amelyet a vállalat »digitális elemeket tartalmazó termékeibe« integrálnak, a beszállítónak kérésre géppel olvasható Software Bill of Materials (SBOM) dokumentumot kell biztosítania szabványos formátumban, például SPDX vagy CycloneDX szerint. Ezt a követelményt minden beszerzési és beszállítói szerződésbe be kell építeni.”

Egy erős beszállítói bizonyítékcsomagnak tartalmaznia kell a beszállítók termékhatás szerinti osztályozását, a szerződésekben rögzített biztonsági követelményeket, a kritikus komponensekre vonatkozó beszállítói biztonságos fejlesztési bizonyítékokat, a beszállítói sérülékenység-feltárási kötelezettségvállalásokat, ahol megvalósítható SBOM-ot vagy komponensnyilatkozatokat, a javítástámogatási és életciklus-végi határidőket, időszakos felülvizsgálati nyilvántartásokat és eszkalációs útvonalakat a beszállítói eredetű sérülékenységekre.

Az ISO/IEC 27002:2022 A.5.19, A.5.20 és A.5.21 adja a kulcsfontosságú beszállítói kontrolltémákat. Az ISO/IEC 27036 mélyebb támogatást nyújt a beszállítói kapcsolatok biztonságához. Több megfelelési keretrendszer nézőpontjából a NIS2 az ellátási láncot és a sérülékenységkezelést hangsúlyozza. A DORA a pénzügyi szervezetek IKT-harmadik fél kockázatát emeli ki. A GDPR akkor válik relevánssá, ha a termék vagy felhőszolgáltatásai személyes adatokat kezelnek. A COBIT 2019 a beszállítói irányítást vállalati technológiairányítási kérdésként kezeli, nem pusztán biztonsági üzemeltetési kérdésként.

A forgalomba hozatal utáni felügyelet működéssé alakítja a bizonyítékokat

A legérettebb termékbiztonsági szervezetek a kiadáson túl gondolkodnak. Azt kérdezik: „Honnan fogjuk tudni, ha ez a termék a terepen kockázatossá válik?”

A forgalomba hozatal utáni felügyeletnek jeleket kell gyűjtenie sérülékenységi hírcsatornákból, exploit információkból, ügyféltámogatásból, telemetriából, bug bounty vagy kutatói bejelentésekből, beszállítói értesítésekből, felhőnaplókból, incidensnyilvántartásokból és terepi teljesítményadatokból. Tartalmaznia kell a termékkockázat időszakos felülvizsgálatát is, amikor a fenyegetési környezet megváltozik.

A Clarysec Enterprise Naplózási és felügyeleti szabályzat 5.4 pontja, Biztonsági felügyelet és felülvizsgálat, így rendelkezik:

„A biztonsági szempontból releváns eseményeket olyan módon kell gyűjteni, felülvizsgálni, eszkalálni és megőrizni, amely támogatja az időszerű észlelést, vizsgálatot, incidensreagálást, megfelelőségi jelentéstételt és folyamatos fejlesztést.”

Hálózatba kapcsolt termékek esetén ezt körültekintően kell értelmezni. A felügyeletnek tiszteletben kell tartania a magánszféra védelmét, az adattakarékosságot és a jogi korlátokat, különösen akkor, ha a telemetria személyes adatokat vagy ügyféloldali működési adatokat tartalmaz. A GDPR-leképezés fontos. A termékbiztonsági csapatoknak együtt kell működniük az adatvédelmi csapatokkal annak meghatározásában, hogy mely telemetria szükséges a biztonsághoz, hogyan minimalizálják azt, mennyi ideig őrzik meg, és hogyan tájékoztatják az ügyfeleket.

A forgalomba hozatal utáni felügyeleti bizonyítékoknak tartalmazniuk kell termékbiztonsági felügyeleti tervet, sérülékenységi információforrásokat, ügyfélbejelentési csatornákat, beszállítói értesítési csatornákat, telemetria- vagy naplófelülvizsgálati hatókört, időszakos termékkockázati felülvizsgálati jegyzőkönyveket, javítási bevezetettség követését, incidenstrend-elemzést és vezetőségi felülvizsgálati bemeneteket.

A Zenith Blueprint 5. fázisának 30. lépése a folyamatos fejlesztésre és a felügyeleti auditra való felkészültségre összpontosít. CRA esetén itt válik a termékbiztonsági dokumentáció élő dokumentációvá. Minden termékkiadásnak, sérülékenységnek, beszállítói változásnak és terepi jelzésnek frissítenie kell a bizonyítéknyilvántartást.

Egy bizonyítékdokumentáció, sok megfelelési kérdés

Egy jól megtervezett CRA termékbiztonsági dokumentáció csökkenti a párhuzamosságot, mert ugyanaz a bizonyíték több megfelelési kérdésre is választ ad. A nyelvezet változik, de a kontrollvalóság gyakran hasonló.

A Zenith Controls ilyen újrafelhasználásra készült. Az ISO/IEC 27002:2022 kontrolltémákat olyan attribútumokhoz kapcsolja, mint a megelőző, észlelő és helyesbítő kontrollcél, a kiberbiztonsági fogalmak, a működési képességek és a biztonsági tulajdonságok. CRA esetén ez segít az információbiztonsági vezetőnek elmagyarázni, hogy egyetlen bizonyítékobjektum, például egy kiadásbiztonsági felülvizsgálat, miért támogatja egyszerre a biztonságos fejlesztést, a kockázatkezelést, a változáskezelést, a sérülékenységkezelést és az auditra való felkészültséget.

Fel kell készülni a különböző auditori nézőpontokra

A CRA termékbiztonsági dokumentációt megkérdőjelezheti ISO-auditor, belső audit csoport, ügyfélbizonyossági csapat, termékmegfelelőségi felülvizsgáló, szabályozó hatóság, NIST-alapú értékelő vagy ISACA-képzett COBIT-auditor. Mindegyik hasonló kérdéseket tesz fel, de más nézőpontból.

Ugyanaz a gyenge pont különböző módon fog felszínre kerülni. Ha az SBOM-ok elkészülnek, de nem őrzik meg őket, az ISO-auditor nyilvántartás-kezelési és operatív kontrollproblémát lát. A NIST-értékelő eszköz- és sérülékenységkezelési gyengeséget lát. A COBIT-auditor gyenge információs vagyon feletti irányítást lát. A termékfelülvizsgáló elégtelen műszaki dokumentációt lát.

A CRA-ra való felkészültségre adaptált 30 lépéses ütemterv

A Zenith Blueprint megakadályozza, hogy a megfelelési csapatok azonnal dokumentumgyűjtésbe ugorjanak. CRA esetén a 30 lépéses ütemterv termékbiztonsági bizonyítékprogramgá válik.

Az 1. fázis a kötelezettségek és a hatály leképezésével indul. Azonosítsa, mely termékek, verziók, komponensek, felhőszolgáltatások és támogatási folyamatok tartoznak a hatályba. Erősítse meg a rendeltetésszerű használatot, a felhasználói kategóriákat, a piacokat és a biztonsági támogatási időszakot.

A 2. fázis felépíti a bizonyítékarchitektúrát. Határozza meg a termékbiztonsági dokumentáció indexét, a bizonyítékfelelősöket, a megőrzési követelményeket, az adattárstruktúrát és a jóváhagyási munkafolyamatot. Igazítsa a mérnökségi rendszerekhez ahelyett, hogy manuális feltöltéseket kényszerítene ki.

A 3. fázis bevezeti a működési kontrollokat. A biztonságos fejlesztésnek, az SBOM-előállításnak, a sérülékenységkezelésnek, a beszállítói bizonyítékoknak, a kiadási kapuknak, a biztonsos frissítéseknek és az incidenseszkalációnak valós folyamatként kell működniük.

A 4. fázis teszteli az auditra való felkészültséget. Válasszon ki egy termékkiadást, és végezzen próbaauditot. Le tudja kérni a csapat az SBOM-ot? Tudják igazolni a biztonsági tesztelést? Be tudják mutatni, hogyan szűrtek elő egy sérülékenységet? Össze tudják kapcsolni a beszállítói bizonyítékot a termékkomponensekkel?

Az 5. fázis beépíti a felügyeletet és a fejlesztést. A forgalomba hozatal utáni felügyelet, a sérülékenységi trendelemzés, a beszállítói felülvizsgálatok és a vezetőségi felülvizsgálati bemenetek naprakészen tartják a dokumentációt.

Ez a sprint általában gyorsan feltárja a valós helyzetet. A szervezetek ritkán azért buknak el, mert egyáltalán nincsenek kontrolljaik. Azért buknak el, mert a kontrollok nem kapcsolódnak termékszinten.

Gyakori CRA-felkészültségi hiányosságok 2026 előtt

A szoftverbeszállítók, eszközgyártók és hálózatba kapcsolt szolgáltatást nyújtók körében visszatérő hiányosságok figyelhetők meg.

Először: az ISMS hatálya túl vállalati szintű. Lefedi a szervezetet, de nem tartalmaz elegendő termék-életciklus részletet. A megoldás termékszintű mellékletek és bizonyítékdokumentációk létrehozása.

Másodszor: az SBOM-ok léteznek, de nem megbízhatók. Eszközök generálják őket, de nem vizsgálják felül, nem hagyják jóvá, nem őrzik meg, és nem kapcsolják sérülékenységi döntésekhez. A megoldás az SBOM-irányítás, nem csupán az SBOM-előállítás.

Harmadszor: a CVD nyilvánosan elérhető, de működési szempontból nem elég érett. A bejelentések beérkeznek, de az előszűrési kritériumok, válaszcélok, tájékoztató-jóváhagyások és lezárási bizonyítékok következetlenek. A megoldás a CVD integrálása a sérülékenységkezeléssel, incidenskezeléssel és kiadáskezeléssel.

Negyedszer: a beszállítói bizonyíték túl felszínes. A kritikus beszállítókat kereskedelmi szempontból jóváhagyják, de nem értékelik őket a termékbiztonsági hatás alapján. A megoldás a beszállítók termékkockázat szerinti osztályozása és a kritikus komponensekre vonatkozó kötelező bizonyíték.

Ötödször: a forgalomba hozatal utáni felügyelet reaktív. A csapatok reagálnak a sürgős sérülékenységekre, de nem végeznek időszakos termékkockázati felülvizsgálatokat. A megoldás az ütemezett, forgalomba hozatal utáni biztonsági felülvizsgálat, amely a vezetői jelentéstételhez kapcsolódik.

Hatodszor: az auditbizonyíték túlságosan manuális. A megfelelési csapatok képernyőképeket hajszolnak. A megoldás a bizonyítéktervezés, amely a mérnökségi rendszereket, jegykezelési munkafolyamatokat és adattárakat hiteles forrásként használja.

Építse fel a bizonyítékdokumentációt, mielőtt a határidő kényszeríti ki

A Cyber Resilience Act azokat a szervezeteket jutalmazza, amelyek működési fegyelemként tudják bizonyítani a termékbiztonságot. Kockázatot teremt azoknak, amelyek a bizonyítékokat utolsó pillanatos megfelelési gyakorlatként kezelik.

Kezdjen egy termékkel. Építsen fel egy termékbiztonsági dokumentációt. Képezze le ISO/IEC 27001:2022 és ISO/IEC 27002:2022 szerint. Csatolja a biztonságos fejlesztési bizonyítékokat, az SBOM-ot, a CVD-nyilvántartásokat, a beszállítói bizonyosságot és a forgalomba hozatal utáni felügyeletet. Futtasson auditszimulációt, mielőtt ezt külső fél teszi meg Ön helyett.

A Clarysec fel tudja gyorsítani ezt az utat a Zenith Blueprint, a Zenith Controls, az Enterprise Biztonságos fejlesztési szabályzat, Sérülékenységkezelési szabályzat, Eszközkezelési szabályzat, Harmadik fél és beszállítói biztonsági szabályzat, Naplózási és felügyeleti szabályzat és Információbiztonsági incidenskezelési szabályzat segítségével.

A legfontosabb CRA 2026 kérdés nem az, hogy „vannak-e biztonsági kontrolljaink?”.

Hanem az, hogy „tudjuk-e bizonyítani a termékbiztonságot kiadásról kiadásra, komponensről komponensre, sérülékenységről sérülékenységre, miután a termék már a piacon van?”.

Építse fel most a bizonyítékdokumentációt, kapcsolja az ISMS-hez, és tegye minden jövőbeli termékkiadását tervezésénél fogva auditra felkészültté.