The Infrastructure That Doesn’t Ask for Permission
Transparency Note: This article was written with AI assistance. All judgments, polemical stances, and perspectives are entirely the author’s own.
A Confession Before We Begin
In 2026, I managed and provided procedural support for several security incidents affecting the websites of institutional clients.
And with this reality in mind, I want to say something uncomfortable: Europe is right about the diagnosis but partially wrong about the treatment. Open source is the only structural solution available—and yet the open-source community is not ready for the responsibilities Brussels is assigning to it. And Romania—as always—watches all of this with a mix of provincial common sense and exhausted institutions, hoping someone else will solve the problem before it becomes unbearable.
So let’s begin.
Security — Or How We Confused “Free” with “Safe” for Decades
The Founding Myth
There’s a story the software industry has told itself with pleasure for twenty years: Open-source code is more secure than proprietary code because “many eyes” review it. Linus’ Law, formulated by Eric Raymond in The Cathedral and the Bazaar: “Given enough eyeballs, all bugs are shallow.”
It’s a beautiful idea. It even contains a grain of truth. But it’s also an idea that has served as an institutional alibi for decades of collective neglect.
The reality isn’t that many eyes review open-source code. The reality is that few eyes review open-source code carefully, most assume someone else already has, and funding for systematic security reviews has been almost entirely absent.
The result? Vulnerabilities hiding for years in code used by billions of systems.
- Heartbleed — 2014. A vulnerability in OpenSSL, the library that encrypts half the world’s internet, written and maintained by a handful of volunteers with minimal funding. It remained undetected for two years. When discovered, the estimated potential damages ran into the hundreds of billions of dollars.
- Log4Shell — 2021. A vulnerability in Log4j, a Java logging library used in billions of enterprise applications, maintained by a small group of volunteers. It lurked undetected for years. When it exploded, it cost the global industry hundreds of millions of dollars in emergency fixes and left vulnerable systems active for months after discovery.
- XZ Utils — 2024. A sophisticated supply-chain attack, carried out over two years by an actor who first built a reputation in the community before introducing malicious code. It was discovered almost by accident by an engineer who noticed SSH was starting a few hundred milliseconds slower than usual.
Each incident produced the same cycle: panic, emergency fixes, solemn declarations that “we must do something”, and then… a return to normal. Normal meaning the same model: critical internet infrastructure maintained by exhausted volunteers with insufficient resources, without formal audit processes.
I think of my father—a mechanic. He understood that an engine without oil breaks down. Not as prophecy, but as basic physics. He didn’t need to read an industry report to know that neglecting maintenance has consequences. He saw it in the tractor factory. He saw it in the garage in our backyard.
The software industry has denied this basic physics for decades. It has treated maintenance as something that resolves itself, through the magical force of community and voluntary enthusiasm. And each time, with fresh surprise, it has marvelled as neglected infrastructure inevitably failed.
2025: The Year Surprise Ran Out
2025 brought a series of supply-chain incidents that exhausted the software industry’s remaining reserves of surprise. I won’t list all the incidents—they’re exhaustively documented in OpenSSF and national security agency reports. What I want to emphasise is the shift in tone that followed.
Previously, each major incident produced a diffuse reaction: companies urgently updated, researchers published analyses, the press wrote articles, conferences added panels on supply-chain security. And then… organised forgetting.
After 2025, the reaction was different. It was systematic.
npm—the JavaScript package manager with over 3 million published packages, used by tens of millions of developers—announced and implemented in 2026 the most radical security change in its 16-year history: default blocking of installation scripts, Git dependencies, and remote sources. Behaviour that had been allowed by default since its inception became explicitly opt-in.
This was a decision that broke decades of developer habit. It created friction, dissatisfaction, and temporarily broken packages. It was implemented regardless.
The direct context: the Miasma campaign, documented in the summer of 2026, in which a 157-byte file—a seemingly innocent binding.gyp—compromised 57 npm packages and 286 malicious versions in under two hours. The mechanism: npm automatically executed scripts during installation; attackers controlled those scripts. An open door for decades, exploited with criminal elegance.
npm’s response says something important: the ecosystem chose security over convenience. This is not a trivial decision. In the competition for developer adoption, friction is the enemy. npm deliberately chose to create friction, because the alternative—continuing insecure behaviour—was no longer acceptable.
Rust: When the Language Becomes a Security Argument
There’s a growing conviction in the 2026 software security community that an entire class of vulnerabilities—those related to memory management—cannot be eliminated through human audits, but only by choosing a language that makes them impossible by design.
That language is Rust.
I won’t dive into deep technical details—there are excellent resources for that. What I want to highlight is the political significance of Rust’s adoption by projects that have defined software infrastructure for decades.
- Git 2.55—the tool created by Linus Torvalds that revolutionised version control—now enables Rust by default.
- The Linux kernel accepts Rust contributions for critical subsystems.
- Android, Windows, Firefox, curl—all the infrastructure that forms the foundation of our daily digital experience—are migrating critical components to Rust.
This isn’t a fad. It’s an acknowledgment that memory safety cannot be guaranteed by the discipline of individual programmers. Decades of effort, audits, and static analysis tools have not eliminated memory vulnerabilities from C and C++ code. The language itself must change.
My mechanic father would immediately understand the argument. You don’t send a mechanic to repair a poorly built car—you change the car’s design. Sometimes the solution isn’t more attention, but a system that prevents error.
AI-Powered Automated Auditing: A Solution That Creates New Problems
2026 saw an explosion of AI-based automated security auditing tools. Companies, open-source projects, and government agencies are investing in systems that scan code, detect vulnerabilities, correlate dependencies with CVE databases, and generate real-time risk reports.
It’s useful. It’s necessary. And it’s simultaneously a new attack surface.
- Models can be poisoned with manipulated training data to miss or generate false positives for certain types of code.
- The infrastructure running these tools itself becomes a target.
- There’s a dangerous temptation to treat AI output as definitive truth, reducing the specialised human judgment that remains essential.
I think of the paradox I see in my practice: organisations that lacked resources for an annual human audit now buy subscriptions to continuous AI audit platforms. It’s better than nothing—but it’s not a substitute. An AI tool can detect known vulnerabilities. It cannot assess architectural risk, understand business context, or judge whether a vulnerability is exploitable in a system’s specific configuration.
Security remains, ultimately, a human problem. AI makes it more efficient, not redundant.
OpenSSF: Institutionalising Common Sense
The Open Source Security Foundation (OpenSSF)—housed under the Linux Foundation—transitioned in 2025–2026 from a coordination body to an active global open-source security infrastructure.
- The SLSA (Supply-chain Levels for Software Artifacts) framework,
- Security scorecards for projects,
- Cryptographic signing standards for software artefacts,
- Funded audit programmes for critical projects.
All represent the institutionalisation of practices that previously existed in fragments—or not at all.
What OpenSSF is building is, essentially, a distributed accountability system: if a project has a public security scorecard, organisations adopting it can make informed decisions. If a project refuses audits or fails to maintain standards, it becomes visible. Transparency as a mechanism for accountability.
It’s a pragmatic, bottom-up American approach: build the tools, set the standards, and hope that voluntary adoption creates critical mass. It works better than the absence of coordination—and less well than mandatory regulation with real teeth.
About that—about regulation—we’ll discuss in the next chapter. And that’s where things get more complicated.
Europe — Correct Diagnosis, Questionable Treatment
The Premise That Can No Longer Be Contested
There’s a phrase in European digital policy discourse that has gone from ambitious rhetoric to a description of reality in just a few years: digital sovereignty.
In its most concise formulation, digital sovereignty means that a political entity—a state, a union of states—has the capacity to control the digital infrastructure on which its functioning depends. To not be dependent on external actors for essential services. To be able to audit, modify, or replace critical components of its own digital infrastructure.
By this standard, Europe is not digitally sovereign. Not in 2026. Maybe not even in 2030.
- The cloud infrastructure on which European public services run is dominated by American providers—AWS, Azure, Google Cloud.
- The operating systems of the devices European citizens use to interact with public services are controlled by Apple and Google, American companies based in California.
- The algorithms that mediate access to information in the European public space—search engines, social networks, content platforms—are produced and controlled outside Europe.
This isn’t an anti-American criticism. It’s an observation about the architecture of dependency. Dependency isn’t inherently bad—globalisation has produced real benefits. But asymmetric dependency on actors not subject to your jurisdiction, whose interests may diverge from yours, and whose infrastructure you cannot auditably oversee—this is a structural vulnerability.
Europe has reached this conclusion. Late, but firmly.
CRA: The Regulation That Scared a Community and Forced a Conversation
The Cyber Resilience Act (CRA)—adopted in October 2024, with reporting requirements applicable from September 2026 and full enforcement from December 2027—is the most ambitious attempt to regulate software security in the history of public policy.
The basic principle is reasonable, even obvious: If a digital product contains security vulnerabilities that harm users, the manufacturer should be liable. Just as the manufacturer of a household appliance is liable if the appliance causes electric shocks due to a design defect.
Applied to software, the principle becomes immediately complicated. Because modern software isn’t produced by a single actor. It’s assembled from hundreds or thousands of components, each produced by someone else, each with its own potential vulnerabilities. Who is responsible for a vulnerability in a transitive dependency that the final manufacturer didn’t even know it had?
The first version of the CRA treated this complexity with brutality: it extended potential liability to any contributor to software that ends up in commercial products. Including volunteers who contribute to open-source projects in their spare time.
The open-source community’s reaction was proportionate: deep concern, a cascade of articles, intense lobbying. The central argument was compelling: If a volunteer who contributes a few hours a week to an open-source project can be held liable for vulnerabilities that later appear in commercial products built on that project, the result will be a mass exodus of volunteer contributions. The very infrastructure everyone depends on could collapse under the weight of legal risk.
The final version of the CRA partially listened to these arguments. It created the category of OSS steward—an entity that provides sustained support for commercialised open-source projects—with an adapted, lighter liability regime. Volunteers contributing without commercial intent are, in principle, protected.
I say “in principle” because the demarcation lines in the regulation are not crystalline. “Commercial activity” has a definition broad enough to create uncertainty. And in law, uncertainty costs: it costs lawyer fees, it costs time, it costs the risk of being caught by an extensive interpretation of the supervisory authority.
There’s a painful irony in this whole story: Brussels wants to strengthen the security of the open-source ecosystem on which Europe depends—and the chosen instrument risks discouraging the very volunteer contributions that built and maintain that ecosystem.
This isn’t the first time good intentions have produced perverse effects through poorly calibrated regulation. It won’t be the last.
AI Act and Open-Weight Models: An Unresolved Tension
If the CRA created tension in the relationship between regulation and the broader open-source ecosystem, the AI Act opens an even more complex front: open-weight AI models.
The AI Act classifies AI systems by risk and establishes proportional obligations: transparency, documentation, conformity assessment, registration. General-purpose AI models (GPAI) with significant capabilities—including freely distributed open-weight models—fall under transparency and risk assessment obligations.
The fundamental problem: An open-weight model, once freely distributed, can be downloaded, modified, and redistributed by anyone. Once released, the original producer loses control over its use. How do you hold them accountable for uses they didn’t anticipate and cannot control?
The analogy with firearms is tempting and imperfect: a gun manufacturer isn’t responsible for every crime committed with that gun. But the producer of an AI model who ignored documented risks of malicious use could be—under the AI Act’s interpretation—in the zone of liability.
The practical response from major open-weight model producers has been extensive documentation—model cards, usage policies, published risk assessments—that serve both compliance and legal defence purposes. It’s useful bureaucracy, but bureaucracy nonetheless.
The question the AI Act hasn’t satisfactorily answered is: What happens to small projects, academic researchers, and independent developers who want to experiment with models? Documentation and assessment obligations are not insurmountable for Google or Meta. They can be insurmountable for a researcher with limited resources at a university in Iași or Cluj.
There’s a risk that the AI Act—like the CRA—involuntarily concentrates the market in favour of large actors who can absorb compliance costs, to the detriment of the very diversity that makes open source valuable.
Billions of Euros: Where They Go and Where They Should Go
Beyond regulation, Europe is acting through industrial policy instruments: the Digital Europe Programme, Horizon Europe, and national co-financing programmes. Billions of euros are being directed towards digital sovereignty, European cloud, and open-source infrastructure.
This is real money. And there are examples of its intelligent use.
The German Sovereign Tech Fund—not European, but German (an important distinction)—has demonstrated that directly funding the maintenance of critical open-source projects is possible and effective. Not through bureaucratic procurement contracts, not through research grants with academic deliverables, but through direct payments for maintenance work—security patches, documentation, compatibility, testing. Invisible and essential work.
The German model deserves to be scaled up to the European level. OpenForum Europe has proposed a European Sovereign Tech Fund of €350 million over seven years. It hasn’t materialised yet. There are proposals, feasibility studies, and statements of intent.
Meanwhile, the European open-source ecosystem remains dependent on volunteerism and American funding—the Linux Foundation, OpenSSF, and Apache Foundation are based in the United States and are primarily funded by American companies. Europe massively benefits from this infrastructure without proportionally contributing to its upkeep.
There’s something awkward about this position: Europe wants digital sovereignty, built on an open-source foundation that is, to a significant extent, American. And it resists investing in the maintenance of that foundation at the level it benefits from it.
It’s a contradiction Brussels hasn’t resolved—and one it won’t resolve through declarations alone.
OSI and the Community: Negotiating a New Contract
The Open Source Initiative (OSI)—the traditional guardian of the open-source definition—finds itself in 2026 in the middle of the most difficult negotiation in its history.
On one side: governments and standardisation bodies demand accountability, transparency, and compliance mechanisms. “If our critical infrastructure runs on your software, we want guarantees.”
On the other side: the open-source community, built on values of freedom, volunteerism, and benevolent contribution, resists any externally imposed legal liability. “We built this out of conviction, not a contract. We’re not signing an SLA with the German government.”
The tension has no elegant resolution. And I try to understand it from both sides, because both are partially right.
The open-source community built the digital infrastructure of the modern world. It did so without asking for permission, without negotiating terms, without waiting for any government to declare it a good idea. It built because it wanted to. And it worked—with all its vulnerabilities, abandoned projects, and incidents—better than any alternative.
The governments and organisations now demanding formal accountability are, to a significant extent, the same ones that benefited from this infrastructure without contributing to it. There’s something irritating about compliance demands from actors who didn’t lift a finger to financially support the ecosystem they now want to regulate.
And yet: Critical infrastructure cannot function without clear accountability. If a hospital in Romania is compromised because it was using a vulnerable version of an abandoned npm package, someone must be liable. Not the volunteer who wrote the code ten years ago. But someone.
The answer to this problem doesn’t yet exist in final form. It’s being negotiated. And the negotiation will take time.
Romania — The Witness That Can’t Afford to Remain a Witness
Our Structural Position
Romania is not a player in the global debate on open-source security and digital sovereignty. At best, we are a recipient of decisions made elsewhere. The CRA was negotiated without significant Romanian contribution. The AI Act was shaped by the interests of Europe’s major economies—Germany, France, Italy. European digital sovereignty funds will be absorbed predominantly by states with the institutional capacity to build eligible projects.
This isn’t a complaint. It’s an observation about the structure of power in the EU, which largely corresponds to the economic structure. Small states with peripheral economies have less access to rule-making processes, regardless of the formal mechanisms of European democracy.
But there’s an important distinction between being a passive witness and an active witness. Romania can be a witness to Europe’s digital transformation—or it can be a participant in it. The difference doesn’t come from the ability to influence Brussels regulations—that’s limited. It comes from the ability to build internal competence that leverages what the regulations create.
What the CRA Creates for Romania
The CRA will become fully applicable in December 2027. From September 2026, vulnerability reporting requirements are active. That means that, in less than a year from the publication of this article, organisations in Romania that produce or distribute digital products will need to report actively exploited vulnerabilities to ENISA (the European Union Agency for Cybersecurity) and the National Cybersecurity Directorate (DNSC).
The direct consequence for Romania’s software market is the creation of demand for services that few currently provide:
- CRA-compliant security audits,
- SBOM (Software Bill of Materials) implementation consulting,
- Vulnerability reporting process support,
- Open-source dependency risk assessment.
There’s a real market opportunity here. Not huge—Romania won’t become the European hub of cybersecurity compliance overnight. But significant for companies and professionals who position themselves now.
I’ve seen this in my own practice. Institutional clients—town halls, schools, hospitals—will face increasing compliance pressure. Not because they necessarily understand the CRA in detail, but because European funding will start requiring evidence of digital security due diligence. Those who cannot demonstrate responsible dependency management will no longer be eligible for certain funding programmes.
This is the mechanism by which European regulations drive change in member states: not through direct coercion, but through conditionalities attached to access to funds.
The Incidents I Managed: A Pedagogy of the Concrete
I want to be specific—within the limits of client confidentiality—about the types of incidents I managed in 2025–2026. Not because they’re unusual—they’re not. But because they concretely illustrate what systemic vulnerability means for small organisations in Romania.
Type 1: Vulnerable, Outdated Template. A Joomla site with a 2023 template, unupdated, exploitable through a public vulnerability. The attacker injected spam content and used the server to distribute malware. The client didn’t know the template had versions. Didn’t know versions had vulnerabilities. Didn’t know vulnerabilities were public and actively exploited by automated scripts.
Type 2: Abandoned Plugin. A content editor with a critical vulnerability (CVSS 10.0) in a version used on multiple sites of institutional clients. The vulnerability was publicly reported; a patch was available. The clients hadn’t applied the patch because they had no process for monitoring updates. Not because they didn’t care—but because they lacked the institutional capacity to track hundreds of software components simultaneously.
Type 3: Compromised Credentials Through Reuse. Identical passwords used across multiple platforms, one of which was compromised in an external breach. The attacker used the credentials to gain access to the admin panel and replaced the content with phishing pages.
None of these incidents were sophisticated. None required serious attacker resources. All were the result of missing basic practices: inventorying, monitoring, systematic updating, password policies.
And all occurred in organisations that processed citizens’ personal data, under GDPR legislation that should have enforced these very basic practices.
The disconnect between existing legal requirements and their actual implementation in small and medium-sized organisations in Romania is itself a subject worthy of separate analysis. I’ll just note that it exists.
DNSC and the National Response Infrastructure
Romania’s National Cybersecurity Directorate (DNSC) has significantly evolved in capacity in recent years. I’ve interacted with them in incident reporting processes, and I can say there’s real technical competence and a desire for constructive engagement.
But DNSC operates with resources disproportionate to the scale of the problem it must manage. The number of reported incidents is growing. Romania’s digital attack surface—with thousands of institutional websites, e-government systems at various maturity levels, and critical infrastructure connected to public networks—is vast.
And there’s a structural paradox: the organisations that most need cybersecurity support—small town halls, schools, hospitals in medium-sized cities—are exactly those with the least access to specialised resources and the least time to interact with the supervisory authority.
The CRA will create reporting obligations for some of these organisations. The obligations will generate reports. The reports will consume resources. But if there’s no real remediation capacity—if reporting isn’t followed by concrete support in resolving vulnerabilities—then reporting becomes a compliance ritual that consumes time without producing security.
What We Should Do and What We’ll Probably Do
I’m a tempered optimist. I’ve seen enough institutional failures and enough unexpected successes not to make categorical predictions.
What should happen:
- A national policy that explicitly treats open-source software as critical infrastructure, with real budgetary consequences. Not an 80-page strategy published on a ministry’s website and forgotten in three months. An operational decision: inventory the open-source dependencies of central public systems, identify critical risks, allocate resources for remediation.
- A funding programme for small organisations—town halls, schools, hospitals—for basic cybersecurity consultation and implementation. Not hundreds of thousands of euros per organisation. Packages of €5,000–15,000 for audits, remediation, and training. Multiplied by thousands of organisations, it’s a serious programme. Financable from available European funds.
- An active presence in European negotiations on the implementation of the CRA, AI Act, and digital sovereignty funds. Not to block regulations—which, on balance, are beneficial—but to shape implementation guidelines so they’re accessible to small organisations in states with limited administrative capacity.
What probably will happen:
A series of visible incidents—a compromise of an important government system, a large-scale personal data breach that makes mainstream news—will generate enough political pressure for a few reactive measures. They’ll be solemnly announced, partially implemented, and superficially evaluated.
In the meantime, individual practitioners—consultants, small agencies, IT professionals in organisations without dedicated departments—will continue to manage the crisis from one incident to the next, with inadequate resources and without an institutional framework to support them.
And in a few years, someone will write a report about how much Romania has progressed in cybersecurity compared to a benchmark from ten years ago, ignoring that the benchmark itself has shifted and that the gap with states with serious policies has grown in absolute terms.
This isn’t cynicism. It’s pattern recognition, based on years of observing how Romanian institutions process systemic problems.
The Infrastructure That Doesn’t Ask for Permission
The Title Explained
I chose the title “The Infrastructure That Doesn’t Ask for Permission” because it describes something essential about the nature of open source as a political and cultural phenomenon, not just a technical one.
Open source didn’t emerge because governments funded it. It didn’t grow because corporations planned it. It didn’t become the critical infrastructure of the internet because it won a public tender or signed a contract with the state.
It emerged because people—thousands, tens of thousands, hundreds of thousands over decades—decided it was worth building things that could be used, modified, and redistributed freely. Without asking anyone for permission.
There’s something in this attitude that’s profoundly at odds with normal institutional logic—which starts from authorisation, from contracts, from hierarchy. Open source starts from direct construction. It doesn’t ask you for permission to contribute. It doesn’t ask for external legitimisation to publish code. You build, you publish, and if it’s useful, others adopt it.
It’s a form of political action that operates at the level of infrastructure, not declarations. It doesn’t say, “There should be an alternative to proprietary software.” It builds the alternative.
The Romanian philosopher Emil Cioran spoke of “intru”—the preposition that describes the depth of commitment to an idea, a form, a vocation. The open-source contributors who built Linux, Apache, Python, PostgreSQL, OpenSSL—those who built the foundations on which the internet runs—acted “intru” something. Not for immediate profit, not for recognition, but from a vision of how things should be.
I don’t have that grandeur in my daily practice. I manage websites for small town halls, resolve security incidents for clinics and schools, and write Joomla plugins for specific needs. But I feel part of the same impulse: that digital infrastructure should be open, auditable, and controllable by those who use it.
Why Regulation Is Neither the Enemy Nor the Saviour
There’s a temptation in technical communities to view any regulation as an attack on the freedom to build. The CRA and AI Act have triggered such reactions—not entirely unjustified, but incomplete.
Regulation that imposes liability for vulnerabilities in commercially distributed software isn’t, in principle, bad. The buyer of a car has the right to assume the vehicle has no manufacturing defects that will kill them. Why shouldn’t the buyer of a software product—or, more importantly, the citizen whose data is managed by that software—have a similar right?
The problem isn’t the principle of accountability. The problem is calibration—who is responsible, for what, under what conditions, with what remediation mechanisms. And here, the first versions of the CRA got it wrong, over-extending responsibility into areas where it wasn’t feasible or fair.
The final version is better. But it’s not perfect. And implementation will generate conflicts the regulation text doesn’t resolve.
What I want to say is that the relationship between the open-source community and European regulators doesn’t have to be one of hostility. It can be—and should be—one of ongoing negotiation, where the community brings expertise and regulators bring democratic legitimacy and enforcement capacity.
Europe wants to build digital sovereignty. It can’t do it without open source. Open source can’t become sustainably critical infrastructure without a framework of accountability and funding. The interests are convergent—even if the negotiation over means is often contentious.
What Digital Sovereignty Means for a Professional in Botoșani
I’ll end with a personal perspective, because that’s what this platform demands.
Digital sovereignty, as discussed in Brussels reports and Berlin policy conferences, sounds abstract. It’s an important concept—and I understand it, and I support it as a direction for European public policy.
But digital sovereignty has real meaning for me not in reports, but in the concrete decisions I make for my clients.
When I recommend an open-source solution to an institutional client instead of an American SaaS product, I’m making a sovereignty choice. Not because open-source software is always technically superior—sometimes it isn’t. But because it gives the client control: they can audit the code, switch hosting providers, modify features, or migrate to another system without being dependent on the availability of an external service they don’t control.
When I build a vulnerability policy for a client and explain why they need an SBOM (Software Bill of Materials), I’m teaching sovereignty. I’m helping them understand that the software they use isn’t a black box they bought and use—it’s a complex infrastructure with dependencies and risks they must actively manage.
When I report an incident to DNSC and document vulnerabilities for the public database, I contribute to the national cybersecurity infrastructure. Not spectacularly. Not with big resources. But concretely.
Digital sovereignty isn’t built in Brussels. It’s built in thousands of daily decisions by thousands of practitioners across Europe who choose—day by day—open infrastructure over closed, responsibility over convenience, knowledge over comfortable ignorance.
My mechanic father knew that a good engine is one you understand—one you can open, inspect, and repair. Not one you’re told “just works” and have to take to an authorised service every time it breaks.
The same principle applies to digital infrastructure.
Know your infrastructure. Open it. Understand it. Fix it yourself when you can.
That’s sovereignty—not a public policy document, but a competence and an attitude.
And that’s what open source makes possible, in 2026 as in 1996: infrastructure that doesn’t ask permission to exist, to be repaired, or to be passed on.
Conclusion: Three Things We Know and One We Don’t
We know that the security of the open-source ecosystem can no longer rely solely on pure voluntarism. The 2025 incidents proved it definitively, and the ecosystem’s response—npm v12, Rust in critical projects, OpenSSF as an active institution—confirms the message has been absorbed.
We know that Europe needs digital sovereignty and that open source is the component without which sovereignty isn’t possible. The CRA and AI Act are imperfect instruments moving in the right direction.
We know that Romania needs to move from being a witness to an active participant in this transformation—and that there’s a window of opportunity, opened by European funds and growing demand for security and compliance skills, that won’t stay open forever.
What we don’t know is whether Romanian institutions—public and private—have the capacity to leverage this window before it closes.
The answer to this question doesn’t come from a report or a public policy. It comes from the decisions made, day by day, by practitioners, managers, decision-makers, and digital citizens in Romania.
Every decision to adopt an auditable solution over an opaque one.
Every decision to update a vulnerable dependency instead of ignoring it.
Every decision to invest in security skills rather than hoping the incident won’t come.
The infrastructure that doesn’t ask permission to exist can be built by anyone who chooses to build it.
The choice is ours.
Selected Bibliography
Security Incidents and Context
- npm v12 — Security Redesign Announcement — npm Blog, July 2026. Default disabling of installation scripts, the most significant security redesign in npm’s 16-year history.
- Miasma Campaign / Phantom Gyp — Legit Security, Pinggy, Rescana (June–July 2026). 57 compromised packages, 286 malicious versions, binding.gyp mechanism.
- XZ Utils Supply-Chain Attack (CVE-2024-3094) — Ars Technica, OpenWall, GitHub Advisory. Two-year attack, discovered accidentally.
- Heartbleed (CVE-2014-0160) and Log4Shell (CVE-2021-44228) — Historical references for the recurring pattern of vulnerabilities in underfunded open-source infrastructure.
- OpenSSF Scorecard and SLSA Framework — openssf.org. Supply-chain security standards, public scoring for projects.
European Regulations
- Cyber Resilience Act — Regulation (EU) 2024/2847 — Official text, EU Official Journal. Reporting requirements applicable from 11 September 2026, full enforcement December 2027.
- EU Cyber Resilience Act — Open Regulatory Compliance Working Group — orcwg.org. Practical implementation guide, OSS steward category.
- What the EU’s new software legislation means for developers — GitHub Blog, December 2024. Impact of CRA on the open-source community, negotiation history.
- AI Act — Regulation (EU) 2024/1689 — Official text. GPAI model obligations, risk categories, transparency requirements.
- EU Open Source Strategy 2026 — European Commission. digital-strategy.ec.europa.eu.
Funding and Sovereignty
- German Sovereign Tech Fund — 2022–2025 Report — sovereigntechfund.de. €23+ million in 60+ projects, European reference model.
- We need a European Sovereign Tech Fund — OpenForum Europe feasibility study + GitHub Blog, 2025. Proposal for €350 million / 7 years.
- Digital sovereignty at the UN — ZDNet, June 2026. UN Open Source Week, open source as national infrastructure.
- Open Infrastructure is Not Free — Joint statement by OpenSSF, Python Software Foundation, Eclipse, Rust Foundation, September 2025.
Romanian Context and DNSC
- DNSC — Incident Reports 2025–2026 — dnsc.ro. Aggregated data on cyber incidents reported in Romania.
- NIS2 Directive — Transposition into Romanian Legislation — Requirements for essential service operators and digital service providers.
- CVE-2026-49049 (Helix3), CVE-2026-21628 (Astroid Framework, CVSS 10.0), CVE-2026-48907 (JCE Editor, CVSS 10.0) — Vulnerabilities managed in own practice, documented in DNSC reports.
Petru Cojocaru is the founder of ABSOLUT WEB EXPERT SRL, a web agency in Botoșani specialising in digital presence, cybersecurity compliance, and content strategy for public institutions and private companies. He writes about digital freedom, technological sovereignty, and real-world cybersecurity practice.
AI Transparency Note: This article was written with the assistance of Claude (Anthropic). All judgments, positions, and perspectives belong to the author. References to incidents from my own practice are real but anonymised to protect client confidentiality.