A Cyber Resilience Act (CRA) rendelkezései 2027. december 11-től válnak teljes egészében alkalmazandóvá, de 2026. szeptember 11. óta a gyártóknak az aktívan kihasznált sérülékenységeket és a súlyos biztonsági incidenseket jelenteniük kell az ENISA által üzemeltetett egységes bejelentési platformon (Single Reporting Platform) keresztül. Ez a kötelezettség a CRA hatálya alá eső, már forgalomban lévő digitális elemeket tartalmazó termékekre is vonatkozik.

A CRA teljes körű kötelező alkalmazására való felkészülés jegyében 2026. október 22-én az Európai Uniós Kiberbiztonsági Ügynökség (ENISA) közzétette a Technical Advisory for Software Bill of Materials (SBOM) című útmutatóját.

Az anyag elsősorban a mikro-, kis- és középvállalkozások, valamint nyílt forráskódú projektek fenntartói számára kíván gyakorlati segítséget nyújtani ahhoz, hogy gyártóként meg tudják határozni, érinti-e a terméküket egy újonnan felfedezett sérülékenység. Ehhez pontos komponensnyilvántartásra és a szoftverellátási lánc átláthatóságára van szükség, ezért a CRA – szintén 2027. december 11. napjától kötelezően alkalmazandó - I. számú melléklet II. részének 1. pontja előírja, hogy a „gyártóknak azonosítaniuk és dokumentálniuk kell a digitális elemeket tartalmazó termékben található sérülékenységeket és alkotóelemeket, többek között egy általánosan használt és géppel olvasható formátumú szoftveranyagjegyzék elkészítésével, amely kiterjed legalább a termék felső szintű függőségeire” – vagyis e szoftveranyagjegyzék (Software Bill of Materials - SBOM) léte jogi kötelezettség lesz a 2027. december 11. napját követően forgalomba hozott, vagy lényegesen módosított termékek vonatkozásában.

Fontos leszögezni, hogy az útmutató nem kötelező erejű, és az ENISA azt is hangsúlyozza, hogy nem tekinthető a CRA jogi értelmezésének. Rögzíteni szükséges ugyanakkor azt is, hogy az EU Bizottsága végrehajtási jogi aktusok útján, az európai és nemzetközi szabványokat és legjobb gyakorlatokat figyelembe véve meghatározhatja az SBOM formátumát és elemeit, az ENISA anyaga ugyanakkor várhatóan fontos hivatkozási ponttá válik a gyártók, a megfelelőségértékeléseket végzők és piacfelügyeleti hatóságok számára egyaránt.

A cikk az első részben bemutatja az ENISA útmutató fejlesztői szempontból fontos elemeit. A második rész pedig azt vizsgálja, hogy mi a helyzet az AI-komponenst tartalmazó termékekkel, és hogyan kapcsolódik ide az EU AI Act.

I. rész – Az ENISA SBOM útmutatója

Mi az SBOM és mi a jelentősége a CRA-megfelelés szempontjából?

A szoftvertermékek gyakran több száz vagy akár több ezer összetevőt tartalmaznak. Ezek nyilvántartása nélkül a sérülékenységkezelés gyakorlatilag nem valósítható meg megfelelő módon.

A Software Bill of Materials – magyarul szoftveranyagjegyzék - lényegében egy strukturált komponensjegyzék, amely felsorolja egy szoftvertermék összetevőit, azok verzióit és ellátási láncon belüli kapcsolatait.

Az SBOM célja, hogy a gyártó gyorsan meg tudja állapítani, hogy milyen komponenseket tartalmaz a terméke; egy újonnan felfedezett sérülékenység érinti-e az adott terméket; mely komponens szorul frissítésre; illetve mely komponensek származnak nyílt forráskódú vagy külső beszállítói forrásból.

Az SBOM elkészítésének kötelezettsége a CRA I. melléklet II. rész (1) bekezdésén alapul, és a sérülékenységkezelési követelményekhez kapcsolódik. A gyártónak többek között azonosítania és dokumentálnia kell a termék komponenseit; kezelnie kell a sérülékenységeket a teljes támogatási időszak alatt; nyomon kell követnie a külső komponensek biztonsági állapotát; megfelelő információval kell rendelkeznie ahhoz, hogy gyorsan – a megszabott határidőn belül - reagálhasson egy új sérülékenység megjelenésekor.

