Is your Java application actually secure, or does it just look that way? In this episode of the Foojay Podcast, Frank is joined by Steve Poole and David Welch, both from HeroDevs, to dig deep into the state of Java security in 2025 and beyond.

Steve introduces the concept of zombie dependencies: end-of-life libraries that appear safely dormant but are quietly accumulating vulnerabilities waiting to bite you. David, a co-chair of the CVE Automation Working Group, explains what a CVE actually is, how the identification and disclosure process works in practice, and why AI tools like Mythos are dramatically accelerating the pace at which new vulnerabilities are found — on both sides of the wall.

Together they cover how CVEs in the Java runtime are handled through coordinated disclosure, why Maven Central is safer than most ecosystems but not a silver bullet, and what insurance companies are starting to demand from organizations that haven't cleaned up their dependency trees. They also discuss practical steps any Java developer can take today, from generating an SBOM and running Snyk or Trivy, to adopting OpenRewrite and Renovate in your pipelines, and why vibe coding with AI tools may be quietly making your security posture worse if you are not reviewing the dependency choices being made for you.

An animated, occasionally alarming, and ultimately optimistic conversation about a problem the Java community is well-positioned to lead on.

YouTube

Podcast Apps

You can listen and subscribe to the Foojay Podcast on:

• Spotify
• Apple Podcasts
• And most others...

Guests

Steve Poole

• LinkedIn
• Foojay Author profile
• Crossing the River Styx: Spring Boot 3.5 and the Zombie Dependency Problem
• Why Java Developers Over-Trust AI Suggestions

David Welch

• LinkedIn

Content

00:00 Introduction of topics and guests
04:00 What are Zombie dependencies?
05:36 What are CVEs?
11:39 How Mythos and other AI tools are influencing the CVE reporting process
16:53 How CVEs in the Java runtime are handled
21:30 How the industry is looking at the increased security threats
30:17 Developers need to make better decisions "the first time" and use the right tools
31:42 Keep your OS, JVM, and dependencies up-to-date! Insurance companies will force you...
44:48 How "safe" is Maven Central compared to other repository systems
50:48 What you can do as a Java developer to make your apps safer
59:01 Should we be scared for the following years and be careful with vibe coding?
01:04:27 Conclusion

The post Foojay Podcast #95: Is Your Java App Actually Secure, Or Does It Just Look That Way? appeared first on foojay.

Tomorrow I start (o so early) for JCON Europe in Cologne and then, at the tail end of the week, go to Devoxx France to give more talks. If you're at either, come say hi. Herodevs has a booth at both.

After digging into the CVE stories behind Tomcat 8.5's end of life, I turned my attention to Spring Boot 3.5. Same question, different framework: what actually happens to your security posture when a project crosses the EOL line?

The CVE Blind Spot

Most of us understand the idea of a CVE. A vulnerability gets discovered, reported, assigned a severity score, and patched. We run our scanners, check our dashboards, update our dependencies. The system works.

Except it doesn't. Not after 'End Of Life'.

It seems we all have a collective blind spot about where CVEs come from. We think about the output: the advisory, the patch, the scanner alert. We rarely think about the process or the people who do this work. Who finds vulnerabilities? Who reports them? Who assigns the CVE identifier?

And critically: what happens to that pipeline when a project reaches end of life?

The answer is that it dries up. Not all at once. Not even dramatically. It just... stops.

The River Styx

Think of moving from active development and maintenance into EOL mode as crossing the River Styx. On the living side, you have maintainers actively looking at the code. Security researchers submitting reports. A CNA (CVE Numbering Authority) assigning identifiers. A disclosure process that, for all its flaws, at least functions.

On the other side? Silence.

The vulnerabilities don't stop existing. The code doesn't magically become secure because nobody's maintaining it. What stops is the reporting. Researchers move their attention to supported versions. Maintainers stop triaging issues against the older branch. Fewer reports reach the CNA. Fewer identifiers get assigned for a codebase nobody's going to patch.

Those on the living, active side know about problems downstream. They can see the vulnerable patterns in the dead code. But they tell no one in any readily discoverable way. There's no obligation to, and no mechanism for it. They don't report the problem because they have no intention of fixing it.

That's been the model forever.

It's actually amazing that any of the problems are fixed at all. I'm certainly not pointing fingers at anyone to say that the way this has worked before was wrong. I'm always grateful to the people who develop and share their creations. Open Source is, well, amazing, and our developer lives would be immeasurably worse off without it.

The Rules Changed. The Habits Didn't.

However, the world has changed and open source is being weaponised against us. Our old certainties are being destroyed, diluted, compromised in the face of the relentless army of bad actors. When once it was ok to accept that EOL meant 'stable' and meant nothing-to-see-here-move-on, well now that's not true.

The maintainers' muscle memory says that not reporting a CVE against an EOL stream is the right thing to do (because they have no intention of fixing it). That muscle memory now works against us.

The bad actors? They see everything...

They watch the CVEs reported on maintained streams, take the juicy ones, and try them against the older EOL streams.

And voilà: a compromise that the maintainers are conceptually aware of but that's not in any CVE database. A free ride for the bad actors.

What This Looks Like in Practice

A vulnerability exists in both the supported and the EOL branch. On the supported side, a researcher finds it, reports it, gets a CVE assigned, ships a patch.

On the EOL side? The same vulnerability sits in the same code. But fewer researchers are looking. Fewer reports get filed. The vulnerability doesn't appear in your scanner results. Not because it doesn't exist, but because nobody filed the paperwork.

When Dependencies Become Zombies

Pretty quickly the public CVE count against an EOL project drops. If you're lucky, it's because there are none to be found. The codebase is what we'd traditionally call stable. But it's more likely the software didn't get safer. All that happened was the system that records the problems wound down.

Nobody, to my knowledge, has done a rigorous study of this effect. But ask anyone who works in open-source security support. It's the pattern they see every time. It's the core reason companies like the one I work for exist.

Your dependencies end up in one of two states: actually stable, or more likely, zombies. Out of support and with hidden CVEs accumulating. Technically present in your stack. Functionally dead from a security standpoint. Slowly deteriorating whilst your scanners give you a green light.

We need to stop thinking silence means stability. It's frequently the opposite.

Spring Boot 3.5: The Next Crossing

Spring Boot 3.5 reaches end of open-source support on June 30, 2026. That's roughly 80 days from now.

When it crosses that line, it doesn't go alone. Spring Framework 6.2, Spring Security, and the entire Spring portfolio lose community patches simultaneously. The CVE reporting pipeline protecting a vast number of Java applications starts winding down for these versions.

We've Seen This Film Before

Spring Boot 2.7 went EOL in November 2023. Since then, multiple CVEs have surfaced for that branch. CVE-2024-38807, for example: a signature spoofing vulnerability in the boot loader. No open-source patches available. Teams still running 2.7 have to find the fix themselves, pay for commercial support, or accept the risk.

And the longer 2.7 sits in EOL, the quieter the CVE stream gets. Not safer. Quieter. Maybe you can hear the sound of dragging feet...

Based on that pattern, it's incredibly unlikely Spring Boot 3.5 won't follow the same trajectory. The transition from stable to zombie isn't a question of "if." It's a question of how fast the reporting pipeline dries up once the maintainers shift focus to 4.0.

The Window Is Open. For Now.

But here's the thing: it doesn't happen overnight. There is time. The zombie transition is gradual, and that window matters.

The quicker you assess the scale of the change from 3.5 to 4.0, the better positioned you'll be. Maybe that means migrating on your own terms. Maybe it means arranging commercial support to bridge the gap, or finding another path entirely. The worst move is to wait until the silence sets in and assume everything is fine.

The Map, Not Just the Landscape

That's the landscape. Now let's talk about the map.

In my recent JDK 8 to 25 review, I started to walk through every major change across seventeen years of Java releases. I map out what teams actually face when they finally modernise. I'm going to do the same for Spring Boot 3.5 to 4.0.

In the coming articles, I'll cover the technical challenges organised by severity. The obvious compilation errors, the runtime failures and hidden behavioural changes that may slip past your test suite. I'll look at the costs, explore the alternatives, and break down what a realistic migration timeline looks like.

The zombie transition is coming for Spring Boot 3.5. The only question is whether you'll be ready for it or surprised by it. If you're at JCON or Devoxx France this week, come find me at the HeroDevs booth. I'd love to swap migration war stories.

Steve Poole is a Java Champion, Oracle ACE and IBM Champion. Also a developer advocate at HeroDevs, and author of the No Regressions newsletter. Find him at the HeroDevs booth at JCON or Devoxx France

The post Crossing the River Styx: Spring Boot 3.5 and the Zombie Dependency Problem appeared first on foojay.

Spring I/O 2026 wrapped in Barcelona on Wednesday. Three days at the Palau de Congressos. A thousand-plus developers, five tracks, sixty sessions (or there abouts) Here are the things I'm still thinking about..

Agents everywhere

It was a Spring AI conference with a Spring Boot conference attached.

That's not a complaint. Count the programme yourself. Across the two main days, roughly a third of the main-track sessions were about Spring AI, MCP, agents, or building on LLMs. Josh Long opened Day 2 at eleven with Bootiful Spring Boot 4. By twelve, the Auditorium had moved on to The Spring AI Ecosystem in 2026: From Foundations to Agents.

A few years ago the headline topics were reactive programming, observability, Kotlin adoption. This year the big rooms belonged to agents. Hallway conversations tracked the programme. Prompts, tool-calling, MCP clients, evaluation harnesses. The classic Java-platform conversations still happened. They were in smaller groups and later in the evening.

Rod Johnson on the road

Rod Johnson gave Building Killer AI Agents on Your Spring Stack with Embabel.

