Interactive Application Security: Frequently Asked Questions

Contrast doesn't neatly fall into either the static analysis (SAST) or dynamic analysis (DAST) categories most security experts ask about. Because of that, we often field questions about what exactly and Contrast does. This post will answer a few of those questions. If you have questions of your own, feel free to leave them in the comments below. We'll do another post addressing questions from the comments and emails we receive.

Question: What is the Contrast deployment model?
Answer: Contrast has two parts: an agent that is installed on your application servers and a centralized management dashboard called TeamServer. Contrast supports both SaaS and "on-premises" deployment models that deliver exactly the same application security functionality to end users.  On-premises Contrast installations can run their TeamServer like an internal SaaS to support many internal organizations or divisions.

Question: How scalable is Contrast?
Answer: Contrast is a distributed technology. There is no limit to the number of applications that can be continuously and simultaneously analyzed using Contrast. With Contrast, the application security analysis SLA is "real-time and continuous" even for a portfolio of hundreds of apps in development, test, and production. Contrast's continuous monitoring is a major differentiator from static and dynamic tools, and even from tools with an agent to assist a dynamic scan. If a new rule needs to be deployed, these legacy technologies will require a complete portfolio rescan -- months or years of work.  Contrast can push a new rule across the portfolio and have results in a matter of hours. Also, unlike static tools, there are no real limits to the size of application that can be analyzed with Contrast. We are monitoring many applications in excess of 20 million lines of code.

Question: Does Contrast support concurrent use among users?
Answer: There are no limits on the number of users with Contrast. All tasks are conducted in parallel across the entire portfolio. There are no licensing or imposed user capacity limits.

Question: Scanning Automation Level?
Answer: Contrast is designed for continuous hands free automation (and installation). Humans are involved in remediation of findings only. A REST API is available (free) that enables complete automation and automated integration into bug and build systems, analysis of findings, reporting…anything that can be done through the user interface.  Contrast even automatically discovers application architecture and libraries which are leveraged in its analyses.

Question: Does Contrast support configurable rules and scans?
Answer: First of all, Contrast doesn't scan; Contrast monitors. Custom rules can be created by users who are granted rights to do so. These rules can be applied to a single application or promoted across the entire application portfolio. Users can also configure Contrast to highlight certain results (by priority). Unlike scanners, enabling additional rules doesn't increase work or time, so most customers choose to activate all vulnerability detection rules and have Contrast prioritize them according to policy.

Question: Does Contrast have configurable scan options?
Answer: Contrast doesn't scan (sorry for the mantra). Contrast continuously analyzes applications in real-time for vulnerabilities.  No need to schedule, re-run, or even re-configure.  Once the Contrast Agent is installed on an application server, it automatically discovers new applications and changes to old ones. Contrast always provides an up-to-date application security dashboard across the entire portfolio and for each individual application.

