Reviewing Static Flaws

Results and Reports

The triage flaws task allows you to review static flaws in the context of their local copy of the source code for the application. This section describes static flaws and explains how to:

About Static Flaws

Flaws found by static analysis represent potentially dangerous code paths in an application. Generally speaking, these fall into two categories: vulnerabilities and potential vulnerabilities. Vulnerabilities are exploitable weaknesses in the application, with a code path that can be found and exploited by an attacker to impair the confidentiality of the application, integrity, or availability. Potential vulnerabilities represent weaknesses in the application code that may not be exploitable by an attacker at the present time, either because the code path is unreachable or because some mitigating factor is in place in the code base. However, potential vulnerabilities may become true vulnerabilities in the future if the code architecture or deployment method of the application changes, or if the flawed code is called in another program.

Veracode Static Analysis uses debug information to report the source file and line number on which the flaw exists, aiding in remediation. Java and .NET applications can be analyzed in non-debug form, but the resulting flaws from a non-debug analysis do not have source file and line number information. Instead, information about location of the flaw is given relative to the module, class path, function name, and approximate location within the function body. See the compilation instructions for information on how to build your application with debug information.

Reviewing the Module Selection

If you have scanned this application before, you can view the differences between the files you uploaded last time, and the files you uploaded this time, so that you can verify you are reviewing the same files as the previous upload. For the most consistent results, Veracode recommends that you scan the same files between scans. From the Application Overview page, click Review Modules in the left navigation menu. The differences are displayed in a table called File Upload Information. See View Changes Between File Uploads for more information.

Viewing Static Results for an Application

To access static results, from the Application Overview page of the application, click Triage Flaws under the application name. Then, click Static under the application name, if it is not already selected.

To begin reviewing a portion of your results while the remainder of your application is scanned, click the View Partial Results link from the Application Overview page. See Viewing Accelerated Results for Static Scans for more information.

The table at the bottom of the page shows the flaw ID, severity, exploitability, CWE, location, source, number of data paths, status, and mitigation status.

You can click the triangle next to a flaw ID to view details about the flaw, including remediation guidance, flaw descriptions, links to software security resources, and links to recommended Veracode eLearning courses and tutorials.

The CWE ID & Name column maps the discovered flaw to the Common Weakness Enumeration (CWE) standard. If this flaw is stopping the application from passing policy compliance, the red shield icon indicates that a fix is required to meet the policy requirements.

Click a specific finding for Triage Flaws to prompt you to load your local copy of the source code into the Source Code view at the top of the page.

View Data Path Information for Flaws

You can view all paths through the code that lead to the sink, the exploitable point where a flaw is expressed, from a link on the Triage Flaws page.

Steps

  1. From Triage Flaws, click the link in the Data Paths column.
  2. The Data Path tab opens, where you can view each path that leads to the sink.
  3. To view details about a specific data path, select a path from the left panel.
  4. Details are displayed for each path, including the steps taken to exploit the flaw, filename or class, function name, and line number or relative location of the flaw by percentage.
  5. Fix each exploitable data path to remediate the flaw.

Use the Source Code View

The Source Code view allows you to load source code from your local system (or a network-accessible directory) into Triage Flaws so that you can view information about the flaw in the context of your original source. To use this feature you must be using an HTML5-supported browser. You can also use a browser that utilizes Java plugins, but Veracode does not recommend using Java. Read Veracode Browser Requirements for security guidelines for avoiding the use of Java.

Note: The Veracode Platform does not have access to the source code for the application, and the source code is not uploaded to the Veracode Platform when you view it in the Source Code view.

Steps

  1. Select Source Code Viewer radio button at the top-right of the page, if it is not already selected.
  2. Select a flaw.
  3. If you have not previously loaded source code for this application, the Platform prompts you to locate the source code on your hard disk. The fully qualified path of the source code that you used to build the application is shown for reference.
  4. The Platform loads the source code and scrolls the file to the line of code containing the flaw. If you selected the wrong source file, you can click Load Different File to change it.
  5. Hovering over the annotation on the left-hand column allows viewing a detailed description of the flaw and a remediation recommendation.

You can also scroll through the code to view other flaws in the same source file, or use the Goto Line field to jump to a particular line.

Viewing Flaws Found in Non-debug Code

The Veracode Platform allows you to view flaws found in code without debug symbols. As source file and line number information is unavailable for these flaws, the Platform presents other location information.

In the Flaws tab, the Source column contains the function prototype containing the flaw and the approximate location in the function body, by percentage where the flaw occurs.

Clicking one of the flaws allows you to open a source file for reference. You are prompted with the name of the class path containing the flaw.

Matching Filenames in Scans

The Veracode Platform attempts to match uploaded application files that appear to be related to a source file, but may have different build or version numbers. By matching these files, Veracode can track flaws across different builds without falsely reporting any new flaws because the name of the container changes between scans.

The matching scheme examines only the last characters of the filename preceding the file extension. Consider these sample files:

  • myapp-123.dll
  • myapp-124.dll

Veracode recognizes these files as different versions of the same file because they contain the same base name, myapp. Only the trailing numbers 123 and 124 at the end of the filename are different.

These filenames do not match the previous filenames because the final part of the names contain alphabetic characters:

  • myapp-123-test.dll
  • myapp-124-test.dll

In some circumstances, this filename matching scheme may encounter problems. You might upload files that appear to match and Veracode does not match them. Consider an application that has multiple, similar files in the build, such as:

  • function-1.dll
  • function-2.dll
  • function-3.dll

In this scenario, flaw-matching can encounter problems between scans when Veracode matches them as versions of the same file although they are unrelated. Depending on which file the Veracode Platform finds first, the module listing for the scan identifies code added or removed because these files contain different code.

Veracode recommends that you append alphabetic characters to the end of the filename to avoid ending the filename with numerals.