Four days earlier he gave essentially the same pitch to the London Java Community at Tessl. Same message, two cities, one week. When the person who shaped Java enterprise for two decades picks one topic and tours with it, it's worth noticing what that topic is.

Right now that topic is agents and AI, not Spring.

The sessions that didn't get the main stage

Migration content was on the programme if you went looking. Raquel Pau ran a session on Hybrid Modernization, pairing OpenRewrite's precision with LLMs. Moritz Halbritter gave Inside Spring Boot 4: Restructuring for the Future. Tim te Beek and Merlin Bögershausen ran a full workshop on Prepare Your Next Spring Boot Migration. Juergen Hoeller on Core Resilience Features in Spring Framework 7. All worth your time when Spring I/O put the videos up.

A few things from the HeroDevs corner

Two colleagues on the programme. Anthony Dahanne spoke on Paketo Buildpacks: the Spring Boot way to build images, and more! Marcin Grzejszczak followed with From Contracts to Confidence: Spring Cloud Contract 5 in the Age of AI. Watch both when the videos land.

Over at our booth, Wendy ran what I think is the best prize draw of the week: 3D-printed articulated dragons and dragon eggs. If you were at Spring I/O and walked past without picking one up, I'm sorry, but also: what were you doing.

The documentary

One other thing worth flagging. A Spring documentary I appear in released its trailer yesterday. You can watch it on YouTube. I'll say more about it when the full piece drops.

And since the topic is Spring anyway: if you want a five-minute reality check on where your team actually sits on the EOL calendar, we built a quiz and ran it at Spring I/O

15 questions about what changed between Spring 3.5 and 4.0
Turns out most Spring developers are just 'ok' on things like this. Well when I say most - it was about 100 devs @ Spring IO. Next week we're at JCON and Devoxx France so maybe the answers will be different.

What I'm taking home

The Spring ecosystem is in the middle of something bigger than a framework upgrade. The shift from "web framework" to "agent platform" is the story this year and it's going to keep getting louder through the rest of 2026. That's a genuinely interesting place to be standing, if you like being on ground that moves.

I'll write more once the videos are up and I've had time to rewatch the sessions I missed. Barcelona was full of good weather, friends, coffee, conversations, and dragons. What more do you want.

The post Spring I/O 2026: Field Notes from Barcelona appeared first on foojay.

This article is adapted from The Confidence Trap, part of the "2026 Supply Chain Reckoning" series on my No Regressions newsletter.

Your boss calls you on a Friday afternoon. He's read all the available data, he tells you with absolute confidence, and he's decided that migrating from Spring Boot 3.5 to 4.0 will be straightforward. Wants it done over the weekend.

You'd push back. You'd ask which data. You'd point out the breaking changes.

Now replace your boss with Copilot. It suggests a code change: a refactored method, a new dependency, an implementation pattern. The recommendation arrives in that polished, authoritative tone we are all used to. No hedging. No "I'm not sure about this one." Just clean, confident code. Do you review it with the same rigour you'd apply to your boss's claim, or do you accept?

Sonatype's 2026 State of the Software Supply Chain report found that nearly 30% of LLM-generated dependency recommendations reference non-existent package versions. Somewhere between one in three and one in four. And that's just dependencies, the same confidence problem applies to every line of AI-generated code.

So why do we keep accepting it?

Your Brain Is Working Against You

The short answer is psychology. Specifically, something called the fluency heuristic: when information is easy to process, your brain treats it as more likely to be true.

Organisational psychologist Tomas Chamorro-Premuzic demonstrated that there's virtually no relationship between how competent people appear and how competent they actually are. We promote confident leaders over capable ones. We trust the colleague who speaks first and sounds certain, even when the quiet one in the corner has the better answer.

Large language models exploit this wiring perfectly. They produce fluent, structured, confident-sounding output every time. A well-formatted code block feels right. The class names follow conventions. The exception handling looks sensible. Your brain pattern-matches against thousands of similar blocks you've seen before and says: fine, move on.

Psychologists at Carnegie Mellon found that LLMs hallucinated in 69% to 88% of legal queries while maintaining a tone that consistently misled even trained evaluators. The packaging was so good that experts couldn't reliably spot the fakes.

Where Java Developers Are Most Exposed

This isn't an abstract concern. Java's ecosystem has characteristics that make several areas particularly vulnerable to confident-sounding AI output.

Dependencies are easy to hallucinate convincingly. Maven Central is vast and version-dense. An LLM can suggest org.apache.commons:commons-csv when it means org.apache.commons:commons-text, or generate a coordinate like commons-utils that follows the naming convention perfectly but doesn't exist. The patterns are regular enough to hallucinate convincingly. And a one-word difference is all an attacker needs to register a slopsquatted package. Lasso Security found that a single hallucinated package name received over 30,000 genuine downloads in three months.

Transitive dependencies are invisible by default. Your pom.xml might declare a few dozen dependencies. Maven resolves hundreds. An AI suggesting a top-level change has no visibility into what that cascades through your transitive tree. It can't know that upgrading spring-cloud-openfeign pulls in a vulnerable version of commons-fileupload through feign-form. Which is exactly what happened with CVE-2025-48976.

Boilerplate code looks right even when it's wrong. Java's verbosity means a lot of AI-generated code is structural. Configuration classes, Spring annotations, repository patterns, DTO mappings. These follow templates closely enough that an LLM can produce them fluently. But "it compiles and follows the pattern" doesn't mean it's correct. A @Transactional annotation on the wrong method. A SecurityFilterChain that looks complete but leaves an endpoint exposed. An ObjectMapper configuration that silently drops unknown fields. The code reads well. The bugs hide in the semantics, not the syntax.

API usage patterns are plausible but outdated. An LLM trained on older codebases will confidently suggest deprecated APIs, removed methods, or patterns that worked in Java 11 but behave differently in Java 21. It doesn't know your runtime version or your Spring Boot version. Code that compiled fine against last year's stack may not compile against this year's.

Your Toolchain Catches Some of This

If an AI hallucinates a Maven coordinate that doesn't exist, your build fails. mvn compile resolves every dependency against Maven Central. IntelliJ underlines it red before you even run the build. Deprecated API calls get warnings. Type errors fail at compile time.

So the obvious mistakes are caught. Your toolchain handles those.

The harder problems are the ones that pass the build. The dependency that does exist but has a known CVE. The code that compiles but has a subtle security flaw. The pattern that works but creates a performance bottleneck under load. Green tick. No warnings.

For dependencies specifically, that verification gap needs:

• mvn dependency:tree -Dverbose to see what shifted in your transitive tree
• OWASP's dependency-check-maven or tools like Snyk and Sonatype Lifecycle scanning against known vulnerabilities in CI
• `` or Gradle platform constraints to pin transitive versions explicitly

For generated code more broadly: code review with the same rigour you'd apply to a pull request from a stranger. The AI is a contributor you've never worked with before. Its code compiles. Its suggestions are well-formatted. But you have no track record to trust.

Make the Model Show Its Working

Toolchain checks catch problems after the fact. But you can also change how you interact with the model to reduce false confidence at the source. There are habits that can help shift the dynamic. Worth trying, not guaranteed to work. (aka - works for me)

1: Ask it what it doesn't know. Before accepting a suggestion, ask: "What assumptions are you making about my project?" or "What are you uncertain about here?" Hopefully, the model will list the caveats it'd otherwise skip. A model that admits "I don't know your Java version or your Spring Boot version" is being more useful than one that silently guesses.

2: Give it your actual context. The less a model has to infer, the less it fabricates. Don't just say "write a REST controller." Paste your existing code, your pom.xml, your Spring Boot version, your constraints. A model working with real context has far less room to hallucinate.

3: Ask for alternatives and trade-offs. If the model can only suggest one approach, that's a warning flag. Ask: "What other ways could I do this? What are the trade-offs?" Even if the model confidently recommends three mutually contradictory approaches, it's still showing you something useful about where it's guessing.

4: Verify the reasoning, not just the output. Ask "why this approach?" If the answer is vague ("it's best practice") or circular ("it's the recommended pattern"), the model is probably hallucinating. A good recommendation has a specific rationale: compatibility with your stack, a security consideration, a performance characteristic.

5: Treat the first answer as a draft. The human expert heuristic hits hardest on the first pass. The code looks good; it makes sense in your head, and your instinct is to paste it in. Train yourself to treat every AI suggestion as a starting point, not a finished answer.

The Confidence Tax

None of this eliminates the confidence trap. But it shifts the dynamic from a model that delivers and a developer who accepts to a conversation where the model has to justify itself.

This bit is scary - take a moment to see if you're affected. Microsoft surveyed knowledge workers and found that the more they use AI tools, the less critical effort they report applying. The "irony of automation": the tool handles the routine thinking, and in doing so, erodes the very skill you need to catch it when it's wrong!

For developers, this is the real risk. Not that AI will suggest something catastrophically wrong on day one. But that the habit of accepting well-formatted, confident-sounding code without checking will become the default.

The tools are useful. The confidence they project is not earned. Build the habit of checking now, while it still feels unnecessary.

For the full psychology behind the confidence trap, including the research on status-enhancement theory and automation bias, read The Confidence Trap on the No Regressions newsletter.

This article is part of the "2026 Supply Chain Reckoning" series. Read the full series on No Regressions.

Sources

1. Sonatype, 2026 State of the Software Supply Chain — 28% hallucination rate and 345 cases of worsened security from LLM dependency recommendations.

2. Chamorro-Premuzic, T., Why Do So Many Incompetent Men Become Leaders? — the confidence-competence gap in leadership selection.

3. Carnegie Mellon University, AI Chatbots Remain Confident — Even When They're Wrong — 69–88% hallucination rate in legal queries with misleading authoritative tone.