Mindezek érdekében a gyártónak egy géppel olvasható formátumú SBOM-ot kell tudnia előállítani, amely legalább a felső szintű függőségeket (top-level dependencies) lefedi. Ez a jogszabályi minimum, de az ENISA ennél tovább megy (lásd lent). A CRA tehát nem pusztán dokumentációs kötelezettséget ír elő: az SBOM a sérülékenységkezelési folyamat egyik alapvető eszköze.

Az SBOM fő szabályként nem nyilvános (a gyártó dönthet úgy is, hogy nyilvánosságra hozza), a piacfelügyeleti hatóság kérésére azonban a rendelkezésére kell bocsátani.

Mely termékekre és kire vonatkozik a kötelezettség?

A CRA fő szabályként a 2027. december 11. után forgalomba hozott „digitális elemeket tartalmazó termékekre” és azok gyártóira vonatkozik.

Azokra a digitális elemeket tartalmazó termékekre, amelyeket 2027. december 11. előtt hoztak forgalomba, a CRA követelményei csak akkor alkalmazandók, ha ez időpontot követően a termék lényeges módosításon megy keresztül. Ettől függetlenül a 14. cikk szerinti jelentéstételi kötelezettségek valamennyi olyan, a rendelet hatálya alá tartozó digitális elemeket tartalmazó termékre is vonatkoznak, amelyet 2027. december 11. előtt hoztak forgalomba.

A CRA „digitális elemeket tartalmazó terméknek” a szoftver- vagy hardvertermékeket és azok távoli adatfeldolgozási megoldásait tekinti, ideértve a külön forgalomba hozott szoftver- vagy hardverkomponenseket is. A rendelet hatálya akkor terjed ki rájuk, ha rendeltetésük vagy észszerűen előrelátható használatuk közvetlen vagy közvetett, logikai vagy fizikai adatkapcsolatot foglal magában valamely eszközzel vagy hálózattal, és kereskedelmi tevékenység keretében (ellenérték fejében vagy ingyenesen) hozzák őket forgalomba. A Bizottság iránymutatása szerint ide tartozik az önállóan forgalomba hozott szoftver (például alkalmazások, programok), a beágyazott szoftvert (például firmware-t) tartalmazó hardver, az önálló hardver (például integrált áramkörök, alaplapok), valamint az együttműködésre szánt, de külön szállított hardver-szoftver kombináció. Utóbbi körbe tartozik a hardverhez szükséges, külön csatornán (például alkalmazásboltból) letölthető szoftver is, például egy okosóra mobilalkalmazása.

A szoftver akkor minősül terméknek, ha a felhasználónak szállítják, és a felhasználó oldali információs rendszeren fut (például letöltött vagy telepített alkalmazás, böngészőbővítmény, helyi futtatásra szánt, webes technológiával készült alkalmazás). Az a szoftver, amely távolról fut, és a felhasználó csak eléri, önmagában ezen az alapon nem digitális elemeket tartalmazó termék. Ez jellemzően a kizárólag böngészőn keresztül használt webalkalmazásokra (a progresszív webalkalmazásokat is beleértve) és a weboldalakra igaz. Ezek is a hatály alá kerülhetnek azonban, ha egy termék távoli adatfeldolgozási megoldásaként működnek.

Távoli adatfeldolgozási megoldásnak az a távolról végzett adatfeldolgozás minősül, amelynek szoftverét a gyártó tervezte és fejlesztette (vagy a gyártó felelőssége alatt, egyedi igényei szerint fejlesztették), és amelynek hiánya megakadályozná, hogy a termék ellásson valamely funkciót. E funkció nem korlátozódik a termék fő funkciójára: ide tartozhat például a parancsküldés, a szinkronizálás, a felhasználó beléptetése, a konfigurálás vagy az azonosítás- és hozzáférés-kezelés. A távoli adatfeldolgozási megoldás csak a szoftverelemeket foglalja magában, és nem kell harmadik fél felhőjében futnia: a gyártó saját szerverén vagy egy harmadik fél IaaS/PaaS-ára telepített, általa fejlesztett szoftver is ilyen lehet. Nem távoli adatfeldolgozási megoldás a gyártó belső rendszere (például HR, CRM, CI/CD), a pusztán tájékoztató weboldal, valamint az a háttérrendszer sem, amellyel a termék közvetlenül nem áll kapcsolatban (ezeket a kockázatértékelésben külső függőségként kell kezelni). A harmadik féltől származó, nem a gyártó felelőssége alatt fejlesztett SaaS-alkalmazás sem távoli adatfeldolgozási megoldás, de az iránymutatás szerint komponensszerűen kezelendő: kockázatértékelés és megfelelő gondosság szükséges hozzá, és a technikai dokumentációban ismertetni kell.

