Interview with Jeff Williams, Co-Founder of Contrast Security


Contrast Security, founded in 2012 is a leader and pioneer in application security. They help companies of all sizes secure applications in all phases of the software lifecycle; from development to production. The founders of Contrast Security know more about OWASP and OWASP Top 10 than anyone on earth, since they are the founders of OWASP. Many believe that FireEye, Palo Alto Networks and the WAF is the first line of defense, especially against the dreaded zero day vulnerability and advanced malware, when in reality the first line of defense is writing and deploying secure code from the get go. A big thanks to Jeff Williams for the interview and insight.

In what year will malware become artificially intelligent, where it can learn its environment and make tactical human like decisions without hacker intervention on how to penetrate a system? Think of malware program built with Google DeepMind AI type system?

It’s important to understand that there are three types of attacks:

  1. Attacks on known vulnerabilities, like those in CVE
  2. Attacks on previously unknown vulnerabilities using a known attack technique
  3. Attacks on previously unknown vulnerabilities using a previously unknown technique

The first two are already easy to automate because the attack techniques and target are known. So while some kind of AI might make this process more efficient, it doesn’t really change the risk for anyone.  That is to say that existing tools like metasploit and sqlmap are already sufficiently terrifying that I don’t see how adding AI will make them any worse.  You could add AI to your blender, but would it really help make it destroy food any faster?

But the last category is more interesting. Discovering previously unknown hacking techniques is a distinctly human process. There was a time before clickjacking, CSRF, and even buffer overflows. These attacks require a deep understanding of the intended behavior of the targeted program and the ability to identify ways of adversely affecting that outcome.

This process is far more complex than checkers, chess, or Jeopardy, and I don’t think we are anywhere close to AI that can achieve this level of insight.  To me it’s the exact same problem as finding loopholes in the US tax code.  Very difficult for humans means very very long time before computers can do it.

Do you help eliminate Zero day vulnerabilities in applications in the development phase?  Yes. Absolutely.  The power of instrumentation is that it works in the background during your normal software development activities.  Contrast dynamically instruments your entire application at runtime, including the platform runtime, application server, framework, and libraries.  Contrast watches your code as it runs and performs behavioral analysis to identify vulnerable patterns of execution.

You get protection against both known and unknown (0day) vulnerabilities.  And anyone can do it.  Just add Contrast to your development environment and you’ll get instant security feedback during coding, integration, and test. There are no changes required to you code, integrate, test, or deployment processes.

How did you come up with idea for Contrast Security? I spent years working as a security consultant, and I found thousands of vulnerabilities in corporate applications manually – doing code review and manual penetration testing.  I tried using static analysis tools and dynamic scanners of all kinds, but they never produced better results than I could do by hand in the same time period.  Nevertheless, most of my clients were overwhelmed with the amount of code they were producing, and desperately needed automation.

So I did a talk at BlackHat about what a malicious developer could do inside a major financial organization.  And one of the topics I covered was the use of software instrumentation to make attacks impossible to discover.  Essentially, the developer would instrument an attack into running application, steal money or data, and then take out the modifications — leaving no trace of their activity.

I realized that we could use software instrumentation to gather data from a running application and observe vulnerable behavior directly. This direct observation allows security analysis to include much more information than traditional techniques, such as the code, HTTP traffic, configuration files, libraries, frameworks, data flow, control flow, and most importantly back-end connections.  Basically everything a security analyst could ever want.

Using all this directly observed security intelligence, Contrast can discover a broad range of vulnerabilities with far better accuracy than legacy static analysis and dynamic vulnerability scanning tools. So we have finally made it possible for an ordinary software developer, tester, or architect to find and fix their own security vulnerabilities without require an expert to get involved.

If an application is developed for the Docker Container, does that change how security code review is done? We see a lot of Agile and DevOps projects that use Docker.  Doing manual security code review is a time-consuming expert-driven process that doesn’t fit well into these high-speed software development processes.

Contrast, on the other hand, works perfectly with Docker based applications. Simply include the Contrast agent in the deployment and it starts working automatically.  You can automatically pull the latest agent from the Contrast TeamServer via the REST API using curl from your Dockerfile.

What are the three biggest mistakes programmers make in the application development phase that result in vulnerabilities later on in production? The biggest issue is that many developers don’t work out their application “security story” in advance. The security story starts with a high level threat model and drives down to strategic defenses.  This tells developers that they need, for instance, to implement the X-FRAME-OPTIONS header to prevent clickjacking.  Otherwise they will have to come back later and build that into their applications later.  And retrofitting security is the most expensive way to do it.

Second, I think developers don’t establish a set of standard security defenses, and code up a bunch of custom ones. Building security controls that are correct, strong, and easy to use property is tricky.  I can guarantee expensive fixes later on for organizations that choose to build their own custom controls on an ad hoc basis.

Finally, I think not establishing continuous application security checking throughout the software development lifecycle is a critical mistake. What you want is immediate feedback to developers and testers throughout the development process.  If you wait until the end to do a big security scan or test, you will almost certainly find a lot of vulnerabilities that would have been almost free to avoid if they were caught earlier.

Scroll to Top