Discover Vulnerabilities

Contrast discovers any code flaws that are in your applications. These vulnerabilities are presented and classified with a severity level to help you prioritize and mark the vulnerabilities as needed. The Vulnerabilities page allows you to browse, search and filter through all an application's vulnerabilities. Click on each vulnerability for more details, including guidelines for determining how to resolve them to prevent an attack.

How It Works

If a vulnerability is reported and Contrast has never seen it before, Contrast creates a new entry for that vulnerability. However, if that vulnerability already exists, Contrast updates the existing entry, issue count and number of days since it was last detected.

Example: A vulnerability was reported to Contrast twice for one server. Instead of displaying each instance as a separate vulnerability, Contrast updates the existing entry and increments the count. Go to the Notes tab within this vulnerability to see a list of the servers in which this vulnerability was found.

View Findings

Contrast shows you all the vulnerabilities it's discovered including SQL Injection, Cross-Site Scripting (XSS), Command Injection, Path Traversal, XML External Entity Processing (XXE), Cross-Site Request Forgery (CSRF), Java Deserialization and many more. Go to the main Vulnerabilities page to see all vulnerabilities across your portfolio, or go to the Vulnerabilities tab from the application's overview page to see a list of all vulnerabilities found in that application.

Note: For Contrast to find weaknesses and present findings, you must also exercise your application. You can then track, share and get remediation guidance for each vulnerability that Contrast reports.

The grid of discovered vulnerabilities provides basic information on each one, including:

  • Type, status and severity of the vulnerability
  • Tutorial on how to fix it
  • Line of code
  • Ability to replay the attack

Vulnerability status

Contrast uses the following statuses for vulnerabilities to help you prioritize and manage findings.

  • Reported: The default for all discovered vulnerabilities.
  • Confirmed: A user triaged the vulnerability and flagged it as a definitive risk.
  • Suspicious: A user found a vulnerability that requires more investigation to determine its validity.
  • Not a Problem: Contrast requires a justification for this status. For example, the vulnerability is found to be a false positive or goes through an internal security control.
  • Remediated: The vulnerability is considered closed, but could be reopened (and returned to Reported) if rediscovered.
  • Fixed: The vulnerability remains closed even if rediscovered, and will never be reported again.
  • Auto-remediated: Contrast automatically remediated a vulnerability based on a Remediation Policy set up by an administrator.

Read how to Analyze Findings, and learn more about vulnerability statuses and workflows in the Contrast UI.

Vulnerability severity

Contrast classifies vulnerabilities in an application into five severity levels. The classifications are based on the likelihood and impact of a vulnerability in the application, from most to least severe:

  • Critical
  • High
  • Medium
  • Low
  • Note

Vulnerability Notes

In each vulnerabilities' Notes tab, Contrast provides further details about the identity, timing and location of the vulnerability, such as:

  • Build numbers
  • Reporting servers
  • Category
  • Security standards

To learn about changing vulnerability status, severity and other features, read how to Manage Vulnerabilities.

Analyze Findings

The process of triaging vulnerability findings can depend on several factors, such as your specific security concerns, assessing the risk to the application and eliminating false positives. Contrast also provides options to modify attributes of findings - such as changing severity levels or merging - when appropriate.

Vulnerability Behaviors

For each reported vulnerability, you can mark a status and create tags as needed. The following chart describes each possible status and behavior when a vulnerability is initially discovered and marked as well as how it's marked if found again.

