Analyze vulnerability events

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 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 policy 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.