Recomandat

Securitate, suveranitate digitală și România ca martor

Cybersecurity Accesări: 272 31 Minute de citire

Infrastructura care nu cere voie — Securitate, suveranitate digitală și România ca martor

 Notă de transparență: Articol redactat cu asistență AI. Judecățile, pozițiile polemice și perspectivele aparțin în întregime autorului.

O mărturisire înainte de început

Am gestionat și am oferit suport procedural în 2026 mai multe incidente de securitate pe site-uri ale unor clienți instituționali. 

Spun asta nu ca să mă laud cu incidentele rezolvate — ci pentru că toată discuția despre securitate open source și suveranitate digitală europeană pe care o voi purta în paginile următoare are, pentru mine, chipuri concrete. Nu este o dezbatere academică despre politici publice. Este realitatea în care lucrez.

Și, cu această realitate în minte, vreau să spun ceva incomod: Europa are dreptate în privința diagnosticului și greșește parțial în privința tratamentului. Open source este singura soluție structurală disponibilă — și comunitatea open source nu este pregătită pentru responsabilitățile pe care i le atribuie Bruxelles-ul. Iar România — ca întotdeauna — asistă la toate acestea cu o combinație de bun simț provincial și instituții epuizate, sperând că cineva va rezolva problema înainte ca ea să devină insuportabilă.

Să deschidem, deci.

Partea I: Securitatea — sau cum am confundat decenii întregi „gratuit" cu „sigur"

Mitul fondator

Există o poveste pe care industria software și-a spus-o cu plăcere timp de douăzeci de ani: codul open source este mai sigur decât codul proprietar pentru că „mai mulți ochi" îl verifică. Linus' Law, formulat de Eric Raymond în The Cathedral and the Bazaar: „given enough eyeballs, all bugs are shallow."

Este o idee frumoasă. Are și un gram de adevăr în ea. Dar este o idee care a funcționat ca alibi instituțional pentru decenii de neglijență colectivă.

Realitatea nu este că mulți ochi verifică codul open source. Realitatea este că puțini ochi verifică cu atenție codul open source, cei mai mulți presupun că altcineva a verificat deja, și că finanțarea pentru această verificare sistematică a lipsit aproape complet.

Rezultatul? Vulnerabilități care stau ascunse ani de zile în cod folosit de miliarde de sisteme.

Heartbleed — 2014. O vulnerabilitate în OpenSSL, biblioteca care criptează jumătate din internetul lumii, scrisă și menținută de o mână de voluntari cu finanțare minimă. A stat ascunsă doi ani. Când a fost descoperită, estimările pagubelor potențiale au mers în sute de miliarde de dolari.

Log4Shell — 2021. O vulnerabilitate în Log4j, o bibliotecă Java de logging folosită în miliarde de aplicații enterprise, menținută de un număr mic de voluntari. A stat ascunsă ani de zile. Când a explodat, a costat industria globală sute de milioane de dolari în remedieri urgente și a lăsat sisteme vulnerabile active luni întregi după descoperire.

XZ Utils — 2024. Un atac de supply-chain sofisticat, desfășurat pe parcursul a doi ani de un actor care a construit reputație în comunitate înainte de a introduce codul malițios. A fost descoperit aproape întâmplător, de un inginer care a observat că SSH pornea cu câteva sutimi de secundă mai lent decât normal.

Fiecare incident a produs același ciclu: panică, remedieri urgente, declarații solemne că „trebuie să facem ceva", și apoi... revenire la normalitate. Normalitate înseamnă același model: fundamente critice ale internetului menținute de voluntari epuizați, cu resurse insuficiente, fără procese formale de audit.

Mă gândesc la tatăl meu — mecanic. El înțelegea că un motor care nu primește ulei se strică. Nu ca profeție, ci ca fizică elementară. Nu trebuia să citească un raport de industrie ca să știe că neglijarea mentenanței are consecințe. O vedea în uzina de tractoare, o vedea în garajul din curte.

Industria software a negat decenii această fizică elementară. A tratat mentenanța ca pe o chestiune care se rezolvă de la sine, prin forța magică a comunității și a entuziasmului voluntar. Și s-a mirat, de fiecare dată cu surprindere proaspătă, când infrastructura neglijată a cedat.

2025: Anul în care surprinderea s-a epuizat

2025 a adus o serie de incidente de supply-chain care au consumat ultimele rezerve de surpriză ale industriei. Nu voi lista toate incidentele — sunt documentate exhaustiv în rapoartele OpenSSF și ale agenților de securitate naționali. Ce vreau să subliniez este schimbarea de ton care a urmat.

Anterior, fiecare incident major producea o reacție difuză: companii care actualizau urgent, cercetători care publicau analize, presă care scria articole, conferințe care adăugau panel-uri despre supply-chain security. Și apoi uitare organizată.

După 2025, reacția a fost diferită. A fost sistematică.