Status Description Behavior If found again
Confirmed A user has confirmed that the vulnerability is a true finding by reviewing the source code or exploiting it. Open No change
Suspicious The vulnerability appears to be a true finding based on the details provided in the Contrast application, but requires more investigation to determine its validity. Open No change
Not a Problem The vulnerability is being accounted for without any source code changes. The user must provide one of the reasons listed below when setting this status. A vulnerability set to this status will not revert back to Reported if found again.
  • URL is only accessible by trusted power users: This vulnerability may only exist in specific environments, such as QA, and may not exist in Production environments.
  • False positive: This vulnerability was reported incorrectly. Contact Support to figure out why Contrast flagged this trace as a vulnerability.
  • Goes through an internal security control: There is custom, corrective code inside the application that will prevent this vulnerability from being exploited.
  • Attack is defended by an external security control: There is another component in the environment, such as a WAF, which will prevent this vulnerability from being exploited.
  • Other: Any reason not listed for which Contrast doesn't need to make any source code changes to fix this vulnerability.
  • Closed (requires justification) Stays Closed
    Remediated The vulnerability has been fixed by changing source code or config files within the application. Closed Reopened as Reported
    Reported The default status of a vulnerability after it's discovered by Contrast. The dataflow could be a possible exploit in the application. Open No change
    Fixed The vulnerability has been fixed by changing the source code or a reason given under the Not A Problem status. A vulnerability set to this status will not revert back to Reported if found again. (Available to Admin only.) Closed Stays Closed
    Auto-remediated Contrast hasn't found the vulnerability in a set amount of time, and assumes that it's been fixed, based on your Remediation Policy configuration. (A user can't apply or change this status.) Closed Reopened

    Vulnerability Events

    Contrast provides information on what it observed when navigating your application, including the exact location in which the vulnerability was found in the code and how the code was used.

    Source events

    The first event in the vulnerability is likely a source event, or the start of a scope. You can use the file and line number of the source event to see exactly where the call was made, and use the stacktrace in the source to understand how the program invoked the notable method. You can also view all the data related to the method, including the:

    • Object: The underlying object instance on which this call is invoked (if not a static call).
    • Return: The object returned from this call (or null, if void).
    • Parameters: The objects passed into this call.

    Propagator events

    Each vulnerability may contain one or more propagation events. These events contain the same information as the source event, but they also have a type that indicates how the data was propagated.

    Example: A P2R propagator takes the data from one or more of the parameters (the "P" in "P2R") and transfers it into the method return value (the "R" in "P2R").

    Tag events

    The vulnerability may also contain one or more tag events. Tag events are events that add a tag, such as validated or html-encoded, to a vulnerability. These tags help eliminate false positives and provide clean, reliable results. They also contain the same contextual information as the other types of events. While tag events may occur within a vulnerability, they have nothing to do with the vulnerability discovered.

    Trigger events

    The trigger is the last event in the vulnerability. The trigger is the call that makes the rule engine in the Contrast JVM Plugin perform its analysis, notice the vulnerability and generate the trace.

    False alarms

    Contrast only detects the actual behavior of an application. If a vulnerability doesn't represent a legitimate problem, an administrator should update the applicable polcy to prevent this issue from occurring again. The most commonly reported false alarm is that the application has a custom control that Contrast doesn't know about.

    Customers with Enterprise-on-Premises (EOP) licenses can add a custom method call to the appropriate tag list in the Contrast policy.

    Example: Your custom HTML-encoder method that takes a string and returns an HTML-encoded string should add the html-encoded tag to the data.

    Manage Vulnerabilities

    Contrast users can manage vulnerabilities based on their organization or application role. Certain functions are available from the Vulnerabilities page, a vulnerability's Overview tab, or an application or server's Vulnerabilities tab, as noted.

    Vulnerability Status

    To change the status of one or more vulnerabilities, select the checkboxes in the grid rows, click the Mark as button and choose a new status from the dropdown menu. You may add comments to logged status changes to provide more context. You can also click on a vulnerability, and change its status from the Overview tab.

    See Analyze Findings to learn more about statuses and behaviors when a vulnerability is marked and found again.

    Vulnerability Severity

    Hover over a vulnerability's severity level in any Vulnerabilities grid to see the Likelihood and Impact calculations. To change the level, click on the colored badge and choose the new selection from the dropdown menu.

    Filter Vulnerabilities

    Contrast provides multiple ways to narrow findings and focus on the vulnerabilities that matter to you. Use basic column sorting to arrange vulnerabilities in a grid, or use the fields above the grid to quickly find one by its vulnerability ID, the date range in which it was found or other criteria. Click the Advanced link for access to more filters including tags, servers and environments.

    Pending Vulnerabilities

    If an administrator requires administrative approval to close vulnerabilities, vulnerabilities with the specified statuses and severities go into a Pending state when you attempt to close them. Administrative approval applies to vulnerability updates by two-way bugtracker integrations as well as auto-remediation policies.

    When you attempt to close a vulnerability that an administrator must approve, you must provide an explanation for the status change. Once completed, Contrast confirms that the closure is pending an administrator's review.

    Once Contrast confirms your request, the vulnerability is marked as Pending in the grid. Hover over the label to see more information about when the request to close was submitted. To see all vulnerabilities awaiting review in your organization, select the Pending Review quick view from the dropdown.

    Note: You may change the status of a pending vulnerability. If approval isn't required for the new status, the vulnerability is no longer marked as Pending.

    You will receive a notification when your request to close the vulnerabilities is approved or denied. If denied, the vulnerability will go back to its previous state; but, the administrator must provide a reason for the decision, which appears in the vulnerability's Discussion tab.

    Review status changes

    To approve or deny vulnerability closures as a Contrast administrator, click on the link in your UI notification or navigate to the Pending Review view in the grid.

    To review vulnerability closures from the grid, select one or more vulnerabilities to review. Click on the Review button in the batch actions menu, and select Approve or Deny. You can also go to a vulnerability's Details tab, and click the Review button in the actions menu to approve or deny its closure.

    If you deny the status change, you must provide a reason in the confirmation dialog. Your reason is then documented in the vulnerability's Discussion tab. The vulnerability automatically reverts to its previous status. If you approve the status change, the user's request is marked as "Approved" in the Discussion tab.

    Merge Vulnerabilities

    Contrast allows you to merge vulnerabilities of the same type to consolidate findings. From any Vulnerabilities grid, select two or more vulnerabilities you'd like to merge, and click the merge icon in the action bar. In the confirmation dialog that appears, select the vulnerability that you want to represent the merge.

    Delete Vulnerabilities

    To delete one or more vulnerabilities, select the checkboxes in the grid rows, and click the trash can icon in the action bar above the grid. You can also delete a single vulnerability by clicking the trashcan icon in the row dropdown menu or in the vulnerability's Overview tab.

    Once this action is confirmed, the vulnerability is removed and no longer appears in your list unless Contrast discovers it again.

    Track Vulnerabilities

    You can send vulnerabilities to a bugtracker from the Send Vulnerability (paper plane) icon located on the Vulnerabilities page, or from the Vulnerabilities tab of an Application Overview page. In the dialog that follows, choose which information should be included when exporting the findings.

    Note: Bugtrackers must be configured before you send vulnerabilities.

    When a vulnerability is sent to a bugtracker, the status of the vulnerability changes to Reported in the Vulnerabilities page or the Vulnerabilities tab of the Application Overview page. An arrow icon also appears beside the status in the grid row for the vulnerability. Hover over this icon for more information, including the bugtracker name(s) and corresponding ticket number(s).

    To quickly see which vulnerabilities are being tracked, click the Advanced link, select Status in the sidebar, and filter for "Being Tracked".

    Export Findings

    Export details on vulnerability findings by selecting the grouping of vulnerabilities that you want to include in the report, and clicking the Export icon to choose either CSV or XML format.

    The exported file contains the following data fields for each vulnerability:

    • Vulnerability Name
    • Vulnerability ID
    • Category
    • Rule Name
    • Severity
    • Status
    • Number of Events
    • First Seen
    • Last Seen
    • Application Name
    • Application ID
    • Application Code
    • CWE ID
    • Request Method
    • Request Port
    • Request Protocol
    • Request Version
    • Request URI
    • Request Qs
    • Request Body

    Custom reports

    For users looking to craft custom software composition analysis reports about their applications, the vulnerability export feature might not provide sufficient information; however, Contrast offers a rich Application API which gives you access to Contrast vulnerability data. Reference the Contrast RESTful API documentation > Application Trace Filtering > /ng/{orgUuid}/traces/{appId}/filter section for instructions on using the Application API.

    You may also explore additional details on your vulnerabilities using a manual method.

    Example: This cURL request retrieves a list of vulnerabilities that also shows a list of the applications in which each vulnerability was found. The jq tool formats the data as CSV for use in a custom report.

    curl \
        -H "Authorization: $(echo -n $username:$servicekey | base64)" \
        -H "API-Key: $apikey" \$orgid/orgtraces/filter?expand=request | \
        jq -r '.traces[] | {uuid: .uuid, protocol: .request.protocol} | [.uuid, .protocol] | @csv'

    For more information, read About the Contrast API.

    Track Findings

    Contrast gives you the ability to send vulnerabilities via bugtracker integrations or by email to notify users who don't have access to Contrast. Integrations allow you to plan and maintain timely patching to protect against attacks, as well as streamline your workflows by sending vulnerabilities directly to your tool to orchestrate standard development processes. You can also have Contrast notify you if it finds any new high or critical vulnerabilities in your application.


    Contrast offers integration with the following bugtrackers:

    • JIRA
    • Bugzilla
    • Serena Business Management
    • VSTS/TFS

    Organization administrators can set up any of these bugtrackers and other integrations - including Slack, HipChat or any generic WebHook integration - by going to the User menu> Organization Settings > Integrations tab. To read more about each option, go to the Integrations section.

    Custom Processing

    Vulnerability data can also be dumped to a CSV or XML file for custom processing. From the Vulnerabilities page, select all or any number of vulnerabilities, and click the paper airplane icon to export them into a spreadsheet.

    If you want to gather this data outside of the interface, Contrast also provides robust APIs where you can explore even more information. Read the Vulnerabilities API for more details.

    How to Fix Them

    Find information on solutions and techniques as well as best coding practices to resolve a vulnerability by delving into Contrast's overview of the issue which will explain why it was flagged. Contrast also provides a How To Fix section which gives steps on resolving the issue.

    Check a Fixed Vulnerability

    You fixed your vulnerability, but how can you verify that in Contrast? There are a few things you can do from the application page:

    • Replay the request: If the issue is remediated and marked accordingly, you can replay the HTTP request under the HTTP Info tab in the Vulnerabilities tab to see if the issue is fixed. If it isn't fixed, the issue reappears with a status of Reported.
    • Check build number: For each application, you can assign it a build version number. By adding the property -Dcontrast.override.appversion to the -javaagent command, you can use this as a filter and verify whether the issue still exists for this build version by clicking the Advanced link and the Build Number dropdown.
    • Check by time unit tests: You can also filter by the time at which your unit tests were run, and set a date range to view your vulnerabilities in the Set Date Range input field above the vulnerabilities grid.

    You can find additional properties in articles on Java Agent System Properties and .NET Agent Configuration.