Analyze vulnerability events
Contrast provides information on what it observed when navigating your application by using vulnerability events. These events include the exact location where the vulnerability was found in the code and how the code was used. There are several types of events:
Source events: Source events occur at 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.
Propagation 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. For example, a P2R propagation event 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: These events 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.
Important
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.
On-premises users can add a custom method call to the appropriate tag list in the Contrast policy. For 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.
You can use Security controls or Application exclusions to remediate false positives.