For as long as most Java developers can remember, we’ve lived inside a comforting story about our ecosystem. It’s the idea that Maven Central, the Jakarta stack, the Spring universe, the vast Apache landscape, and all the independent libraries quietly carrying enterprise workloads together form a coherent, self-maintaining, self-healing whole.
A world where problems are fixed upstream, where maintainers have time, where the dependencies we pull down are being actively watched by someone who knows exactly what they’re doing. It’s a lovely idea. It’s also never been completely real.
When you look beneath the surface of the Java systems that actually matter: the identity platforms, banking engines, warehouse systems, telco backends, and the unglamorous machinery that keeps entire countries functioning, you do not find a perfectly stewarded ecosystem.
You find layer upon layer of libraries written by people who have long since moved on. You find critical infrastructure held together by volunteers whose names, in many cases, no organisation ever bothered to learn. You see the remnants of choices made ten or fifteen years ago that nobody has touched since, except perhaps to shade into an uber-jar out of desperation.
The heady days of open source
What allowed this to work for so long was not the excellence of maintenance but the absence of evil attention. Java projects that stopped receiving commits were rarely considered abandoned; they were called “stable.” Libraries that had not shipped a release since 2014 weren’t suspicious; they were “battle-tested.” And if a maintainer disappeared, well, most of us shrugged and assumed the project was simply complete.
Workarounds became a point of pride. If a dependency misbehaved, we wrapped it, patched it, or quietly forked it and kept the fork inside the company Nexus. Entire generations of Java engineers built careers on strategic glue code.
Nobody worried because the risk felt abstract. Attackers were unknown and, for a long time, looked elsewhere. Regulators were not crawling through JAR files. And the global Java estate, so large it has its own weather systems, continued to grow atop a sedimentary stack of frameworks and utilities whose maintainers never expected to be supporting today’s planet-scale workloads.
And then, of course: Log4Shell
And then Log4Shell happened, and the illusion evaporated.
The moment Log4j broke the news cycle, every Java developer on the planet was forced to confront the reality of our ecosystem. A logging library that most of us took entirely for granted was embedded in everything from Hadoop clusters and Spark jobs to Spring Boot microservices, Kafka pipelines, industrial systems, and ancient J2EE deployments. The vulnerability wasn’t shocking because it was complicated. It was surprising because almost the entire Java universe depended on a library maintained by a small number of volunteers with no contractual obligation, no SLA, no enterprise support desk, no hotline, and ultimately no responsibility to fix anything.
The maintainers were generous enough to fix it anyway. But the episode revealed a truth many organisations had quietly ignored: open source is given to us without warranty, without guarantees, and without any promise that it will be maintained at the pace the modern world demands. All responsibility lies with the consumer, not the creator. That’s what the licences tell us, even if we choose not to read them that way.
Bad Actors upped their game.
Log4Shell wasn’t the first sign. Heartbleed had already shown the pattern years earlier, but that happened outside the Java ecosystem, so many teams treated it as someone else’s problem. Log4Shell made that impossible. It showed us that we had built our entire world on the assumption that upstream would always be there when needed. It turned out that upstream had lives, jobs, families, and limited time.
While this was happening, attackers were quietly becoming more methodical. They began analysing ecosystems the way Java conference talks had been urging us to for years. They discovered that most Java libraries have one active maintainer. They found that many packages pulled billions of times from Maven Central exhibit signs of abandonment. They mapped dependency graphs with the same thoroughness that SCA tools do, except with a different outcome in mind. What we had long treated as dusty corners of the build became bright red targets.
Government Responds
Regulators were watching this unfold with growing clarity. Contrary to widespread complaints, laws like the EU Cyber Resilience Act weren’t written out of ignorance; they were written with a painfully accurate understanding of the ecosystem. They recognised that modern software (Java, especially) relies almost entirely on open source. They understood that organisations routinely ship products they cannot patch because they have no control over the libraries within them. And they understood that “free” had accidentally come to mean “unregulated,” “unsupported,” and “everyone else’s problem.”
Their response wasn’t intended to kill open source. It was designed to make organisations take responsibility for what they consume and/or ship. Anyone building software at scale knows the real ratio: only about ten per cent of most enterprise Java systems is written in-house. The rest comes from libraries, frameworks, platforms, and transitive dependencies.
Without open source, most Java applications would cost ten times as much to build. Regulators looked at that equation and concluded, quite reasonably, that if industry depends on this ecosystem, then industry (not volunteer maintainers) must be accountable for it.
Legislative Penalties
The EU Cyber Resilience Act, for example, requires software vendors to provide a Software Bill of Materials (a complete inventory of what you ship) and to maintain a vulnerability-handling process that actually works. The CRA effectively imposes a duty of care over every component in your stack. If a vulnerability appears, you’re expected to address it within a reasonable timeframe. You are also expected to demonstrate that you develop software in accordance with secure development practices and to ensure that everything you ship can receive security updates for years after release.
NIS2 goes even further by tying executive responsibility directly to the security and resilience of digital infrastructure. Its reporting obligations require logging, monitoring, and transparency across the entire supply chain. And when you read the official ENISA mapping documents, you see a clear expectation that organisations must understand the security posture of their dependencies, not just their own code.
In the US, Executive Order 14028 and the NIST Secure Software Development Framework set their own expectations: signed artefacts, rigorous provenance checks, tamper-evident builds, and SBOMs that include the NIST-defined minimum elements. These aren’t suggestions; they are procurement requirements. If you want to sell software into specific sectors, you must demonstrate that you can maintain the entire stack. Including the parts you didn’t write.
The EU AI Act pushes the boundary even further by requiring traceability not only of code, but of the training data and model lineage behind AI systems. In other words, the software supply chain now extends all the way into the internals of machine learning models. If a model or framework is built on an unmaintained dependency, the regulatory view is brutally simple: it is non-compliant by default.
The new world of open source
SCA tools, Vulnerability scanners, and SBOMs are no longer optional. Provenance and signing requirements are no longer nice-to-haves; they are now requirements. Vulnerability handling obligations moved from “should” to “must.” And enforcement became real rather than theoretical. Fines now reach into the millions. Executive liability is no longer a distant worry but a written clause. “We didn’t know” no longer helps anyone. “Upstream didn’t fix it” doesn’t help at all.
This hits hardest in the long tail of open source: the small libraries created by talented individuals who never intended to become critical components. These projects rarely receive funding. Their maintainers often have other jobs. Their release cadence is aligned to personal life, not enterprise timelines. They owe the world nothing more than what they have already given.
New Commercial Realities
That belief collapses immediately under regulatory scrutiny. The familiar strategy of forking a library internally, long celebrated as a sign of engineering maturity, now drags an organisation into a churn of legal review, security scanning exceptions, compliance audits, procurement headaches, and provenance complications that frequently outweigh the cost of the patch itself. A one-line fix carried as a new artefact becomes a new identity, with all the obligations that come with new software.
Meanwhile, the common reassurance that “upstream might fix it eventually” is no longer viable. Upstream might fix it, or upstream might be on holiday, or upstream might have changed careers, or upstream might have no interest at all in dealing with somebody else’s production deadline. We built a global industry on top of these rhythms, and only now are we confronting what that actually means.
Add AI to the mix
Then came AI, and everything accelerated again.
AI coding tools understand the Java ecosystem only as it appeared in their training data, not as it exists today. They do not know which libraries are maintained. They do not know which examples are outdated. They do not know that Java moved on from specific patterns, nor that certain frameworks should not be revived from the depths of Maven Central. They simply reflect what was common. And because older code is often more abundant, AI gently amplifies the past, including insecure idioms and long-abandoned libraries. It doesn’t do this maliciously. It does it because it cannot tell the difference between good Java and archaeological Java. It has no connection to vulnerability databases or project activity logs. It predicts, rather than understands.
The Penny Drops
This is the moment we realise that the centre of all this isn’t innovation. It is maintenance.
Maintenance is the unglamorous foundation of modern Java development, and it has always been economically fragile. The world was built on software nobody paid for, and we are now paying for that decision through outages, incidents, forced migrations, emergency rewrites, and compliance demands. The cost of modernisation projects is evidence enough. The number of failed rewrites is further proof. Security debt and technical debt have fused into something heavier and more consequential: existential debt.
As a result, the Java ecosystem is shifting. Many organisations are moving towards curated internal repositories in which dependencies are treated as approved financial assets. Others are adopting verified component catalogues that restrict development to a smaller, safer universe of libraries. Foundations and ecosystem groups are increasing investment in auditing and supporting critical projects. All of these are positive developments. But they do not solve the final, most stubborn problem.
Fines under the CRA can reach up to 15 million euros. NIS2 stretches into the millions as well and carries personal liability for executives. “We didn’t know” is no longer a defence. “Upstream didn’t fix it” is no longer an excuse.
The laws do not assume open source is perfectly maintained. They think the opposite. And they are now beginning to force organisations to plan accordingly.
The long tail remains.
Those forgotten Java libraries. Those abandoned frameworks. The components that quietly keep systems running even though their maintainers have long since left the scene. These are now more valuable to attackers than they ever were to their creators.
This is where extended maintenance becomes not a product category but a reality of the world we now inhabit. Some organisations will choose commercial providers. Some will build internal stewardship teams. Some will rely on foundations. The shape doesn’t matter. The acknowledgement does. We can no longer allow a dependency to become nobody’s responsibility.
We have left behind the era when “it still works” was enough. We have left behind the era when “upstream might fix it” was a comfortable bet. And we are rapidly leaving behind the era when “we can always fork it” is a viable path.
Conclusion
What we have now is a recognition that maintenance is not a courtesy, but a legal requirement, an operational necessity, and a strategic function. The Java supply chain we actually have is older, more fragile, and more interconnected than anyone wanted to admit. But seeing it clearly is not a sign of decline. It is the first step toward resilience.
Because at the bottom of every CVE, every emergency patch cycle, every regulator’s expectation, every SCA alert, lies a truth so simple it should never have been ignored:
You cannot secure what nobody maintains. And now, finally, the world understands why.
Reference Table
GitHub Maintainer Statistics
https://octoverse.github.com/2022/repositories/
CHAOSS Bus Factor Research
https://chaoss.community/metrics/
Sonatype State of the Software Supply Chain Report
https://www.sonatype.com/state-of-the-software-supply-chain
European Union Legislation
| Legislation | Claim Backed Up | Official Link / Key Resource |
| Cyber Resilience Act (CRA) | Requires SBOMs, vulnerability handling, duty of care, long-term security updates, and imposes fines up to €15 million. | Official Text (Regulation (EU) 2024/2847) (This is the final published regulation.) |
| NIS2 Directive | Ties executive responsibility to resilience, mandates risk management measures (including supply chain security), and requires incident reporting. | Official Text (Directive (EU) 2022/2555) (See Article 21 for cybersecurity risk-management measures, including supply chain security, and Article 33 on penalties and executive liability.) |
| EU AI Act | Requires traceability not only of code but of training data and model lineage, extending the supply chain concept. | The EU AI Act’s final text is extensive, but the most relevant links would be to the adopted version: Final EU AI Act Text (This link provides context for the legislative process leading to the final Act.) |
United States Requirements
| Mandate | Claim Backed Up | Official Link / Key Resource |
| Executive Order 14028 (Improving the Nation’s Cybersecurity) | Mandates baseline security standards, rigorous provenance checks, signed artifacts, and the use of the NIST SSDF for software sold to the US government. | Executive Order 14028: Improving the Nation’s Cybersecurity |
| NIST Secure Software Development Framework (SSDF) | Defines practices for secure development, which is required for compliance with EO 14028 procurement rules. | NIST SP 800-218 (SSDF) Version 1.1 (This PDF details the framework and its practices.) |
| NIST Software Bill of Materials (SBOM) | Defines the “NIST-defined minimum elements” for SBOMs required by US procurement rules. | NIST Guidance on the Minimum Elements for a Software Bill of Materials (SBOM) |
