OWASP Global AppSec EU 2026 wrapped at the Austria Center in Vienna on June 26, capping a week that began with three days of training and ended with two days of talks, and it landed on a fitting milestone: OWASP turned 25 this year, and the conference was rebuilt around that anniversary with redesigned tracks, a project demo lab, interactive pods, a dedicated mobile security track, and the usual capture-the-flag. More than 800 practitioners came through. The single sentence I would use to summarize the two conference days is this: AI stopped being the novelty track and became the lens through which almost every other AppSec problem was discussed, from supply chain to identity to the question of who, or what, is now writing the vulnerable code.
The setting, and why the 25th anniversary framing mattered
The Austria Center is a large venue, and OWASP used the space to run several parallel tracks plus workshops on level minus two and level two, a project demo room built for longer hands-on conversations, and MobileAppSecCon, effectively a half-day conference within the conference spearheaded by the OWASP MAS project. The anniversary was not just a t-shirt. Twenty-five years in, OWASP's center of gravity has visibly shifted from "here is a list of the top ten web risks" to "here is how you run a security program, measure its maturity, and keep it honest as the software underneath it changes shape." That shift is the real story of the week, and the AI conversation rides on top of it.
A practical note for anyone planning attendance next time: the training days, June 22 to 24, were where a lot of the depth lived, with multi-day courses from well-known instructors running alongside the OWASP SAMM user day. The two conference days are for breadth and serendipity; the training days are for skills. Budget for both if you can.
Theme 1: AI security moved from a sidebar to the main argument
The clearest trend was that AI security is no longer a single curiosity slot. It was threaded through the whole program, and notably it showed up on both sides of the table: AI as the thing you must secure, and AI as the thing doing the securing.
On the "secure the AI" side, the OWASP AI Security Verification Standard, AISVS, had both a talk and a hands-on workshop, which signals that the project has matured past the manifesto stage into something teams can actually test against. Sessions like "From Safety to Policy: Enforcing Organizational Rules in LLMs and AI Agents," "Effort is All You Need: Testing LLM Applications in the Real World," and "Teaching AI Agents Like Guide Dogs: A Progressive Trust Framework" all circled the same hard problem: an LLM-backed application has a non-deterministic trust boundary, and our existing verification habits assume deterministic ones. The progressive-trust framing, treating an agent like something you train and supervise rather than a function you call, was the most useful mental model I took away.
On the "AI is now in your estate whether you authorized it or not" side, "Infrastructure Doesn't Lie: Using Infrastructure Signals to Detect Shadow AI Built Applications" was a standout premise: you may not be able to inventory shadow AI by asking, but the infrastructure it runs on leaves signals you can detect. That reframing, from policy to telemetry, is going to matter a lot over the next year.
And then there was the question nobody could resist: "Who Really Writes More Vulnerabilities," a session squarely aimed at the human-versus-AI-generated-code debate. The honest takeaway from the corridor conversations afterward was not a scoreboard. It was that AI-assisted code shifts the distribution of defects rather than simply raising or lowering the count, which means our detection has to shift with it.
Theme 2: the attack surface scaled faster than our mental models
If AI was the loudest theme, supply chain and surface growth was the most sobering. "Insecurity as Code: How Modern Software Scaled the Attack Surface" named the thing directly: the same practices that let us ship faster, infrastructure as code, generated configuration, package-everything, also let us scale our exposure faster, often invisibly.
Two sessions made that concrete. "Marketplace Takeover: One Bug Away from Pwning 10 Million Developer Machines" was the kind of talk that makes a room go quiet, because the blast radius of a single compromised distribution point in a developer ecosystem is the entire downstream population. And on the defensive side, the OWASP CycloneDX work, including a workshop that literally walked SBOMs from static documents into queryable, conversational artifacts, made the case that a software bill of materials is only useful if you can ask it questions in the moment you need answers, not file it for an audit.
The conclusion I keep coming back to: most organizations still cannot answer "which of our systems contain component X at version Y" in minutes, and almost every major incident of the last two years has hinged on exactly that question. The SBOM conversation has finally moved from compliance theater to operational necessity, and the tooling shown in Vienna is starting to catch up.
Theme 3: the program is the product now
A quarter century in, OWASP's maturity-and-program track has real weight. "From Maturity to Mastery: Accelerating Software Security with OWASP SAMM," the companion "Using OWASP SAMM and OWASP DSOMM together in practice," "Enforcing Application Security Policies at Scale: Lessons from an Enterprise Rollout," and "Security Champions: Lessons from Opposite Trenches" all spoke to the same audience: the person who has the scanners and the findings and now has to turn that into a functioning, measurable program that survives reorgs and tool churn.
The recurring honest admission across these sessions, and OWASP deserves credit for cultivating a culture where people share failures, was that tooling is the easy part. Policy enforcement at scale, getting security champions to stick, and keeping a maturity model from becoming a box-ticking exercise are the hard parts, and they are organizational, not technical. The talks that drew the warmest response were the ones describing what did not work, which is exactly the content you cannot get from a vendor datasheet.
Theme 4: what pentests miss, and the attacker's view
The most quietly important talk title of the conference, for me, was "What Our Pen Tests Never Found, And How Attackers Did." It is the whole argument for continuous, attacker-aligned validation compressed into a sentence. A point-in-time pentest is scoped, time-boxed, and human-limited; real attackers are none of those things. Pair that with "CHAMELEON-REN," advancing the OWASP Web Application Honeypot project with adaptive behavior, and "Updates on the OWASP Automated Threats Project," and a clear message emerges: the defensive community is leaning hard into understanding automated, adaptive adversary behavior rather than modeling attackers as occasional manual testers.
This is the same shift we have written about repeatedly: from periodic assessment to a continuous loop that re-checks whether your defenses still hold as your code and environment change underneath them. Vienna confirmed it is now mainstream thinking, not a vendor talking point.
Theme 5: identity and cryptography refused to be background noise
Two areas that sometimes get treated as solved got sharp, current talks. On identity, "Why IAM Remains a Challenge and What We Can Do About It" was a refreshingly unromantic look at the fact that identity and access management is still where a huge share of real-world compromise begins, and "Phishing for Passkeys, An Analysis of WebAuthn and CTAP" punctured any complacency that passkeys are a finished story, examining the seams in the standards we are all migrating toward.
On cryptography, "Q-Day is Cancelled: Practical Strategies to Defeat Harvest Now, Decrypt Later" was a usefully calm counter-narrative to post-quantum panic, focused on what teams can do today about adversaries who record encrypted traffic now to decrypt later. And "The TPM and You" made the case that hardware roots of trust most of us already own go almost entirely unused. None of these are headline-grabbing, all of them are the kind of foundational hygiene that quietly decides whether the rest of your security program stands on anything.
What I am taking back to how we build
Five conclusions worth carrying out of Vienna, each of them transferable beyond any single talk:
- Treat AI-backed features as a new trust boundary, not a new feature. The verification habits that work for deterministic code do not transfer cleanly. Adopt the emerging standards (AISVS is the obvious starting point) and test LLM applications against adversarial input as a first-class activity.
- Your SBOM is only as good as your ability to query it under pressure. Generate it continuously, keep it current, and make sure someone can answer the "which systems contain component X" question in minutes, because that is the question every supply chain incident asks.
- The program, not the scanner, is the deliverable. Maturity models, security champions, and policy enforcement at scale are organizational problems. Budget for the human work, and learn from other teams' documented failures rather than rediscovering them.
- Assume attackers are continuous and automated, and validate accordingly. A pentest that ran once last quarter is a snapshot. The honest question is what an adaptive adversary would find today.
- Do not skip the boring foundations. Identity, passkey rollout seams, post-quantum planning, and unused hardware roots of trust are unglamorous and decisive. The flashy talks were about AI; the talks that will save someone from a breach were about IAM and crypto hygiene.
How this maps to how Pragma Core is built
A useful test of any conference is whether its themes match the direction you have already bet on. For us, Vienna read less like a set of surprises and more like the AppSec community converging on the model the Pragma Core platform was designed around: continuous, AI-driven, and focused on how risk flows across components rather than on isolated findings.
Continuous SBOM and dependency tracking, ready for the query you cannot predict
The CycloneDX sessions argued that an SBOM is only valuable if it is current and answerable on demand. Pragma Core generates a full component inventory per repository with CycloneDX export, and tracks vulnerable packages across every connected repo with CVSS data and fix paths. That is precisely the "which systems contain component X at version Y, and what is the upgrade" capability that the marketplace-takeover and supply chain talks made urgent.
AI security research, applied to the new non-deterministic trust boundary
The AISVS and LLM-testing track is about verifying systems whose behavior is not fully deterministic. Pragma Core's autonomous AI agents are built to reason over how input and state move through an application, which is exactly the muscle you need when the dangerous boundary is an agent or model rather than a single function. As AISVS matures, this is the part of the platform that grows with it.
Continuous, attacker-aligned validation instead of point-in-time pentests
"What Our Pen Tests Never Found" is the thesis behind our white-box pentest and adversary emulation pillars: source-assisted testing and breach-and-attack simulation aligned to the live MITRE ATT&CK matrix, running continuously rather than once a quarter. The conference framed periodic assessment as insufficient; that is the gap the platform is built to close.
Call graphs and SAST tuned for how the surface actually scaled
"Insecurity as Code" described an attack surface that grew across functions, services, and generated configuration. Pragma Core's interactive call graphs and tunable static analysis are aimed at exactly that: finding the issues that live in the relationships between components, the ones a single-file scanner misses because the defect is in the wiring, not one line.
Closing thoughts
The honest conclusion from OWASP Global AppSec EU 2026 is that the field's center has moved. Twenty-five years ago the work was teaching developers that web applications had a security model at all. Today the work is running a continuous, measurable program over a surface that is scaling faster than any team can manually track, with AI sitting on both sides of the fight. The conference did not resolve that tension, and it was better for not pretending to; the most valuable rooms were the ones admitting what did not work.
What separates teams that treat a week like this as inspiration from teams that treat it as a to-do list is AppSec maturity and visibility into their own code and dependencies. Organizations that want to move from "we scan and report once in a while" to "we continuously and systematically verify what is fragile, in our code, our dependencies, and our defenses" can reach Pragma Core at pragma-core.com for a demo.
Sources
- OWASP Foundation, OWASP Global AppSec EU 2026 (Vienna, Austria), event listing and tickets, owasp.glueup.com.
- OWASP Foundation, OWASP Chapter Vienna and About OWASP, owasp.org.