I’ve been posting about AI, EOL software and the HeroDevs EOL dataset for a while now, and as always happens when you dive into a subject, you uncover unexpected things. Often they’re more insightful than scary. Though AI and security are often both.
I’d been treating end-of-life as a time-thing: when does support stop, how long have you got, what does that mean for your risk. All fine. But focused on the when, I had completely missed the other important element.
How do you actually communicate that something is End Of Life?
Given the millions and millions of package versions out there, how does the HeroDevs EOL dataset get its information?
Well, there’s a mix. Data mining, obviously, plus project analysis: the maintainer has disappeared, or written a so-long-and-thanks-for-all-the-fish note in the README, or the last release was ten years ago.
Even the OpenSSF, who built a Scorecard precisely to measure this stuff, had difficulty working out what “alive” means. The Scorecard’s Maintained check awards top marks for roughly a commit a week over the last 90 days, with partial credit for issue activity from the core team. Their own docs admit the limits: some software (their example is a library that checks whether an integer is even) simply doesn’t need maintaining. And the measure misleads in the other direction too. A suitably configured GitHub Action merrily applying dependabot PRs keeps the commit graph green. Even if the maintainers have no intention of ever fixing a bug.
The excellent endoflife.date tracks the most important ~500 products directly. HeroDevs keeps tabs on over 12 million. And the insight, my epiphany, was realising just how hard it is to get a definite answer without real work and the occasional finger in the air. That leads to missed projects, things marked EOL when they’re still alive, or things that effectively died years ago looking healthy. Zombie anyone?
Not great.
When I say “tracking EOL for software”, you’re probably thinking about applications and their dependencies. Maybe operating systems and their packages?
Think wider. Think of all the software products that exist today. Mobile apps. Web apps. All that JavaScript in CDNs being pulled into pages as you read this.
Oracle boasts Java on 3 billion devices. The Apple App Store has about 2 million apps, with maybe 4 million more across Android stores. And that’s just the public stuff we can see: many industries have their own commercial software stacks that never go near an app store.
Keep going. Device drivers. Routers. Smart devices. Washing machines. Ring doorbells…
Every connected device is a potential target for attackers, and the software inside it has a lifecycle whether the manufacturer admits it or not.
It would be good if manufacturers, hardware or software, could signal “this component is EOL: update it, or treat the device as unsafe”. And it would certainly make all our lives better if that signal could be found and shared mechanically, by tools, at scale, rather than by humans reading forum posts and using scripts to calculate the years since the last commit.
Bad Actors already operate at scale. I’ve already talked about machine-speed vulnerabilities, human-speed fixes. The least we can do is make “is this even supported?” answerable at machine speed too.
…that this is one of the goals of the OASIS OpenEoX standards group. I’m a recent member (representing HeroDevs, so consider my interest declared)
OpenEoX's aim is to standardise how product lifecycle information gets exchanged, machine-readably, across commercial software, hardware and open source.
More than EOL, the objective is to cover the full run of milestones, from launch to shutdown, and every date in between. Including EOL and End-Of-Security-Patching (EoSSec). Which to me originally was the same thing, but now I know better.
The committee includes Cisco, Microsoft, IBM, Oracle, Red Hat, Dell, Siemens, CISA and Germany’s BSI. CISA is already urging producers to publish this data openly, without hiding it behind customer portals or paywalls.
The design comes in layers, and the first layer is out for review right now.
The Core schema is deliberately tiny: four lifecycle milestones in sequence, GA → EoS → EoSSec → EoL. General Availability (it exists), End-of-Sales (you can no longer buy it), End-of-Security-Support (vulnerability fixes stop), End-of-Life (everything stops). Plus a last_updated field and an explicit tba for unavailable or undecided dates.
Those middle milestones matter as much as the last one. A product can be off the price list for years while still fully supported, and it can still be “supported” in the brochure sense after security fixes have ended.
The Shell handles product identification: which product these dates describe, and from whom.
The API layer covers how tools discover and fetch the data at scale.
Because Core carries no product identity of its own, it slots into things that already exist. An SBOM knows what product it describes, so it can carry an OpenEoX statement inside it. Same for a CSAF advisory.
Best of all, a “vendor” in OpenEoX terms is whoever created or maintains a product, which explicitly includes open source communities and individual maintainers. A one-person project gets the same standard way to say “this is finished, here’s the date” as a trillion-dollar company.
The OpenEoX Core Schema v1.0 (CSD01) is in public review now, closing on 13 August 2026. The review is open to everybody, OASIS member or not: if you can send an email, you can have a say.
Read the spec: https://docs.oasis-open.org/openeox/eox-core/v1.0/csd01/eox-core-v1.0-csd01.html. It’s not long.
Send feedback to the public comment list: openeox-comment@lists.oasis-open.org (comments fall under the standard OASIS Feedback License).
If you build tooling, point your actual JSON Schema validator at the published schema and see what happens.
Want in properly? TC membership is open to interested parties via join@oasis-open.org.
So go and read the spec. It’ll take you less time than finding the EOL date for whatever’s running your CI server.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.