Regulamentul privind reziliența cibernetică: integrați obligațiile în dezvoltarea produselor

Regulamentul privind reziliența cibernetică (CRA) aduce obligații de securitate cibernetică în ciclul de viață al produselor cu elemente digitale care intră sub incidența sa. Pentru un CTO, sarcina practică este de a lega ceea ce echipa de inginerie construiește, livrează și întreține de dovezile necesare pentru a demonstra respectarea acestor obligații.

Această legătură trebuie să funcționeze la nivel de produs și de versiune. O politică de securitate la nivelul întregii companii nu explică dacă o anumită versiune are setări implicite sigure, ce dependențe conține sau cum vor primi clienții o actualizare de securitate. Un tichet de vulnerabilitate marcat „rezolvat” nu stabilește care dintre versiunile suportate rămân expuse.

Punctul de plecare util este, așadar, un model al ciclului de viață al produsului: perimetru, cerințe de securitate, dovezi privind versiunile lansate, gestionarea vulnerabilităților, angajamente de suport și decizii asumate. Integrați acest model în dezvoltare, în loc să îl asamblați separat înaintea unei evaluări.

Definiți limitele produsului înainte de a atribui controale

CRA se referă la produsele cu elemente digitale care intră în domeniul său de aplicare, inclusiv hardware-ul și software-ul vizate. Nu este o regulă universală pentru orice serviciu SaaS. Un serviciu găzduit și un software distribuit clienților pot necesita analize diferite, iar prelucrarea la distanță care face parte integrantă dintr-un produs trebuie, de asemenea, examinată.

Folosiți ghidul Comisiei Europene privind CRA ca referință de pornire, apoi clarificați întrebările juridice specifice produsului. Înregistrați concluzia, în loc să vă bazați pe o presupunere informală a echipei.

Pentru fiecare produs candidat, stabiliți:

• Ce primesc clienții: hardware, software instalat, componente descărcabile sau o combinație a acestora.
• Ce funcții de prelucrare la distanță sunt necesare pentru ca produsul să își îndeplinească funcțiile.
• Cum este furnizat produsul pe piața UE și ce entitate îl furnizează.
• Rolul dumneavoastră de operator economic: producător, importator, distribuitor sau alt rol relevant.
• Excluderile aplicabile, legislația specifică produsului și aspectele legate de open source.
• Categoria produsului și cerințele de evaluare a conformității care rezultă.

Open source-ul necesită o atenție deosebită. Tratamentul aplicat software-ului furnizat în afara unei activități comerciale nu înseamnă că un producător comercial poate ignora componentele open source încorporate în produsul său. Distingeți poziția contribuitorului din amonte de responsabilitatea dumneavoastră pentru produsul pe care îl furnizați.

Livrabilul de inginerie ar trebui să fie o scurtă înregistrare a perimetrului, cu o diagramă de arhitectură, identificatorii produsului, entitățile comerciale relevante, ipotezele și o concluzie aprobată. Numiți persoana responsabilă de redeschiderea acestei concluzii atunci când funcționalitatea sau modul de distribuție se schimbă.

De exemplu, o aplicație de management descărcabilă și serviciul de analiză găzduit asociat nu ar trebui să primească automat o singură decizie de perimetru nediferențiată. Identificați ce funcții rulează local, care depind de serviciu și dacă acea prelucrare la distanță se încadrează în limitele produsului. Această distincție influențează evaluarea riscurilor, evidențele dependențelor și responsabilitatea pentru incidente.

Lucrați pe baza datelor actuale de aplicare

Comisia indică 11 septembrie 2026 pentru obligațiile de raportare și 11 decembrie 2027 pentru principalele cerințe ale CRA. La 7 octombrie 2026, data pentru raportare a trecut deja. Tratați pregătirea pentru raportare ca pe o cerință operațională actuală, nu ca pe o sarcină amânată până la pregătirea conformității.

Mențineți vizibile două direcții de lucru:

Produsele furnizate înainte de data principală de aplicare necesită atenție la dispozițiile tranzitorii și la modificările substanțiale. Nu presupuneți că un produs mai vechi este irelevant pentru raportare doar pentru că lansarea sa inițială a avut loc înainte de decembrie 2027.