npm — managerul de pachete JavaScript cu peste 3 milioane de pachete publicate, folosit de zeci de milioane de dezvoltatori — a anunțat și implementat în 2026 cea mai radicală schimbare de securitate din istoria sa de 16 ani: blocarea implicită a scripturilor de instalare, a dependențelor Git și a surselor remote. Comportament permis implicit de la înființare devine opt-in explicit.

Este o decizie care a rupt decenii de obișnuință a dezvoltatorilor. A creat frecare, nemulțumire, pachete care au încetat temporar să funcționeze. A fost luată oricum.

Contextul direct: campania Miasma, documentată în vara lui 2026, în care un fișier de 157 de octeți — un binding.gyp aparent inofensiv — a compromis 57 de pachete npm și 286 de versiuni malițioase în sub două ore. Mecanismul: npm executa automat scripturi la instalare, atacatorii controlau acele scripturi. O poartă deschisă de decenii, exploatată cu eleganță criminală.

Răspunsul npm spune ceva important: ecosistemul a ales securitatea în detrimentul comoditatii. Aceasta nu este o decizie banală. În competiția pentru adopție de dezvoltatori, fricțiunea este dușman. npm a ales să creeze fricțiune în mod deliberat, pentru că alternativa — continuarea comportamentului nesigur — nu mai era acceptabilă.

Rust: când limbajul devine argument de securitate

Există o convingere în creștere în comunitatea de securitate software din 2026 că o clasă întreagă de vulnerabilități — cele legate de gestionarea memoriei — nu poate fi eliminată prin audit uman, ci doar prin alegerea unui limbaj care le face imposibile prin design.

Rust este acel limbaj.

Nu intru în detalii tehnice profunde — există resurse excelente pentru asta. Ceea ce vreau să subliniez este semnificația politică a adoptării Rust de către proiecte care au definit infrastructura software a ultimelor decenii.

Git 2.55 — instrumentul creat de Linus Torvalds care a revoluționat controlul versiunilor software — a activat Rust by default. Kernelul Linux primește contribuții în Rust pentru subsisteme critice. Proiectele Android, Windows, Firefox, curl — toată infrastructura care constituie fundația experienței digitale cotidiene — migrează componentele critice spre Rust.

Aceasta nu este o modă. Este o recunoaștere că siguranța memoriei nu poate fi asigurată prin disciplina programatorilor individuali. Zeci de ani de eforturi, audituri, instrumente de analiză statică nu au eliminat vulnerabilitățile de memorie din cod C și C++. Limbajul însuși trebuie să se schimbe.

Tatăl meu mecanic ar înțelege imediat argumentul. Nu trimiți un mecanic să repare o mașină construită defectuos — schimbi designul mașinii. Uneori soluția nu este mai multă atenție, ci un sistem care nu permite eroarea.

Auditarea automată cu AI: soluția care introduce noi probleme

2026 a văzut o explozie a instrumentelor de auditare automată a securității bazate pe AI. Companii, proiecte open source și agenții guvernamentale investesc în sisteme care scanează cod, detectează vulnerabilități, corelează dependențele cu bazele de date CVE și generează rapoarte de risc în timp real.

Este util. Este necesar. Și este, simultan, o nouă suprafață de atac.

Instrumentele de securitate bazate pe AI au propriile lor vulnerabilități. Modelele pot fi otrăvite cu date de antrenament manipulate pentru a rata sau a genera fals pozitive pentru anumite tipuri de cod. Infrastructura pe care rulează aceste instrumente devine ea însăși o țintă. Și există o tentație periculoasă de a trata outputul AI ca pe adevăr definitiv, reducând judecata umană specializată care rămâne necesară.

Mă gândesc la paradoxul pe care îl văd în practica mea: organizațiile care nu aveau resurse pentru un audit uman anual cumpără acum subscripții la platforme de audit AI continuu. Este mai bine decât nimic — dar nu este o substituție. Un instrument AI poate detecta vulnerabilitățile cunoscute. Nu poate evalua riscul arhitectural, nu poate înțelege contextul de business, nu poate judeca dacă o vulnerabilitate este exploatabilă în configurația specifică a sistemului respectiv.

Securitatea rămâne, în ultimă instanță, o problemă umană. AI-ul o face mai eficientă, nu redundantă.

OpenSSF: instituționalizarea bunului simț

Open Source Security Foundation — adăpostită sub umbrela Linux Foundation — a trecut în 2025–2026 de la stadiul de organism de coordonare la cel de infrastructură activă a securității globale open source.

Cadrul SLSA (Supply-chain Levels for Software Artifacts), scorecards de securitate pentru proiecte, standardele de semnare criptografică a artefactelor software, programele de audit finanțat pentru proiecte critice — toate reprezintă instituționalizarea unor practici care anterior existau fragmentat sau deloc.

Ceea ce OpenSSF construiește este, în esență, un sistem de responsabilitate distribuită: dacă un proiect are un scorecard public de securitate, organizațiile care îl adoptă pot face decizii informate. Dacă un proiect refuză auditul sau nu menține standardele, devine vizibil. Transparența ca mecanism de responsabilitate.

