With Only a Hammer, Everything Looks Like a Security Vulnerability!

Did you know that most security vulnerabilities are simply the result of failing to use the right security control in the right place?   For example:

• SQL Injection - failure to use parameterized query
• XSS - failure to do context-sensitive escaping on data
• CSRF - failure to use a token on state-changing requests
• DOR - failure to strictly validate a direct object reference
• etc...

Vulnerabilities *are* mistakes with security controls

When we studied the root cause of vulnerabilities across thousands of applications, we discovered something very interesting...

Whoa!  55% of the vulnerabilities in custom applications happen when the security control isn't used. In 35% of those instances the control isn't there at all.  And the other 20% of the time, the control is present, but the developer fails to invoke it.  The rest of the vulnerabilities are caused by a control that doesn't work properly or isn't used properly.

Accurate security vulnerability detection requires identifying custom security controls 

So how does one automatically find these vulnerabilities? Well, what you want to do is look for places in the code that should have these controls, but don't.  The problem is that if you can't see the controls, everything looks like a vulnerability.  This is one reason that tools like static analysis (SAST) tools and dynamic scanners (DAST) have trouble analyzing real applications.  Unless you teach them about all of the custom security controls, they can't tell what's safe and what's not.

There are a few widely used security controls, like Struts Validator, Java Cryptography Extension, ESAPI Encoder, and others. However, the vast majority of security controls are custom written code. There could be dozens or hundreds of these custom methods in a typical application (including all the libraries and frameworks it uses).

If your security vulnerability analysis tool doesn't know about these controls, it will report vulnerabilities that don't exist. You could "teach" your legacy tools about all these controls by creating custom rules, but the process is so complex that most organizations don’t have staff capable of doing it effectively.

Fortunately, now there's a better way...

Automatically detecting security controls at runtime

We're proud to announce automatic discovery of custom security controls in our latest release.

We have discovered a way to identify security controls by analyzing the application at runtime. After three years of research we're bringing this technology to fruition in our latest release.  Essentially, Contrast automatically analyzes the code in your applications and automatically identifies security controls. 

The "Security Controls" tab is just one small part of Contrast's easy-to-use security policy management features. Our goal is to provide complete visibility and control of application security across your entire application portfolio.

Once enabled, Contrast's powerful rule engine uses the knowledge of these custom controls to enhance securityvulnerability detection. For example, a custom HTML encoding control might set a "html-encoded" tag on any data that flows through it. When that data flows into a dangerous "trigger" method, such as a method that sends a SQL query to a database, Contrast uses its knowledge of the control to recognize that the wrong escaping method was used and that there is still a real vulnerability.

Automatically identifying custom security controls is just one more way Contrast is advancing the state of the art in security vulnerability analysis.

Try Contrast, free for 14-days and see for yourself how Contrast enables applications to continuously test themselves for vulnerabilities — without experts.