Gyártónak a CRA alapján az minősül, aki a digitális elemeket tartalmazó terméket gyárt, fejleszt, illetve terveztet, gyártat vagy fejleszttet, és azt ingyenesen vagy ellenérték fejében az uniós piacon forgalmazza. Itt fontos megjegyezni, hogy a CRA „gyártó” és az AI Act „szolgáltató” fogalma lényegében megegyezik az értékláncban elfoglalt szerepet tekintve, és mindkettő az EU termékbiztonsági szabályait és az Új Jogszabályi Keretet (NLF) megalapozó, Blue Guide-ban gyökerezik.

Miben segíthet az ENISA új útmutatója?

Az ENISA dokumentuma kifejezetten gyakorlati megközelítést alkalmaz. Nem azt magyarázza el, hogy miért szükséges az SBOM, hanem azt, hogyan érdemes azt a fejlesztési és üzemeltetési folyamatokba integrálni.

Az útmutató három fő területre fókuszál.

1. SBOM architektúra és életciklus

Az ENISA bemutatja, hogy az SBOM nem egyszeri dokumentum, hanem egy életcikluson át karbantartott adatállomány. Az ajánlott életciklus: generálás → validálás → kriptográfiai aláírás → biztonságos tárolás → felhasználás → folyamatos karbantartás. Az a fontos, hogy az SBOM a fejlesztési folyamat részeként keletkezzen; automatikusan frissüljön a build folyamat során; verziózott legyen; kapcsolódjon a kiadott szoftververzióhoz; a teljes életciklus alatt naprakész maradjon.

Fejlesztői szemmel a legfontosabb paraméterek:

2. Kockázatok és fenyegetések

Az útmutató külön fenyegetési modellt mutat be az SBOM ökoszisztémára. Kockázatot jelenthet például a hiányos vagy pontatlan SBOM; a manipulált komponenslista; a jogosulatlan módosítás; az elavult verziók használata; a sérült vagy elveszett SBOM-adatállomány.

Az ENISA STRIDE-modellt alkalmaz, és az egész láncot vizsgálja, nem csak az állományt: a hamisított szerzőt vagy build-pipeline-t, a módosított komponens-, hash- vagy PURL-adatokat, a generálás vagy terjesztés letagadását, a technológiai stack kiszivárgását a verziókból és a függőségi gráfból, a tárhely- vagy parser-kimerítést, valamint a kompromittált CI/CD- vagy aláíró infrastruktúrát. Ez magyarázza az SBOM korlátozott megosztását is: a pontos verziólista a lehetséges támadóknak is térkép.

3. Bevált gyakorlatok és biztonsági intézkedések

A dokumentum számos gyakorlati ajánlást fogalmaz meg, többek között: automatizált SBOM-generálás; digitális aláírás alkalmazása; integritásvédelem; verziókezelés; automatizált sérülékenység-figyelés; CI/CD integráció; ellátási lánc monitorozása.

Az intézkedések technikai magja:

• szerepkör-alapú hozzáférés-szabályozás, többfaktoros hitelesítés és a legkisebb jogosultság elve a pipeline-ban és az SBOM-tárolóban;
• TLS 1.3 érvényes tanúsítvány-ellenőrzéssel az átvitelnél, az aláíró kulcsok, API-tokenek, repository-hitelesítő adatok kezelése (vault);
• hiteles build-provenance, amely összeköti a forráskódot, a buildet, az SBOM-ot és a kiadott artifactot;
• manipulálásnak ellenálló tárolás, integritás-monitorozás, auditnaplózás és riasztás;
• az SBOM-tár, az aláíró anyagok és a naplók mentése és helyreállíthatósága.

Az ENISA szerint az SBOM valódi értéke nem a dokumentum létrehozásában, hanem annak napi használatában rejlik.