Ory Open Source moves to two releases a year. Here is how security fixes reach each edition of Ory, and why.

When we started Ory more than ten years ago, identity and access management was in a frustrating state. If you needed OAuth2, OpenID Connect, or fine-grained authorization, your options were largely split between opaque proprietary platforms that locked you in, or abandoned, half-baked sample code.

We believed, and still believe, that the core protocols securing the internet belong in the open. What began as a few focused open source repositories grew into Ory Hydra, Ory Kratos, Ory Keto, Ory Oathkeeper and the projects around them, shaped by a community of developers and security researchers who run them in production, report issues and contribute.

The conditions around that software have changed. The number of published vulnerabilities keeps climbing, and AI models now find bugs and turn published fixes into working exploits faster than ever. That changes how we release Ory Open Source.

This post covers two changes: a new release rhythm for Ory Open Source, and the way security fixes reach each edition of Ory, including why our customers get them before the public repositories do.

Moving from 1 to 2 Releases a Year

Until now, we aimed for about one Ory Open Source release a year. Starting in 2027, we are moving to two: one in the first half and one in the second half of each year. We won't commit to exact dates, but you can plan around that rhythm.

Two releases a year means:

• Fixes and features sooner: security fixes, new capabilities and performance improvements reach Ory Open Source twice as often.
• Fresher dependencies: the open source images pick up current Go, base image and library versions twice as often.

Releases follow Ory's YY.Q.B versioning scheme.

How Security Fixes Reach Each Edition

Security fixes ship continuously in Ory's commercial editions and reach Ory Open Source with the next release. We know that isn't how most open source projects handle security fixes, so here is how it works and why.

• Ory Network: fixes are deployed as vulnerabilities are resolved. The Network always runs the latest version.
• Ory Enterprise License: patched builds as vulnerabilities are resolved.
• Continuous Security License: patched builds for self-hosted Ory Open Source as vulnerabilities are resolved.
• Ory Open Source (Apache 2.0): each release includes the fixes for the vulnerabilities known at the time of the release, and we publish the security advisories with that release. There is no security SLA, no guaranteed release date and no commitment to out-of-band patch releases. Fixes go into the latest release only.

The three commercial editions share the same resolution timelines: 14 days for critical, 30 days for high, 90 days for medium and 180 days for low severity issues.

The open source terms aren't new. They have been in the security policy of every Ory repository for a long time. What's new is that since the end of July 2026, the public repositories receive the code with each release instead of commit by commit.

Why Customers Get Security Fixes First

A security fix shows where the bug was. The diff shows the missing check, the commit message names the problem, and the test that comes with it often reproduces the attack.

What has changed is the speed. Mandiant tracks time-to-exploit, the average time attackers take to exploit a vulnerability, measured against the release of its patch. It was 63 days in 2018 and 2019, 32 days in 2021 and 2022, and five days in 2023, not counting a small number of outliers (Mandiant). Those numbers are from before the current generation of AI models. Today a model can read a diff, work out which input triggers the bug and draft a proof of concept.

We see the same shift in our own work. The number of vulnerability reports we receive has gone up sharply this year, much of it AI-assisted, and we run AI security models against our own code to find issues before anyone else does (more on that here). Models are good at finding bugs, and they're just as good at reading fixes.

If a fix lands in a public repository the moment it's merged, everyone running Ory has to notice it, pull or build a new version, test it and roll it out. That takes days at best. An attacker only has to read the commit.

So we change the order. Customers get a patched build first, without the source of the fix, and have time to roll it out. A build can still be reverse-engineered, but that takes more work than reading a diff, and it buys our customers time. The source, the fix and the advisory go public with the next release.

The same applies to new code, so we hold back all changes until the release, not only security fixes. Keeping the newest code internal gives us time to find and fix issues in it before attackers with strong models can read it. It also means a gap in the public history can't point at security work. When a release ships, its full source goes public together with its builds.

Why Ory Open Source Waits for the Next Release

The head start explains why we don't publish a fix the moment it's written. It doesn't explain why Ory Open Source gets it with the next release and not a few weeks after our customers. That part is about funding.

Triaging a growing stream of reports, scanning our own code, fixing issues and shipping builds on SLA timelines is ongoing work for a dedicated team. The companies that need those timelines pay for them, and that revenue funds the development of everything that later ships in Ory Open Source. The fixes are available right away. They just aren't free. Without that revenue there would be less development on Ory, and nobody who runs Ory benefits from that.

What This Means If You Run Ory Open Source

You wait longer for security fixes than our customers do. We're not going to pretend otherwise.

The vulnerability is in the code you run whether the fix is public or not. An attacker can still find the same bug in the public code on their own. Publishing our fix early wouldn't protect you from that; it would make the bug easy to find for everyone else, while you're still exposed. With fixes published at release time, you get the fix and the advisory at the same moment the details become public.

Some things to plan for:

• Upgrade to each release. Fixes go into the latest release only.
• CVEs in third-party dependencies, such as the Go standard library, are public the day they're disclosed, and your scanner will flag them in the open source images until the next release. You can rebuild from a release tag with updated dependencies to close them sooner.
• If you need security fixes between releases, on SLA timelines, that's what the Continuous Security License is for.

Introducing the Continuous Security License

Alongside the new release rhythm, we are launching the Continuous Security License (CSL), a CVE-only subscription for self-hosted Ory Open Source. It gives you patched builds as vulnerabilities are resolved, on the same timelines as the Ory Enterprise License, instead of with the next open source release. You keep running Ory Open Source on your own infrastructure. The CSL covers security patching only, not enterprise features or dedicated support. It's priced per component, and non-production environments are included.

Which Edition Fits

• Ory Open Source fits evaluation and prototyping, and production use where fixes at release time with no SLA are acceptable.
• The Continuous Security License fits self-hosted Ory Open Source in production when you need CVE fixes on SLA timelines, but not enterprise support or features.
• The Ory Enterprise License fits when you also need 24/7 support, zero-downtime migrations and enterprise features, for example in regulated, certified or air-gapped environments.
• Ory Network fits when you'd rather not run Ory yourself. It always runs the latest version.

What Comes Next

Ory Network and the Ory Enterprise License are built on Ory Open Source, and the commercial editions pay for its development. Every release is published in full under Apache 2.0, together with its security advisories.

The first release under the new rhythm is planned for the first half of 2027. Thank you to everyone who builds with Ory.

Found a vulnerability? Report it through our security process.

Questions about the release rhythm or the security policy are welcome in the Ory Community Slack.

Interested in the Continuous Security License? Contact our team for more information.