Olvasási idő: 14 perc

Vonatkozik-e a Cyber Resilience Act egy tipikus TYPO3-weboldalprojektre?

Egy vezérigazgató mérnöki nézőpontja — az Európai Bizottság 2026. július 27-i CRA-útmutatása alapján frissítve.

Ottó AndrásOttó András · CEO & TYPO3-architekt27. July 2026

Jogi nyilatkozat: Ez a cikk a személyes véleményemet és mérnöki nézőpontomat tükrözi egy TYPO3-fejlesztő cég vezérigazgatójaként. Nem jogi tanácsadás, nem minősül jogi véleménynek, és nem helyettesíti egy konkrét üzleti modell vagy szerződés képzett ügyvéd általi értékelését.

Egy vezérigazgató mérnöki nézőpontja — az Európai Bizottság 2026. július 27-i CRA-útmutatása alapján frissítve.

Egy fontos pontosítás pont a megfelelő időben érkezett

Amikor elkezdtük vizsgálni a Cyber Resilience Actet, egy kérdés újra és újra visszatért: ha egy ügynökség weboldalt épít TYPO3-mal, akkor az ügynökség egy digitális elemeket tartalmazó termék gyártójává válik-e?

Az óvatos válasz csak az lehetett, hogy egy hagyományos weboldal másképp néz ki, mint azok a szoftvertermékek, amelyekre a CRA-t írták — különösen, mert a (12) preambulumbekezdés kifejezetten megemlíti azokat a weboldalakat, amelyek nem támogatják egy digitális elemeket tartalmazó termék funkcionalitását. Mégis maradt tér a kritikának. A TYPO3 szoftver, az extensionök szoftverek, az egyedi PHP-kód szoftver, és az ügynökséget azért fizetik, hogy ezeket a komponenseket működő rendszerré fűzze össze. Miért ne lenne ez termék?

2026. július 27-én az Európai Bizottság új útmutatást tett közzé a CRA alkalmazásáról. Bár ez az útmutatás nem kötelező erejű, közvetlenül foglalkozik a megkülönböztetéssel, és 67 gyakorlati példát, valamint több folyamatábrát tartalmaz.

A lényegi pontosítás meglepően egyértelmű: egy weboldal nem attól válik digitális elemeket tartalmazó termékké, hogy egyes részei technikailag a látogató böngészőjében futnak. Egy kizárólag böngészőn keresztül elért webalkalmazás önmagában szintén nem ilyen termék, kivéve, ha egy másik, digitális elemeket tartalmazó termék funkcionalitását támogatja.

Ez az útmutatás nem jelenti azt, hogy az ügynökségek megfeledkezhetnek a kiberbiztonságról, és nem zár ki minden TYPO3-hoz kapcsolódó kereskedelmi tevékenységet. Sokkal erősebben alátámasztja azonban azt az álláspontot, amelyet akkor fejtettem ki, amikor először vizsgáltunk egy tipikus, ügyfélspecifikus TYPO3-weboldalprojektet.

Az álláspontom

Azokra a TYPO3-weboldalprojektekre, amelyeket az ügynökségek és a szakosodott fejlesztő szolgáltatók jellemzően együtt szállítanak, az álláspontom a következő:

Egy hagyományos céges weboldal, amelyet böngészőn keresztül érnek el, és amely nem támogatja egy másik, digitális elemeket tartalmazó termék funkcionalitását, önmagában nem digitális elemeket tartalmazó termék a CRA értelmében.

Ebből következik, hogy egy ügynökség nem attól válik egy CRA-termék gyártójává, hogy TYPO3-at használ, extensionöket telepít, projektspecifikus kódot ír, és fizetést kap ezért a munkáért.

Ez a következtetés attól függ, mit szállítanak valójában. Nem szabad automatikusan átvinni egy kereskedelmi TYPO3-extensionre, egy újrafelhasználható szoftverdisztribúcióra, egy helyben telepített alkalmazásra, licencelt forráskódra vagy egy olyan weboldalra, amely egy csatlakoztatott termék valamelyik funkciójának ellátásához szükséges.

Mit akar elérni a CRA

