Two keynotes on the first morning of Open Source Summit Europe 2026 in Prague told the same story from opposite ends. AI has made finding vulnerabilities fast and cheap. The hard part is now everything that happens after the report lands.
I photographed both keynotes from the Congress Hall. These are my notes, with the numbers as they appeared on the slides.
In the Congress Hall during the Wednesday morning keynotes.
A spike nobody could ignore: 42 OpenStack advisories
The first slide needed no explanation.
OpenStack published a handful of security advisories per year from 2021 to 2025. In 2026 the bar jumps to 42. OpenStack did not suddenly become less secure. What changed is that AI-assisted vulnerability discovery now produces reports faster than a volunteer security team can triage them.
The response presented on stage was to organise the defence:
The Open Secure AI Alliance brings industry players together on AI safety and security by sharing research, developing open techniques, tools and models, and safeguarding software and agents in the age of AI. The slide framed it as two jobs: pooling resources to deal with incoming security reports, and developing shared, open defensive infrastructure for the AI era.
SAFE: learning from agentic incidents without blame
The alliance’s first initiative is the Shared AI Findings Exchange (SAFE).
As presented:
- It proposes guidelines for turning lessons from agentic cybersecurity incidents into stronger protection across the AI ecosystem.
- It is a confidential incident-learning and assurance initiative, not an enforcement body.
- The RFC has concluded, and the SAFE guidelines are due to be published in late October.
The background text on the slide is a good line to steal for your own incident policy: AI systems will make mistakes, safeguards will sometimes fail, and a responsible ecosystem is measured by how quickly it contains harm and turns each incident into stronger protection. If you run agents in production, you will want a way to share near misses without exposing customers. SAFE is worth watching for that reason alone.
OSERA: when banks stop fixing the same CVE alone
The second keynote came from the financial sector. OSERA, the Open Source Enterprise Resiliency Alliance, is a FINOS initiative and part of the Linux Foundation. Its pitch starts with a sentence every platform engineer in a regulated company will recognise.
“In a bank, a dependency upgrade is not a pull request.”
It is a change record, a regression run, a risk acceptance and an audit trail, multiplied by thousands of applications. The slide listed the reasons fixes get stuck: change control and release windows, regulatory evidence for DORA, NIS2 and the EU CRA, competing priorities (around 70% of bank IT budgets go to keeping legacy running), and “the fork tax”: 1 in 5 financial institutions maintain private forks of the same project and re-create the same fix.
The supporting numbers, with the sources shown on the slide:
- 92% of codebases carry open source components 4+ years out of date, and only 7% of components in use are the latest version (Black Duck OSSRA 2026).
- 6 in 10 security incidents hit where a patch already existed but had not been applied.
- Only 1 in 3 institutions are confident that the components they consume are maintained and current (FINOS State of Open Source in Financial Services, 2024).
The slide’s closing line: patching is the easy half; consuming fixes at scale, safely, with evidence, across the estate, is the half nobody had mutualised.
Why now: “Patchmageddon”
This slide cited J.P. Morgan’s Patchmageddon analysis (2026) and other sources:
- ~48,000 CVEs were published in 2025, up 20.6% year on year, about 131 per day. AI-driven discovery is pushing 2026 well beyond that trend.
- The average time from disclosure to first exploitation is 0 days. About 78% of exploitations now begin on or before disclosure day.
- ~3,900 high and critical open source vulnerabilities were surfaced by a single “Mythos-class” model preview (Anthropic disclosure, May 2026, via Patchmageddon).
- 66 CVEs landed in a single month on one framework family (Spring, June 2026). CVE waves, not single CVEs, are the new operating condition.
The C-suite message: yesterday a known-but-unpatched backlog was a tolerated risk. Today boards and regulators want evidence, not intent.
The model: public source, FSI-grade releases
OSERA’s flow has three steps. A known CVE in a package and version is surfaced and prioritised across firms (only anonymised package and version tuples leave a bank). A vetted vendor maintainer produces and tests the fix under an alliance SLA and the upstream licence, accepted through a Remediation Standards gate. Then a signed, FSI-grade release ships with VEX and test evidence, pulled through the bank’s existing proxy with the same coordinates and zero CI changes.
It is sovereign by design: neutral Linux Foundation and FINOS governance with one firm, one vote; every backport open source; no commercial end-of-life cliff. The releases are meant to be time-bound, a managed bridge to a supported version, not a licence to stay behind.
After 100 days, the slide reported:
- 6 premier members: Citi, Deutsche Bank, Goldman Sachs, Morgan Stanley, NatWest and RBC. Three of the six are outside the US.
- 3 weeks to publish v0.1 of the open Remediation Standard.
- 50+ lines under management, with Spring and its transitive closure patched with standard attestations.
- 0 CI changes for the bank pilots.
- Partners and contributing vendors include Moderne, Control Plane, Sonatype and Scott Logic. Chainguard, Docker, HeroDevs and RapidFort have joined FINOS since OSERA launched.
Next on the roadmap: 80 or more patches a month under SLA, the first end-to-end OSERA platform release at OSFF New York on 4–5 November, and remediation standards for other ecosystems. For the Remediation Standards themselves (verifiable patches, provenance and VEX), see my deeper look at FINOS OSERA: patch once, verify everywhere.
My take
Both keynotes say the same thing. The bottleneck has moved from finding bugs to absorbing fixes. AI finds vulnerabilities at machine speed; humans still approve changes at committee speed.
What I would take back to a platform team:
- Measure time-to-consume, not just time-to-patch. How long does a fixed upstream version take to reach production in your estate? That number is now your exposure window.
- Stop maintaining private forks alone. If 1 in 5 banks run private forks of the same project, the same is true in your industry. Find the shared effort and join it.
- Automate the evidence. VEX, SBOMs and signed builds are what turn a patch into something an auditor accepts. The CRA SBOM requirements are a good place to start.
- Plan for CVE waves. Size your pipeline for 66 CVEs in a month on one framework, not one critical a quarter.
More from Prague: the State of Open Source in Europe report, my notes on trusted agentic workloads, and the full recap.