4. Microsoft Research, The Impact of Generative AI on Critical Thinking — documented reductions in independent problem-solving among AI tool users.

The post Why Java Developers Over-Trust AI Suggestions appeared first on foojay.

In the companion article to this one, I looked at the revitalisation of Grails under the Apache Software Foundation: the 18-month migration, the technical modernisation, and the release of Grails 7 as a Top-Level ASF Project. That is the good-news story, and it is a genuinely impressive piece of community engineering.

This article is about the other side of the same coin.

While Grails moves forward, many of the applications built on it cannot move at the same pace. The result is a growing gap between where the framework is heading and where a significant number of production systems actually sit. Understanding that gap, and what options exist for managing it, is what this piece is about.

The inflexion point

The alignment of Grails with modern Spring Boot and Java baselines brings us to a critical inflexion point in 2026. While the framework is being revitalised, the “gravity” of the underlying ecosystem is shifting. Many legacy Grails applications remain tied to versions of Spring Boot and Java that are rapidly approaching or have already reached End of Life.

Where Grails versions stand today

The Apache Grails support schedule tells the story clearly:

• Grails 3 and 4 have reached End of Support.
• Grails 5 ended support in June 2024.
• Grails 6 (the last pre-ASF release, with 6.2.3 shipping in January 2025) reached End of Support in June 2025.
• Grails 7 is in Active Maintenance with support through June 2026
• Grails 7.1 and 8 are in Active Development with Grails 8 maintenance support targeted for December 2026.

That is the Grails layer. Beneath it, the picture gets more complicated.

The Spring Boot gravitational pull

Beneath all of this, the Spring Boot timelines create their own gravitational pull.

Spring Boot follows a six-month release cycle with roughly 13 months of open-source support per release. That sounds generous until you lay the dates out: Spring Boot 3.3 OSS support ended in June 2025. 3.4 ended in December. 3.5 runs until June 2026. Spring Boot 4.0 (released November 2025) has OSS support through December 2026.

For teams still running applications on Spring Boot 2.x, open-source support ended years ago. Only commercial extended support remains available. The window is not slamming shut. It is closing steadily, and each version that falls off the end makes the next upgrade harder.

Taken together, this is less a single deadline and more a slow-moving dependency cliff.

What the risk actually looks like

The primary corporate risk is rarely that these systems suddenly stop working. Mature Grails applications are typically very stable. The real exposure appears more slowly and more quietly, when organisations lose visibility of their dependency health and drift out of a supported posture without fully realising it.

In the Java ecosystem, supply chain health matters far more than announcement-day excitement.

A team running Grails 4 on Spring Boot 2.x and Java 11 does not wake up one morning to a broken application. What they wake up to, eventually, is a CVE that applies to their stack and no upstream patch to apply. Or a compliance audit that flags unsupported components. Or a new integration requirement that demands a Java version their framework cannot support.

The danger is not sudden failure. It is the slow accumulation of exposure that nobody is tracking.

The practical middle ground

In practice, most organisations are not choosing between “upgrade tomorrow” and “do nothing.” Reality is rarely that clean. Portfolio constraints, regulatory timelines, and simple engineering capacity mean many teams need a supported holding pattern while they plan their next move.

Increasingly, this is where commercial continuity support for end-of-life open source is emerging as a pragmatic middle ground. A small but growing number of providers now specialise in keeping critical open source components supported beyond their community end-of-life, giving teams breathing room without forcing rushed or poorly sequenced migrations.

Even the ASF itself acknowledges this reality: the Foundation does not offer commercial support, but it recognises that not everyone can keep pace with upstream release cadences.

Upgrade is an action, not a strategy

The reflex response to EOL exposure is “just upgrade.” And upgrading is, eventually, the right thing to do. But treating it as a strategy rather than an action ignores the complexity of real-world systems.

A Grails 4 application is not merely a Grails application. It is a Spring Boot 2.x application, running on a specific Java version, with a specific set of transitive dependencies, deployed into a specific infrastructure.

Upgrading Grails means upgrading Spring Boot, which means upgrading Java, which means re-validating every integration point, every test suite, every deployment pipeline.

For teams with a single application, that is manageable. For teams with a portfolio of services, some of which were built by people who have since left the organisation, it is a multi-quarter programme of work.

Pretending otherwise does not make the problem smaller. It just makes the plan worse.

What to actually do about it

Know what you’re running

This sounds obvious. It often is not. Fat JARs, shaded dependencies, containers, vendor forks, embedded runtimes: over time, even the teams shipping a system may no longer be certain what is actually inside it. SBOMs are not insight. They are institutional memory. Start there.

Understand your exposure window

Map your Grails and Spring Boot versions against the support schedules. Know which components are still covered, which are approaching EOL, and which have already passed it. This does not require a commercial tool. It requires someone spending a day with a spreadsheet.

Buy time if you need it

If a full upgrade is not feasible in the near term, commercial continuity support for EOL components can keep your systems in a supported posture while you plan. This is not a permanent solution (unless your aiming to retire the app real-soon-now), but it is a pragmatic one for teams that need breathing room.

Commercial EOL support.

If you are currently assessing the support posture of older Grails estates, it is worth understanding the continuity support options available in the Java ecosystem. The landscape has evolved significantly in the past few years.

See here for some ‘official’ offerings

I work for one on that list: HeroDevs (see later for the full disclaimer) ,who provide support for Grails and many other Java and non Java products.

Providing EOL support is not a simple undertaking and requires particular skills and knowledge which I like to believe is something HeroDevs excels at. Visit their website https://herodevs.com

Plan the upgrade as a programme, not a task

If you have multiple Grails applications at different versions, sequence the work. Prioritise by exposure, not by convenience. Treat the dependency cliff as the engineering constraint it is, and fund it accordingly.

Summary

The Grails revitalisation under the ASF is real, and it matters. But it does not retroactively protect the applications that were built on earlier versions of the framework. Those systems need their own plan.

In an industry that celebrates only the new, the work of keeping older systems safe and supported is easy to overlook. It probably should not be.

Resources

Apache Grails Support Schedule
Spring Boot End of Life Dates
Grails 7.0.0 Release Announcement

Author’s note: Full Disclosure

In the interest of transparency: I work for HeroDevs, a company provides extended security support for end-of-life open source components ( including Java ecosystem frameworks ) and funds open source maintainers through its sustainability programme.

Where HeroDevs tools or services are referenced in this article it’s because I truly believe that what they offer is significant and relevant. My views on open source sustainability and EOL risk are formed independently and predate that relationship.

The post Grails Isn’t Done Yet (Part 2): EOL, Spring Boot, and What Comes Next appeared first on foojay.

Steve Poole | With contributions from James Fredley, Apache Grails PMC Chair

For a technology that many people filed under “legacy,” Grails has been unusually active. While much of the industry’s attention has drifted toward newer frameworks and shinier stacks, something more deliberate has been happening in the background.

Grails has been moving into the Apache Software Foundation (ASF), modernising and positioning itself for the next chapter.
If you have not looked at Grails recently, your mental model is likely several years out of date. And that, in many ways, is exactly the problem.

The technology we stop seeing

Software ecosystems rarely end with a bang; most of the time, they simply slip out of focus. Conference agendas move on, blog coverage thins out, and new frameworks capture the narrative. Eventually, we collectively “agree” that a technology is “basically done”.

Except in enterprise environments, that is often not true at all. There are still Grails applications in production, processing transactions and serving customers. But while the systems remain, the organisational spotlight has shifted.

There is a significant gap between what gets hype and what actually runs the web.

According to W3Techs, PHP powers roughly 71.8% of all websites whose server-side language is known. Between 40% and 60% of the web runs on WordPress alone.

JavaScript, for all its conference-circuit dominance, accounts for under 6% on the server side. The technologies that quietly keep the internet running and the ones that dominate the narrative are often not the same technologies at all.

Why the Apache move matters

The transition of Grails into the ASF is not merely administrative tidying. Moving under the ASF umbrella is one of the clearest signals an open-source project can send about its long-term intent.

ASF provides a neutral home, predictable release discipline, and a contributor model that reduces perceived vendor risk.

For Grails, this matters because mature platforms live or die on trust signals. The ASF move changes the risk conversation for organisations evaluating whether Grails still has a place on their servers.

Twenty years of changing hands

The context makes the move even more significant. Grails was primarily led by single organisations for most of its 20-year history: G2One from 2005 to 2008, then SpringSource through 2015, Object Computing through 2021, and the Grails Foundation/Unity Foundation through 2025.

Each transition introduced uncertainty about the project’s direction and sustainability.

The ASF model is designed to break that pattern, replacing single-organisation dependency with volunteer-driven governance, vendor neutrality, and the structured transparency of the Apache Way.

Eighteen months of migration

In October 2025, Grails officially graduated from incubation to become a Top-Level Project at the ASF, following a board vote in September.

That sounds like a single event. It wasn’t. The migration was an 18-month process that began in late spring 2024 with a volunteer team assessing project readiness and submitting an incubation proposal.

What followed was a substantial modernisation effort: merging repositories into a mono-repo, overhauling the build system and dependency management, upgrading Maven coordinates, and issuing releases under ASF governance. The first ASF release (Milestone 4) shipped in June 2025, with the 7.0.0 General Availability release arriving in October.

One hundred repositories become nine

The scale of the repository consolidation tells its own story. Grails originally had around 100 Git repositories, of which 43 were slated for ASF migration. By the time the move was complete, those had been consolidated to 18, with only 9 still in active use.

That is a lot of plumbing.

The mono-repo approach accelerated compliance with ASF policy but required integrating separate build systems and release processes across hundreds of commits.