Mențineți un registru datat al cerințelor legale. Pentru pragurile evenimentelor, termenele etapizate de raportare, destinatari și procedurile de transmitere, verificați textul legal actual și ghidurile oficiale de aplicare. Nu înlocuiți procesul specific CRA cu un șablon generic de răspuns la incidente.

Transformați cerințele de securitate în criterii de proiectare și de lansare

Cerințele esențiale ale CRA acoperă proprietățile de securitate ale produsului și gestionarea vulnerabilităților. Implementarea lor ar trebui să urmeze evaluarea riscurilor de securitate cibernetică ale produsului, nu o listă de verificare universală aplicată fără context arhitectural.

Porniți de la modul în care produsul poate cauza prejudicii. Descrieți utilizatorii, mediile de implementare, interfețele expuse, operațiile privilegiate, datele sensibile și utilizarea abuzivă previzibilă. Includeți ipotezele de operare ale clientului: un echipament implementat într-o rețea industrială are o expunere și constrângeri de recuperare diferite față de un utilitar de desktop.

Un exercițiu practic de modelare a amenințărilor poate sprijini această activitate; ghidul OWASP privind modelarea amenințărilor oferă o abordare consacrată. Rezultatul ar trebui să lege amenințările de cerințe specifice, decizii de implementare și teste.

Iată cum pot deveni testabile cerințe familiare:

Acestea sunt exemple practice de implementare, nu un substitut pentru cerințele aplicabile. Stabiliți relevanța și suficiența prin evaluarea riscurilor.

Adăugați criterii de acceptare privind securitatea la dezvoltarea funcționalităților. Un nou API administrativ ar trebui să vină cu decizii privind autentificarea, autorizarea, gestionarea datelor de intrare și jurnalizarea, nu cu promisiunea că echipa de securitate îl va inspecta mai târziu. Revizuiți modelul de amenințări atunci când adăugați o interfață la distanță, o componentă privilegiată sau o nouă limită de încredere.

Aprobarea lansării ar trebui să identifice vulnerabilitățile nerezolvate, exploatabilitatea lor, configurațiile afectate și tratarea lor. Aplicați cerința CRA de a pune produsele la dispoziție pe piață fără vulnerabilități exploatabile cunoscute, ținând seama de evaluarea riscurilor și de cerințele esențiale aplicabile; simpla înregistrare sau acceptare a unui risc nu satisface, în sine, această cerință. Rezultatul unui scanner nu poate lua singur această decizie: contează accesibilitatea codului vulnerabil, condițiile prealabile și comportamentul produsului. Invers, un scor numeric de severitate scăzut nu este un motiv suficient pentru a ignora o vulnerabilitate care are consecințe în modelul dumneavoastră de implementare.

Înregistrarea lansării ar trebui să lege revizia sursă aprobată, artefactul de build, inventarul dependențelor, rezultatele testelor și decizia de securitate. Astfel, evaluarea devine reproductibilă atunci când un client sau o autoritate întreabă ulterior despre o anumită versiune.

Faceți din diligența privind componentele o parte a procesului de build

Componentele terțe creează obligații care nu pot fi îndeplinite prin simpla redirecționare a unui aviz de securitate din amonte. Trebuie să înțelegeți ce ați livrat, dacă este afectat și cum îl puteți remedia.

CRA include, în cadrul cerințelor privind gestionarea vulnerabilităților, o cerință referitoare la lista materialelor software: un format utilizat în mod obișnuit, care poate fi citit automat și care acoperă cel puțin dependențele de nivel superior. Ca recomandare practică, colectați informații mai detaliate despre dependențe oriunde instrumentele de build pot produce rezultate fiabile. Dependențele tranzitive determină adesea expunerea.

Un SBOM este util doar atunci când corespunde unui artefact real al produsului. Asociați-l cu identificatorul versiunii și cu build-ul și distingeți componentele livrate de instrumentele folosite doar în dezvoltare. Includeți, acolo unde este relevant, firmware-ul, pachetele sistemului de operare, bibliotecile incluse și componentele comerciale; un export din managerul de pachete poate omite mai multe dintre acestea.

