1. Home
  2. Docs
  3. Learning Center
  4. Detecting Bugs and Vulnerabilities

Detecting Bugs and Vulnerabilities

GUARDARA supports three methods to pick up unexpected behavior during test runs. These can be utilized separately or in combination. We are discussing these methods below.


This method allows detecting when the target becomes unavailable or unresponsive at any step of the test execution. The target under test could become unavailable or unresponsive, for example, because of a crash, unhandled exception, or data corruption. The benefit of this detection mechanism is that it is easy to configure and allows detecting some issues in an entirely black-box fashion. This approach becomes unreliable, for example, when testing multi-threaded applications where each test case may be handled by a new thread. In such a case, even if a thread crashes, the target remains available and ready to serve the subsequent request. Connection-based detection is configurable by adjusting the properties of the Actions within Test Flow templates.


This method allows picking up unexpected behavior by looking at the response received from the target under test. GUARDARA provides a very powerful way to analyze responses received from the target and detect unexpected behavior: Response Processing Rules. Response processing rules are multi-purpose. They can be used to influence the testing process or to detect unexpected behavior. The general approach to response processing rules regarding issue detection is very similar to classical software testing methodologies, such as unit testing or user acceptance testing. First, we define how we expect the target to behave under normal circumstances. GUARDARA then feeds the target with unexpected data, so the defined processing rules can pick up if the target does not behave as expected.

The Heartbleed demo demonstrates the power of processing rules very well. In the demo, we use advanced response processing implemented using a Callback. During the test:

  1. We are sending dynamically generated (mutated) TLS heartbeat messages
  2. We use the Callback to check if the heartbeat response is compliant with the specification

As a result of #2, GUARDARA picks up that the target’s behavior goes against the specification: the heartbeat response payload is not identical to the payload sent in the heartbeat request. In the report, GUARDARA shows the actual payload (basically, the proof-of-concept exploit) that triggered the issue.


Monitors are GUARDARA extensions that allow monitoring the state of the target(s) under test to detect anomalous behavior in ways not possible with the methods discussed previously.


Was this article helpful to you? Yes No