Over 2,000 commits went into the grails-core mono-repo alone, and build times for a release dropped from over three weeks to approximately 30 minutes.

Read that again. Three weeks to thirty minutes.

Beyond the code: licensing and compliance

The code was only part of it. The team also had to meet ASF security and licensing requirements. Reproducible, verifiable builds were implemented (requiring upstream contributions to dependencies including Apache Groovy).

Every source file was reviewed for licence headers, and 327 separate artefacts were audited for licensing compliance. The team automated licence review by adopting Software Bill of Materials for every published jar, ensuring ongoing compliance with reduced future effort.

Migrating the fully automated Gradle and GitHub Actions workflows proved to be a novel challenge in its own right; other Gradle-based projects at the ASF are now looking at the result as a reference implementation.

The modernisation you might have missed

A significant amount of careful modernisation has been focused on keeping Grails aligned with the moving baseline of the JVM and the Spring ecosystem.

This is not cosmetic: dependencies have been pulled forward, and compatibility with newer Java runtimes has been tightened.

What Grails 7 actually ships

Grails 7.0.0 shipped in October 2025 as the first stable release under ASF stewardship. It brings major dependency upgrades including Java 17+ support (through to Java 25), Groovy 4, Spring Boot 3.5, Spring Framework 6.2, and Jakarta EE 10.

Alongside the platform alignment, the release introduced containerised browser testing via Testcontainers and Geb, optional Micronaut integration, SBOM generation for all published binaries, and reproducible builds and artefacts.

The grails-core mono-repo now produces over 325 published jar files across 109 Gradle projects, with local build times between two and ten minutes depending on caching and hardware.

Grails 8 and the release cadence

Grails 8 development started in late November 2025, tracking Spring Boot 4.0 which reached general availability at the end of that month.

The project now follows Spring Boot’s six-month release cadence, with 13 months of support per release. Giving teams predictable timelines to plan around.

The humans behind the reboot

Open-source projects do not evolve by inertia. They move forward because a relatively small number of people decide the work is worth doing.

One of the challenges Grails faces today is not a lack of activity but a lack of visible narrative.

Much of the effort is concentrated in a tight group of committed maintainers. From the outside, that can appear to be silence even when meaningful progress is underway.

To make that work more visible, I spoke with James Fredley, the Apache Grails PMC Chair, about where the project stands and where it is heading.

What motivated the move to the Apache Software Foundation?

There were real questions about Grails’ future, and they were understandable.

The concerns crept in during the 4.x through 6.x era, when the project moved through several organisations and its direction felt uncertain. For most of its 20-year history, Grails was primarily led by a single organisation at any given time, with limited community contributions or input.

The move to the ASF was about addressing that directly: shifting from single-organisation dependency to a volunteer-driven, vendor-neutral model. The ASF’s structure: the Project Management Committee, mailing lists, consensus-based voting, the incubation process, gives people confidence that the project is sustainable, not dependent on any one company’s priorities.

From inside the project, what kind of technical work has been happening?

The scale of it probably surprises people. Thousands of hours of volunteer time have gone into modernising the 7.x line and building toward 8.x.

We consolidated from around 100 repositories down to 18 (with 9 active), rewrote the build and release pipeline, achieved reproducible and verifiable builds, implemented SBOM generation, and ensured licensing compliance across hundreds of artefacts.

Grails 7 now produces over 325 published jar files across 109 Gradle projects, with local build times between two and ten minutes. The release process itself went from a three-week ordeal to about 30 minutes.

Migrating our fully automated Gradle and GitHub Actions workflows to the ASF was a novel challenge, but grails-core can now serve as a model for other Gradle-based projects joining the Foundation.

What people also need to understand is that a Grails application is a Spring Boot application.

With roughly 85–90% of Java applications running on Spring Boot,Grails is not some exotic outlier: it is extra developer-productivity layers on top of what everyone in the Java ecosystem already uses.

What do you hope the ASF transition unlocks?

Broader adoption and broader contribution. The ASF gives us credibility with enterprise decision-makers who need to know a framework will still be around in five or ten years.

But it also lowers the barrier for new contributors. The governance is transparent, the processes are well-documented, and the project is genuinely welcoming.

Grails now follows Spring Boot’s release cadence: a six-month cycle with 13 months of support, which gives teams predictable timelines to plan around.

What misconception about Grails would you most like to correct?

That it’s a legacy technology for legacy teams.

Grails is still the most productive way to build a web application in the Java ecosystem, and that should be a draw for newer engineers and greenfield projects, not just established estates.

The convention-over-configuration approach means less boilerplate, sensible defaults, and a gentle learning curve.

It is a “framework of frameworks,” built on Spring Boot, Spring Framework, Jakarta EE, and Hibernate.

If you know those, you already know a significant part of Grails.

Where Grails realistically sits in 2026

Grails is not trying to out-Spring Boot Spring Boot. Where it continues to make sense is in environments that value convention-heavy productivity and rapid delivery, particularly where there is already meaningful investment in the Groovy ecosystem.

For teams with established Grails estates, the question isn’t “does it work?” but “is it still safe to stay?”

The ASF graduation, the release of Grails 7 (supporting Java 17 through 25), and the active development of Grails 8 tracking Spring Boot 4 are designed to lower the perceived risk of that decision. But that safety is contingent on moving forward.

For teams evaluating new projects, the productivity argument deserves a fresh hearing. As Fredley puts it, Grails is extra developer-productivity layers on top of what 85–90% of the Java ecosystem already uses. That framing: not “legacy framework” but “productivity accelerator built on Spring Boot”, is a different proposition than the one most people have filed away in their mental models.

The hard work that keeps software alive

Software rarely dies because of a single technical flaw; it fades because attention moves somewhere else.
What the current maintainers are doing is the careful, methodical work required to keep a mature framework viable in a fast-moving ecosystem.

In an industry that celebrates only the new, that kind of work, and the difficult EOL conversations it requires, is easy to overlook.

It probably should not be.

Of course, none of this helps the teams still running Grails 3 or 4 on their servers. For them, the dependency cliff is already here. In part two, I want to look at what that cliff actually looks like and what the options are.

Resources