Construiți revizuirea componentelor în jurul întrebărilor care schimbă deciziile de inginerie:

• Este componenta întreținută și este durata sa de suport compatibilă cu a noastră?
• Putem obține prompt informații despre vulnerabilități și actualizări de securitate?
• Avem acces la codul sursă, o cale de patch-uri prin furnizor sau o strategie de înlocuire?
• Introduce componenta execuție privilegiată sau o nouă conexiune externă?
• Poate fi produsul întreținut în continuare dacă furnizorul încetează să ofere suport?

Pentru componentele comerciale, achizițiile ar trebui să stabilească persoanele de contact pentru securitate, aranjamentele de notificare și accesul la remedieri. Termenele furnizorului trebuie să lase timp pentru propria evaluare și pentru obligațiile de raportare. Producătorul produsului are nevoie în continuare de o cale internă de escaladare atunci când răspunsul unui furnizor este incomplet.

Pentru dependențele open source, păstrați proveniența și un plan realist de întreținere. Faptul că un depozit de cod este accesibil public nu dovedește că cineva va produce un patch compatibil în perioada dumneavoastră de suport.

Proiectați împreună perioada de suport și mecanismul de actualizare

Suportul este un angajament de inginerie cu consecințe comerciale. CRA impune, în general, o perioadă de suport de cel puțin cinci ani, cu excepția cazului în care perioada preconizată de utilizare a produsului este mai scurtă. Stabiliți perioada aplicabilă folosind criteriile regulamentului, în loc să alegeți o dată arbitrară care să se potrivească cu roadmap-ul.

Înregistrați justificarea, comunicați clienților informațiile necesare privind suportul și legați-le de versiunile întreținute ale produsului. Angajamentul de suport trebuie să țină cont de capacitatea de a livra actualizări de securitate, nu doar de păstrarea unei adrese de helpdesk.

Înainte de a aproba planul de suport al unui produs, întrebați dacă puteți:

• Reconstrui ramurile mai vechi suportate cu toolchain-uri întreținute.
• Produce, autentifica și distribui în siguranță actualizări de securitate.
• Testa remedierile pe hardware-ul și configurațiile de implementare suportate.
• Întreține cheile de semnare și reveni în siguranță după compromiterea unei chei.
• Menține disponibile pentru clienți informațiile privind actualizările și securitatea.
• Gestiona dependențele al căror suport din amonte se încheie înaintea suportului dumneavoastră.

Actualizările de securitate trebuie, în general, furnizate gratuit pe durata perioadei de suport, sub rezerva dispozițiilor regulamentului. Fiecare actualizare de securitate emisă în această perioadă trebuie să rămână disponibilă cel puțin zece ani de la emitere sau pentru restul perioadei de suport, oricare dintre acestea este mai lungă. Planificați remedierile de securitate separat de dezvoltarea funcționalităților, astfel încât clienții să nu fie obligați inutil să accepte modificări funcționale fără legătură.

Testați mai mult decât scenariul ideal. O instalare întreruptă, spațiul de stocare insuficient, credențialele expirate și verificarea eșuată pot transforma un patch valid într-o problemă de disponibilitate. Decideți ce mecanisme de recuperare sunt necesare pentru profilul de risc al produsului.

La sfârșitul suportului, comunicarea către clienți și evidențele interne ar trebui să concorde. Nu lăsați o pagină de descărcare care sugerează continuarea mentenanței de securitate atunci când registrul produselor arată că angajamentul s-a încheiat.

Construiți un runbook de raportare care rezistă incertitudinii

O vulnerabilitate obișnuită, o vulnerabilitate exploatată activ și un incident grav de securitate nu sunt interschimbabile. Procesul de raportare CRA necesită o evaluare documentată a declanșatorului relevant, nu raportarea automată a fiecărei alerte de scanner și nici respingerea automată a oricărui eveniment în lipsa unei investigații criminalistice finalizate.

