Cyber Resilience Act (CRA) marchează una dintre cele mai importante schimbări de paradigmă în modul în care securitatea produselor digitale este reglementată la nivel european. Dincolo de cerințele de conformitate, CRA forțează o repoziționare profundă a modului în care organizațiile proiectează, dezvoltă și întrețin software, aducând în prim-plan concepte precum secure-by-design, transparența lanțului de aprovizionare și responsabilitatea continuă asupra vulnerabilităților.
În acest context, proiectul european CYBERFORT „Strengthening Cyber Defenses of SMEs for Cyber Resilience Act (CRA) Compliance” își propune să sprijine IMM-urile în procesul de aliniere la noile cerințe, prin instrumente, resurse, training și modele practice de implementare. Proiectul este coordonat de I-ENERGYLINK din România și reunește un consorțiu format din opt organizații partenere din România și Cipru, inclusiv DNSC și parteneri din mediul tehnologic, juridic și industrial.
Conferința CRA Europe 2026, desfășurată la București, a oferit un cadru relevant pentru discutarea modului în care principiile CRA pot fi transformate în măsuri concrete pentru companii, în special pentru IMM-uri și pentru sectoarele critice. În acest interviu, Mihaela Curcă vorbește despre provocările implementării, despre rolul proiectului în acest efort și despre felul în care teme precum inteligența artificială și codul generat asistat de AI se intersectează cu noile cerințe de reziliență cibernetică.
Mihaela Curcă este Project Manager în cadrul proiectului CYBERFORT, o inițiativă europeană dedicată consolidării capacităților de securitate cibernetică și reziliență la nivel național și regional. Implicată activ în organizarea conferinței CRA Europe 2026, aceasta contribuie la facilitarea dialogului dintre autorități, industrie și mediul academic privind implementarea Cyber Resilience Act. Activitatea sa se concentrează pe susținerea inițiativelor de creștere a nivelului de maturitate în securitate și pe promovarea unor abordări practice și colaborative în domeniul rezilienței cibernetice.
1. CRA este adesea perceput ca un cadru ambițios, dar complex. Din perspectiva dumneavoastră, care sunt cele mai frecvente neînțelegeri pe care le observați în rândul organizațiilor din România?
Cred că una dintre cele mai frecvente neînțelegeri este aceea că CRA este privit doar ca o nouă obligație de conformitate, un set de documente care trebuie bifate la un anumit moment. În realitate, filosofia CRA merge mai departe de atât. Vorbim despre integrarea securității în întreg ciclul de viață al unui produs digital, de la proiectare și dezvoltare până la mentenanță, actualizări și gestionarea vulnerabilităților.
O altă percepție pe care o întâlnim este că CRA ar viza doar companiile mari sau producătorii de soluții foarte complexe. În practică, impactul poate ajunge și la organizații mai mici, inclusiv IMM-uri, furnizori de software, integratori sau companii care dezvoltă componente digitale utilizate în lanțuri de aprovizionare mai ample.
Din perspectiva proiectului CYBERFORT, această zonă este foarte importantă, pentru că multe organizații au nevoie de sprijin practic: instrumente, ghidaj, exemple concrete și o înțelegere clară a pașilor de urmat.
Conformitatea nu ar trebui privită ca un exercițiu administrativ, ci ca o oportunitate de a construi produse și servicii digitale mai sigure, mai reziliente și mai de încredere.
2. Care sunt pașii concreți pe care companiile românești ar trebui să îi facă în următoarele 12–18 luni pentru a se alinia cu cerințele CRA, dincolo de conformitatea formală?
Cred că primul pas, și poate cel mai important, este o evaluare onestă a situației actuale. Multe organizații nu au încă o imagine clară asupra nivelului lor real de maturitate în materie de securitate – fie că vorbim de procese, de dezvoltare software sau de gestionarea vulnerabilităților. Apoi, aș spune că este esențial să înceapă integrarea principiilor de secure-by-design în procesele interne. Asta înseamnă să nu mai tratăm securitatea ca pe un pas final, ci ca pe ceva care este prezent încă din faza de proiectare și dezvoltare. Pentru unele companii, asta poate însemna ajustări în modul de lucru al echipelor de dezvoltare sau introducerea unor controale suplimentare în pipeline-urile existente.
Un alt pas concret este definirea și testarea unui proces clar de vulnerability management. Nu doar identificarea vulnerabilităților, ci și prioritizarea, remedierea și comunicarea lor – inclusiv către utilizatori, acolo unde este cazul. CRA pune destul de mult accent pe această zonă. Din perspectiva proiectului CYBERFORT, vedem că organizațiile au nevoie și de instrumente practice care să le ajute în acest proces – fie că vorbim de evaluări de risc, de maparea cerințelor CRA sau de generarea documentației necesare.
Automatizarea unor astfel de activități poate face diferența, mai ales pentru IMM-uri. Nu în ultimul rând, cred că următoarele 12–18 luni sunt foarte importante pentru partea de conștientizare și training. Oamenii din organizații – dezvoltatori, echipe tehnice, dar și management – trebuie să înțeleagă ce presupune CRA în mod real. Fără acest nivel de înțelegere, există riscul ca eforturile să rămână doar la nivel formal, fără impact real în securitate.
3. Cum pot fi sprijinite, din perspectiva proiectului CYBERFORT, IMM-urile și organizațiile cu un nivel mai redus de maturitate în securitate pentru a înțelege și aplica practic cerințele CRA?
Din perspectiva proiectului CYBERFORT, sprijinul pentru IMM-uri trebuie să fie cât mai practic și ușor de aplicat. Multe organizații nu au echipe dedicate de securitate sau resurse suficiente pentru a interpreta singure toate cerințele CRA, așa că au nevoie de ghidaj clar, instrumente simple și exemple concrete. Cred că primul pas este traducerea cerințelor CRA într-un limbaj accesibil și în acțiuni concrete: ce trebuie evaluat, ce procese trebuie documentate, cum se gestionează vulnerabilitățile și cum se integrează securitatea în dezvoltarea produselor digitale. Un rol important îl au și instrumentele automatizate, cum sunt cele vizate în
CYBERFORT, care pot ajuta organizațiile să își evalueze nivelul de conformitate, să identifice zonele vulnerabile și să genereze documentația necesară. Pentru IMM-uri, automatizarea poate reduce mult povara administrativă și poate face conformitatea mai realistă. În același timp, este nevoie de training și conștientizare. CRA nu ar trebui înțeles doar de specialiștii tehnici, ci și de management, pentru că implementarea lui presupune decizii organizaționale, prioritizare și asumarea unor procese pe termen lung.
Prin urmare, IMM-urile trebuie sprijinite printr-o combinație de ghiduri clare, instrumente accesibile, exemple practice și formare continuă, astfel încât CRA să nu fie perceput ca o obligație birocratică, ci ca un cadru care le ajută să devină mai sigure și mai reziliente.
4. CRA introduce cerințe clare privind secure-by-design și vulnerability handling. Credeți că industria locală de software este pregătită pentru această schimbare de paradigmă?
Cred că industria locală de software are competențe tehnice foarte bune, dar nivelul de pregătire nu este uniform. Există companii care aplică deja practici mature de secure development, testare de securitate, code review, gestionare a vulnerabilităților și actualizări regulate. În același timp, sunt și organizații pentru care securitatea este încă tratată mai degrabă reactiv, atunci când apare o problemă sau când este cerută într-un audit.
Schimbarea adusă de CRA este că securitatea nu mai poate fi privită ca un element opțional sau ca o etapă de final. Secure-by-design presupune ca riscurile să fie luate în calcul încă din faza de proiectare, iar vulnerability handling presupune procese clare pentru identificare, remediere, documentare și comunicare.
Aș spune că industria este pregătită din punct de vedere al potențialului, dar mai este nevoie de maturizare la nivel de procese. Nu este suficient să ai oameni tehnici foarte buni; trebuie să existe și proceduri, responsabilități clare, instrumente adecvate și o cultură organizațională în care securitatea este parte normală din dezvoltarea unui produs. Din perspectiva CYBERFORT, exact aici vedem una dintre nevoile majore: sprijin practic pentru organizații, mai ales pentru IMM-uri, astfel încât această tranziție să fie realizabilă și nu doar teoretică.
5. În contextul adoptării accelerate a inteligenței artificiale, cum se intersectează CRA cu sistemele care generează sau modifică cod (AI-assisted development)?
Cred că aici discuția este foarte actuală, pentru că AI-assisted development schimbă deja modul în care se scrie software. Din perspectiva CRA, însă, principiul rămâne același: indiferent dacă un cod este scris de un dezvoltator sau generat cu ajutorul unui instrument de inteligență artificială, organizația care îl integrează într-un produs digital rămâne responsabilă pentru securitatea acelui produs. AI poate aduce beneficii reale: poate accelera dezvoltarea, poate ajuta la documentare, la testare sau chiar la identificarea unor vulnerabilități. Dar, în același timp, poate introduce cod nesigur, dependențe nevalidate sau soluții care par corecte la prima vedere, dar care nu au fost analizate suficient din punct de vedere al securității. De aceea, cred că utilizarea AI în dezvoltarea software trebuie tratată ca parte a procesului de secure-by-design.
Codul generat sau modificat cu ajutorul AI trebuie verificat, testat, documentat și inclus în aceleași procese de control ca orice altă componentă software.Vorbind despre CYBERFORT, această temă este relevantă mai ales pentru că organizațiile vor avea nevoie de metode practice prin care să coreleze cerințele CRA cu noile moduri de dezvoltare software. Nu este suficient să folosim AI pentru viteză; trebuie să ne asigurăm că viteza nu vine în detrimentul securității și al trasabilității.
6. Considerați că utilizarea AI pentru generarea de cod introduce riscuri sistemice noi care ar trebui explicit adresate în cadrul CRA sau în ghiduri derivate?
Da, cred că utilizarea AI pentru generarea de cod introduce riscuri noi, iar unele dintre ele pot deveni sistemice dacă nu sunt gestionate corect. Nu vorbim doar despre o vulnerabilitate punctuală într-o aplicație, ci despre posibilitatea ca aceleași tipare nesigure de cod, aceleași dependențe nevalidate sau aceleași erori de logică să fie replicate rapid în foarte multe produse. În opinia mea, CRA oferă deja un cadru important prin accentul pus pe secure-by-design, gestionarea vulnerabilităților și responsabilitatea pe întreg ciclul de viață al produsului. Totuși, pentru zona de AI-assisted development, cred că ar fi utile ghiduri derivate, mai practice, care să explice cum se aplică aceste principii în situații concrete. De exemplu, organizațiile ar trebui să știe cum documentează utilizarea AI în procesul de dezvoltare, cum validează codul generat, cum verifică dependențele propuse de astfel de instrumente și cum mențin trasabilitatea deciziilor tehnice.
Nu aș privi AI ca pe o problemă în sine. Este un instrument foarte valoros, dar trebuie integrat într-un proces controlat. Riscul apare atunci când codul generat este preluat automat, fără analiză, fără testare și fără responsabilitate clară. Din această perspectivă, ghidurile practice ar putea ajuta foarte mult organizațiile să folosească AI într-un mod sigur și responsabil.
7. Cum ar trebui organizațiile să abordeze analiza de securitate a codului generat de AI, în special în lipsa trasabilității tradiționale a autorului?
Cred că primul lucru care trebuie înțeles este că lipsa unui „autor clar” nu reduce responsabilitatea asupra codului. Din contră, obligă organizațiile să fie mai riguroase în procesele de validare. Practic, codul generat de AI ar trebui tratat ca un cod provenit dintr-o sursă externă necunoscută, care necesită verificare completă înainte de a fi integrat. Asta înseamnă, în primul rând, integrarea lui în aceleași procese de securitate existente: code review, testare automată, analiză statică și dinamică, scanare de vulnerabilități și verificarea dependențelor. Nu ar trebui să existe „scurtături” doar pentru că a fost generat mai rapid.
În al doilea rând, cred că este importantă introducerea unui minim de trasabilitate la nivel de proces, chiar dacă nu există la nivel de autor. De exemplu, să existe politici interne privind utilizarea AI (unde este permis, pentru ce tipuri de componente), logarea prompturilor sau a rezultatelor relevante și documentarea deciziilor tehnice atunci când codul generat este acceptat. Un alt aspect important este componenta de training.
8. SBOM-urile devin esențiale în CRA. Cum vedeți evoluția practicilor de Software Bill of Materials în România și ce obstacole anticipați în adoptare?
Cred că SBOM-urile vor deveni, treptat, o practică normală și în România, mai ales pentru organizațiile care dezvoltă produse software sau integrează componente digitale în servicii mai complexe. În prezent, însă, nivelul de maturitate este încă diferit de la o organizație la alta. Sunt companii care au început deja să își documenteze componentele software, dependențele și bibliotecile folosite, dar sunt și multe organizații pentru care SBOM-ul este încă un concept relativ nou. Principalul obstacol cred că va fi lipsa de vizibilitate asupra propriului lanț software. Multe companii folosesc biblioteci open-source, framework-uri, componente terțe sau cod reutilizat, dar nu au întotdeauna o evidență clară și actualizată a acestora. Fără această vizibilitate, este greu să gestionezi eficient vulnerabilitățile. Un alt obstacol este percepția că SBOM-ul este doar o documentație în plus. În realitate, el ar trebui privit ca un instrument de securitate și de management al riscului. Dacă știi exact ce componente ai într-un produs, poți reacționa mult mai rapid atunci când apare o vulnerabilitate într-o bibliotecă sau într-o dependență utilizată. Din perspectiva CYBERFORT, cred că zona de automatizare va fi foarte importantă. Pentru IMM-uri, în special, adoptarea SBOM-urilor trebuie să fie cât mai simplă și integrată în procesele existente de dezvoltare, nu un efort manual greu de susținut. Pe termen mediu, mă aștept ca SBOM-ul să devină o cerință firească în relațiile dintre furnizori, clienți și parteneri, mai ales în sectoarele unde reziliența cibernetică este critică.
9. Din perspectiva dumneavoastră, care sunt cele mai importante lecții învățate la nivel european până acum în implementarea CRA și cum pot fi aplicate concret în România?
Cred că una dintre lecțiile importante este că implementarea CRA nu poate fi tratată izolat, doar ca un exercițiu juridic sau tehnic. Este nevoie de o colaborare reală între autorități, industrie, dezvoltatori, furnizori de tehnologie, IMM-uri și comunitatea de securitate. Pe de altă parte, organizațiile au nevoie de claritate și de exemple practice. Un regulament poate stabili direcția, dar aplicarea lui în viața de zi cu zi presupune ghiduri, instrumente, modele de documentație, training și mecanisme de evaluare. Fără acestea, mai ales pentru IMM-uri, conformitatea poate părea greu de atins. Pentru România, cred că aplicarea concretă înseamnă să traducem cerințele CRA în pași simpli și utilizați practic: evaluarea produselor și proceselor existente, integrarea securității în dezvoltare, gestionarea vulnerabilităților, documentarea componentelor software și creșterea nivelului de conștientizare în organizații. În interiorul CYBERFORT, aceasta este exact direcția pe care încercăm sa o oferim: sprijin practic pentru organizații, în special pentru IMM-uri, prin instrumente accesibile, resurse educaționale și o abordare care să transforme CRA dintr-o obligație percepută ca dificilă într-un cadru util pentru creșterea rezilienței cibernetice.
10. Dacă ar fi să transmiteți un singur mesaj liderilor tehnici și de securitate din România privind CRA și reziliența cibernetică, care ar fi acesta?
Dacă ar fi să sintetizez într-un singur mesaj, ar fi acesta: nu tratați CRA ca pe o obligație de bifat sau ca pe un lucru care să împovăreze, ci ca pe o oportunitate de a construi produse mai sigure și organizații mai reziliente. În practică, diferența se face în modul în care integrați securitatea în procesele de zi cu zi – în dezvoltare, în testare, în gestionarea vulnerabilităților și în relația cu partenerii. Nu este vorba doar despre conformitate, ci despre încredere: încrederea utilizatorilor, a clienților și a partenerilor în produsele și serviciile pe care le livrați. Cred că organizațiile care vor aborda CRA în mod pragmatic, investind în procese, oameni și instrumente, nu doar că vor respecta cerințele, dar vor avea și un avantaj competitiv real pe termen mediu și lung. Este vorba despre a fi mai competitiv.
Sursă foto: https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation