There’s a major problem in application security: Organizations secure code before release, but attackers strike in production. This gap is exactly where runtime application security comes in.

In his DevOpsCon Munich keynote, Backbase CISO Brian Vlootman explained how this reality shapes defense for Backbase, a modern banking platform that runs on top of customers’ aging core systems. Banks rely on Backbase to deliver digital banking experiences even when their legacy cores are hard to modernize or staff. That dependency raises the stakes in production, and Vlootman showed why prevention alone cannot protect live banking applications.

What follows are the five security learnings he laid out, including the case for Application Detection and Response (ADR). Use these links to jump to each section:  

Learning 1: Why ADR belongs in production

Most teams run EDR on hosts but leave applications undefended.

Learning 2: Why SDLC prevention cannot close production risk

Shipped flaws and new CVEs still reach live banking systems.

Learning 3: How defensible architecture limits attacker movement

Restrict reconnaissance and lateral movement in cloud native banking apps.

Learning 4: How ADR detects and blocks exploitation at runtime

Follow untrusted input through live execution and stop attacks instantly.

Learning 5: How ADR changes production visibility and CVE triage

Ground truth on real exposure, real endpoint usage and real dependencies.

Learning 1: Why ADR belongs in production

At DevOpsCon Munich, CISO Brian Vlootman asked the room two questions.

1. Who runs EDR in production? Almost every hand went up.
2. Who runs ADR (Application Detection and Response) in production? Almost no one moved.

His point landed instantly. The entire industry protects hosts in production, but leaves live applications unguarded, even though that is where attackers strike. Backbase could not accept that blind spot. What followed was his five-lesson playbook for defending real banking applications under real attack.

Client input → application runtime → sensitive sink (for example, a database call)

If the input turns malicious along that path, ADR can block the exploit in real time. SQL injection was his concrete example.

The takeaway is simple. Host-level detection is now standard in production. Application runtime detection is not, even though exploitation actually happens in the application layer.

Learning 2: Why SDLC prevention cannot close production risk

Backbase first built a prevention-heavy SDLC program. The baseline he described included:

• Developer security training to build secure coding habits and prevent basics like SQL injection

• OWASP-based application security requirements, extended for banking and regulatory expectations
• Map likely threats to mitigations early in threat modeling and define how you will validate those mitigations later.
• Layered SDLC tooling that spans SAST for first-party code, SCA for open source libraries, dynamic testing once environments exist, and internal plus external penetration tests before release

Some controls only work once the application is running in a real environment. Without that full runtime context, including real traffic paths and real service interactions, those controls cannot be tested or trusted.

That is why Brian pushed back on “shift left” as a blanket rule. His point was to do the right security at the right time in the SDLC, because some controls only make sense at the end of the lifecycle. He made the same point about tools. Backbase dropped an early SAST tool because the findings were so noisy that developers could not clear them, so the tool was adding security debt instead of reducing risk.

Even with a mature prevention program, he called out an “uncomfortable truth” that AppSec teams have to plan for. The SDLC still focuses on prevention and vulnerability hunting before release. That work is necessary, but it does not close the production risk.

1. Some vulnerabilities still reach production.

   Prevention tools and processes miss things. Vulnerabilities can slip past SAST, threat modeling, and reviews, then ship anyway.

2. Open source can become vulnerable after release.

   A build that is safe today can become unsafe tomorrow when a new CVE drops. That turns production back into an exploit surface, even if release day looked clean.

He tied both gaps to Backbase’s shift into SaaS. Once you operate the platform, you own production risk and customer data protection continuously, not just at release.

Learning 3: How defensible architecture limits attacker movement

The first production answer he described was Defensible Security Architecture. It starts from assuming production is under constant attack. When a vulnerability is exploited, attackers gain access, but exploitation is not automatically game over. Attackers usually need time for reconnaissance, foothold and lateral movement. He said that a window can last hours, days, weeks, or even months. Defensible architecture is designed to exploit the attacker’s post-exploit window. It limits how far an attacker can move after landing and makes any abnormal movement appear quickly as a high-signal event.

He made the approach concrete in cloud native microservices:

• Start with the business flow. If service A only needs to talk to services B and C, restrict it to B and C.
  
  
• Avoid flat networks. Without restrictions, attackers can land on one service and run cheap reconnaissance across every downstream service.
  
  
• Write network policies that match real application logic. Enforce them so that only intended service-to-service paths exist.
  
  
• Treat violations as high-fidelity detection. A policy break should never happen during a regular operation, so it is a strong indicator of attacker activity.
  
  
• Apply the same idea to endpoints. If service A only needs 20 of service B’s endpoints, scope access to those 20. Attempts to reach the other 80 become another clear signal of compromise.
  
  

Resilience and compliance rationale

He linked defensible security architecture to cyber resilience and EU DORA. The posture assumes compromise, reduces blast radius and keeps unaffected components operating. Detection engineering sits within the same layer, prioritizing logs and alerts for events that should not happen. Those exceptions produce the highest fidelity signals.

Two Backbase security principles he highlighted:

• Bounded least privilege. Least privilege fails if stolen tokens still work anywhere. His example was sender-constrained tokens. If a token leaks, only the server that issued it can use it, limiting attacker reuse.
  
  
• Purpose-driven, secure by design. Secure by design has to anticipate long-horizon threat shifts. His example was post-quantum cryptography pressure beyond about 2030, when RSA and elliptic curve cryptography will no longer be acceptable. He argued for crypto agility now so algorithms can be swapped when standards change.
   

Learning 4: ADR instruments live applications to detect and block exploitation at runtime

After laying out prevention and a defensible architecture, he added ADR to Backbase's production runtime control.

ADR mechanics at runtime

ADR is deployed as an agent beside the software already running in production. That agent instruments what is going on inside the application. It can trace how client-supplied input flows through live execution to sensitive operations such as database calls. When the runtime path exhibits malicious behavior, such as an injection attempt, ADR can block the exploit on the spot.

Threat model and coverage scope

He ties ADR to two production facts:

1. Attackers target production, not staging. Even representative staging environments are not where real exploitation occurs, so runtime defense must sit in production, where the attacks occur.
2. Production exposure comes from first-party code and third-party libraries. ADR applies to both, including vulnerabilities that were unknown at release and new CVEs that open exploit paths before a patch is ready.

In his model, ADR sits behind the SDLC as the runtime layer that catches exploitation-prevention misses and exposure that occurs after shipping.

Learning 5: How ADR changes production visibility and CVE triage

ADR is more than a runtime exploit blocker. Once the agent runs in production, it gives two kinds of ground truth that SDLC tools cannot: what the live application is actually exposing and which dependencies are actually executing in memory. That production data reshapes how AppSec teams scope risk and prioritize CVEs.

1. Endpoint exposure, measured in production

   ADR shows which endpoints are really exposed and reached in production. He said teams often rely on what developers think is deployed or what documentation claims is exposed. Production data can show a delta. ADR replaces assumptions with runtime truth about the live attack surface.

2. Dependency usage, measured in memory

   ADR shows which open source libraries are loaded into memory at runtime. His Spring example was specific:
• A Spring-based build may pull roughly 150 transitive dependencies.
• About 60 percent of those may never load into memory in production.
• CVEs tied to those unused libraries exist on paper, but the code is not executed.

3. Operational implication

   He tied this visibility back to his opening point that EDR is common in production, while ADR is not. Leaving production applications without ADR, he said, is like running a laptop without EDR.

4. Proof it finds what prevention missed

   Backbase validated ADR through a proof-of-value. The first finding was an SQL injection in production that had been present for years and had survived previous AppSec tooling. He concluded that prevention is necessary but not perfect, so production needs runtime control to detect and block exploitation when it occurs.

5. Key use case: Legacy banking applications that can’t be patched.
   

   He closed on legacy systems that can’t be patched. The usual controls are segmentation, a tightly controlled WAF and long-term risk acceptance. ADR changes the calculus because it can be deployed at runtime without code changes and still detect and block exploitation in production.

Final takeaway

Runtime defense has to be engineered in layers, not bolted on after prevention fails.
Brian’s DevOpsCon model was layered.

• Prevent hardening in the SDLC.
  
  
• Assume compromise and build a defensible architecture.
  
  
• Run ADR in production to block exploitation of what slips through or becomes vulnerable later, especially in open source and legacy applications.