Runbook-ul ar trebui să înceapă cu preluarea semnalărilor. Cercetătorii, suportul pentru clienți, furnizorii și echipele de inginerie au nevoie de o cale cunoscută către funcția de securitate a produselor. Păstrați raportul original și înregistrați momentul în care au devenit cunoscute informațiile relevante; nu resetați marcajele temporale ale luării la cunoștință atunci când un tichet trece la altă echipă.

Pentru evenimentele care ar putea fi raportabile, colectați:

• Identificatorii produsului și versiunile suportate afectate.
• Dovezi ale exploatării sau ale impactului incidentului, cu nivelul de încredere și incertitudinile.
• Condițiile de atac cunoscute, funcțiile afectate și ipotezele de implementare.
• Măsurile de atenuare disponibile și stadiul măsurilor corective.
• Evaluarea declanșatorului, responsabilul de raportare și calculul termenelor aplicabile.
• Notificările transmise, confirmările de primire, actualizările ulterioare și comunicările către clienți.

Verificați în surse oficiale termenele etapizate de notificare, cerințele privind raportul final, destinatarii și procedura actuală de raportare. Vulnerabilitățile exploatate activ și incidentele grave au detalii de raportare distincte; un singur câmp copiat pentru termen nu este suficient.

Desemnați un responsabil principal de raportare și un înlocuitor cu autoritatea de a coordona ingineria, echipa juridică și comunicarea cu clienții. Asigurați din timp accesul la mecanismul de raportare aplicabil. Revizuirea juridică ar trebui să fie disponibilă în fereastra de raportare, nu să devină o coadă de aprobare fără limită.

Exersați procesul cu informații incomplete. O repetiție utilă începe cu un raport credibil de exploatare, o listă incertă a versiunilor afectate și un furnizor de componente indisponibil. Echipa ar trebui să poată lua o decizie de raportare la timp și documentată, în timp ce investigația continuă.

Raportarea CRA nu înlocuiește alte obligații aplicabile. Un eveniment legat de produs ar putea necesita și o evaluare în temeiul legislației privind protecția datelor sau al unui contract cu clientul. Coordonați aceste evaluări, dar păstrați separat declanșatorii, destinatarii și înregistrările deciziilor.

Confirmați clasificarea înainte de a alege planul de evaluare

Clasificarea produsului influențează procedura de evaluare a conformității disponibilă. Nu presupuneți că fiecare produs conectat necesită aceeași evaluare externă sau că fiecare producător se poate baza pe evaluarea internă.

Stabiliți categoria aplicabilă pe baza funcțiilor produsului și a definițiilor și anexelor regulamentului. Apoi confirmați procedura permisă, inclusiv orice condiții privind standardele armonizate, specificațiile recunoscute, schemele de certificare sau evaluarea de către terți.

Planificarea standardelor necesită un registru explicit al dependențelor: ce referințe sunt aplicabile, care este stadiul lor actual și ce se schimbă dacă o procedură preconizată nu este disponibilă. Evitați ca planul de lansare să depindă de o presupunere neconfirmată privind standardele sau capacitatea de evaluare.

Revizuiți clasificarea atunci când funcționalitatea se schimbă. Adăugarea unor capabilități de management al securității sau de control al rețelei poate afecta analiza, dar denumirea unei funcționalități nu stabilește, în sine, o categorie. Evaluați funcția reală și documentați concluzia.

Mențineți clasificarea, procedura aleasă și livrabilele de conformitate legate de documentația tehnică. Marcajul CE și declarația de conformitate trebuie să urmeze procesul aplicabil; ele nu înlocuiesc implementarea cerințelor de fond.

Mențineți un pachet de dovezi care poate explica o versiune lansată

Documentația tehnică ar trebui să descrie atât produsul, cât și raționamentul din spatele deciziilor sale de securitate. Păstrați evaluările riscurilor și documentația pe măsură ce produsul se schimbă și aplicați cerințele legale de păstrare evidențelor relevante.

Un pachet util de dovezi pentru produs include decizia de perimetru, arhitectura, evaluarea riscurilor, cerințele de securitate, informațiile despre componente, rezultatele verificărilor, procedurile de gestionare a vulnerabilităților, justificarea perioadei de suport și evidențele de conformitate. Fiecare element are nevoie de un responsabil și de o versiune identificabilă.