Este o abordare americană, pragmatică, de tip bottom-up: construiești instrumentele, stabilești standardele, speri că adoptarea voluntară creează masa critică. Funcționează mai bine decât absența oricărei coordonări — și mai puțin bine decât o reglementare obligatorie cu dantură reală.

Despre asta — despre reglementare — vorbesc în capitolul următor. Și acolo lucrurile devin mai complicate.

Europa — Diagnosticul corect, tratamentul discutabil

Premisa care nu mai poate fi contestată

Există, în discursul politicii publice europene despre digitalizare, o sintagmă care a trecut în câțiva ani de la retorică ambițioasă la descriere a realității: suveranitate digitală.

Suveranitatea digitală înseamnă, în formularea sa cea mai concisă, că o entitate politică — un stat, o uniune de state — are capacitatea de a controla infrastructura digitală de care depinde funcționarea sa. De a nu fi dependent de actori externi pentru servicii esențiale. De a putea audita, modifica sau înlocui componentele critice ale propriei infrastructuri digitale.

Prin acest criteriu, Europa nu este suverană digital. Nu în 2026. Poate nu va fi nici în 2030.

Infrastructura cloud pe care rulează serviciile publice europene este dominată de furnizori americani — AWS, Azure, Google Cloud. Sistemele de operare ale dispozitivelor cu care cetățenii europeni interacționează cu serviciile publice sunt controlate de Apple și Google, companii americane cu sediul în California. Algoritmii care mediază accesul la informație în spațiul public european — motoare de căutare, rețele sociale, platforme de conținut — sunt produși și controlați în afara Europei.

Aceasta nu este o critică anti-americană. Este o observație despre arhitectura dependenței. Dependența nu este rea prin definiție — globalizarea a produs beneficii reale. Dar dependența asimetrică față de actori care nu sunt supuși jurisdicției tale, ale căror interese pot diverge față de ale tale, și pe a căror infrastructură nu ai vizibilitate auditabilă — aceasta este o vulnerabilitate structurală.

Europa a ajuns la această concluzie. Tardiv, dar ferm.

CRA: reglementarea care a speriat o comunitate și a forțat o conversație

Cyber Resilience Act — adoptat în octombrie 2024, cu cerințe de raportare aplicabile din septembrie 2026 și intrare în vigoare completă în decembrie 2027 — este cea mai ambițioasă tentativă de reglementare a securității software din istoria politicii publice.

Principiul de bază este rezonabil, chiar evident: dacă un produs digital conține vulnerabilități de securitate care prejudiciază utilizatorii, producătorul ar trebui să fie responsabil. La fel cum producătorul unui aparat electrocasnic este responsabil dacă aparatul produce electrocutări din cauza unui defect de design.

Aplicat la software, principiul devine imediat complicat. Pentru că software-ul modern nu este produs de un singur actor. Este asamblat din sute sau mii de componente, fiecare produsă de altcineva, fiecare cu propriile vulnerabilități potențiale. Cine este responsabil pentru o vulnerabilitate în o dependență tranzitivă pe care producătorul final nici nu știa că o are?

Prima versiune a CRA a tratat această complexitate cu brutalitate: a extins potențial responsabilitatea la orice contribuitor la software care ajunge în produse comerciale. Inclusiv voluntarii care contribuie la proiecte open source în timpul liber.

Reacția comunității open source a fost pe măsură: îngrijorare profundă, articole în cascadă, lobby intensiv. Argumentul central era convingător: dacă un voluntar care contribuie câteva ore pe săptămână la un proiect open source poate fi tras la răspundere pentru vulnerabilitățile care apar ulterior în produse comerciale construite pe acel proiect, rezultatul va fi abandonarea masivă a contribuțiilor voluntare. Tocmai infrastructura pe care toată lumea depinde se va prăbuși sub greutatea riscului juridic.

Versiunea finală a CRA a ascultat parțial aceste argumente. A creat categoria de OSS steward — entitate care furnizează suport susținut pentru proiecte open source comercializate — cu un regim de responsabilitate adaptat, mai ușor. Voluntarii care contribuie fără intenție comercială sunt, în principiu, protejați.

Spun „în principiu" pentru că liniile de demarcație din regulament nu sunt cristaline. „Activitate comercială" are o definiție suficient de largă pentru a crea incertitudine. Și în drept, incertitudinea costă: costă taxe de avocat, costă timp, costă riscul de a fi prins de o interpretare extensivă a autorității de supraveghere.

Există o ironie dureroasă în toată această poveste: Bruxelles-ul vrea să consolideze securitatea ecosistemului open source de care depinde Europa — și instrumentul ales riscă să descurajeze exact contribuțiile voluntare care au construit și mențin acel ecosistem.

Nu este prima dată când intenții bune produc efecte perverse prin reglementare insuficient calibrată. Nu va fi ultima.

AI Act și modelele open source: o tensiune nerezolvată

Dacă CRA a creat tensiune în relația dintre reglementare și ecosistemul open source general, AI Act deschide un front și mai complex: modelele AI open-weight.