• Apache Grails Support Schedule
• HeroDevs Grails EOL Support
• Spring Boot End of Life Dates
• HeroDevs Spring Boot EOL Support
• ASF Graduation Announcement
• Grails 7.0.0 Release Announcement
• Introduction to Apache Grails 7 (Community Over Code NA 2025, James Fredley
• Migrating a 20 Year Old Project to the ASF (Community Over Code NA 2025, James Fredley)

Author’s note:

In the interest of transparency, I work for HeroDevs, a company that provides extended support for end-of-life open-source components. If you are currently assessing the support posture of older Grails estates, it is worth understanding the continuity support options available in the Java ecosystem. The landscape has evolved significantly in the past few years.

The post Grails Isn’t Done Yet (Part 1): Inside the ASF Reboot appeared first on foojay.

first, a word about ecosystems

Before we dive into Shai-Hulud, before we label it “sophisticated” or “advanced” or “next generation,” we need to be honest about something.

The worm didn’t appear in a broken system. It appeared in the one we deliberately optimised.

In the book Dune, the worm is integral to the ecosystem. The planet, its environment, and the worms are deeply interconnected.

That's true for the cyber-worm equivalent. The worm is an entirely predictable outcome of the ecosystem in which we, as developers, are part

Speed first.

Modern software development is not primarily about writing code. It is about assembling it. Most production systems today consist of orchestration layers that sit on top of hundreds or thousands of external components.

The majority of what runs in your application was written by someone else. Often years ago. Often maintained by very small teams. Sometimes no longer maintained at all.

And that model works extraordinarily well. It has given us leverage that would have been unimaginable twenty years ago.

Still optimised for speed.

Dependencies install automatically. Pipelines publish automatically. Credentials are injected automatically.

We removed friction wherever possible because it slows delivery. Over time, the practice of executing third-party code during installation became routine rather than risky.

In npm, lifecycle scripts run during dependency resolution. That is not considered unusual behaviour. It is normal build plumbing. Developers run npm install dozens of times a week without consciously registering that they are executing code pulled from the internet.

The same cultural shift happened everywhere. Whether it is curl | bash, brew install, or apt install, installing software has become so common that the execution aspect fades into the background.

Even security warnings feel ornamental. Of course, the file came from the internet. That was the intent.

Meanwhile, we centralised authority in automation. CI systems don’t just build. They publish. They push. They modify repositories. They deploy infrastructure. They do this using tokens that are often long-lived and broadly scoped because tight scoping and aggressive expiry introduce inconvenience.

Automation is trusted precisely because it removes human delay.

This is the architecture we normalised: install-time execution, credential-rich automation, and frictionless publishing, all operating within the same trust boundary.

Once you see that, the worm stops looking exotic.

Open Source Security Doesn’t Work the Way You Think It Does

There’s a deeper problem running underneath this.

A significant portion of widely deployed open-source components sit on branches that no longer receive patches.

Some projects formally declare end of life. Others simply stop maintaining older versions. Security fixes are released in the current major versions without consistently documenting the full historical impact. In many modern components, it is a deliberate choice: older software, even though vulnerable, is often not included in CVE reports.

It's vital to understand that vulnerability databases reflect what is disclosed, not what can be inferred from patch diffs.

Software Composition Analysis tools mostly rely on those databases. If a vulnerability is not formally recorded against your exact version, the tool has no authoritative basis to flag it. “No CVEs found” becomes interpreted as “safe,” even when the branch has effectively stopped receiving security attention.

Attackers can read patches. They can see what changed. They can infer the bug from the fix. Older branches don’t become secure just because a CVE doesn’t list them.

This matters more than people realise.

There is an entire commercial support industry built around keeping end-of-life open source secure, and most developers I speak to don’t even realise that’s an option. The broader reporting gap is even less understood. We assume visibility is complete because dashboards are green. It isn’t.

This situation is so bad, so misunderstood, that the company I work for, HeroDevs, a company that provides support for EOL open source for times like these. Pretty much no one I speak to knows that this is an option. That said, most aren't aware of the broader security reporting situation either.

The Inevitable AI in the Mix

AI Language models suggest dependencies based on prevalence and pattern similarity. They do not reason about support windows. They do not possess privileged vulnerability intelligence. If an older version appears frequently in training data and compiles successfully, it remains attractive. Humans behave in much the same way. If an installation works and triggers no alerts, it is accepted.

We built a system in which execution is invisible, authority is automated, lifecycle awareness is partial, and adoption is increasingly rapid.

In that environment, a registry-native worm is not surprising, other than how long it’s taken to appear.

Enter Shai-Hulud

In September 2025, the npm ecosystem saw what is widely regarded as the first documented self-propagating registry-native worm.

Nobody hacked npm. Nobody broke TLS. There was no exotic zero-day. Attackers phished maintainers and harvested legitimate npm and GitHub tokens. That was enough.

Malicious versions of popular packages such as @ctrl/tinycolor and ngx-bootstrap were published. They contained a payload, typically named bundle.js, that executed via npm lifecycle scripts during installation.

When developers ran npm install, the worm ran automatically.
The script harvested credentials from developer machines and CI environments. It searched for npm authentication tokens, GitHub Personal Access Tokens, and cloud provider keys. Some variants deployed TruffleHog to aggressively scrape secrets.

Then it pivoted.

If it found valid npm tokens, it enumerated other packages owned by the compromised maintainer, injected the malicious payload, incremented the version number, and republished them using authenticated npm publish --force.

The registry accepted those publications because they were authorised.

At that point, the attack moves from “malicious code in a package” and became something fundamentally different.

The stolen credentials were not used solely to push a single malicious version. They were used to infect other legitimate, already-trusted packages owned by the same maintainer.
The worm enumerated the maintainer’s portfolio, injected itself, incremented versions, and republished. The registry itself became the replication medium.

The defining shift.

This was not typosquatting. It was not dependency confusion. It was not a one-off compromised release. It was automated, identity-driven propagation using a legitimate publishing authority. That is what makes Shai-Hulud a worm rather than simply malware in npm.

Across multiple waves, nearly 800 packages were implicated, representing potential exposure in excess of 20 million weekly downloads.

The attack evolved. A later wave shifted execution to the Bun runtime, likely to evade process-based monitoring, and briefly introduced destructive fallback behaviour before refining itself for stability.

This was not smash-and-grab. It was automated replication using legitimate, local authority.

This Is Also What Cyberwar Looks Like

There’s another angle here that most coverage skipped.

Shai-Hulud had a theatrical quality. The name. The public GitHub repositories. The visible propagation. The slightly adolescent branding in later waves. It looked loud. Almost playful. That can be misleading.

In military terms, weapons are not simply built and deployed. They are tested. They are refined. They are evaluated in live environments. Visibility is not always a flaw.

Sometimes it is telemetry.

A registry-native worm that exercises install-time execution, credential harvesting, token replay, automated publishing, CI mutation, and cross-platform runtime switching is not just “malware.” It is a systems test.

It measures detection latency. It measures registry response. It measures how quickly maintainers rotate credentials. It measures how effectively organisations distinguish authorised from malicious behaviour.

We tend to assume that if something is visible, has a name, and leaves public traces, it is unsophisticated. That assumption is dangerous.

The fact that Shai-Hulud was noisy does not mean it was trivial. It may simply mean that noise was part of the experiment.

History should make us cautious here.

When the Equifax breach was first disclosed, the focus was on data theft. Much later, it emerged that records had also been modified. False credit ratings were inserted. The integrity impact was subtler than the headline about exfiltration.

Exfiltration is easy to understand. Integrity manipulation is harder to detect and slower to surface. Shai-Hulud’s public behaviour does not guarantee that its full impact is understood.

A worm capable of harvesting credentials and republishing packages is also capable of modifying code in ways that are far less obvious than a visible payload file.

If you wanted to test ecosystem response, this is exactly how you would do it. And if you wanted to insert something subtle, you would hide it behind the noise.

None of this requires conspiracy thinking.

It simply requires acknowledging that software supply chains now operate within geopolitical realities. Package registries are a global infrastructure. CI systems are critical infrastructure. They are soft targets compared to hardened networks.

Funny names and public repositories can lull us into treating something as mischievous rather than strategic.

That would be a mistake.

Why It Was So Effective

Shai-Hulud did not need to break the registry. It exploited the fact that install-time execution, credential-harvesting potential, and publish authority coexist within the same operational flow.

Dependency installation is routine and rarely scrutinised. Lifecycle scripts are accepted as build behaviour rather than treated as remote code execution. CI environments are credential-rich by design. Maintainer identities often span multiple packages. Publishing is frictionless for authenticated users.

When the worm harvested tokens, it did not need to escalate privileges. The privileges were already present. When it republished packages, it did not exploit npm. It exercised legitimate authority.

The truth is that we allowed the worm to behave like a developer. It authenticated, it published, it modified workflows, and it interacted with GitHub APIs. From the perspective of logs, it looked like a maintenance activity.

This is why detection is hard

Traditional security models ask whether an action is authorised. In this case, it was. Once credentials were stolen, the worm operated entirely within permission boundaries.

The challenge lies in distinguishing malicious use of legitimate authority from routine automation. In environments already saturated with scripted releases and automated publishing, that distinction is not trivial.

The worm hides inside the behaviours we normalise.

Getting Practical: Without Pretending It’s Easy

At this point, the obvious question is: what do we actually do?
The industry response to incidents like this is predictable. We talk about dependency provenance checks. We talk about SBOMs and supply chain visibility. We talk about lockfile enforcement, short-lived credentials, least privilege, egress controls, and hardened CI.

All of those things are useful. None of them, on their own, is decisive. Dependency provenance is useful when verifying and when you are prepared to block builds on verification failure.

Generating an SBOM is useful only if it informs a system that changes behaviour. A lockfile protects you from unexpected version drift, but it does nothing if the version you locked was already compromised.

Short-lived credentials reduce the blast radius, but they do not prevent phishing.

Network controls make exfiltration harder, but they require treating your build environment as more than a convenience tool.

These measures are just friction.

Friction works only if you accept that some workflows must slow down.

I expect that most organisations will implement visible controls while silently preserving the behaviours that made the worm effective. They will generate SBOMs but not act on them. They will enable security scanning but auto-merge updates. They will reduce token lifetimes while keeping publish authority within the same trust boundary as install-time execution.

The Shai-Hulud worm didn’t succeed because we lacked tooling. It succeeded because install-time execution, credential concentration, and frictionless publishing coexisted without meaningful separation.

If you want practical mitigation, you have to separate those concerns.

Treat dependency installation as code execution. Treat CI as critical infrastructure rather than background plumbing. Treat the authority to publish as something that deserves ceremony. Treat unsupported software as a risk condition even when dashboards are green.

Provenance checks, SBOM-driven alerts, lockfiles, token rotation, and network segmentation can materially reduce impact. However, they only change outcomes when paired with a cultural shift away from “speed first, security later.”

Without that shift, they are compliance theatre. With it, they become leverage in your favour.

The Mirror

Shai-Hulud did not introduce a new class of risk. It exposed the one we had already optimised for.

We built a software factory designed for trust and speed. Attackers optimised for leverage and scale. When those incentives aligned, replication became trivial.

We didn’t get unlucky. We got efficient.

The worm was not an anomaly. It was the mirror. It was a completely predictable product of our ecosystem's behaviour.

It won't be the last.

The post The Shai-Hulud Cyber Worm and more thoughts on supply chain attacks. appeared first on foojay.

FOSDEM 2026: A Live Snapshot of Open Source

(a.k.a. “So… what did you do this weekend?”)

I’m back from four days in Brussels and the uniquely exhausting experience that is FOSDEM. Mentally fried. Physically wrecked. Entirely glad I went.

The Chaos and the Crowd

Around 8,000 people made the trip this year. Some arrived for the first time; many returned as annual pilgrims.

FOSDEM remains a strange outlier in the modern conference world: free to attend, no registration gatekeeping, and no sponsors dictating the tone. You just turn up.

Its official description, “a free event for software developers to meet, share ideas and collaborate”, is technically accurate and utterly inadequate.

FOSDEM isn’t a conference so much as a live snapshot of the open source ecosystem in action.

In 2026, that snapshot featured 1,000+ sessions and nearly 1,200 speakers across ~70 tracks. Organizers squeezed them into 37 rooms on the Université Libre de Bruxelles Solbosch campus. Do the maths, and you quickly realise something important: you are not there to consume everything. You are there to sample the firehose.

Navigating the Firehose

The organizers stream and record most talks (https://video.fosdem.org/2026/), which is a mercy. Physically moving between rooms is often futile. Staff strictly enforce capacity limits; you can arrive 30 minutes early and still lose out. The organisers never compromise on safety or timing. That discipline is the only reason the whole thing works at all.

So why go in person when you could watch from your sofa?

Because of who fills the rooms. When you strip away the PR layer, FOSDEM brings together the real movers: project founders, maintainers, and foundation reps. You’ll find lawyers, researchers, and distro builders sitting next to compiler engineers, students, and the people quietly keeping production systems alive.

No one pitches here. You get progress, blockers, failed experiments, and difficult questions. All aired publicly. Where else can you hear CycloneDX and SPDX contributors debating SBOM reality rather than policy theory? Where else can you ask a CRA-focused lawyer naïve but necessary questions without being sold a compliance product?

FOSDEM is the heartbeat of open source. It is a reliable way to distinguish what’s real from what’s hype. Ideas that survive here tend to matter. Ideas that don’t… don’t.

Trends and Tensions in 2026

What did FOSDEM 2026 actually tell us?

The familiar themes all appeared: AI, software supply chains, security, and the CRA. We saw robotics, compilers, Linux distros, and embedded systems. If it’s open source—from QA and mobile to radio and model railways—it was likely there.

I learnt a lot and met new people. I discussed the latest developments with experts in the areas I care about and came away with plenty to think about.

One telling gap appeared this year: no dedicated Java room. While a small Java presence remained across the tracks, the usual JVM-centric room was missing. I spent time with the Foojay.io folks discussing whether that absence matters.

For 2027, we’re considering a proposal for a Java Users room. We want to focus deliberately above the JVM and JDK, looking at how Java works in modern systems, supply chains, CI/CD, and regulated environments.

FOSDEM 2026 made one thing clear:

The hardest problems aren’t language features anymore. They are how we build, ship, and sustain software. AI included.

Security as Engineering, Not Defense

Security conversations threaded the event, though they often appeared indirectly. Speakers framed them as good engineering rather than reactive cyber defence. We talked about hardening build systems, reducing attack surfaces, and improving dependency hygiene. It felt less like “panic patching” and more like “this is how things should have been built.”

A noticeable urgency accompanied this, occasionally bordering on anxiety or a shared weariness. Technical collaboration is losing the race against legal obligation. The work needed to make software ecosystems safer is real and ongoing, but compliance deadlines now drive it more than shared engineering goals.

The Economics of "Free"

Open source is approaching a watershed moment.

Legislation like the Cyber Resilience Act (CRA) is reshaping expectations, responsibilities, and liability. Yet funding models for this work remain unclear, fragmented, or missing entirely.

Maintainers feel it. Foundations feel it. Downstream users are only just starting to notice.

One standout talk captured this tension perfectly: Michael Winser’s “The Terrible Economies of Package Registries.” He provided an evidence-rich look at how the assumption that “open source is free” collapses.

Once you factor in infrastructure, security, compliance, and abuse prevention, the math changes.

As open source becomes less free in economic terms...

Organisations are becoming more selective about what they use. Pay-to-download might not change behaviour first, but the equations are shifting. Our relationship with open source is changing because the world is changing.

AI accelerates this pressure; legislation compounds it. Together, they are distorting the economics of open source consumption in ways we are only beginning to understand.

A Practical Call to Action

So what should you actually do?

This article started as an ode to open source, and it still is. But nostalgia won’t keep systems compliant or safe. The good news is that the first responses require solid engineering, not ideology.

1. Know your software supply chain intimately

Not approximately. Not via a quarterly report. You must know what’s in production well enough to find vulnerabilities before regulators or attackers do.

FOSDEM saw intense discussion regarding supply chain security, SBOMs, and PURLs. Simplistically—since I am not a lawyer—demonstrating control over what you ship requires knowing what you ship. That 'demonstration' is quickly becoming a hard compliance requirement.

2. Make your CI/CD pipelines boringly efficient

Updates to the OS, dependencies, and tooling have to be routine, not heroic. If updates are painful, the next compliance deadline or vulnerability disclosure becomes an existential risk.

3. Establish a support posture for every component

That includes open source. You must know when your dependencies reach EOL, your legal exposure when that happens, and your technical options.

If upgrading is too risky or too slow, more commercial support is appearing to help with EOL open source. Being in control of your software means being able to explain how you resolve security issues.

Whatever path you choose: planning for frequent upgrades, yearly modernisation, the draconian withdrawal of applications, or simply buying a support contract, you must be able to deliver. Auditors will not accept hand-waving or "we'll figure it out when it happens" type of answers.

Silver Linings

The points above all come down to having solid engineering foundations. New tools are arriving to make things easier and many were on display at FOSDEM. They will , eventually, help you take the drama out of delivering secure software, whether AI is included or not.

Many non-technical elements remain unresolved though . We still need cultural and economic shifts.

FOSDEM 2026 showed us how vital and dynamic open source is and how it is rising to the challenges we all face, but perhaps we saw the beginning of the end of the "just more tech" era.

We are finally acknowledging that cultural and economic changes will rewrite our relationship with software.

I’d rather hear that now, out loud and in public from the people doing the work, than from a regulator, a breach report, or a courtroom.

FOSDEM 2027 is looking like the place to be next year.

Time to mark your calendar.

The post FOSDEM 2026 and the Open Source Firehose appeared first on foojay.

This is a follow-on to the article The Real Mechanics of Vulnerabilities in an Upstream/Downstream, Topsy-Turvy EOL World.

What you'll learn in this article:

• The Security Timeline Inversion: CVE disclosure is no longer the true start of the security timeline.
• Security Outcomes: Routine maintenance decisions, not reaction speed or tooling, determine security outcomes.
• Flawed Indicators: CVE scores, scanners, and compliance deadlines are not effective early-warning systems.
• Vulnerability Distortion: Embedded, forked, and end-of-life components obscure vulnerability visibility and responsibility.
• Your Mission: Governance and lifecycle changes are necessary to avoid being structurally late to "silent" vulnerabilities.

Are you sitting comfortably?

In February 2025, Apache Tomcat shipped a set of routine point releases. They arrived without urgency, without commentary, and without the kind of noise that can accompany significant security incidents.

For most teams, there was no immediate reason to treat these releases any differently from other maintenance updates. Nothing appeared broken. Nothing appeared compromised. There was no vulnerability identifier to react to.

A few weeks later, those same releases became the centre of a security emergency.

By the time CVE-2025-24813 was made public in March, the vulnerable code path had already been identified, corrected, and shipped across supported Tomcat branches.

The fix existed before the problem had a name. For teams that had upgraded in February, the CVE arrived as an explanation for something that had already happened.

For everyone else, it came as a nasty surprise: a CVSS score of 9.8 is a great way to start your day.

The CVE is (almost) not important

Feel free to look up the details of the CVE here https://nvd.nist.gov/vuln/detail/CVE-2025-24813. We’ll look at the content later, since what is recorded and by whom is part of this story. The gory technical details of the CVE are mostly irrelevant. The important characteristic is that this CVE doesn’t occur in default mode; it has to be enabled.

What the following sequence of events will help us understand is how CVEs can evolve and how that can impact consumers.

The Inversion of the Security Timeline

This inversion is easy to miss if you only look at disclosure dates.

Security timelines are usually told as if they begin when a CVE is published. In reality, they start earlier. When the problem is reported or when maintainers change code.

When a rocket on the launch pad begins counting down, we see the engines start before the rocket leaves the ground. That’s sort of the pattern we see with CVEs.

In this case, the Tomcat security team followed a pattern that is entirely normal for long-lived open-source infrastructure. A private report arrived. The issue was investigated. A fix was developed and shipped. Quietly, and all before the’rocket’ left the pad.

Only after patched versions were available did public disclosure occur. The intention was not secrecy, but containment: The aim is to reduce the window in which defenders have no viable response.

Habit vs. Hype

That approach works well for organisations that treat point releases as something to be applied routinely.

Those teams upgraded without knowing why, and by the time the vulnerability was publicly discussed, they were already protected. The upgrade decision that mattered had been made weeks earlier and as part of an ongoing plan.

For organisations that rely on disclosure as the trigger for action, March felt like a zero-day. The vulnerability appeared fully formed, complete with severity scores, exploit claims, etc.

From the outside, it looked as though everyone was confronting the same risk at the same time. In reality, the outcome had already diverged.

Two teams could have been running identical Tomcat versions in January and ended up in very different positions by mid-March.

One was insulated, the other exposed.

The difference was not threat intelligence, tooling, or awareness. It was habit.

The Flawed Assumption of Loud Alerts

There is a persistent assumption in many engineering organisations that serious security issues will announce themselves loudly enough to demand attention.

That assumption is increasingly unreliable.

In this case, the most crucial indicator was indistinguishable from routine maintenance. A changelog entry. A version bump. A release that did not feel urgent because nothing had yet told anyone that it should be.

Once the CVE was published, the usual narrative took over. The vulnerability acquired a name, a score, and a target audience. Discussions about severity, exploitability, and configuration began immediately. But by then, the window for quiet safety had already closed.

Prioritising Changes Over Stories

It is tempting to view those February releases as fortunate timing.

They were not.

They were simply the result of a process that prioritises fixing code over managing perception.

The discomfort comes from realising how many organisations are unknowingly structured to respond to stories rather than changes, to declarations rather than diffs.

By the time the wider ecosystem began debating the implications of CVE-2025-24813, the technical outcome had already been set. Some systems were safe, others were not, and the distinction had nothing to do with how quickly anyone reacted in March.

What followed was not a single, shared reality. How this CVE (and to be honest, the vast majority of all CVEs) rolled out across the world was a collision of interpretations, assessments, and obligations.

That is where this case study becomes interesting and makes such a great sample.

The main timeline

There's a lot to unwrap.

The critical elements all circle around the NVD’s CVE and CPE information. Which you can find here https://nvd.nist.gov/vuln/detail/CVE-2025-24813 I need to stress that this is not at any point intended to suggest anything untoward happened. This is a worked example of how things are.

January 13, 2025. Vulnerability Privately Reported

The Apache Tomcat security team receives a private report of a vulnerability involving partial HTTP PUT requests and the default file servlet. The flaw affects file upload handling when writes are enabled.

January 24th 2025: Fix committed.

The commit https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c was recorded, and, as usual and expected, there’s no indication that it fixes a security flaw. The associated pull request is named “Enhance lifecycle of temporary files used by partial PUT”

February 10th, 2025: Fix released silently.

Apache quietly releases Tomcat 9.0.99, 10.1.35, and 11.0.3 with the fix included. That's one month before public disclosure. Organizations routinely updated were protected early.

March 10, 2025: CVE-2025-24813 Publicly Disclosed

Apache publicly discloses the vulnerability via the OSS security mailing list, rated "Important" with potential for RCE and information disclosure. Discovery credited to COSCO Shipping Lines DIC and researcher "sw0rd1ight".

The posting to the NVD system (https://nvd.nist.gov/vuln/detail/CVE-2025-24813) cites
“This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.2, from 10.1.0-M1 through 10.1.34, from 9.0.0.M1 through 9.0.98.”

March 13–14, 2025: PoC Exploits & Active Attacks Begin

Within 30 hours of disclosure, proof-of-concept exploits appear publicly. Mass scanning and exploit attempts begin immediately. Attack method: upload JSP webshell via partial PUT, trigger via crafted JSESSIONID request.

Sources: Sonatype Blog | CyRisk Analysis

17 March, 2025: A POC exploit is added to the NVD CVE record.

https://github.com/absholi7ly/POC-CVE-2025-24813/blob/main/README.md

18th March 2025: The first CPE information is added to the CVE

The CPE https://nvd.nist.gov/products/cpe is the magic information that makes the CVE basically machine readable. Its lets automated consumers of the CVE ‘know’ what versions of the product are vulnerable.

At this point the CPE simply matches the original version range declaration we saw earlier.

March 19–26, 2025: Security Vendor Analysis Published

Rapid7, Akamai, Wiz, and Sonatype publish detailed analyses.

Rapid7 notes "no need to panic" as widespread exploitation was unconfirmed, and some of Apache's stated prerequisites were overstated. Sonatype reports ~100,000 downloads of vulnerable versions post-disclosure.

Sources: Rapid7 Blog | Akamai Blog | Wiz Analysis

April 1, 2025 :CISA Adds to KEV Catalog

The CVE records that CISA adds CVE-2025-24813 to its Known Exploited Vulnerabilities catalogue, citing evidence of active exploitation.

U.S. Federal agencies have been given an April 22, 2025, deadline to patch. Amazon AWS also releases ALAS-2025-2812 the same day.

Sources: Keysight Analysis | Amazon Linux Advisories

Early April 2025 : Enterprise Vendor Patches Released

Red Hat, Amazon, SUSE, Atlassian, and other enterprise vendors release patches. Most emphasise that default configurations are not vulnerable since the default servlet is read-only.

The CPE entry gains an debian tomcat entry.

Sources: Red Hat CVE | Amazon CVE

July 3, 2025: Unit 42 Reports 125K+ Attack Attempts

Palo Alto's Unit 42 reports 125,856 exploit attempts blocked in March 2025 alone. Most exploitation traffic appears "opportunistic" using public PoCs by low-sophistication actors. No major confirmed breaches attributed specifically to this CVE.

Source: Unit 42 Report

Are we done?

Well, for some set of Tomcat users , those on versions 9,10 or 11 everythings ok. They have a fix and as long as they upgrade, then they are safe. But there is more to tell

August 7, 2025 - CVE updated “ Older, EOL versions may also be affected.”

Due to some lobbying led by HeroDevs, the Apache team added a warning. This is important. This very rarely happens, but there were engineers in the mix both at Apache and elsewhere who felt that the warning was needed. The CPE was updated, but it did not gain any information about the EOL versions, as there was nothing specific to include.

August 8, 2025 - CVE Updated with more information about EOL versions

The CVE now states, “The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 through 8.5.100.” Now the CVE is officially applicable to another version stream of Tomcat. Unfortunately, the CPE was not updated.

Jan 2026

Even today, this CVE hasn’t been updated to include the CPE information that might help a scanner detect a problem in version 8.5.

Thats not particularly unusual.

The CPE doesn’t include information about many of the Linux distros or any of the products that embed Apache Tomcat.

Some of that can be attributed to the nature of the CVE.

Since the vulnerability is only possible if a default configuration is changed. A simple readyonly=true changed to readonly=false.

That means, in theory, exploitability depends on the Tomcat user being able to make this change. If Tomcat is embedded in any way, this config can’t be changed, so the ‘embedding’ product may rightly claim they are not vulnerable...

However, there are many forks and commercial variants of Apache Tomcat. For instance It’s a component of Spring Boot, and Broadcom Tanzu embeds it too. How many fat jars are out there where the component information has been lost, or the project POM has been updated since shipping?

How the message dilutes

The frequently bitter truth is that CVE reporting and getting appropriate awareness to the right people fails. In fact the more popular a component is to be forked or embedded the harder it can be to reach those who need to know.

Often, in the heat of the moment, downstream vendors reach to the initial CVE report but dont come back for updates. The Tanzu support page
https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/25536

Rightly spells out that the CVE is applicable to Tanzu and gives it its own identifier TNZ-2025-014. They alert their users to the CVE being applicable to versions 9,10 and 11, but then, as always, it gets messy.

The Tanzu suite is sophisticated and complex. Suddenly, the CVE, rather than being a simple are-you-exposed or not turns into a list of maybes and false positives.

I don't know if Tanzu has versions with Tomcat 8 or earlier - I assume they do. Given their advisory is dated 2025-03-25, well before the CVE had the additional EOL version info added one can sympathise with this omision even if it could be a major exposure for older Tanzu products,

A common scenerio

By the time CVE-2025-24813 acquired a name, a score, and a media cycle, the outcome had already diverged.

The fix existed before the CVE. Some systems were protected before anyone knew why. Others would remain exposed no matter how fast they reacted in March.

That divergence did not come from awareness, tooling, or any threat intelligence. It came from timing. More precisely, from an assumption that security begins when a vulnerability is declared, rather than when code quietly changes.

What followed was not a single event but a prolonged cascade. The CVE text evolved. CPE data arrived late and incompletely. Vendor advisories reframed the scope. Compliance deadlines hardened partial truths into policy. Updates about EOL exposure appeared months later, after many downstream decisions had already been made.

None of this was malicious. None of it was unusual. It is simply how the modern vulnerability ecosystem behaves when it treats disclosure as a moment rather than a process.

CVE-2025-24813 did not “happen” in March. It happened in January, February, March, August, and beyond. Depending on where you sit and which signals you rely on.

The uncomfortable reality is that by the time the wider ecosystem had finished debating severity and exploitability, the technical outcome had already been fixed.

How should you react?

What This Means to You and What to Do Next

Much as I dislike the term “uncomfortable truth” its the one used most often in these circumstances. So the “uncomfortable conclusion” of this case study is not that CVE-2025-24813 was unusually dangerous. It is that nothing about it was unusual at all

The vulnerability did not arrive with any fanfare. It did not announce itself as urgent. It was resolved before it was named. The systems that survived did so not because they reacted faster, but because they had already decided, long before, how they treat change.

If your security posture depends on knowing why an update matters before you apply it, then you are already operating too late.

In modern ecosystems, explanation follows action, not the other way around.

What this means in practice

First, disclosure is no longer the start of the security timeline.

By the time a CVE acquires a name, a score, and eventually a compliance deadline, the decisive technical work has often already happened elsewhere. If your organisation treats disclosure as the trigger for motion, you are structurally exposed to silent fixes you will never prioritise in time.

Second, scanners do not give you foresight, they just tell you you’re late.

CVE databases, CPEs, and KEV catalogues are coordination tools.

They help large ecosystems move together once a narrative stabilises. They do not tell you when the risk actually entered your codebase, nor when it quietly left. Treating them as early-warning systems guarantees blind spots.

Third, “default safe” is not a strategy.

Many teams took comfort in the idea that this vulnerability required a non-default configuration. That distinction collapsed the moment embedded distributions, forks, and fat-JAR deployments entered the picture.
If you cannot prove how a component is configured in production, you cannot rely on upstream assumptions about safety.

Finally, habit beats heroics.

The difference between the protected and the exposed systems in this story was not tooling, threat intelligence, or response speed. It was whether routine maintenance had been institutionalised before anyone knew it mattered.

What you should do next

Do not wait for the next CVE to test these assumptions. You already have enough information to act.

1) Start by identifying where your upgrade decisions come from.

If updates are prioritised only after a vulnerability is named, scored, or mandated, that is a governance and control problem, not a technical one.

Fixing it requires changing when decisions are made, not which tools are consulted.

2) Examine how you treat “quiet” releases

Ask which point releases in your environment would be applied automatically, and which would be deferred until justified. Every deferral you make is a bet that the justification will arrive before the exploit does.

3) Map responsibility for end-of-life components explicitly.