A Cyber Resilience Act, formálisan az (EU) 2024/2847 rendelet, kiberbiztonsági követelményeket állapít meg az Európai Unió piacán forgalmazott, digitális elemeket tartalmazó termékekre.

A célja észszerű és szükséges. A gyártóknak ismerniük kell a termékeikben lévő komponenseket, fel kell mérniük a kiberbiztonsági kockázatokat, kezelniük kell az ismert sérülékenységeket, biztonsági frissítéseket kell szállítaniuk, és egy meghatározott életcikluson át támogatniuk kell a termékeiket. A biztonság ne érjen véget a termék kiadásával.

A CRA ezért olyan területeken vezet be kötelezettségeket, mint:

  • kiberbiztonsági kockázatértékelés;
  • sérülékenységkezelés;
  • biztonsági frissítések és támogatási időszakok;
  • műszaki dokumentáció;
  • megfelelőségértékelés;
  • EU-megfelelőségi nyilatkozatok;
  • CE-jelölés;
  • az aktívan kihasznált sérülékenységek és a súlyos incidensek bejelentése.

Egyetértünk e követelmények szellemiségével. Egy olyan világban, ahol a szoftvertermékek több száz vagy több ezer függőségből állnak össze, egy gyártó ne adhasson el egy terméket úgy, hogy utána elveszíti a rálátást arra, mit tartalmaz.

Ugyanakkor a CRA termékszabályozás. Mielőtt megfelelőségértékelésről, CE-jelölésről vagy gyártói kötelezettségekről beszélnénk, először azonosítanunk kell egy piacon forgalmazott, digitális elemeket tartalmazó terméket.

Ez a termékhatár az ügynökségek központi kérdése.

Mit mond a Bizottság új útmutatása a weboldalakról

A CRA 3. cikk (1) bekezdése a digitális elemeket tartalmazó terméket úgy határozza meg, mint egy szoftver- vagy hardvertermék és annak távoli adatfeldolgozási megoldásai, beleértve a külön a piacon forgalmazott szoftver- vagy hardverkomponenseket is.

A Bizottság útmutatása elmagyarázza, hogyan kell ezt a definíciót a szoftverre alkalmazni.

A 20. bekezdés szerint egy szoftver akkor lehet digitális elemeket tartalmazó termék, ha egy felhasználónak biztosítják, a felhasználó megszerzi, és a felhasználó oldalán egy elektronikus információs rendszeren vagy annak részeként működtetik. Egy letöltött asztali alkalmazás, egy böngészőbővítmény vagy egy helyi futtatásra csomagolt alkalmazás ezért terméknek minősülhet.

A 21. bekezdés a megkülönböztetés másik oldalát írja le. Az a szoftver, amely távolról fut, és amelyet a felhasználó csupán elér, önmagában emiatt nem digitális elemeket tartalmazó termék. Az útmutatás szerint ez jellemzően a webalkalmazásokra igaz — beleértve a progresszív webalkalmazásokat is —, amikor kizárólag böngészőn keresztül érik el őket.

Ezután ugyanezt az érvelést kifejezetten a weboldalakra is alkalmazza:

„A weboldalak önmagukban nem tekintendők digitális elemeket tartalmazó termékeknek."

Az útmutatás két különösen hasznos példát ad. Az 5. példa kimondja, hogy egy kizárólag webböngészőn keresztül elért webalkalmazás nem digitális elemeket tartalmazó termék; csak akkor esik a CRA hatálya alá, ha egy másik, digitális elemeket tartalmazó termék funkcionalitását támogatja. A 6. példa kimondja, hogy egy weboldal, amely pusztán információt jelenít meg a látogatóknak, és nem támogatja egy digitális elemeket tartalmazó termék funkcionalitását, önmagában nem digitális elemeket tartalmazó termék, ezért nem esik a CRA hatálya alá.

Ez már nem csupán a (12) preambulumbekezdés szövegéből levont következtetés. Ez immár a Bizottság kifejezett értelmezése arról, hogyan alkalmazandó a rendelet a weboldalakra és a böngészőalapú alkalmazásokra.

De a TYPO3 szoftver. Miért nem válik ettől az ügynökség gyártóvá?

Ez a legerősebb kritika az álláspontommal szemben, és közvetlen választ érdemel.