Question: Can Contrast isolate and scan target code, or does it have to scan the whole application?
Answer: Yes, Contrast supports targeted scanning (even though we don't scan). Typically each developer will develop and test their own code locally with Contrast enabled. They can choose to see only those vulnerabilities coming from their test environment. This has two major advantages. First, developers only see the vulnerabilities from the part of the code that they are currently working on. Second, their results are not mixed up with other changes that were made to other parts of the codebase.

Question: We like having role-based access control in our current tool. Does Contrast support something like that?
Answer: Contrast provides a hierarchy of user roles, including Super Administrator, Administrator, API-user (for REST interface) and User. Each User can be configured with permissions for billing, rules administration, edit, and view.

Question: What percentage of your results can be tabulated as false positives?
Answer: Contrast researchers have discovered a new way to merge the power of static and dynamic analysis, weaving it directly into a running application.   From this new internal vantage point, Contrast has the context to see more security vulnerabilities more accurately than any other static or dynamic tools combined.

For example, Contrast identifies the full context for each transaction, including data-flow, control-flow, HTTP request/response, libraries, frameworks, back-end connections, and configuration files. We can even access the actual data values passing through the running code. This wealth of information allows Contrast to identify problems more accurately that other tools cannot.  This "fact-based" approach dramatically reduces false positives.

Further, Contrast performs "whole app" analysis, tracing data and execution through custom code, libraries, frameworks, and even the runtime platform. Static tools only see the custom code, and therefore generate large amounts of "lost sources" and "lost sinks" that lead to false positives. Contrast simply does not have these problems. In fact, the execution path for all vulnerabilities reported by Contrast is confirmed to have actually executed.

For example, Contrast's analysis approach can identify: credit card numbers extracted from a database and flag when they end up in a log file; a weak encryption algorithm specified in a properties file; and even data that flows from within an encoded cookie, through a data bean, into a session store, into a JSF component, and finally into a browser – indicating an XSS weakness. 

Question: So does that mean that Contrast eliminates false positives by verifying vulnerabilities in runtime? 
Answer: Contrast's unique and patented technology both detects and verifies vulnerabilities at runtime. No external scanner is required, which improves results and simplifies both deployment and operation. It's important to remember that Contrast can be easily used in development, test, staging, continuous integration, or production environments.

Question: How does Contrast Security stay on top of their research capabilities for new and emerging vulnerabilities?
Answer: Contrast founders and employees are the founders of OWASP and are the driving force behind many of the most successful OWASP projects, including the OWASP Top 10, ESAPI, WebGoat, XSS Prevention Cheat Sheet, and others. All of Contrast's employees spend some time on security research, which we share openly through OWASP. 

In addition, Contrast has partnered with Aspect Security, a leading application security company that has since been acquired by Ernst & Young (EY), to share research/consulting knowledge. Aspect has several dozen researchers/consultants analyzing hundreds of millions of lines of code and discovers thousands of vulnerabilities every year for the largest and most important financial, government and commercial institutions around the globe. Through this relationship, Contrast has access to the real vulnerabilities in real applications that drive useful new rules.

Question: Talk to me about Contrast's scan update frequency. How do scheduled and continuous scanning work in your tool?
Answer: Contrast runs in real-time on a fully continuous and automated basis. New flaws are discovered and updated on a continual basis.  For example, as soon as "Expression Language Injection" was discovered, the Contrast team quickly modeled the vulnerability pattern and pushed out rules to cover all the susceptible frameworks.

Question: How robust is Contrast? What is the maximum number of applications that can be simultaneously monitored?
Answer: There is no limit.  Any number of applications can be analyzed simultaneously, continuously, and in real-time.

Question: Does Contrast access binary or byte code, do semantic checking, or process complex data flow analysis?
Answer: Contrast uses byte code instrumentation to perform a variety of security checks, including complex data flow analysis. This includes ALL the libraries, frameworks, other components, and even the platform runtime libraries used in the application.  No changes are required to the development, build, test, or deployment process for the instrumentation to work, as all the information needed is available using the default compile steps.

Contrast doesn't require source code to perform a variety of security checks, including complex data flow analysis.  Many of these checks are performed statically, by analyzing source, binary, and configuration files on the server. Contrast provides the full runtime stack trace and exact source line of code for each event in vulnerability.

Question: What languages, language versions, supported frameworks, and application servers do you support?
Answer: The easiest way to answer those questions are for you to download the Contrast Datasheet, or read about it on our website.

Question: Let's talk about flaws. Does Contrast tell me the line number location on flaws?
Answer: Contrast also provides full traceability with the complete call stack (through both custom code and libraries), exact line of code, full runtime data trace, and originating HTTP request/response. Note that the exact line of code is provided for JSP, JSF, and other file types that are compiled into Java and then into byte code. Many solutions only provide the (useless) Java line number.

Contrast's custom rule capability provides support for a wide variety of custom security controls and business logic security analysis. For example, enforcing the use of a custom AccessControlManager from every Spring Controller is an easy rule to create.  Contrast also provides built-in protection against various rootkit techniques and backdoors. Because of this, Contrast can address business logic flaws, including enforcement of multi-factor authentication rules, backdoors, anti-fraud rules, etc.

Question: Can Contrast identify sensitive data? Does it allow for the creation of custom rules?
Answer: Yes, Contrast can identify sensitive data. It also allows for the creation of custom rules. Using custom rules, an organization can identify methods generating sensitive data, tag that data with an identifying label, and track that data wherever it goes within the application.

Rules can also specify whether data with certain tags is required and/or prohibited as parameters to other methods. You can also create custom rules that easily detection of virtually any pattern of method calls and data flow. Notably, this can be used to create both "positive" and "negative" rules.  "Negative" rules model a vulnerable pattern of behavior in the codebase.  "Positive" rules are intended to be used to codify enterprise secure coding guidelines by modeling "good" behavior.

In addition, Contrast performs data flow analysis over the entire application, including all frameworks, libraries, components, and the runtime itself. Solutions that only perform analysis over source code will have significant "lost sources" and "lost sinks" that lead to large numbers of false positives.

Question: Can Contrast test mobile applications? Third-party applications?
Answer: Contrast supports server-side mobile application testing.  Because Contrast instruments the running application, it is, for the most part, agnostic to the "presentation layer" of the application, and provides full analysis of the application logic. Thus, for example, mobile applications that leverage SOAP, REST, or HTML5 APIs are covered by Contrast. By the way, many of the most critical mobile application vulnerabilities are located in the server-side of these applications. Mobile application logic that runs on-device is not covered. See, we do have limitations. ;-)