If a dependency is out of upstream support, the risk is no longer abstract or future-dated. Security responsibility has already shifted. It now sits either with you, with a downstream vendor, or with nobody at all—and that ambiguity is itself a form of exposure.

I should be explicit about my own position here. I work for a company that provides extended support for end-of-life open-source components. That is one way, sometimes a very practical one, to regain control when vulnerabilities appear in older software. It can buy breathing space. It can stabilise a system long enough for thoughtful decisions to be made.

But it is not the only option, and it is not a substitute for understanding how you ended up here.

Extended support is a safety net, not a strategy. So are accelerated upgrades, compensating controls, isolation, or architectural change. All of them are valid responses in different contexts. The real failure mode is not choosing any response. Drifting into a state where no one is clearly responsible, and no response is actually owned is the wrong choice.

End-of-life does not mean “unsafe by default.” It means the burden of proof has moved. Someone now has to actively carry security responsibility. If you cannot point to who that is,or explain how that responsibility is being met, then the risk is already present, whether a CVE has your attention or not.

4) Finally, treat security as a lifecycle, not an event

CVE-2025-24813 unfolded over months, not days. So do most real vulnerabilities. If your processes only engage at the moment of disclosure, you are optimising for narratives rather than outcomes.

Security does not start at liftoff.

By the time the countdown reaches zero, the engines have already been burning for a long time. The only question is whether you noticed, and whether you built your systems to move before someone told you why.