AI Act clasifică sistemele AI după risc și stabilește obligații proporționale: transparență, documentare, evaluare de conformitate, registrare. Modelele de uz general (GPAI) cu capacități semnificative — inclusiv modelele open-weight distribuite liber — intră sub obligații de transparență și evaluare a riscurilor.

Problema fundamentală: un model open-weight distribuit liber poate fi descărcat, modificat și redistribuit de oricine. Odată eliberat, producătorul original pierde controlul asupra utilizării. Cum îl faci responsabil pentru utilizările pe care nu le-a anticipat și nu le poate controla?

Analogia cu armele de foc este tentantă și imperfectă: producătorul unui pistol nu este responsabil pentru fiecare crimă comisă cu acel pistol. Dar producătorul unui model AI care a ignorat riscurile documentate de utilizare malițioasă poate fi — în interpretarea AI Act — în zona de responsabilitate.

Răspunsul practic al marilor producători de modele open-weight a fost documentarea extensivă — model cards, usage policies, evaluări de risc publicate — care servesc simultan scopului de conformitate și de apărare juridică. Este birocrație utilă, dar birocrație.

Întrebarea la care AI Act nu a răspuns satisfăcător este ce se întâmplă cu proiectele mici, cu cercetătorii academici, cu dezvoltatorii independenți care vor să experimenteze cu modele. Obligațiile de documentare și evaluare nu sunt insurmontabile pentru Google sau Meta. Pot fi insurmontabile pentru un cercetător cu resurse limitate dintr-o universitate din Iași sau Cluj.

Există riscul că AI Act — la fel ca CRA — concentrează involuntar piața în favoarea actorilor mari care pot absorbi costurile de conformitate, în defavoarea exactei diversități care face open source valoros.

Miliardele europene: unde merg și unde ar trebui să meargă

Dincolo de reglementare, Europa acționează prin instrumente de politică industrială: Digital Europe Programme, Horizon Europe, programele naționale de cofinanțare. Miliarde de euro sunt direcționate spre suveranitate digitală, cloud european, infrastractură open source.

Sunt bani reali. Și există exemple de utilizare inteligentă a lor.

German Sovereign Tech Fund — nu european, ci german, important de precizat — a demonstrat că finanțarea directă a mentenanței proiectelor open source critice este posibilă și eficientă. Nu prin contracte de achiziție birocratice, nu prin granturi de cercetare cu deliverables academice, ci prin plăți directe pentru muncă de mentenanță — patch-uri de securitate, documentație, compatibilitate, testare. Muncă invizibilă și esențială.

Modelul german merită extins la nivel european. OpenForum Europe a propus un European Sovereign Tech Fund de 350 de milioane de euro pe șapte ani. Nu s-a materializat încă. Există propuneri, studii de fezabilitate, declarații de intenție.

Între timp, ecosistemul open source european rămâne dependent de voluntariat și de finanțare americană — Linux Foundation, OpenSSF, Apache Foundation au sediul în Statele Unite și sunt finanțate predominant de companii americane. Europa beneficiază masiv de această infrastructură fără a contribui proporțional la susținerea ei.

Există ceva stânjenitor în această poziție: Europa vrea suveranitate digitală, construită pe o fundație open source care este, în proporție semnificativă, americană. Și rezistă să investească în mentenanța acelei fundații la nivelul la care beneficiază de ea.

Este o contradicție pe care Bruxelles-ul nu a rezolvat-o și pe care nu o va rezolva prin declarații.

OSI și comunitatea: negocierea unui contract nou

Open Source Initiative — gardianul tradițional al definiției open source — se găsește în 2026 în mijlocul celei mai dificile negocieri din istoria sa.

Pe de o parte: guvernele și organizațiile de standardizare cer responsabilitate, transparență, mecanisme de conformitate. „Dacă infrastructura noastră critică rulează pe software-ul vostru, vrem garanții."

Pe de altă parte: comunitatea open source, construită pe valori de libertate, voluntariat și contribuție benevolă, rezistă oricărei forme de responsabilitate juridică impusă extern. „Am construit asta din convingere, nu dintr-un contract. Nu semnăm un SLA cu guvernul Germaniei."

Tensiunea nu are o rezolvare elegantă. Și încerc să o înțeleg din ambele direcții, pentru că ambele au dreptate parțial.

Comunitatea open source a construit infrastructura digitală a lumii moderne. A făcut-o fără să ceară aprobare, fără să negocieze termeni, fără să aștepte ca vreun guvern să declare că e o bună idee. A construit pentru că a vrut. Și a funcționat — cu toate vulnerabilitățile, cu toate proiectele abandonate, cu toate incidentele — mai bine decât orice alternativă.

Guvernele și organizațiile care acum cer responsabilitate formală sunt, în proporție semnificativă, aceleași care au beneficiat de această infrastructură fără să contribuie la ea. Există ceva iritat în cererea de conformitate din partea actorilor care nu și-au dat osteneala să susțină financiar ecosistemul pe care acum vor să îl reglementeze.