Egy ügynökség a TYPO3 Core-t, a harmadik féltől származó csomagokat, a konfigurációt és az egyedi kódot egy teljes technikai rendszerré fűzi össze. Az új útmutatás azt is elmagyarázza, hogy egy integrátor gyártóvá válhat, ha komponenseket egy új, digitális elemeket tartalmazó termékké állít össze, és ezt az új terméket forgalomba hozza.

E mondat lényegi része nemcsak a komponensek integrálása. Az eredménynek magának is egy piacon forgalmazott, digitális elemeket tartalmazó terméknek kell lennie.

Ha szoftverkomponensek minden integrálása automatikusan új CRA-terméket hozna létre, a Bizottság nem juthatna egyszerre arra a következtetésre, hogy a kizárólag böngészős webalkalmazások és a hétköznapi weboldalak önmagukban nem digitális elemeket tartalmazó termékek. Szinte minden modern weboldal tartalmaz tartalomkezelő rendszert, könyvtárakat, frontend-függőségeket, API-kat és projektspecifikus kódot.

Az, hogy egy architektúrán belül termékeket vagy szoftverkomponenseket használnak, önmagában nem határozza meg a kész ajánlat besorolását.

Egy TYPO3-projektnél legalább négy réteget kell megkülönböztetnünk:

  1. a TYPO3 Core mint szabad, nyílt forráskódú szoftver;
  2. a külön terjesztett TYPO3-extensionök és egyéb csomagok;
  3. az ezekkel a komponensekkel megvalósított, ügyfélspecifikus weboldal;
  4. az azt körülvevő hosting-, karbantartási és üzemeltetési szolgáltatások.

E rétegeknek nem automatikusan ugyanaz a szabályozási státuszuk vagy ugyanaz a felelős gazdasági szereplőjük.

A TYPO3 Core önmagában is vizsgálható szoftverként. Egy külön forgalmazott extension szintén lehet digitális elemeket tartalmazó termék. Ebből azonban nem következik, hogy az ezekkel a komponensekkel épített céges weboldal egy újabb, az ügynökség által a piacon forgalmazott szoftvertermékké válna.

Az első kérdés nem az, hogy „Ki integrálta a TYPO3-at?", hanem az, hogy „Mi a végeredmény ajánlata?" Ha az eredmény egy hétköznapi weboldal, amely távolról fut, böngészőn keresztül érik el, és nem támogat másik, digitális elemeket tartalmazó terméket, akkor a Bizottság útmutatása szerint a weboldal önmagában nem digitális elemeket tartalmazó termék. Ilyen termék nélkül az ügynökség pusztán az integráció révén nem válhat annak gyártójává.

A TYPO3 Core szoftver — de a telepítése nem teszi az ügynökséget a gyártójává

Van egy másik megkülönböztetés, amelyet nem szabad a weboldal-érv mögé rejteni: a TYPO3 Core kétségtelenül szoftver. Letölthető, telepíthető és üzemeltethető az ügyfél szerverén vagy egy hostingcég által biztosított infrastruktúrán.

Az, hogy az elkészült weboldal önmagában nem digitális elemeket tartalmazó termék, nem jelenti azt, hogy a TYPO3 Core valahogy megszűnt volna szoftvernek lenni. Azt jelenti, hogy több különböző dologgal van dolgunk, és nem szabad mindegyiknek ugyanazt a szabályozási státuszt tulajdonítanunk.

A Bizottság útmutatása különösen releváns pontosítást ad a szabad, nyílt forráskódú szoftverrel dolgozó ügynökségeknek. Az 55. és 56. bekezdés elmagyarázza, hogy pusztán az a tény, hogy egy FOSS-t közzétevő személy fizetett professzionális szolgáltatásokat is kínál, nem jelenti azt, hogy magát a szoftvert kereskedelmi tevékenység keretében biztosítják. Az útmutatás kifejezetten megemlíti a tanácsadást, a képzést, a dokumentációt, a konfigurációt és a deployt. Az 59. bekezdés ezután egy független szolgáltatóval foglalkozik, amely olyan FOSS-hoz nyújt technikai segítséget, amely nem az ő felelőssége alá tartozik. Az ilyen szolgáltató nem tekintendő úgy, mint aki ezt a szoftvert a piacon forgalmazza, kivéve, ha a szállítása részeként lényegesen módosítja a FOSS-t.