The post Security Doesn’t Start at Liftoff appeared first on foojay.

In this article you’ll learn

• Why CVEs record that a vulnerability exists, not that a usable fix exists
• How vulnerabilities are often discovered and fixed downstream before upstream ever acknowledges them
• Why EOL branches continue to accumulate exploitable behaviour even when no CVEs appear
• How downstream-only patches break the assumptions scanners and SBOMs rely on
• What disclosure actually enables when “just upgrade” is not a viable option

Introduction

There is a tidy, almost academic version of how software security is supposed to work. It appears in conference talks, compliance documents and in the cheerful diagrams seen on marketing slides. It usually looks something like this:

A researcher finds a bug, tells upstream, upstream patches it, a CVE appears, downstream maintainers pull the fix, scanners notice, defenders patch, and the world stays mostly ok. A few poor souls miss the memo, and of course, the bad guys get yet another weapon to add to their arsenal.

What this article is about

If that were truly how things worked, I wouldn’t be here writing about downstream-only fixes, silent patches, or security issues that exist in one place and vanish in another. But the real world has a different rhythm and one that is increasingly being disturbed - and everyone needs to know.

What? You thought CVE pixies fixed the problem everywhere?

The first uncomfortable truth most people don’t realise: a CVE is not a demand for a patch.

