Jeff Williams, Founder of OWASP and Founder & CTO of Contrast Security – Interview Series

Jeff Williams, Founder of OWASP and Founder & CTO of Contrast Security, is widely regarded as one of the most influential figures in modern application security. Over the past several decades, he has helped shape how organizations approach secure software development, vulnerability management, and runtime application protection. Williams played a central role in building OWASP from a small volunteer initiative into a globally recognized nonprofit security foundation, contributing to landmark projects such as the OWASP Top Ten, WebGoat, ESAPI, ASVS, and the XSS Prevention Cheat Sheet. Before founding Contrast Security in 2014, he also founded Aspect Security, one of the earliest firms dedicated exclusively to application security consulting, training, penetration testing, and secure development practices for enterprise organizations.

OWASP is a nonprofit foundation focused on improving software security through open-source projects, global community collaboration, education, and industry standards. Founded in 2001, the organization has become one of the most important authorities in application security, with hundreds of local chapters, thousands of contributors, and widely adopted resources used by developers, security professionals, enterprises, and governments worldwide. OWASP is best known for projects such as the OWASP Top Ten, which identifies the most critical web application security risks, alongside numerous security frameworks, testing tools, documentation projects, and training initiatives. The organization operates with a vendor-neutral philosophy, making its educational resources and security guidance freely accessible to the global technology community.

Contrast Security is an application security company focused on protecting software from within the running application itself rather than relying solely on external scanning tools. The company’s platform uses runtime instrumentation technology to provide real-time visibility into vulnerabilities, attacks, APIs, open-source dependencies, and application behavior across development and production environments. Its offerings span areas such as Interactive Application Security Testing (IAST), Application Detection and Response (ADR), Runtime Application Self-Protection (RASP), and software composition analysis. Contrast Security has positioned itself around integrating security directly into modern DevSecOps workflows, enabling developers, AppSec teams, and security operations teams to identify and remediate vulnerabilities faster while maintaining rapid software delivery cycles.

After helping shape modern application security through your work with the Open Web Application Security Project (OWASP), what gap in the industry led you to found Contrast Security, and how has that original thesis held up as security challenges have evolved?

The industry was drowning in theoretical static findings and unable to focus on the issues that actually matter. Security teams had scanners generating massive backlogs without knowing which vulnerabilities were reachable, exploitable, or under attack in production. We founded Contrast on a simple idea: security decisions should come from directly observing actual running applications, not guessing from the outside.

Ultimately, I hope the industry progresses to the point where we get off the hamster-wheel of finding problems, fixing them, and finding more forever.  I’m hopeful we can start creating software that has a strong security architecture and a real argument that it has the right defenses for the expected threats.  The combination of runtime security and AI has the potential, but we are years away.

You have described the emergence of “Mythos-level vulnerabilities.” What defines this new class of risk, and why are they so difficult for conventional security tools to detect?

Mythos-level vulnerabilities are flaws that emerge from the complexity of modern software stacks. The interaction between framework behavior, dependencies, and architectural patterns is so complex that developers often don’t fully understand it.  Conventional tools are still optimized for relatively simple known patterns and observable events. Mythos-style vulnerabilities often require understanding application behavior, execution flow, and runtime context at a much deeper level.

Why do entire categories of vulnerabilities fail to generate alerts in modern Security Operations Center (SOC) environments, and what does that reveal about how security teams currently measure risk?

Most SOCs are built around observable events: logs, signatures, network traffic, endpoint activity. But many application-layer attacks never produce meaningful signals in those systems. The developer didn’t know there was a vulnerability and didn’t add any logging that would reveal an exploit.  So most application exploits are completely invisible in logs.  SOC  teams can only respond to what they can see.  So as the application and API layer becomes increasingly important, it’s critical to ensure that we instrument it with security sensors that can detect and report anomalous behavior.

Modern application architectures such as microservices, APIs, and serverless systems have evolved rapidly. Where are these architectures outpacing current detection-based security approaches?

These architectures shattered the old perimeter model. Requests now traverse dozens of services, ephemeral functions, APIs, queues, and third-party dependencies before completing a transaction.  Most detection systems still see fragments instead of the full execution path. They can inspect packets or logs, but they can’t understand intent, data flow, or whether dangerous code actually executed.  Security is about context, so we need to build a model, a digital twin, of our application infrastructure that enables us (or AI agents) to reason about what we see happening.

The OWASP Top Ten continues to highlight issues like insecure design and vulnerable components. Why do these risks persist despite widespread awareness and tooling?

Awareness doesn’t fix incentives or complexity. Most organizations still measure success by scan volume, ticket closure, or compliance checklists rather than actual exposure reduction.

At the same time, software supply chains exploded in size. Developers assemble applications from thousands of components they didn’t write and certainly didn’t evaluate for security. Security teams are overwhelmed trying to triage theoretical risks and can’t focus on the 1-2% that actually matter. Without runtime evidence, prioritization breaks down.  And with the emergence of powerful AI models and harnesses, the volume is increasing exponentially.

How should organizations rethink their reliance on logs and alerts when some of the most critical vulnerabilities leave no observable signals?

Logs are evidence of what applications choose to report, not necessarily evidence of what actually happened. That’s a dangerous distinction.  Organizations need to shift from indirect observation to direct observation. Instead of hoping an exploit creates a detectable artifact, security systems should identify the vulnerable behavior and the exploit behavior at runtime. If dangerous code executes, the system should know immediately — whether or not a log entry exists.

You have advocated for runtime visibility as a solution. What does true runtime visibility look like in practice, and how does it change the way security teams operate on a daily basis?

True runtime visibility means understanding what the application is actually doing in production: which routes are exposed, which libraries are active, where sensitive data flows, what code executed, and whether an attack reached vulnerable functionality. Operationally, it changes security from a reactive hunting exercise into a precision discipline. Teams stop chasing massive vulnerability backlogs and start focusing on the small percentage of exposures that are reachable, critical, and actively targeted. That dramatically improves signal-to-noise ratio and response speed.  On average, only 38% of open source libraries packaged in an application are actually loaded into memory and executed.  And not all the code in this subset is used.  So one simple thing that runtime security enables is a focus on the code that actually runs, and not all the unused libraries and functions that come along with an application.

How does instrumentation-based security compare to traditional approaches such as SAST, DAST, or perimeter monitoring in terms of effectiveness and scalability?

Traditional tools infer risk from the outside. Instrumentation observes reality by observing the actual code as it runs.  Instrumentation can see actual execution paths, framework behavior, authentication context, data flow, and exploit success in real time. It eliminates huge categories of false positives and exposes vulnerabilities that perimeter tools completely miss.
At scale, that precision becomes critical. Organizations cannot manually triage millions of theoretical findings anymore. Runtime evidence is becoming the only sustainable filter. Runtime works in realtime, so it’s a better match for development and CI/CD pipelines than scanning and triaging.  And runtime is continuous, so you’re not limited to a snapshot point-in-time view of security.

As AI systems and autonomous applications become more prevalent, do these invisible vulnerabilities become more dangerous, and how should teams prepare?

AI makes invisible vulnerabilities much more dangerous because it accelerates both sides of the problem. Developers are generating software faster, and attackers are finding and exploiting weaknesses faster. But most security programs still rely on human-in-the-loop processes that cannot operate at AI speed.   Teams should prepare in two ways. First, build stronger runtime defenses that can detect, block, and contain attacks in production while vulnerabilities are being fixed. That gives organizations air cover. Second, use AI and automation to write more secure code in the first place — with better design, testing, review, and verification. Otherwise, we are just creating risk faster than we can manage it.

If you were advising a modern Security Operations Center (SOC) leader today, what are the first concrete steps they should take to close this visibility gap before it leads to a major breach?

First, accept that perimeter telemetry alone is insufficient for modern application security.  In fact, it is impossible to see or stop many application and API attacks at the perimeter.  The SOC needs visibility inside running applications, not just the infrastructure that hosts them.  Second, prioritize runtime evidence over theoretical findings. Focus on vulnerabilities that are in active code, identify active attack paths, and exposed services actually executing in production.  Finally, unify application security and detection engineering. The future SOC cannot treat applications as opaque black boxes anymore. Applications are now the primary attack surface, and they need first-class visibility at runtime.

Thank you for the great interview, readers who wish to learn more should visit OWASP or Contrast Security.