Și totuși: infrastructura critică nu poate funcționa fără responsabilitate clară. Dacă un spital din România este compromise pentru că folosea o versiune vulnerabilă dintr-un pachet npm abandonat, cineva trebuie să fie responsabil. Nu voluntarul care a scris codul acum zece ani. Dar cineva.

Răspunsul la această problemă nu există încă în formă finală. Se negociază. Și negocierea va dura.

România — Martorul care nu-și permite să rămână martor

Poziția noastră structurală

România nu este un actor în dezbaterea globală despre securitate open source și suveranitate digitală. Suntem, în cel mai bun caz, un destinatar al deciziilor luate altundeva. CRA a fost negociat fără contribuție semnificativă românească. AI Act a fost modelat de interesele marilor economii europene — Germania, Franța, Italia. Fondurile europene de suveranitate digitală vor fi absorbite preponderent de state cu capacitate instituțională să construiască proiecte eligibile.

Aceasta nu este o plângere. Este o constatare despre structura puterii în UE, care corespunde în linii mari structurii economice. Statele mici și cu economii periferice au mai puțin acces la procesele de formare a regulilor, indiferent de mecanismele formale de democrație europeană.

Dar există o distincție importantă între a fi martor pasiv și a fi martor activ. România poate fi martor la transformarea digitală europeană sau poate fi participant la ea. Diferența nu vine din capacitatea de a influența regulamentele de la Bruxelles — aceea este limitată. Vine din capacitatea de a construi competență internă care valorifică ceea ce regulamentele creează.

Ce creează CRA pentru România

CRA va deveni complet aplicabil în decembrie 2027. De la septembrie 2026, cerințele de raportare a vulnerabilităților sunt active. Asta înseamnă că, în mai puțin de un an de la data publicării acestui articol, organizațiile din România care produc sau distribuie produse digitale vor trebui să raporteze vulnerabilitățile exploatate activ către ENISA și DNSC.

Consecința directă pentru piața de software din România este crearea unei cereri pentru servicii pe care puțini le oferă în prezent: audit de securitate cu documentare conformă CRA, consultanță pentru implementarea SBOM, suport pentru procesele de raportare a vulnerabilităților, evaluare de risc pentru dependențele open source.

Există o oportunitate de piață reală aici. Nu enormă — România nu va deveni over night centrul european al cybersecurityty compliance. Dar semnificativă pentru companiile și profesioniștii care se poziționează acum.

Am văzut asta în propria practică. Clienții instituționali — primării, școli, spitale — vor fi supuși unor presiuni de conformitate crescânde. Nu pentru că înțeleg neapărat CRA în detaliu, ci pentru că finanțările europene vor începe să ceară dovezi de due diligence în securitate digitală. Cine nu va putea demonstra că gestionează responsabil dependențele software nu va mai fi eligibil pentru anumite programe de finanțare.

Aceasta este mecanica prin care reglementările europene produc schimbare în statele membre: nu prin constrângere directă, ci prin condiționalitățile atașate accesului la fonduri.

Incidentele pe care le-am gestionat: o pedagogie a concretului

Vreau să fiu specific, în limita confidențialității față de clienți, despre tipurile de incidente pe care le-am gestionat în 2025–2026. Nu pentru că sunt neobișnuite — nu sunt. Ci pentru că ilustrează concret ce înseamnă vulnerabilitatea sistemică a organizațiilor mici din România.

Tipul 1: Template vulnerabil neactualizat. Un site pe Joomla cu un template din 2023, neactualizat, exploatabil prin o vulnerabilitate publică. Atacatorul a injectat conținut de spam și a folosit serverul pentru distribuție de malware. Clientul nu știa că template-ul are versiuni. Nu știa că versiunile au vulnerabilități. Nu știa că vulnerabilitățile sunt publice și exploatate activ de scripturi automate.

Tipul 2: Plugin abandonat. Un editor de conținut cu o vulnerabilitate critică (CVSS 10.0) într-o versiune folosită pe multiple site-uri ale unor clienți instituționali. Vulnerabilitate raportată public, patch disponibil. Clienții nu aplicaseră patch-ul pentru că nu aveau un proces de monitorizare a actualizărilor. Nu pentru că nu le păsa — ci pentru că nu aveau capacitatea instituțională de a urmări sute de componente software simultan.

Tipul 3: Credențiale compromise prin refolosire. Parole identice folosite pe multiple platforme, una dintre ele compromisă într-un breach extern. Atacatorul a folosit credențialele pentru a obține acces la panoul de administrare și a înlocuit conținutul cu pagini de phishing.

Niciunul dintre aceste incidente nu este sofisticat. Niciunul nu necesita resurse serioase de atacator. Toate au fost produse de absența unor practici de bază: inventariere, monitorizare, actualizare sistematică, politici de parole.

Și toate s-au produs în organizații care procesau date personale ale cetățenilor, sub legislație GDPR care ar fi trebuit să impună exact aceste practici de bază.