Ez a megkülönböztetés nagyon pontosan megfelel egy normál TYPO3-projektnek. Az ügyfél önállóan letöltheti a TYPO3-at. Az ügynökséget a szakértelméért fizetik: architektúra, telepítés, konfiguráció, integráció, frontend-fejlesztés, minőségbiztosítás, deploy és support. A fizetség nem vásárol engedélyt a TYPO3 Core-hoz való hozzáférésre.

Még közvetlenebbül, a 19. példa egy olyan szolgáltatót ír le, amely segít egy ügyfélnek szabad, nyílt forráskódú szoftvert telepíteni az ügyfél helyi szerverére. Ha a szolgáltató nem módosítja lényegesen ezt a FOSS-t, a Bizottság arra a következtetésre jut, hogy a szolgáltató nem tekinthető úgy, mint aki a FOSS-t a piacon forgalmazza. Ez szokatlanul közeli analógia sok TYPO3-projekt munkájához.

Az ügynökség nem teszi közzé a TYPO3 Core-t a saját neve alatt, nem irányítja a kiadásait, és nem határozza meg az általános roadmapjét. A TYPO3 telepítése és konfigurálása ezért nem teszi az ügynökséget a TYPO3 Core gyártójává. A telepítést üzemeltető ügyfél sem válik annak gyártójává pusztán a használat révén.

Van egy fontos korlát. A 19. példa kifejezetten feltételezi, hogy a szolgáltató nem módosítja lényegesen a FOSS-t. Egy ügynökség, amely lényegesen módosított TYPO3-forkot hoz létre és szállít, a 22. cikk szerint más szerepben lehet. A TYPO3 rendeltetésszerű extension- és konfigurációs mechanizmusainak normál használatát — site-konfiguráció, TypoScript, Fluid-sablonok, tartalomelemek és extensionök — nem szabad automatikusan összekeverni a TYPO3 Core lényeges módosításával. Nehezebb kérdés merül fel, ha egy ügynökség forkolja a Core-t, megváltoztatja a rendeltetési célját, vagy olyan változtatásokat vezet be, amelyek lényegesen befolyásolják a CRA-megfelelőségét vagy a kiberbiztonsági kockázati profilját.

Ezért is kell a saját tulajdonú extensionöket külön értékelni. Az ügynökség a TYPO3 Core tekintetében maradhat csupán telepítő és szolgáltató, miközben egyúttal gyártójává válik egy olyan extensionnek vagy disztribúciónak, amelyet a saját neve alatt fejleszt, irányít és szállít.

Hogyan dolgozunk valójában az ügynökségekkel

A Digital Zombies általában TYPO3-szakértőcsapatként vesz részt, egy másik ügynökséggel együttműködve. A projekttől függően architektúrával, extension-fejlesztéssel, integrációkkal, frissítésekkel, deploy-támogatással vagy hosszú távú technikai karbantartással járulunk hozzá.

Nem várjuk el az ügynökségektől vagy az ügyfelektől, hogy egy saját tulajdonú Digital Zombies alap-témát vagy egy kötelező termék-extensiont vásároljanak egy projekt megépítéséhez. Nem tesszük minden ügyfél-megvalósítást egy szabványos „Digital Zombies weboldaltermék" újabb telepítésévé.

Egy tipikus projekt jellemzői:

  • egy azonosított ügyfélnek készül;
  • a dizájnja, tartalommodellje és integrációi ügyfélspecifikusak;
  • az ügyfél domainje és identitása alatt fut;
  • a látogatók a böngészőjükön keresztül érik el;
  • a látogatók nem kapják meg és nem telepítik a mögöttes TYPO3-rendszert;
  • a weboldal nem szükséges egy másik digitális termék működéséhez;
  • a TYPO3 Core és a harmadik féltől származó csomagok megtartják saját identitásukat és licencüket;
  • a részt vevő cégek fejlesztési és integrációs szolgáltatásokat nyújtanak, nem pedig egy újrafelhasználható weboldalterméket licencelnek.

