OWASP Global AppSec EU 2026 Vienna

We analyzed CVE remediation patterns across 10,000 open source projects to uncover a critical problem: vulnerabilities fixed upstream often take weeks or months to reach downstream containers. This lag creates massive security exposure windows in Kubernetes environments.

In this talk, we'll present our findings showing how CVE fixes flow (or stall) across ecosystem layers, from upstream projects to package managers to base images to final containers. You'll see real metrics on remediation delays, and the compounding effect of layered dependencies.

But we won't stop at the problem. The second half focuses on practical solutions. From automated patch backporting to in-place image patching with tools like Copa. You'll learn how to build workflows that dramatically reduce MTTR, including dependency automation patterns and risk-based prioritization.

Attendees will leave with both a data-driven understanding of the CVE remediation challenge and a practical playbook for fixing it.

SBOMs are known to be at the forefront of modern strategies to ensure supply chain security. However, there are two key problems that traditional SBOM workflows do not solve: working with components that do not have well-established identifiers and the introduction of malware in the supply chain.

This presents a significant gap between the expectations of SBOM adoption and the real value it can deliver. This talk will explore the concept of applying continuous SBOM diffing as part of the CI process. Rather than analyzing an SBOM for each release as a standalone artifact, we can compute diffs and take actions based on whether something has changed from the previous component release.

This approach makes all SBOM components actionable, even those that otherwise seem meaningless. For example, if an individual file that is not part of any library appears in an SBOM, legacy approaches make it difficult to reason about such a file. However, with continuous SBOM diffing, tracking changes in such components becomes meaningful and therefore actionable. For example, if a new component file appears with an unknown origin, we can sanitize the build and conduct additional investigations into what happened.

We will also demonstrate practical examples of how to achieve such actionable workflows using open-source tooling.

Your API keys, business logic, database connections, sometimes even customer data and user information - might be all directly accessible from your IDE. This makes the IDE in one of the top spots for threat actors to try and break into.

Because the IDE has direct access to so much data, it makes your entire software supply chain to be as secure as a single extension, turning it to the weakest link in the chain.

It takes only one evil extension, one vulnerability or one prompt, to compromise your entire organization. We will explore how each of these attack scenarios can turn a developer’s workspace into a gateway for threat actors to exfiltrate customer data before a single line of code is even written.

We’ll dive deep into the IDEs architecture, starting from how IDE extensions are developed and their permissions stack, and how threat actors could manipulate extensions and IDE configurations to bypass security measures including the ability to exfiltrate valuable information from the developer’s IDE, then perform lateral movement directly after infection, and their ability to stay persistent even after being removed.
It's not just about threat actors hacking your IDE - they will go after everything in the organization that’s connected to it, and they will try to stay there as long as possible.

We’ll take a look at how threat actors could leverage vulnerabilities that lie in existing IDE extensions to execute remote code & exfiltrate information - transforming a developer's local machine into an under the radar backdoor of your organization. This includes our finding of multiple 0-day vulnerabilities in popular IDE extensions, and our research of weaponizing Chromium 1-day vulnerabilities on Cursor & Windsurf.

We’ll wrap up by giving the best practice recommendations for securing your IDE, avoiding evil extensions, adding company-wide policies and for approved extensions, and showing security teams how to integrate IDE security into their organization at scale.

SLSA (Supply-chain Levels for Software Artifacts) promises to secure your software supply chain—but implementing it at enterprise scale is harder than the spec suggests. This talk shares our journey to SLSA Level 3, including the architectural decisions, performance trade-offs, and customer escalations that shaped our approach.

You'll learn:
- Provenance attestation architecture for multi-tenant CI/CD pipelines
- How to integrate SLSA verification without breaking existing workflows
- Real metrics: what SLSA costs in CI minutes and what attacks it actually catches
- Common implementation pitfalls and how to avoid them

Whether you're just starting your SLSA journey or stuck at Level 2, walk away with battle-tested patterns that work at scale.

Whichever public cloud you use, there are literally hundreds of assignable permissions — and while everyone quotes the ideal of “least privilege,” just when the deadline looms it becomes far too tempting to grant “just one more permission.” Before you know it, your developer teams and service accounts are swimming in high privileges.

In this session we’ll start from the basics of structured permission management, then go deeper — all the way to time-limited access, rule-based privileged-access workflows, and on-demand role elevation. We won’t rehash each cloud provider’s security guide; instead, we’ll deliver pragmatic, maintainable, and flexible guidelines that balance solid permission hygiene with the realities of tight deadlines.

This talk is targeted at security engineers, cloud engineers or anyone just looking for a point to start organizing and structuring their permission approach.