Well, ok, it may also be a demand, but mostly it’s a record of reality. It documents the existence of a vulnerability, not the willingness of upstream to fix it. For most practical purposes CVEs simply start as a record of an instance of a vulnerability against a particular version of a component. It's up to others to expand the scope of the CVE.

You can have a CVE for software that is unmaintained, unpatchable, obsolete, unsupported, or even abandoned. It still matters because people still run it. And defenders still need to know what risks exist, even when no patch is coming.

By The way

As an important aside, the CVE can be rejected. Working-as-designed is an often quoted reason. In that case, the CVE gets formally marked “rejected”. It doesn’t get fixed, but it sits in the system. A little waving red flag for the bad guys to review and maybe exploit. Working-as-designed doesn’t always mean “safe”.

Back in the real world

The process of finding and fixing vulnerabilities is stuttering and developing arrhythmia. The patterns of old are being replaced by ones shaped by exhaustion, understaffing, commercial pressure, legacy systems that never die, and codebases that ‘outlive’ the people who wrote them.

Once you look honestly at how this system actually behaves, what's happening today. What you might call the downstream-fix / upstream-blind problem, stops looking shocking and starts looking inevitable.

Code Flows

To understand anything in this article, you have to start with the software supply chain itself and how code flows.

The terms “Upstream” and “Downstream” are often used to describe the flow of code and dependencies in the software supply chain. Upstream generally refers to the original source of a software component (like an open-source project or a third-party library). They are at the beginning of the stream, where the code is first created and maintained. Downstream refers to the consumers of that code-stream, such as vendors who embed the component into their products or end-users who deploy those vendors' products.

Downstream organisations take code from upstream and may fork, modify, package, or distribute it, placing them further along the supply chain.

A different type of waterfall

The terms “Upstream” and “Downstream” suggest a calm river: water flowing neatly from one point to another. In practice, for popular projects, it’s more like a vast delta with rapids and the occasional waterfall. The code spreads, splits, branches, gets repackaged, embedded, wrapped, containerised, and shipped out into the world in directions nobody can fully track.

A component like Apache Tomcat is a perfect example. It exists as the official Apache distribution, yes, but also inside enterprise servers, inside product bundles, inside Spring Boot JARs, inside appliances, inside internal systems last touched in 2017, inside the developer’s local install, and in a thousand places between. It becomes part of the ecosystem in a way that is both powerful and almost impossible to map fully.

Unpredictable as the weather?

That sprawling micro-ecosystem is precisely where and how vulnerabilities emerge. Not neatly and systematically, but in sideways, unpredictable ways.

People often imagine security issues being discovered in upstream by the maintainers themselves. That does happen, but it’s surprisingly rare.

More often, a vulnerability first surfaces in a downstream fork, or it’s uncovered by a customer running a fuzz test, or it’s noticed by a developer who spots a strange edge case during a refactor, or it’s found by a researcher who wasn’t even looking at Tomcat but happened to trigger a code path shared with some upstream version.

In other words, the first person to see a vulnerability is very often someone far from the upstream project.

The idealised workflow

That’s where the disclosure process is meant to kick in. In the ideal world, the discoverer quietly contacts upstream (please don't publish it to the world), upstream acknowledges, a patch is worked out, a CVE is assigned, and everything proceeds as it should.

But once upstream is older, slower-moving, busy with the next major version, or no longer maintaining that branch, the ideal workflow dissolves.

When a vulnerability appears in an End-of-Life upstream, like Tomcat 8.5, nobody expects upstream to reopen that branch. They have moved on. The patch would be difficult, risky, or time-consuming. They quite reasonably decline. And so the vulnerability persists.

Now imagine you’re a downstream vendor. You support customers running Tomcat 8.5 on your fork (remember the delta analogy) because their workloads can’t simply jump to Tomcat 9. You discover a vulnerability. You know it exists in code originally taken from upstream Tomcat. You fix it in your fork. You do the right thing for your customers.

The ethics of vulnerability patching

Now you face the real dilemma: do you tell upstream?

Some vendors don’t.

The reasoning seems tidy: upstream is EOL, so no patch will be forthcoming. Why bother them? Why risk raising an issue that attackers might see and exploit if there’s no available fix? Why “expose” the project when the problem might remain safely quiet?

Except the idea of safe quiet is an illusion.

Attackers are not relying on CVE databases. Attackers are much, much more sophisticated and armed.

They diff patches. They fuzz older codebases. They target EOL systems precisely because they know nobody is watching.

Unreported is not safe

A silent vulnerability is not safer than a disclosed one: it is just more profitable for attackers. The only people kept in the dark by silence are defenders, auditors, and the teams desperately trying to keep unmaintained systems alive long enough to migrate them.

This is the real ethical bottom line: disclosure does not create risk; it distributes knowledge of the risk to the people who need it. The vulnerability is already present and likely known. The attackers already have the upper hand. The only thing disclosure changes is that defenders can finally see the problem too.

Downstream's responsibility to the ecosystem

And this is why downstream vendors have a deeper responsibility than most realise.

Once you discover a vulnerability in upstream-derived code, you are no longer only responsible for your own customer base. You have identified a problem that likely affects parts of an ecosystem far beyond your fork.

Upstream may not fix it. Nobody is suggesting they must. But the ecosystem needs to know it exists, because the ecosystem is still running that code, often at staggering scale.

This becomes painfully clear when you remember that, in our example, Apache Tomcat ( including forks varients and versions that are End-of-Life ) is everywhere. Not because people love running outdated servers, but because it has been embedded in frameworks, enterprise products, appliances, Spring Boot applications that “just work,” and internal systems that never got migrated after the architect left.

End of Life software is everywhere

An EOL project can still be foundational. In fact, EOL projects are often foundational because nobody touches them when they work well.

So what happens in practice when a downstream vendor fixes a security issue that upstream will never patch?

In an ideal world, the vendor notifies upstream anyway. Upstream acknowledges the report, marks the issue as affecting an EOL branch, and declines to patch. A CVE is published to document the problem. Downstream ships its fix. SBOMs reflect the vulnerability’s existence. Scanners alert operators running older versions. Users can apply compensating controls. EOL support vendors can build mitigations.

Everyone gets to act. Nobody stays blind.

The peril of downstream silence

But when downstream maintainers (especially of forked variants ) remain silent; when the vulnerability is fixed in one place and remains unacknowledged or just “noted” everywhere else, then you get the worst possible outcome.

Upstream knows nothing. Defenders see nothing. SBOMs misrepresent reality. Vulnerability scanners report “no known issues.” Legacy systems continue running with a false sense of safety. And attackers who grok the downstream patch now hold precious knowledge of a vulnerability that won’t be fixed.

How the world works

None of this is malice. It’s not incompetence. It is simply what happens when the system relies on people voluntarily and consistently doing the right thing across dozens of organisations, time zones, codebases, and priorities.

The truth is that nothing in the ecosystem enforces upstream notification. It happens because maintainers, vendors, and researchers believe in the value of shared signals.

The entire system works only if everyone believes disclosure helps defenders more than attackers — which it does.

Summary

If there’s one lesson from the downstream-patch / upstream-silence dynamic, it’s this: silence is the real exposure.

Vulnerabilities don’t become dangerous when disclosed; they become harmful when only one part of the ecosystem knows about them.

Transparency isn’t just ethical. It’s operationally necessary, especially where EOL software frequently remains the backbone of production infrastructure long after anyone expects it to.

This is how it all works in practice. Not the polished diagram, but the real machinery: code that forks and diverages, vulnerabilities that surface unexpectedly, upstreams that age out, downstreams that patch, ecosystems that depend on honesty, and defenders who can only defend what they can see.

If we want a safer and more predictable world, the answer isn’t silence or secrecy. It’s accurate signals. Even when no fix is coming, and even when the upstream is long past its supported life.

CVEs dont work the way you think - but I wish they did

Next time

In the next article I’ll explore an important case study and show just how messy CVE reporting, fixing, and discovery can be.

The post The Real Mechanics of Vulnerabilities in an Upstream/Downstream, Topsy-Turvy EOL World appeared first on foojay.