Ezek a körülmények nem egyenkénti jogi mentességek. Az egyedi szoftver attól még lehet termék, és a fizetség bizony lehet egy kereskedelmi tevékenység része. Azt írják le azonban, mit szállítanak: egy távolról üzemeltetett ügyfél-weboldalt, nem pedig egy ügynökségi márkájú szoftvercsomagot, amelyet a felhasználók a saját elektronikus információs rendszereikben való futtatásra kapnak meg. Ez a technikai valóság nagyon pontosan megfelel annak a megkülönböztetésnek, amelyet a Bizottság most tesz.

A Digital Zombies számára a gyártói kérdés sok white-label projektben még távolibb. Szakosodott mérnöki munkával járulunk hozzá a partnerügynökség felelőssége és szállítási modellje alatt. Nem forgalmazzuk az ügyfél-weboldalt a Digital Zombies néven, és a weboldal látogatói gyakran soha nem tudják meg, hogy a csapatunk részt vett benne. Ez a tény önmagában nem döntené el a CRA hatályát, de különösen nehezen tarthatóvá teszi azt az állítást, hogy a Digital Zombies a saját neve alatt forgalmaz egy weboldalterméket.

A nyilvános hozzáférés nem azonos egy szoftvertermék megkapásával

Egy céges weboldal nyilvánosan elérhető. Ez nem jelenti azt, hogy a szoftverét minden látogatónak átadják.

A látogatók HTML-t, CSS-t, JavaScriptet, képeket és a weboldal használatához szükséges adatokat kapnak. Nem szerzik meg a TYPO3-telepítést, nem deployolják a saját rendszereikre, és nem kapnak licencet arra, hogy a kész weboldal-szoftvert önállóan üzemeltessék.

A Bizottság útmutatása elismeri ezt a technikai megkülönböztetést. Megjegyzi, hogy egy weboldal egyes részei futhatnak a látogató eszközén, mégis arra a következtetésre jut, hogy a weboldalak önmagukban nem digitális elemeket tartalmazó termékek. Néhány letöltött frontend-asset nem alakítja át a teljes, távolról üzemeltetett weboldalt helyben szállított szoftvertermékké.

Ezért sem dönthető el a kérdés azzal, hogy egy weboldal hálózatot használ. A hálózati kapcsolat csak azután releváns, hogy azonosítottunk egy digitális elemeket tartalmazó terméket. Önmagában nem tud termékké alakítani valamit, amit az útmutatás kifejezetten weboldal-szolgáltatásként kezel.

A (11) és (12) preambulumbekezdés továbbra is fontos határt húz

A Bizottság értelmezése a CRA (11) és (12) preambulumbekezdésére épül.

A (11) preambulumbekezdés elmagyarázza, miért képezheti a távoli adatfeldolgozás egy digitális elemeket tartalmazó termék részét. Egy gyártó ne kerülhesse meg a termékbiztonsági kötelezettségeket pusztán azzal, hogy a terméke egy lényeges funkcióját a felhasználó eszközéről a saját backendjébe helyezi át. Egy okoseszköz például függhet egy távoli hitelesítési szolgáltatástól, API-tól vagy felhő-backendtől. Ha e távoli feldolgozás hiánya megakadályozná, hogy a termék ellássa valamelyik funkcióját, a távoli megoldás a CRA szerint a termék részét képezheti.

A (12) preambulumbekezdés a megfelelő korlátot állítja fel. Azok a weboldalak, amelyek nem támogatják egy digitális elemeket tartalmazó termék funkcionalitását, kívül esnek ezen a viszonyon.

Az új útmutatás gyakorlati tesztet ad. Pusztán információt közzétenni egy digitális termékről nem elég, még akkor sem, ha a termék a weboldalra hivatkozik. Egy útmutatókat tartalmazó külső oldal nem automatikusan távoli adatfeldolgozási megoldás. Ezzel szemben egy hitelesítési portál, amely a termék működéséhez szükséges azonosítókat vagy tokeneket bocsát ki, támogathat egy termékfunkciót, ezért távoli adatfeldolgozásként a CRA hatálya alá eshet.

