Timp de mulți ani, securitatea cibernetică a software-ului a fost considerată în principal o sarcină tehnică. Echipa de dezvoltare trebuia să se ocupe de securitatea codului, administratorii de configurarea infrastructurii, iar după implementare trebuia să se reacționeze la problemele semnalate și să se publice remedieri. În multe organizații, acest model este încă în vigoare.
Regulamentul european Cyber Resilience Act, prescurtat CRA, consolidează o abordare diferită: securitatea unui produs digital ar trebui luată în considerare încă de la începutul proiectării și menținută pe toată durata perioadei de asistență. Nu este vorba doar despre securizarea sistemului în ziua lansării, ci și despre gestionarea vulnerabilităților, actualizări, documentație, răspunderea producătorului și capacitatea de a reacționa la incidente.
Pentru companiile care creează software, dezvoltă propriile produse digitale sau le introduc pe piața europeană, acest lucru înseamnă că trebuie să analizeze nu doar codul, ci și procesele de afaceri și organizaționale.
Important este că CRA nu mai este doar o reglementare pentru care pregătirile pot începe cândva în viitorul îndepărtat. Regulamentul a intrat în vigoare la 10 decembrie 2024. Obligațiile privind raportarea anumitor vulnerabilități și a incidentelor grave au început să se aplice la 11 septembrie 2026, în timp ce partea principală a cerințelor va deveni aplicabilă la 11 decembrie 2027. Acestea sunt două etape diferite, care nu trebuie confundate.
Ce este Cyber Resilience Act?
Cyber Resilience Act este un regulament european privind securitatea cibernetică a produselor care conțin elemente digitale. Scopul său este de a spori nivelul de securitate al acestor produse disponibile pe piața Uniunii Europene și de a limita situațiile în care utilizatorii primesc soluții vulnerabile la atacuri, protejate necorespunzător sau lipsite de asistența adecvată.
Reglementarea acoperă o categorie largă de produse hardware și software a căror utilizare prevăzută sau utilizare previzibilă în mod rezonabil implică o conexiune logică sau fizică, directă sau indirectă, la un dispozitiv ori la o rețea. Domeniul de aplicare poate include atât produse finite, cât și componente digitale introduse separat pe piață.
În practică, aceasta înseamnă că CRA nu se referă exclusiv la dispozitivele asociate cu Internetul obiectelor. În anumite circumstanțe, reglementarea poate include și software, sisteme de operare, aplicații sau alte componente digitale oferite pe piață.
Este însă importantă distincția dintre simpla creare de software și introducerea unui produs pe piață. Nu orice serviciu de dezvoltare software, site web sau sistem creat la comandă este automat supus acelorași obligații. Printre factorii relevanți se numără natura soluției, modul în care este pusă la dispoziție, rolul diferitelor companii și eventualele excluderi prevăzute de reglementări.
Prin urmare, primul pas nu ar trebui să fie implementarea fără discernământ a tuturor procedurilor posibile. Mai întâi trebuie stabilit dacă produsul respectiv intră în domeniul de aplicare al CRA și ce rol revine organizației în cauză.
De ce schimbă CRA abordarea privind dezvoltarea software-ului?
Cea mai importantă schimbare constă în faptul că securitatea cibernetică nu mai este doar un set de activități desfășurate cu ocazia implementării sau după identificarea unei probleme. Ea devine o componentă a întregului ciclu de viață al produsului.
În acest model, securitatea ar trebui luată în considerare în timpul analizei cerințelor, proiectării arhitecturii, implementării, testării, pregătirii lansării, mentenanței și planificării încetării asistenței. Nu este suficient să se constate că aplicația funcționează corect. Trebuie, de asemenea, să se înțeleagă riscurile asociate funcțiilor, dependențelor, modului de actualizare și integrărilor acesteia.
De exemplu, o echipă își poate securiza corect propriul cod, folosind în același timp o bibliotecă în care a fost descoperită o vulnerabilitate. Produsul poate avea un mecanism de autentificare, dar să gestioneze incorect permisiunile. Actualizările pot fi disponibile, dar fără o procedură de distribuire clar definită. De asemenea, este posibil ca firma să nu știe ce versiuni ale produsului sunt încă utilizate de clienți.
Fiecare dintre aceste cazuri arată că securitatea nu depinde doar de competențele programatorilor. Ea necesită și controlul dependențelor, un proces de răspuns la sesizări, documentație și asumarea responsabilității pentru produs după punerea acestuia la dispoziție.
Prin urmare, CRA consolidează direcția în care ar trebui să evolueze un proces matur de dezvoltare software, independent de reglementarea în sine: securitatea trebuie proiectată, verificată și menținută, nu doar declarată.
Cui i se aplică dispozițiile și de ce trebuie stabilit rolul companiei?
CRA impune obligațiile principale mai ales producătorilor de produse cu elemente digitale. În sensul regulamentului, producător este entitatea care dezvoltă un produs sau comandă dezvoltarea acestuia și apoi îl pune la dispoziție pe piață sub propriul nume sau propria marcă comercială.
Această distincție este importantă pentru companiile de dezvoltare software și cele de tehnologie.
Dacă o companie creează un sistem la comanda unui client, acest lucru nu înseamnă automat că va fi producător în sensul CRA în toate cazurile. Contează modelul concret de colaborare, modul în care produsul este pus la dispoziție și cine este entitatea responsabilă pentru acesta pe piață. De asemenea, nu se poate presupune din start că responsabilitatea revine întotdeauna exclusiv clientului. În anumite modele de afaceri, situația poate fi diferită.
Merită analizate câteva scenarii tipice:
-
O companie care dezvoltă propriul produs SaaS sau propria aplicație sub propria marcă. Trebuie verificat dacă produsul intră în domeniul de aplicare al CRA și dacă modul în care este pus la dispoziție și arhitectura sa fac ca reglementarea să i se aplice.
-
O companie de dezvoltare software care creează un sistem pentru un client. Trebuie stabilit cine va pune soluția la dispoziție pe piață, sub ce marcă și în ce calitate acționează părțile. Simplul fapt că a scris codul nu lămurește toate aspectele juridice.
-
Un producător care integrează componente de la alți furnizori. Poate fi necesară analizarea nu doar a propriei soluții, ci și a dependențelor, a modului în care sunt actualizate și a informațiilor de securitate furnizate de furnizori.
-
O companie care vinde sub propria marcă un produs dezvoltat de o altă entitate. Acest model poate avea consecințe diferite față de simpla furnizare a unui serviciu de dezvoltare software și necesită o evaluare separată.
-
Un furnizor de componente software. Dacă o componentă este pusă separat la dispoziție pe piață, poate fi necesară o analiză proprie a domeniului de aplicare al reglementării.
Aceasta nu este o listă exhaustivă de cazuri și nici o calificare juridică formală. Scopul este să arate de ce merită să se înceapă prin cartografierea produselor și a rolurilor, nu prin afirmația generală că „CRA se aplică tuturor programatorilor”.
Regulamentul prevede, de asemenea, excepții și norme speciale, printre altele pentru anumite categorii de produse reglementate prin acte normative separate și pentru anumite cazuri de software open source. Totuși, detaliile acestor excepții nu trebuie interpretate doar pe baza denumirii produsului sau a modelului de licențiere. Este necesară analizarea situației concrete.
Termenele CRA: ce se aplică deja și ce va intra în vigoare în 2027?
Datele sunt esențiale în planificarea conformității cu regulamentul. Este util să distingem între intrarea în vigoare a regulamentului, începerea aplicării obligațiilor de raportare și începerea aplicării cerințelor principale.
10 decembrie 2024 – intrarea în vigoare a CRA. Regulamentul a fost adoptat și a intrat în vigoare, însă acest lucru nu a însemnat că toate obligațiile au început să se aplice simultan.
11 septembrie 2026 – începerea aplicării obligațiilor de raportare prevăzute la articolul 14. Producătorii produselor vizate de regulament trebuie să raporteze vulnerabilitățile exploatate în mod activ și incidentele grave care afectează securitatea produsului, atunci când află despre un astfel de eveniment. Aceste obligații au termene și o procedură de raportare proprii.
11 decembrie 2027 – începerea aplicării principalei părți a CRA. De la această dată se vor aplica cerințele principale ale regulamentului privind produsele cu elemente digitale, inclusiv cerințele legate de securitatea produsului, gestionarea vulnerabilităților și procedurile de evaluare a conformității, în conformitate cu dispozițiile aplicabile.
Un detaliu important: obligațiile de raportare care au început să se aplice în septembrie 2026 vizează și produsele care intră sub incidența CRA și care au fost puse la dispoziție pe piață înainte de 11 decembrie 2027. Prin urmare, nu trebuie să presupuneți că toate obligațiile legate de regulament încep abia în decembrie 2027.
Există și dispoziții tranzitorii, iar situația produselor deja disponibile pe piață poate depinde de circumstanțe concrete, printre altele de faptul dacă produsul va suferi o modificare substanțială după începerea aplicării principalei părți a regulamentului. Din acest motiv, datele trebuie considerate un punct de plecare pentru analiză, nu un răspuns de sine stătător la întrebarea privind obligațiile unei anumite companii.
Principalele surse de informații sunt rezumatul oficial al Comisiei Europene și pagina sa dedicată raportării în cadrul CRA.
Raportarea vulnerabilităților și a incidentelor: o obligație a cărei aplicare a început deja
Unul dintre cele mai practice aspecte ale CRA este obligația de a raporta anumite evenimente legate de securitatea produselor.
Nu este vorba despre raportarea fiecărei defecțiuni minore, fiecărei erori de aplicație sau fiecărei vulnerabilități potențiale menționate de cineva într-un comentariu neverificat. Dispozițiile indică anumite categorii de evenimente, inclusiv vulnerabilitățile exploatate în mod activ și incidentele grave care afectează securitatea produsului.
Pe scurt, o vulnerabilitate exploatată în mod activ este o vulnerabilitate pentru care există dovezi credibile că a fost exploatată fără autorizare de către un atacator. Un incident grav este un eveniment care afectează în mod semnificativ securitatea produsului. Pentru a stabili dacă un anumit eveniment îndeplinește criteriile legale, trebuie luate în considerare circumstanțele și definițiile relevante, nu doar evaluarea intuitivă a echipei.
Pentru producătorii vizați de obligația de raportare, termenele principale includ:
-
24 de ore pentru o alertă inițială de la momentul în care află despre un eveniment care face obiectul obligației;
-
72 de ore pentru raportarea principală;
-
în cazul unei vulnerabilități exploatate în mod activ, raportul final trebuie transmis în cel mult 14 zile de la punerea la dispoziție a unei măsuri de remediere sau de atenuare;
-
în cazul unui incident grav, raportul final trebuie transmis în termen de o lună de la raportarea în 72 de ore.
Termenele și cerințele trebuie interpretate în conformitate cu dispozițiile relevante și cu orientările actuale. Rezumatul de mai sus nu trebuie considerat un ghid juridic complet aplicabil tuturor cazurilor.
Raportările se transmit prin platforma UE CRA Single Reporting Platform, administrată de ENISA. Conform regulilor sistemului, producătorul transmite raportarea prin această platformă, iar CSIRT-ul competent și ENISA participă la etapele ulterioare ale procesului.
Ce înseamnă acest lucru din punct de vedere operațional? Compania nu ar trebui să aștepte până la detectarea unei probleme pentru a se întreba cine îi va evalua gravitatea, cine va decide dacă trebuie raportată și de unde vor fi obținute informațiile necesare întocmirii raportului.
Este util să stabiliți din timp un proces care să includă cel puțin:
-
primirea raportărilor din partea clienților, a cercetătorilor în domeniul securității și a altor surse;
-
verificarea faptului că raportarea privește o vulnerabilitate sau un incident real;
-
evaluarea impactului asupra produsului și stabilirea dacă evenimentul ar putea face obiectul obligației de raportare;
-
desemnarea persoanelor responsabile de deciziile tehnice, organizaționale și formale;
-
pregătirea informațiilor necesare și gestionarea termenelor;
-
elaborarea unei remedieri sau a altor măsuri de reducere a riscului;
-
informarea destinatarilor relevanți în conformitate cu obligațiile aplicabile;
-
documentarea acțiunilor și desprinderea concluziilor după încheierea incidentului.
Nu este necesar ca fiecare companie să creeze în acest scop un departament de securitate extins. Amploarea procesului trebuie să corespundă caracteristicilor produsului, riscului și structurii organizației. Totuși, procesul trebuie să fie suficient de concret încât, într-o situație de criză, compania să poată acționa rapid, nu să fie nevoită să stabilească abia atunci principiile de bază privind responsabilitățile.
Security by design și security by default
Două concepte descriu deosebit de bine direcția în care se îndreaptă CRA: security by design și security by default.
Security by design înseamnă luarea în considerare a securității încă din etapa de proiectare a produsului. Security by default presupune, în schimb, că setările implicite ar trebui să favorizeze utilizarea în siguranță a soluției, în loc să oblige utilizatorul să remedieze singur setările nesigure.
În practică, acest lucru nu se reduce la o singură funcție sau la o listă de controale în panoul de administrare. Este vorba despre un set de decizii arhitecturale și de implementare care influențează securitatea întregului produs.
În funcție de caracteristicile soluției, merită analizate, printre altele:
-
metoda de autentificare și gestionarea sesiunilor;
-
modelul de autorizare și controlul accesului la date;
-
stocarea în siguranță a secretelor și a datelor de autentificare;
-
protejarea datelor în timpul transmiterii și al stocării;
-
mecanismele de actualizare și securitatea acestora;
-
modul de gestionare a erorilor și de înregistrare a evenimentelor;
-
reducerea suprafeței de atac și dezactivarea funcțiilor inutile;
-
configurația implicită, inclusiv absența setărilor inițiale nesigure;
-
gestionarea vulnerabilităților din componente proprii și externe.
Nu toate măsurile vor fi necesare în aceeași formă pentru fiecare produs. O aplicație mobilă necesită soluții diferite față de un sistem încorporat, iar o platformă complexă pentru afaceri necesită alte soluții. De aceea, analiza riscurilor ar trebui să preceadă alegerea mecanismelor concrete.
De asemenea, este important de reținut că securitatea nu se limitează la cod. Configurarea greșită a mediului, permisiunile excesive, accesul necontrolat la repository sau un proces de publicare a actualizărilor insuficient gândit pot compromite calitatea chiar și a unei soluții bine proiectate.
Analiza riscurilor și documentația tehnică
CRA prevede o abordare bazată pe evaluarea riscurilor de securitate cibernetică ale produsului. Această analiză ar trebui să influențeze deciziile privind proiectarea, dezvoltarea, producția, livrarea și întreținerea soluției.
Merită să începeți cu câteva întrebări de bază:
-
Ce date prelucrează produsul și ce consecințe ar avea divulgarea, modificarea sau pierderea disponibilității acestora?
-
Cu ce dispozitive, rețele și servicii externe comunică sistemul?
-
Ce permisiuni are aplicația și cine le poate folosi?
-
Care sunt cele mai importante dependențe tehnologice?
-
Ce se va întâmpla dacă una dintre dependențe se dovedește vulnerabilă?
-
Cum poate producătorul să livreze o remediere și să verifice dacă aceasta a fost implementată?
-
Ce riscuri rămân după aplicarea măsurilor de securitate?
Răspunsurile nu ar trebui să existe doar în mintea programatorilor. În funcție de produs și de obligațiile producătorului, va fi importantă documentația tehnică, care să arate, printre altele, ce soluție a fost introdusă pe piață, ce riscuri au fost identificate și cum sunt îndeplinite cerințele relevante.
O documentație bună nu este doar un material pregătit pentru audit. Ea ajută, de asemenea, la dezvoltarea sistemului, la transferul responsabilităților între echipe, la reconstituirea deciziilor arhitecturale și la reacția la problemele apărute după implementare.
Asta nu înseamnă că fiecare companie ar trebui să pregătească imediat un document uriaș care să descrie toate scenariile posibile. Amploarea documentației ar trebui să decurgă din tipul produsului și din cerințele aplicabile. Esențial este ca documentele să fie actualizate, să corespundă soluției reale și să poată fi folosite în activitatea curentă.
Dependențe și componente externe: securitatea întregului lanț de aprovizionare
Software-ul modern este rareori creat în întregime de la zero. Acesta folosește biblioteci, framework-uri, componente gata făcute, motoare de baze de date, sisteme de operare și servicii externe. Acest lucru accelerează dezvoltarea, dar înseamnă și că securitatea produsului depinde parțial de elemente asupra cărora producătorul nu deține control deplin.
Dacă se descoperă o vulnerabilitate într-o bibliotecă populară, problema poate afecta numeroase produse independente. Faptul că biblioteca provine dintr-un proiect consacrat nu garantează că va rămâne sigură pe toată durata utilizării sale.
De aceea, merită să cunoașteți componența tehnologică a produsului și să puteți stabili ce componente au fost utilizate, în ce versiuni și în ce părți ale sistemului. Printre măsurile utile se numără controlul dependențelor, scanarea vulnerabilităților, înregistrarea modificărilor și procedurile de actualizare.
În procesele mai mature se utilizează și inventare ale componentelor software, cunoscute sub denumirea SBOM (Software Bill of Materials). Un astfel de inventar poate facilita identificarea bibliotecilor și a altor elemente afectate de o vulnerabilitate nou descoperită. Totuși, nu trebuie să presupuneți că un SBOM asigură automat conformitatea cu CRA. Este un instrument care sprijină gestionarea componentelor, nu un substitut pentru întregul proces de securitate și pentru documentația necesară în cazul unui anumit produs.
Relația cu furnizorii este, de asemenea, importantă. Compania ar trebui să știe cum primește informații despre vulnerabilități, cine răspunde de actualizarea componentelor utilizate și cât de repede poate reacționa la o problemă critică.
Acest lucru este deosebit de important în sistemele de business cu durată lungă de viață, în care înlocuirea unei singure biblioteci poate afecta integrările, compatibilitatea sau stabilitatea întregii soluții.
Actualizările și perioada de asistență pentru produs
Una dintre cele mai importante chestiuni este întreținerea produsului după punerea sa la dispoziție pe piață. În cazul produselor care intră sub incidența CRA, producătorul trebuie să stabilească perioada de asistență și să asigure gestionarea corespunzătoare a vulnerabilităților pe durata acesteia, în conformitate cu cerințele regulamentului.
Aceasta înseamnă că securitatea trebuie planificată nu doar pentru momentul lansării produsului, ci și pentru lunile și anii următori de utilizare.
În practică, merită să stabiliți:
-
cine monitorizează informațiile despre vulnerabilitățile noi;
-
cum este evaluat impactul acestora asupra produsului;
-
cine decide pregătirea unei remedieri;
-
cum sunt testate și publicate actualizările;
-
cum sunt informați utilizatorii sau clienții;
-
cât timp va beneficia produsul de asistență;
-
cum este comunicat sfârșitul perioadei de asistență.
Este importantă și predictibilitatea. Utilizatorul ar trebui să primească informații clare despre securitatea și asistența produsului. Simpla afirmație că producătorul „va pregăti o actualizare dacă va fi necesar” nu înlocuiește un proces care să permită gestionarea efectivă a unei vulnerabilități descoperite.
Nu toate actualizările trebuie să urmeze același proces. Totuși, echipa ar trebui să poată distinge modificările funcționale obișnuite de remedierile de securitate și să evalueze când riscul impune o intervenție accelerată.
Din perspectivă comercială, merită să rețineți și că întreținerea software-ului implică costuri. Dacă modelul de vânzare nu include perioada de asistență, monitorizarea dependențelor, gestionarea vulnerabilităților și livrarea remedierilor, compania poate promite clienților mai mult decât poate asigura în mod responsabil.
Prin urmare, CRA nu este doar o chestiune pentru echipa tehnică. Poate influența oferta, contractele, stabilirea prețului produsului, planificarea dezvoltării și modul de comunicare a condițiilor de asistență.
Testarea securității și procesul de lansare a versiunilor noi
Securitatea unui produs nu poate fi confirmată în mod credibil printr-un singur test efectuat chiar înainte de lansare. Este nevoie de un proces care să ajute la detectarea problemelor pe măsură ce software-ul se dezvoltă.
În funcție de tipul produsului și de nivelul de risc, acesta poate include revizuiri de cod, analiză statică, testarea dependențelor, scanarea configurațiilor, teste dinamice și teste de penetrare. Instrumentele automate sunt utile, dar rezultatele lor trebuie interpretate. Nu fiecare alertă indică o amenințare reală, iar absența alertelor nu dovedește că sistemul este sigur.
De asemenea, merită să integrați activitățile de securitate în procesul CI/CD, adică în automatizarea construirii, testării și implementării software-ului. Astfel, anumite verificări pot fi efectuate regulat, nu doar atunci când cineva își amintește să le pornească.
Nu este vorba despre blocarea fiecărei modificări cu zeci de verificări nesincronizate. Este vorba despre alegerea testelor în funcție de risc și despre stabilirea unor reguli clare pentru situațiile în care o verificare detectează o problemă. Echipa ar trebui să știe care erori împiedică lansarea unei versiuni, care necesită o analiză suplimentară și cine poate accepta riscul rămas.
Procesul de lansare a versiunilor ar trebui, de asemenea, să permită identificarea unei anumite versiuni a produsului, reconstituirea modificărilor relevante și asocierea remedierii cu problema pe care aceasta trebuie să o rezolve. Acest lucru facilitează analiza incidentelor și ajută la demonstrarea măsurilor întreprinse.
În cazul CRA, setul detaliat de măsuri necesare depinde de produs și de procedura de evaluare a conformității aplicabilă. Prin urmare, este util să privim testarea și automatizarea ca elemente care sprijină îndeplinirea cerințelor, nu ca pe un certificat de conformitate de sine stătător.
CRA se aplică și întreprinderilor mici și companiilor de dezvoltare software?
Dimensiunea organizației nu ar trebui să fie singurul criteriu pentru a evalua dacă merită analizat subiectul. Esențial este ce produs creează sau pune la dispoziție compania, ce rol are și ce obligații decurg din legislație.
Întreprinderile mici pot avea mai puține resurse decât producătorii mari, dar dezvoltă și ele produse digitale, integrează componente și întrețin sisteme utilizate de clienți. Tocmai de aceea, merită să înceapă cu măsuri proporționale cu amploarea activității, în loc să presupună că pregătirea pentru CRA trebuie să însemne un program costisitor de conformitate încă din prima zi.
Pentru o companie mai mică, un început rezonabil poate fi întocmirea unei liste de produse, stabilirea rolurilor juridice, identificarea celor mai importante dependențe, descrierea procesului de gestionare a vulnerabilităților și desemnarea persoanelor responsabile de securitate. Abia apoi se poate stabili ce controale, documente sau consultanță suplimentare sunt cu adevărat necesare.
Nu trebuie presupus că orice entitate mai mică este scutită de obligații. CRA prevede norme speciale și soluții proporționale în anumite cazuri, dar acestea nu pot fi reduse la o regulă generală potrivit căreia o companie mică nu trebuie să se pregătească.
De asemenea, este util să se facă distincția între obligațiile producătorului și așteptările clienților acestuia. Chiar dacă o anumită companie de dezvoltare software nu este producătorul unui anumit produs în sensul CRA, clientul poate solicita informații despre componentele utilizate, modul de gestionare a vulnerabilităților, actualizări sau documentația tehnică. Acordurile clare reduc riscul ca, după implementare, fiecare parte să presupună că altcineva este responsabil de securitate.
Cum să vă pregătiți compania pentru CRA? Listă practică de măsuri
Cel mai bun punct de plecare este un plan bazat pe produsele, procesele și responsabilitățile reale. Pașii de mai jos nu constituie o listă completă a cerințelor legale pentru fiecare caz, dar ajută la organizarea pregătirilor.
1. Întocmiți un inventar al produselor digitale. Identificați soluțiile oferite pe piață, destinația lor, modul de distribuție și componentele esențiale. Nu vă limitați la produsele pe care compania le dezvoltă activ. Includeți și versiunile întreținute și puse la dispoziția clienților.
2. Stabiliți rolul companiei pentru fiecare produs. Verificați cine dezvoltă soluția, cine comandă dezvoltarea acesteia, sub marca cui este pusă la dispoziție și cine răspunde de produs pe piață. În cazul unui model de colaborare neobișnuit, nu vă bazați decizia exclusiv pe denumirea uzuală a serviciului.
3. Verificați domeniul de aplicare al reglementării și eventualele excluderi. Pentru fiecare produs, evaluați dacă intră în domeniul de aplicare al CRA, ce norme se pot aplica și dacă există circumstanțe care necesită o interpretare specială. Dacă aveți îndoieli, consultați orientările actuale ale Comisiei Europene și apelați la consultanță juridică adecvată.
4. Efectuați o evaluare a riscurilor. Identificați principalele amenințări, datele, integrările, dependențele și consecințele unui eventual incident. Pe această bază, stabiliți ce măsuri de securitate și controale sunt adecvate produsului.
5. Descrieți procesul de gestionare a vulnerabilităților. Stabiliți unde sunt primite raportările, cum sunt verificate, cine le evaluează gravitatea, cum sunt create corecțiile și cum sunt documentate deciziile. Procesul trebuie să funcționeze și atunci când problema apare în afara programului obișnuit de lucru.
6. Pregătiți o procedură de raportare. Deoarece obligațiile de raportare prevăzute la articolul 14 se aplică deja, entitatea vizată de aceste obligații trebuie să cunoască criteriile de raportare, termenele aplicabile și modul de utilizare a platformei CRA Single Reporting Platform. Procedura internă trebuie să permită colectarea informațiilor fără întârzieri nejustificate.
7. Analizați dependențele tehnologice. Verificați bibliotecile, frameworkurile și alte componente utilizate de produs. Gândiți-vă dacă firma poate stabili rapid care versiuni ale software-ului său sunt vulnerabile la o vulnerabilitate nou descoperită.
8. Verificați actualizările și perioada de asistență. Stabiliți modul în care sunt pregătite, testate și publicate corecțiile de securitate și cum sunt comunicate condițiile de asistență. Evaluați dacă modelul actual de întreținere corespunde angajamentelor față de clienți și cerințelor aplicabile produsului respectiv.
9. Verificați documentația. Adunați informațiile tehnice și despre procese necesare pentru gestionarea securității și demonstrarea îndeplinirii cerințelor aplicabile. Documentația trebuie să reflecte produsul real, nu doar planul de funcționare a acestuia.
10. Stabiliți responsabilitățile în echipă și în contracte. Precizați cine răspunde de securitatea produsului, cine ia deciziile în timpul unui incident și cum colaborează producătorul, compania de dezvoltare software, furnizorii de componente și clientul. Asigurați-vă că domeniul asistenței și al actualizărilor este definit clar.
11. Verificați pregătirea în practică. Simulați scenariul descoperirii unei vulnerabilități grave. Verificați dacă echipa poate stabili amploarea problemei, identifica versiunile vulnerabile, lua decizii și pregăti o corecție. Simplul fapt că există o procedură într-un document nu garantează că aceasta va funcționa într-un incident real.
12. Monitorizați orientările actuale. Detaliile privind punerea în aplicare a CRA sunt dezvoltate în materialele Comisiei Europene, iar regulamentul include mecanisme și cerințe care trebuie interpretate în contextul produsului concret. Este recomandat să verificați periodic publicațiile oficiale și să actualizați planul de pregătire.
Cele mai frecvente greșeli în pregătiri
Prima greșeală este amânarea subiectului până la sfârșitul anului 2027. Aceasta ignoră faptul că obligațiile de raportare a anumitor evenimente au intrat deja în vigoare, iar pregătirea proceselor de securitate poate necesita schimbări organizaționale, tehnice și contractuale.
A doua greșeală este presupunerea că CRA se aplică exclusiv producătorilor de hardware. Regulamentul include și categorii relevante de software și componente digitale, deși domeniul de aplicare trebuie evaluat în raport cu produsul concret.
A treia greșeală este să se considere că este suficientă achiziționarea unui instrument de scanare a vulnerabilităților. Un instrument poate ajuta la detectarea problemelor, dar nu înlocuiește evaluarea riscurilor, responsabilitatea pentru decizii, procesul de actualizare, gestionarea raportărilor sau documentația necesară.
A patra greșeală este tratarea conformității ca pe un proiect punctual. Produsul se schimbă în timp, apar vulnerabilități noi, componentele sunt actualizate, iar modul de utilizare a soluției poate evolua. Procesul de securitate trebuie să țină cont de această dinamică.
A cincea greșeală este repartizarea neclară a responsabilităților între producător, executant și client. În contracte și în practica echipei trebuie să fie clar cine monitorizează vulnerabilitățile, pregătește corecțiile, comunică problemele și ia deciziile.
A șasea greșeală este crearea unei documentații care nu corespunde stării reale a produsului. Un document care descrie o arhitectură de acum câțiva ani, o listă neactualizată a componentelor sau o procedură pe care nimeni nu o cunoaște nu oferă o bază solidă pentru gestionarea incidentelor.
CRA ca impuls pentru organizarea procesului de dezvoltare software
Noile cerințe de reglementare pot fi percepute ca o obligație suplimentară, însă pregătirea pentru CRA oferă și ocazia de a verifica modul în care compania gestionează securitatea propriilor produse.
Se știe din ce componente este alcătuit sistemul? Poate echipa să stabilească rapid ce versiuni necesită corecții? Actualizările de securitate au un proces clar definit? Clientul știe cât timp va fi susținut produsul? În cazul unui incident, se știe cine ia deciziile și ce măsuri trebuie luate?
Dacă răspunsurile la aceste întrebări nu sunt clare, problema nu începe cu reglementarea. CRA doar sporește importanța unor domenii care influențau deja securitatea, mentenabilitatea și credibilitatea produsului.
Dezvoltarea software matură nu înseamnă promisiunea că erorile nu vor apărea niciodată. Înseamnă reducerea riscurilor, detectarea rapidă a problemelor, un răspuns responsabil și menținerea produsului într-o stare adecvată scopului său și obligațiilor producătorului.
Ce merită făcut acum?
Pentru început, nu este nevoie să implementați dintr-odată toate procedurile posibile. Merită să întocmiți o listă a produselor, să stabiliți rolurile organizației, să verificați domeniul de aplicare al CRA și să vedeți dacă procesele de bază pentru gestionarea vulnerabilităților și incidentelor funcționează. Acest lucru este deosebit de urgent pentru entitățile care se supun deja obligațiilor de raportare.
Următoarea etapă este analiza riscurilor, a dependențelor, a actualizărilor, a perioadelor de asistență și a documentației. Abia pe această bază pot fi planificate schimbări concrete, tehnologice și organizaționale, precum și evaluată necesitatea unei consultanțe juridice suplimentare sau a unei evaluări specializate a conformității.
Cyber Resilience Act nu ar trebui redus la un singur termen din calendar. Este un regulament care consolidează abordarea securității cibernetice pe întregul ciclu de viață al unui produs digital. Cu cât compania înțelege mai devreme cărui produs și cărui rol li se aplică situația sa, cu atât va fi mai ușor să pregătească un plan de acțiune proporțional și practic.
Important: articolul are caracter informativ și nu constituie consultanță juridică sau o evaluare formală a conformității. Domeniul obligațiilor trebuie stabilit pe baza textului integral al regulamentului, a orientărilor actuale și a situației produsului concret.
Surse și lecturi suplimentare
-
Comisia Europeană: Cyber Resilience Act - sinteza prevederilor
-
Comisia Europeană: Cyber Resilience Act - obligațiile producătorilor
-
Comisia Europeană: Cyber Resilience Act - obligațiile de raportare
-
ENISA: Întrebări frecvente despre platforma de raportare CRA
