Q. What email notifications will I get from CA Veracode? A. CA Veracode keeps customers up to date with scan and overall service status via email. CA Veracode users will receive emails when: Password is changed, Pre-scan verification is complete, Scan is submitted, and Scan has completed.
Q. What is pre-scan verification? A. The CA Veracode platform performs a preliminary analysis, or Pre-Scan, of your binaries to validate that they can be analyzed and to give you an opportunity to fix problems with the uploaded files before submitting your scan request. The results of the Pre-Scan verification are given as messages in the module table; summary information appears as you select modules to be scanned.
During pre-scan, red and orange informational messages will be shown in the status column. Red messages prevent proceeding with scanning the corresponding module only. Orange messages indicate issues that should be corrected to ensure an accurate scan, but which do not block analysis from proceeding. Green messages indicate that all is well with the associated module. If there is a failure CA Veracode will attempt to provide details on why the failure occurred and how to resolve it.
One example of pre-scan helping to resolve failures is the identification of missing dependencies that are referenced by the uploaded files. The output of the pre-scan will tell you what binaries are missing and will give you the option to upload them. In some cases binaries will need to be uploaded in order to provide a complete picture of the application for analysis. Other times it will be optional to upload the dependency, since the scan can complete without the additional information it provides.
After you resolve a pre-scan warning you will need to resubmit the affected files or libraries to the CA Veracode platform. If you need to re-upload binaries, or upload new binaries, click the Back or Add Files button, locate the files to be added, and upload them.
You do not need to wait for pre-scan verification to complete, as you will receive an email notification that you can return to the platform to select modules to scan. Refer to the CA Veracode help center for more information on Pre-scan error messages and application submittal error codes.
Q. What is the difference between a Flaw and a Vulnerability? A. A CA Veracode scan highlights flaws discovered in a submitted binary. It is important to understand that not all flaws will be exploitable vulnerabilities. A flaw is a potential vulnerability. A flaw is a pattern that is flagged in the analyzed binary that is indicative of a vulnerability.
A vulnerability is a hole within the security of a system caused by software flaws, incorrect configurations and/or insecure user behavior. Vulnerabilities can cause the software to work contrary to its documented design and can be exploited to cause the system to violate its documented security policy. An exploit is something that takes advantage of a vulnerability to either gain unauthorized access or do damage to a system.
The nature of static analysis means the scope of CA Veracode’s assessment is limited to the binaries that are submitted to the CA Veracode platform. The static binary analysis engine models the binary executable into an intermediate representation, which is then verified for security flaws using a set of automated security scans. This modeling occurs in isolation as the submitted application is not running in a live environment. After the model is created, CA Veracode security scans look for patterns that are indicative of vulnerabilities. When a pattern is found it is flagged. Every pattern that is flagged is a flaw in the applications source. A flaw is a potential vulnerability. However, not all flaws will be exploitable vulnerabilities.
There are a number of reasons why a flaw will not always be an exploitable vulnerability: 1. A flaw may not be an exploitable vulnerability if it is flagged in a part of the code that is not easily reachable by an attacker. 2. CA Veracode consider anything external passing in data to the application to be un-trusted. However, when the application is running in its live environment it is not always the case that data it receives will be un-trusted. 3. A flaw may require certain privileges in the application to be a vulnerability. 4. A mitigating control external to the application code may prevent exploitation of the flaw.
Let’s expand one of the examples above – Input data may not be trusted: CA Veracode considers input data the application receives from a database to be untrusted however this data may be trusted within the context of the application. For example, when untrusted data is received by an application, eventually the data may get concatenated into a SQL statement in an unsafe fashion, and then the query is executed. This is an example of the pattern a CA Veracode scan looks for. However, the scan can’t take into account contextual knowledge of the application.
To recap the important distinction between flaws and vulnerabilities: A flaw occurs when a scan finds a pattern indicative of a type of vulnerability. The gap between flaws and vulnerabilities occurs because a static binary analysis cannot take contextual knowledge of the application into account. CA Veracode scans look for patterns, to accept or know if a flaw is a vulnerability or not, additional knowledge is required that a static analysis does not have.
Q. What flaw categories do you look for? A. The flaw categories we look for increases all the time. Contact Us for the latest list. Examples of flaw categories that are scanned for include: • Input Validation: Command Injection, SQL Injection, Cross-Site Scripting, Log Forging, CRLF Injection, Path Manipulation • Memory Corruption: Stack/Heap Overflow, Format String Vulnerability, Unchecked Array Indexing, Improper Null Termination • Numeric Errors: Integer Overflow/Underflow, Signed-to-unsigned Conversion, Off-by-one Error, Numeric Truncation • Cryptographic Issues: Hardcoded Crypto Keys, Failure to Encrypt Sensitive Data, Insufficient Entropy • Others: Hardcoded Passwords, Missing XML Validation, Unchecked Return Value, Information Leakage, TOCTOU Race Conditions, Malicious Code and Backdoors, Rootkit-like Behavior, Time Bombs, Anti-Debugging, Data Exfiltration, Code and Data Anomalies
CA Veracode’s core innovation is our static binary analysis technique that operates on the executable. The static binary analysis can be performed without exposing the underlying source code. In order to perform binary analysis, customers securely upload their executables to the CA Veracode platform. After the analysis is performed, results are delivered back to customers via the platform.
Static Binary Application Security Testing is similar to a line by line code review without requiring source code. A scan examines the compiled binary at implementation time to detect security flaws. This type of analysis creates a model of the entire application and analyzes all the particular things an application can do. As part of this the analysis examines the applications data and inter-procedural flows. If untrusted data enters the app CA Veracode can trace the data path through all the possible control flow paths it might take. An analogy used in the industry to describe this type of analysis is “looking at the code from the inside out”.
Static binary analysis has distinct advantages in that it can evaluate both web and non-web applications, and through advanced modeling, can detect flaws in the software’s inputs and outputs that cannot be seen through penetration testing alone. By examining a compiled form of an application in its runtime environment, Static Binary Scanning can provide a more comprehensive picture of real-world vulnerabilities. Performing binary code reviews reduces concerns surrounding intellectual property contained in source code and is applicable to situations where access to source code is not available, as is the case with commercial software, legacy applications or many offshore outsourced applications.
Q. Why should I use CA Veracode instead of a desktop source code analyzer? A. CA Veracode is out to change the world of software by solving this application security challenge in a fundamentally different and better way. Our cloud-based application risk management services platform offers the industry’s most complete, accurate and easy to use application security testing, elearning and application intelligence services. Our innovative binary analysis technology and delivery model allow those who develop software and those who purchase software to cost-effectively assess and manage risk from their software infrastructure be it internally developed, outsourced, open source or commercial applications.
In addition, customers whose applications achieve a high level of security quality are eligible to be listed in the VERAFIED software directory and use the VERAFIED quality seal. The VERAFIED Software Directory identifies software applications from Independent Software Vendors (ISVs), Service Providers and Enterprises that have earned the VERAFIED or VERAFIED HIGH ASSURANCE security marks. The VERAFIED security marks signify that a software provider has taken appropriate steps to remove vulnerabilities in their software or to comply with respected industry standards such as the OWASP Top 10 or the CWE/SANS Top 25 Most Dangerous Software Errors. A VERAFIED mark and Directory listing provides insight into the security quality of the software similar to the insights provided to their customers by independent organizations such as Standard and Poor's and Consumer Reports.
Q. Why do I need to package my java app as a war file? A. CA Veracode expects Java web applications to be submitted in a standard WAR format. This is so that, regardless of the application server technology being used, CA Veracode can correctly analyze the data and control flow of the application and understand the application boundaries. CA Veracode understands standard J2EE application packages, including JAR, WAR, and EAR.
Q. How long will it take to get my results? A. CA Veracode performs a fully automated scan on uploaded applications, including constructing a model of the data and control flow and identifying any flaws. The turnaround time depends on the size and complexity of the application, but on average CA Veracode analyzes 75% of all uploaded Java applications in six hours or less.
Q. You marked a cross site scripting flaw when my application was writing data to a web page that came from my file system/database, rather than from a web-based input vector. Isn’t this a false positive? A. There are two primary kinds of attack vectors for cross-site scripting (XSS): reflected XSS and persistent XSS. The former kind is easier to demonstrate because the vulnerability can be exposed through the web directly, usually by inputting a specially crafted attack string into a form field, query parameter, or header value. Persistent XSS, on the other hand, requires the attacker to embed the attack string in a persistent location (usually the file system or database), where the application will read it and expose it to an end user. Reflected XSS is more common, but persistent XSS is more insidious because many developers trust the integrity of their filesystem or database and do not take appropriate measures to sanitize data coming from these sources before displaying the information to the user. If a persistent XSS attack succeeds, the attack will be exposed to any user who visits the site, without needing to target victims individually. Security best practices dictate that a layered defense be used, first ensuring that data is written safely to persistent storage, then ensuring that the data is securely sanitized or encoded for display.
Q. I only see the source file and line number where the issue exists. How can I tell where the attack is coming from? A. Each cross-site scripting flaw in the CA Veracode service carries two types of information: the location at which the flaw is exposed to the end user, and the data or control flow through which a tainted attack string travels to reach the vulnerable part of the code. You can view this control flow in the Call Stack view. To access the Call Stack view: 1. Click on the flaw for which you want to view the call stack. 2. Click the Call Stack tab at the bottom of the list of flaws. 3. The call stack is presented with the line of code at which the attack is output to the user at the top (marked END), and the point at which the attacker’s data enters the application at the bottom (marked START). 4. You can click on each line in the call stack to view the progress of the attack data through the code.