A legtöbb céges TYPO3-weboldalnál a megkülönböztetés egyértelmű. Szolgáltatások, telephelyek, esettanulmányok, cikkek, álláshirdetések vagy elérhetőségek bemutatása rendszerint nem teszi lehetővé egy másik, digitális elemeket tartalmazó termék működését. Egy CRM-integráció, hírlevél-kapcsolat, keresőszolgáltatás vagy kapcsolati űrlap sem változtat automatikusan ezen a következtetésen. A releváns kérdés nem az, hogy a weboldal kommunikál-e egy másik rendszerrel, hanem az, hogy egy másik, digitális elemeket tartalmazó termék a weboldal vagy annak távoli feldolgozása nélkül akadályozott lenne-e valamelyik funkciója ellátásában.

Hol változik a következtetésünk

Az új útmutatás erősíti a hétköznapi weboldalak melletti álláspontot, de segít azonosítani azokat az eseteket is, amelyeket az ügynökségeknek külön kell értékelniük.

Egy kereskedelmi TYPO3-extension

Ha egy ügynökség extensiont fejleszt, a saját neve alatt teszi közzé vagy licenceli, és TYPO3-telepítésekben való használatra szállítja, akkor ez az extension digitális elemeket tartalmazó szoftvertermék lehet. Az ügynökség ekkor az extension gyártója lehet. Ez az a forgatókönyv, amelyben az SBOM-generálás, a függőségek átláthatósága, a sérülékenység-figyelés, a koordinált közzététel, a biztonsági frissítések, a műszaki dokumentáció és egy meghatározott támogatási időszak közvetlenül relevánssá válik. Nem számít, hogy az extensionnek csak egy ügyfele van, ha kész szoftvertermékként szállítják; a termékbesorolás nem igényel tömeges terjesztést.

Termékként szállított forráskód

A fejlesztési szolgáltatás és a szoftvertermék közötti különbség nem egyszerűsíthető le arra, hogy az ügyfél kap-e forráskódot. Az útmutatás 7. példája egy olyan céget ír le, amely egy testreszabható belső platform forráskódját licenceli. Bár az ügyfélnek a kódot adaptálnia és fordítania kell, a Bizottság úgy tekinti, hogy a forráskódot termékként hozták forgalomba. Egy szerződés, amely egy ügyfélprojekten belüli mérnöki munkára szól, nem automatikusan azonos egy meghatározott platform, disztribúció vagy kódbázis termékként való licencelésével. Az ügynökségeknek érteniük kell, e modellek közül melyiket hozzák létre valójában a szerződéseik és a szállítási folyamataik.

Helyben telepített alkalmazások

Egy asztali alkalmazás, böngészőbővítmény, mobilalkalmazás vagy webtechnológiákkal épített, de helyi telepítésre csomagolt alkalmazás lehet digitális elemeket tartalmazó termék. Az, hogy HTML-t és JavaScriptet használ, nem teszi weboldallá. A döntő különbség az, hogy az alkalmazást a felhasználónak szállítják, és a felhasználó környezetében fut.

Egy másik terméket támogató weboldal

Egy TYPO3-weboldal a CRA hatálya alá eshet, ha egy másik, digitális elemeket tartalmazó termék funkcionalitását támogatja. Példa lehet egy portál, amely egy csatlakoztatott eszköz által igényelt azonosítókat bocsát ki, egy backend, amely egy helyben telepített termék konfigurálásához szükséges, vagy olyan távoli feldolgozás, amely nélkül a termék nem tudja ellátni valamelyik funkcióját. Ebben a helyzetben a weboldal vagy a backend nem feltétlenül külön termék; a csatlakoztatott termék távoli adatfeldolgozási megoldásának részét képezheti, és be kell vonni a gyártó értékelésébe.

SaaS és kizárólag böngészős üzleti alkalmazások

Az új útmutatás megköveteli annak a gyakori állításnak a finomítását is, hogy egy fizetős SaaS-alkalmazás automatikusan CRA-termék. Egy kizárólag böngészős webalkalmazás nem attól válik digitális elemeket tartalmazó termékké, hogy az ügyfelek fizetnek a hozzáférésért. Ez általában egy távolról nyújtott szolgáltatás, és a felhőszolgáltatási modellekre inkább a NIS2 és más alkalmazandó jogszabályok vonatkozhatnak. A CRA mégis relevánssá válhat, ha ez a szolgáltatás egy másik, digitális elemeket tartalmazó termék funkcióját támogatja. Az architektúra és a távolról üzemeltetett szolgáltatás és a termék közötti viszony ezért többet számít, mint a „SaaS" címke.

