Cyber Resilience Act: „e open source” nu te scutește dacă dezvolți comercial peste WordPress, PrestaShop sau Magento
de Claudiu Hulea · IT Management Consultant
„E open source, nu e treaba mea” e exact greșeala pe care Cyber Resilience Act o taie. Dacă firma ta dezvoltă comercial peste WordPress, PrestaShop sau Magento, adică vinde plugin-uri, teme și module sau construiește site-uri și magazine pentru clienți din UE, CRA te poate face producătorul produsului livrat, cu tot ce ține de asta. Nucleul open-source nu e responsabilitatea ta; ce construiești și livrezi comercial peste el, da. Iar în România, unde o mare parte din industria de web și e-commerce trăiește pe aceste platforme, expunerea e uriașă.
Ce e în scop și ce nu
Distincția-cheie a CRA nu e „open source sau nu”, ci „activitate comercială sau nu”.
Proiectele open-source în sine, WordPress, PrestaShop, Magento ca software, nu sunt problema ta. Software-ul dezvoltat în afara unei activități comerciale e în mare parte în afara scopului, iar organizațiile care întrețin aceste proiecte au un rol special și mai ușor, de „open-source steward”.
Ce intră în scop e ce faci tu comercial cu ele, iar aici prețul nu contează, ci intenția comercială. Un plugin gratuit care are o versiune pro, colectează date, afișează reclame sau e întreținut de o firmă e în scop. Un plugin sau o temă vândute pe un marketplace te fac producător cu obligații complete.
Când devii producător
Sunt câteva situații în care CRA te tratează ca producător al produsului, chiar dacă nucleul e al altcuiva.
Vinzi un plugin, o temă sau un modul. Comercial, direct sau printr-un marketplace. Ești producătorul acelui produs.
Construiești bespoke pentru un client din UE. Software făcut la comandă și livrat comercial unui client e în scop. Nu te salvează că e „doar pentru un client”.
Integrezi componente într-un produs pe care îl pui pe piață. Dacă asamblezi module, teme și cod propriu într-un produs livrat clientului, ești integrator, iar CRA te consideră producătorul produsului asamblat.
Modifici substanțial un produs existent. O schimbare de după punerea pe piață care afectează conformitatea de securitate sau scopul pentru care produsul a fost evaluat te face producătorul acelei versiuni, cu obligațiile complete.
Cazul cel mai expus: cei care modifică nucleul
Am văzut firme care modifică direct nucleul, de exemplu core-ul Magento, nu prin module și override-uri, ci umblând în cod. E cazul cel mai expus sub CRA, din două motive care se adună.
Întâi, e modificarea substanțială în forma ei cea mai clară: ai schimbat produsul, deci ești producătorul versiunii tale.
Al doilea motiv e mai practic și mai dureros. Când umbli în nucleu, îți rupi calea de actualizare din upstream. Nu mai poți aplica curat patch-urile de securitate pe care le scoate proiectul, fiindcă ai divergit de la codul lui. Exact atunci când CRA îți cere să livrezi update-uri de securitate pe toată durata de suport, tu ești cel care trebuie să reproducă manual fiecare corecție, singur, pe versiunea ta. E o datorie pe care ți-o creezi singur și pe care legea o face acum obligatorie.
Ce ți se cere, și de când
Două momente contează.
Din 11 septembrie 2026, deja: raportarea. Dacă o vulnerabilitate a produsului tău e exploatată activ sau ai un incident sever, o raportezi către CSIRT-ul național și ENISA în 24 și 72 de ore. Se aplică inclusiv la ce ai livrat deja. Concret, dacă un plugin sau un nucleu pe care l-ai pus în producție la un client are o vulnerabilitate exploatată, obligația de raportare poate fi a ta.
Din 11 decembrie 2027: obligațiile de producător. Securitate prin design, gestionarea și dezvăluirea coordonată a vulnerabilităților, un SBOM care spune din ce e făcut produsul, update-uri de securitate pe durata de suport, și evaluarea de conformitate cu marcaj CE pentru produsele noi.
Pentru produsele deja pe piață înainte de 2027, o modificare substanțială nu te obligă să aduci tot produsul la conformitate CRA, dar obligația de raportare rămâne.
De ce România e expusă
O parte foarte mare din dezvoltarea de web și e-commerce din România se face peste WordPress, PrestaShop și Magento: agenții, freelanceri și firme de produs care vând plugin-uri și teme sau construiesc magazine pentru clienți din toată UE. Presupunerea comodă e „folosim open source, deci nu e responsabilitatea noastră”. CRA spune opusul: în momentul în care faci bani punând un produs digital pe piața UE, îi datorezi securitatea, indiferent pe ce e construit.
Ce faci acum
- Cartografiază-ți rolul pe fiecare livrare: vinzi un produs, integrezi sau modifici substanțial? Fiecare te poate face producător.
- Cunoaște-ți dependențele. Livrezi codul altora peste al tău și ești responsabil de securitatea produsului asamblat. Un SBOM e punctul de plecare.
- Nu umbla în nucleu. Folosește module, override-uri și puncte de extensie, ca să poți lua patch-urile de securitate din upstream. E și bună practică, și acum apărare de conformitate.
- Pornește un proces de tratare și dezvăluire coordonată a vulnerabilităților: un canal de raportare, un contact de securitate, o procedură. Pentru ecosistemul WordPress există și platforme dedicate, unele gratuite și sprijinite de Comisia Europeană.
- Definește durata de suport a fiecărui produs și cum livrezi update-uri de securitate pe toată perioada.
- Pune-o în contracte. Clarifică cu clienții și cu subcontractorii cine e producătorul, cine întreține și cine raportează.
Ce reținem
„E open source” nu e un scut, e o temelie pe care construiești, iar temelia gratuită nu mută responsabilitatea de la tine. În momentul în care livrezi comercial un produs digital în UE, ești răspunzător de securitatea lui pe toată durata de viață, oricât de mult din el vine din proiecte pe care nu le-ai scris tu.
Asta nu e sfat juridic, iar aplicarea CRA depinde de situația ta concretă; Comisia Europeană a publicat deja ghiduri care clarifică scopul și merită citite. Dar reflexul corect e clar: nu presupune că ești în afara scopului fiindcă folosești open source. Verifică, exact ca la orice control de securitate.
Vrei să știi dacă livrările tale peste WordPress, PrestaShop sau Magento intră sub CRA, în ce rol și ce ai de pregătit? Scrie-ne și pornim de la o evaluare.
Surse
Întrebări frecvente
Dacă folosesc software open-source, sunt în afara CRA?
Nu automat. Distincția CRA nu e open source sau nu, ci activitate comercială sau nu. Proiectele open-source în sine (WordPress, PrestaShop, Magento ca software) și software-ul dezvoltat în afara unei activități comerciale sunt în mare parte în afara scopului, iar organizațiile care întrețin aceste proiecte au un rol mai ușor de open-source steward. Dar ce construiești și livrezi comercial peste ele te poate face producător, cu obligații complete.
Când devin producător sub CRA?
Când vinzi un plugin, o temă sau un modul, chiar și gratuit dacă are versiune pro, colectează date sau e întreținut de o firmă. Când livrezi software bespoke comercial unui client din UE. Când integrezi componente într-un produs pe care îl pui pe piață. Și când modifici substanțial un produs existent, de exemplu îi schimbi postura de securitate sau scopul; atunci devii producătorul acelei versiuni, cu obligațiile complete.
Ce înseamnă că modific nucleul Magento sau WordPress?
E cazul cel mai expus. O modificare a nucleului care schimbă postura de securitate sau scopul produsului e o modificare substanțială, deci devii producătorul acelei versiuni. În plus, îți rupi calea de update-uri din upstream: nu mai poți aplica curat patch-urile de securitate ale proiectului, exact atunci când CRA îți cere să livrezi update-uri pe toată durata de suport. Ajungi responsabil de fiecare corecție, singur.
Ce trebuie să fac și de când?
Din 11 septembrie 2026, deja: raportarea vulnerabilităților exploatate activ și a incidentelor severe în 24 și 72 de ore, inclusiv pentru ce ai livrat deja. Din 11 decembrie 2027: obligațiile de producător, adică securitate prin design, gestionarea și dezvăluirea coordonată a vulnerabilităților, SBOM, update-uri pe durata de suport și marcaj CE pentru produsele noi. Cartografiază-ți rolul pe fiecare livrare și pornește acum un proces de tratare a vulnerabilităților.