Discrepanța dintre cerințele legale existente și implementarea lor reală în organizațiile mici și mijlocii din România este, ea însăși, un subiect care merită o analiză separată. Mă limitez la a constata că există.

DNSC și infrastructura națională de răspuns

Direcția Națională de Securitate Cibernetică — DNSC — a evoluat semnificativ în capacitate în ultimii ani. Am interacționat cu ei în procesele de raportare a incidentelor și pot spune că există o competență tehnică reală și o dorință de angajament constructiv.

Dar DNSC operează cu resurse disproporționate față de amploarea problemei pe care trebuie să o gestioneze. Numărul de incidente raportate crește. Suprafața de atac a României digitale — cu mii de site-uri instituționale, sisteme de e-guvernare în diferite stadii de maturitate, infrastructuri critice conectate la rețele publice — este vastă.

Și există un paradox structural: organizațiile care au cel mai mult nevoie de sprijin în securitate cibernetică — primăriile mici, școlile, spitalele din orașe medii — sunt exact cele care au cel mai puțin acces la resurse specializate și cel mai puțin timp să interacționeze cu autoritatea de supraveghere.

CRA va crea obligații de raportare pentru o parte din aceste organizații. Obligațiile vor genera rapoarte. Rapoartele vor consuma resurse. Dar dacă nu există capacitate reală de remediere — dacă după raport nu urmează un sprijin concret în rezolvarea vulnerabilității — raportarea devine un ritual de conformitate care consumă timp fără să producă securitate.

Ce ar trebui să facem și ce probabil vom face

Sunt un optimist temperat. Am văzut destule eșecuri instituționale și destule reușite neașteptate pentru a nu mai face predicții categorice.

Ce ar trebui să se întâmple:

O politică națională explicită care tratează software-ul open source ca infrastructură critică, cu consecințe bugetare reale. Nu o strategie de 80 de pagini publicată pe site-ul unui minister și uitată în trei luni. O decizie operațională: inventariem dependențele open source ale sistemelor publice centrale, identificăm riscurile critice, alocăm resurse pentru remediere.

Un program de finanțare pentru organizații mici — primării, școli, spitale — pentru consultanță și implementare în securitate cibernetică de bază. Nu sute de mii de euro per organizație. Pachete de 5.000–15.000 de euro pentru audit, remediere și formare. Înmulțit cu mii de organizații, e un program serios. Finanțabil din fonduri europene disponibile.

O prezență activă în negocierile europene despre implementarea CRA, AI Act și fondurilor de suveranitate digitală. Nu pentru a bloca reglementările — care, în ansamblu, sunt benefice. Ci pentru a modela ghidurile de implementare astfel încât să fie accesibile și pentru organizații mici din state cu capacitate administrativă limitată.

Ce probabil se va întâmpla:

O serie de incidente vizibile — compromise unui sistem guvernamental important, pierdere de date personale la scară suficient de mare pentru a intra în presa mainstream — va produce presiune politică suficientă pentru câteva măsuri reactive. Vor fi anunțate solemn, implementate parțial, evaluate superficial.

Între timp, practicienii individuali — consultanți, agenții mici, profesioniști IT din organizații fără departament dedicat — vor continua să gestioneze criza de la un incident la altul, cu resurse inadecvate și fără un cadru instituțional care să îi susțină.

Și în câțiva ani, cineva va scrie un raport despre cât de mult a progresat România în cybersecurity față de un benchmark de acum zece ani, ignorând că benchmarkul însuși s-a deplasat și că decalajul față de statele cu politici serioase a crescut în termeni absoluți.

Nu este cinism. Este pattern recognition, bazat pe ani de observare a modului în care instituțiile românești procesează problemele sistemice.

Infrastructura care nu cere voie

Titlul explicat

Am ales titlul „Infrastructura care nu cere voie" pentru că descrie ceva esențial despre natura open source ca fenomen politic și cultural, nu doar tehnic.

Open source nu a apărut pentru că guvernele l-au finanțat. Nu a crescut pentru că marile corporații l-au planificat. Nu a devenit infrastructura critică a internetului pentru că a câștigat o licitație publică sau a semnat un contract cu statul.

A apărut pentru că oameni — mii, zeci de mii, sute de mii în decurs de decenii — au decis că merită să construiești lucruri care să poată fi folosite, modificate și redistribuite liber. Fără să ceară permisiunea nimănui.

Există în această atitudine ceva profund în dezacord cu logica instituțională normală — care pornește de la autorizare, de la contract, de la ierarhie. Open source pornește de la construcție directă. Nu îți cere voie să contribui. Nu îți cere legitimare externă pentru a publica cod. Construiești, publici, și dacă e util, alții îl adoptă.

Este o formă de acțiune politică care acționează la nivelul infrastructurii, nu la nivelul declarațiilor. Nu spune „ar trebui să existe o alternativă la software-ul proprietar". Construiește alternativa.

