Production Safety

If you prefer to read the entire WhiteHat Service Definition section in PDF format, you can view or print here.

WhiteHat Dynamic services have been designed from the very beginning to be extremely safe for production web applications. Our maxim at Synopsys is "Do no harm" or, put more casually, we like to ask "Is this important?" before running a scan, rather than asking "Was that important?" afterward. By default, WhiteHat Dynamic operates "production-safe." This means that WhiteHat Dynamic only performs tests that will not permanently change the state of the system. So, you can be confident that we will safely scan your production business websites during business or high-traffic hours. To make sure we maintain little to no impact on your application, we’ll need you to let us know if any of the following exists on your application:

  • State-changing functionality performed via GET request

  • Areas of the application or specific functionality you’d like us to refrain from testing

Key Features

In addition, we have implemented three key features that are unique to WhiteHat Dynamic that ensure that our testing remains completely safe for your production websites.

  1. Customized Configuration

    The Synopsys Threat Research Center (TRC) manually reviews your web application and customizes WhiteHat Dynamic testing for safety and thoroughness. Every input, state changing request (POST request), or sensitive functionality is carefully analyzed by a human TRC engineer. Our engineers check this functionality first for safety, then for depth and coverage.

    This is especially applicable to administrative level functionality—things like create/delete users or groups. This kind of functionality is deemed unsafe to test in an automated fashion and WhiteHat Dynamic will be configured not to place these sensitive requests. Instead, a security engineer can check this functionality by hand in order to ensure little to no impact on the application. Examples of functionality that are commonly deemed unsafe:

    • Creation and deletion of users or data

    • Contact us features that involve sending email

    • Updating/Editing Profile or account data

    • Leaving comments or forum posts (Submit functionality)

      When an input or area of functionality is deemed safe for automated testing, a security engineer configures WhiteHat Dynamic to submit valid data in order to get further into the application.

      Customized Configuration Example: A website has a "create user" page that requires a valid address and email address in order to successfully complete. A security engineer recognizes that these inputs are required and trains WhiteHat Dynamic to submit valid information in order to get through this page. This action is repeated as long as the submitted request is deemed safe until the functionality is thoroughly covered. As part of the configuration process, TRC engineers also examine every link discovered by WhiteHat Dynamic to ensure overall coverage and to streamline the automated assessment for safe and efficient scanning.

  2. Non-Invasive Testing

    Many scanners bombard your site with hundreds or thousands of simultaneous requests, running the risk of negatively affecting or even bringing down the site being tested. Instead, WhiteHat Dynamic uses single-threaded requests during the automated portion of the web application assessment; much like a real user, WhiteHat Dynamic sends a request to your website and waits for a response before submitting the next request. In addition, by default WhiteHat Dynamic will place a maximum of four requests per second for a given set of credentials. (You can control this cap from the WhiteHat Portal interface.) This approach ensures that your production sites never receive an unexpected heavy load of requests coming from our scanner.

  3. WhiteHat Dynamic Will Not Execute Live Code

    By leveraging customized testing methodology unique to WhiteHat Dynamic in combination with our TRC’s vulnerability verification process, WhiteHat Dynamic is able to detect vulnerabilities safely without executing live code on your web application. You are guaranteed that WhiteHat Dynamic will never execute live code in an automated fashion on your website. This greatly reduces the chance of negatively impacting the application.

Tracking Our Assessment Activities

As well as these production safety measures, we also provide clients with two easy methods of tracking all assessment activity:

  1. Custom Watermark All requests from WhiteHat Dynamic will contain a custom "WhiteHat Security" user agent header. This allows you to create filters to monitor our activity or to exclude certain alerts or warnings. If there is a specific watermark you would like us to use, let us know and we can customize the user agent header to include it.

    Sample watermark:

    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OSX 10.7; rv:13.0) Gecko/20100101Firefox/13.0.1 WhiteHat Security

IP Address Allow List

All WhiteHat Dynamic scans or manual work will come from one of our IP addresses or IP address ranges. Which IP addresses should you add to your allow list?

  • Non-EU Customers: If your company does not reside in the EU and you are not restricting access to US Synopsys employees, allowlist all IPs within this column.

  • EU Customers: If your company resides in the EU, allowlist all IPs within this column.

    Non-EU Customers EU Customers

    • 104.45.216.22

    • 162.223.124.0/27

    • 3.72.175.49

    • 3.76.244.88

    • 18.194.206.33

    • 54.93.186.146

    • 54.229.46.147

    • 148.253.176.50

    • 194.46.129.108