Folosiți identificatori stabili pentru a lega aceste evidențe. O înregistrare a unei vulnerabilități ar trebui să explice versiunile afectate, expunerea, tratarea, versiunea de remediere și comunicarea necesară. „Rezolvat” fără contextul versiunii lasă dovezile privind produsul incomplete.

Procesele SMSI existente pot furniza dovezi utile privind guvernanța, furnizorii și dezvoltarea sigură. Totuși, ISO 27001 privește un sistem de management al securității informației cu perimetru definit; certificarea nu stabilește conformitatea unui produs individual cu CRA. Reutilizați dovezile relevante fără a trata corespondențele dintre cadrele de referință ca echivalență juridică.

Exemplu practic: o vulnerabilitate a unei dependențe într-un echipament suportat

Să luăm în considerare un producător ilustrativ care furnizează în UE un echipament conectat la rețea. Să presupunem că perimetrul și clasificarea acestuia au fost revizuite, că două ramuri de versiuni rămân suportate și că o bibliotecă inclusă este raportată ca fiind exploatată activ în alte contexte.

Prima sarcină nu este închiderea avizului din amonte. Echipa de inginerie identifică ce build-uri ale echipamentului conțin biblioteca vulnerabilă și dacă funcția afectată este accesibilă. SBOM-ul sugerează că ambele ramuri o conțin, dar analiza configurației arată o expunere diferită. Această distincție este înregistrată împreună cu dovezile justificative.

Responsabilul cu securitatea produsului evaluează apoi dacă faptele disponibile îndeplinesc declanșatorul de raportare CRA aplicabil. Incertitudinea privind o anumită configurație de implementare este înregistrată; ea nu justifică lăsarea nedesemnată a persoanei care ia decizia. Runbook-ul de raportare furnizează etapele actuale de notificare și procedura.

Echipa de inginerie dezvoltă o măsură temporară de atenuare și un build cu patch pentru fiecare ramură afectată. Testele acoperă calea vulnerabilă, funcționarea normală și instalarea autentificată a actualizării. Dacă o ramură nu poate folosi patch-ul din amonte, echipa înregistrează tratarea alternativă și riscul rezidual, în loc să marcheze întregul produs drept rezolvat.

Comunicarea către clienți identifică versiunile afectate, acțiunile imediate de protecție și modul de obținere a actualizării. Momentul divulgării este coordonat cu cerințele aplicabile privind gestionarea vulnerabilităților și cu orice considerente de securitate justificate.

Înregistrarea finalizată leagă avizul, analiza build-urilor afectate, decizia de raportare, notificările transmise acolo unde este necesar, commit-urile de patch, rezultatele testelor, artefactele de lansare și comunicările. Un evaluator poate reconstitui acum atât răspunsul de inginerie, cât și decizia de conformitate.

Începeți cu un singur produs și un lanț complet de dovezi

Alegeți un produs suportat reprezentativ și urmăriți o versiune recentă și o vulnerabilitate pe parcursul ciclului de viață. Legăturile lipsă cu versiunile, angajamentele de suport neclare și procedurile de raportare inaccesibile vor deveni rapid vizibile. Transformați fiecare lacună într-o sarcină cu responsabil, apoi extindeți modelul la întregul portofoliu.

Secani poate sprijini acest flux de lucru privind dovezile prin conectarea cerințelor, dovezilor, responsabililor, sarcinilor și deciziilor de revizuire. Instrumentele de inginerie rămân sursele operaționale pentru build-uri, versiuni și vulnerabilități; spațiul de lucru pentru conformitate pune aceste evidențe în relație cu obligația aplicabilă. Mențineți explicită aprobarea umană pentru corespondențe și concluzii și păstrați trasabilitatea surselor atunci când folosiți ciorne asistate de IA.

Următorul pas imediat este testarea runbook-ului de raportare. În paralel, cereți ca următoarea versiune a produsului să fie însoțită de o decizie de perimetru asociată, o evaluare actuală a riscurilor, un inventar al componentelor și o aprobare de securitate. Astfel se creează o practică de inginerie repetabilă, în timp ce pregătirea conformității avansează.