Noica vorbea despre „întru" — prepoziția care descrie adâncimea angajamentului față de o idee, față de o formă, față de o vocație. Contribuitorii open source care au construit Linux, Apache, Python, PostgreSQL, OpenSSL — cei care au construit fundamentele pe care rulează internetul — au acționat întru ceva. Nu pentru profit imediat, nu pentru recunoaștere, ci dintr-o viziune despre cum ar trebui să fie lucrurile.

Eu nu am această grandoare în practica mea zilnică. Gestionez site-uri ale unor primării mici, rezolv incidente de securitate la clinici și școli, scriu plugin-uri Joomla pentru nevoi specifice. Dar mă simt parte din același impuls: că infrastructura digitală ar trebui să fie deschisă, auditabilă, controlabilă de cei care o folosesc.

De ce reglementarea nu este dușmanul, dar nici mântuitorul

Există o tentație în comunitățile tehnice de a privi orice reglementare ca pe un atac la adresa libertății de a construi. CRA și AI Act au declanșat reacții de tipul acesta — nu complet nejustificate, dar incomplete.

Reglementarea care impune responsabilitate pentru vulnerabilitățile din software distribuit comercial nu este, în principiu, rea. Cumpărătorul unui automobil are dreptul să presupună că mașina nu are defecte de fabricație care îl vor ucide. De ce cumpărătorul unui produs software — sau, mai important, cetățeanul ale cărui date sunt gestionate de acel software — nu ar avea un drept similar?

Problema nu este principiul responsabilității. Problema este calibrarea — cine este responsabil, pentru ce, în ce condiții, cu ce mecanisme de remediere. Și aici, primele versiuni ale CRA au greșit, supraextinzând responsabilitatea în zone unde nu era fezabilă sau justă.

Versiunea finală este mai bună. Dar nu este perfectă. Și implementarea va genera conflicte pe care textul regulamentului nu le rezolvă.

Ceea ce vreau să spun este că relația dintre comunitatea open source și reglementatorii europeni nu trebuie să fie una de ostilitate. Poate fi — și ar trebui să fie — una de negociere continuă, unde comunitatea aduce expertiză și reglementatorul aduce legitimitate democratică și capacitate de constrângere.

Europa vrea să construiască suveranitate digitală. Nu o poate face fără open source. Open source nu poate deveni infrastructură critică sustenabilă fără un cadru de responsabilitate și finanțare. Interesele sunt convergente — chiar dacă negocierea despre mijloace este adesea conflictuală.

Ce înseamnă suveranitatea pentru un profesionist din Botoșani

Închei cu o perspectivă personală, pentru că asta cere registrul acestui site.

Suveranitatea digitală, discutată în rapoartele de la Bruxelles și în conferințele de policy de la Berlin sau Paris, sună abstract. Este un concept important — și îl înțeleg, și îl susțin ca direcție de politică publică europeană.

Dar suveranitatea digitală are sens real pentru mine nu în rapoarte, ci în deciziile concrete pe care le iau pentru clienții mei.

Când recomand o soluție open source unui client instituțional în loc de un produs SaaS american, fac o alegere de suveranitate. Nu pentru că software-ul open source este întotdeauna superior tehnic — uneori nu este. Ci pentru că dă clientului control: poate audita codul, poate schimba furnizorul de hosting, poate modifica funcționalitățile, poate migra la un alt sistem fără să fie dependent de disponibilitatea unui serviciu extern pe care nu îl controlează.

Când construiesc o politică de vulnerabilitate pentru un client și îi explic de ce are nevoie de un SBOM, fac educație de suveranitate. Îl ajut să înțeleagă că software-ul pe care îl folosește nu este o cutie neagră pe care a cumpărat-o și o folosește — este o infrastructură complexă cu dependențe și riscuri pe care trebuie să le gestioneze activ.

Când raportez un incident la DNSC și documentez vulnerabilitățile pentru baza publică de date, contribui la infrastructura națională de securitate cibernetică. Nu spectaculos. Nu cu resurse mari. Dar concret.

Suveranitatea digitală nu se construiește la Bruxelles. Se construiește în mii de decizii zilnice ale miilor de practicieni din toată Europa care aleg, zi de zi, infrastructura deschisă față de cea închisă, responsabilitatea față de comoditate, cunoașterea față de ignoranța confortabilă.

Tatăl meu mecanic știa că un motor bun este un motor pe care îl cunoști — pe care îl poți deschide, înțelege, repara. Nu un motor despre care ți se spune că merge și pentru care trebuie să îl duci la service autorizat de câte ori se strică.

Același principiu se aplică infrastructurii digitale.

Cunoaște-ți infrastructura. Deschide-o. Înțelege-o. Reparo-o singur când poți. Asta este suveranitate — nu un document de politică publică, ci o competență și o atitudine.

Și asta este ceea ce open source face posibil, în 2026 ca și în 1996: infrastructura care nu cere voie să existe, nu cere voie să fie reparată, nu cere voie să fie transmisă mai departe.

Concluzie: Trei lucruri pe care le știm și unul pe care nu îl știm