A CRA-n kívül nem jelenti a felelősségen kívül

A cikkből levonható rossz következtetés az lenne, hogy egy hétköznapi TYPO3-weboldal kevésbé komoly biztonsági mérnöki munkát igényel.

A weboldal feldolgozhat személyes adatokat, kapcsolódhat belső rendszerekhez, fogadhat jelentkezéseket vagy megkereséseket, és kritikus kommunikációs csatorna lehet. Támadható a terméktörvény szerinti besorolásától függetlenül.

Az ügynökségeknek ettől még fenn kell tartaniuk:

  • a TYPO3- és frontend-függőségek leltárát;
  • reprodukálható deployokat;
  • sérülékenység-figyelést;
  • időben végrehajtott biztonsági frissítéseket;
  • dokumentált felelősségi köröket az ügyfél, az ügynökség, a hostingszolgáltató és a szakosodott fejlesztő partner között;
  • tesztelt biztonsági mentési és helyreállítási eljárásokat;
  • egy folyamatot a sérülékenységi bejelentések fogadására és megválaszolására.

A gyakorlatban a CRA által ösztönzött mérnöki gyakorlatok közül sok jó gyakorlat azoknál a weboldalaknál is, amelyek a termékkörén kívül esnek. Egy SBOM továbbra is segíthet az ügynökségnek megérteni, mi van telepítve. A biztonsági advisoryknak továbbra is el kell jutniuk a megfelelő emberekhez. Egy nem támogatott extension akkor is kockázat marad, ha nincs szükség CE-jelölésre.

A jogi besorolás a formális kötelezettségeket változtatja meg. A technikai kockázatot nem szünteti meg.

Összegzés: a TYPO3 nem tesz egy weboldalt termékké

A CRA célja értékes, és egyetértünk az alapelvével: azoknak a cégeknek, amelyek digitális termékeket hoznak forgalomba, a teljes termék-életciklus során felelősséget kell vállalniuk a biztonságukért. A felelősség azonban a helyes termékhatár azonosításával kezdődik.

Az, hogy a TYPO3 szoftver, nem jelenti azt, hogy minden TYPO3-mal megvalósított weboldal az ügynökség által gyártott új szoftvertermékké válik. Az Európai Bizottság 2026. júliusi útmutatása most kifejezetten kimondja, hogy egy weboldal önmagában nem digitális elemeket tartalmazó termék, és hogy egy kizárólag böngészőn keresztül elért webalkalmazás sem ilyen termék, kivéve, ha egy másik termék funkcionalitását támogatja.

Egy tipikus, ügyfélspecifikus céges weboldalnál ez egyértelmű következtetést támaszt alá: az ügynökség architektúra-, fejlesztési, integrációs és üzemeltetési szolgáltatásokat nyújt egy távolról elért weboldal köré. Nem automatikusan hoz forgalomba egy digitális elemeket tartalmazó weboldalterméket.

A határ akkor változik, ha az ügynökség kereskedelmi extensiont szállít, forráskódot licencel termékként, helyben futtatott szoftvert biztosít, vagy egy másik, digitális elemeket tartalmazó termék által igényelt távoli funkcionalitást épít.

Ezért az ügynökségeknek sem válogatás nélkül félniük nem kell a CRA-tól, sem teljesen elutasítaniuk. Fel kell térképezniük, mit szállítanak valójában, el kell választaniuk a termékeket a szolgáltatásoktól és komponensektől, azonosítaniuk kell, ki forgalmazza az egyes termékeket, majd a releváns kötelezettségeket a megfelelő rétegre kell alkalmazniuk. Ez hasznosabb mérnöki válasz, mint megpróbálni minden sor egyedi PHP-kódot új, CE-jelöléssel ellátott termékként besorolni.

Hivatkozások

← Előző cikkBelső eszközből TYPO3-termék: amit az extension-gyártóknak tudniuk kell az SBOM-okról