Știm că securitatea ecosistemului open source nu mai poate fi lăsată pe seama voluntariatului pur. Incidentele din 2025 au demonstrat-o definitiv, și răspunsul ecosistemului — npm v12, Rust în proiectele critice, OpenSSF ca instituție activă — confirmă că mesajul a fost asimilat.

Știm că Europa are nevoie de suveranitate digitală și că open source este componenta fără de care suveranitatea nu este posibilă. CRA și AI Act sunt instrumente imperfecte care merg în direcția corectă.

Știm că România are nevoie să treacă de la stadiul de martor la cel de participant activ în această transformare — și că există o fereastră de oportunitate, deschisă de fondurile europene și de cererea crescândă pentru competențe de securitate și conformitate, care nu va rămâne deschisă indefinit.

Ce nu știm este dacă instituțiile românești — publice și private — au capacitatea de a valorifica această fereastră înainte ca ea să se închidă.

Răspunsul la această întrebare nu vine dintr-un raport sau dintr-o politică publică. Vine din deciziile pe care le iau, zi de zi, practicienii, managerii, decidenții și cetățenii digitali din România.

Fiecare decizie de a adopta o soluție auditabilă în loc de una opacă. Fiecare decizie de a actualiza o dependență vulnerabilă în loc de a o ignora. Fiecare decizie de a investi în competențe de securitate în loc de a spera că incidentul nu va veni.

Infrastructura care nu cere voie să existe poate fi construită de oricine alege să o construiască.

Rămâne să alegem.

Bibliografie selectivă

Incidente și context de securitate

  1. npm v12 — Security Redesign Announcement — npm Blog, iulie 2026. Dezactivare implicită scripturi de instalare, cel mai semnificativ redesign de securitate din 16 ani de npm.

  2. Campania Miasma / Phantom Gyp — Legit Security, Pinggy, Rescana (iunie–iulie 2026). 57 pachete compromise, 286 versiuni malițioase, mecanism binding.gyp.

  3. XZ Utils Supply-Chain Attack (CVE-2024-3094) — documentare Ars Technica, OpenWall, GitHub Advisory. Atac pe parcursul a doi ani, descoperit accidental.

  4. Heartbleed (CVE-2014-0160) și Log4Shell (CVE-2021-44228) — referințe istorice pentru pattern-ul recurent de vulnerabilități în infrastructura open source subfinanțată.

  5. OpenSSF Scorecard și SLSA Framework — openssf.org. Standarde de securitate supply-chain, scoring public pentru proiecte.

Reglementări europene

  1. Cyber Resilience Act — Regulation (EU) 2024/2847 — text oficial, Jurnalul Oficial al UE. Cerințe raportare aplicabile din 11 septembrie 2026, intrare vigoare completă decembrie 2027.

  2. EU Cyber Resilience Act — Open Regulatory Compliance Working Group — orcwg.org. Ghid practic implementare, categoria OSS steward.

  3. What the EU's new software legislation means for developers — GitHub Blog, decembrie 2024. Impact CRA asupra comunității open source, istoricul negocierilor.

  4. AI Act — Regulation (EU) 2024/1689 — text oficial. Obligații GPAI models, categorii de risc, cerințe transparență.

  5. EU Open Source Strategy 2026 — Comisia Europeană. digital-strategy.ec.europa.eu.

Finanțare și suveranitate

  1. German Sovereign Tech Fund — Raport 2022–2025 — sovereigntechfund.de. €23+ milioane în 60+ proiecte, model de referință european.

  2. We need a European Sovereign Tech Fund — OpenForum Europe feasibility study + GitHub Blog, 2025. Propunere €350 milioane / 7 ani.

  3. Digital sovereignty at the UN — ZDNet, iunie 2026. Open Source Week ONU, open source ca infrastructură națională.

  4. Open Infrastructure is Not Free — Declarație comună OpenSSF, Python Software Foundation, Eclipse, Rust Foundation, septembrie 2025.

Context românesc și DNSC

  1. DNSC — Rapoarte incidente 2025–2026 — dnsc.ro. Date agregate despre incidente cibernetice raportate în România.

  2. NIS2 Directive — Transpunere în legislația românească — cerințe pentru operatori de servicii esențiale și furnizori de servicii digitale.

  3. CVE-2026-49049 (Helix3), CVE-2026-21628 (Astroid Framework, CVSS 10.0), CVE-2026-48907 (JCE editor, CVSS 10.0) — vulnerabilități gestionate în practica proprie, documentate în rapoarte DNSC.

Petru Cojocaru este fondatorul ABSOLUT WEB EXPERT SRL, agenție web din Botoșani specializată în prezență digitală, conformitate în cybersecurity și strategie de conținut pentru instituții publice și companii private. Scrie despre libertate digitală, suveranitate tehnologică și practică reală în securitate cibernetică.

Notă de transparență AI: Articol redactat cu asistență Claude (Anthropic). Judecățile, pozițiile și perspectivele aparțin autorului. Referințele la incidente din practica proprie sunt reale, anonimizate pentru protejarea confidențialității clienților.