I want to integrate OWASP Zap security tests in my continuous integration chain using the official Jenkins plugin.

However, since it injects harmful payloads in database, I don't want the database to become corrupted! And it's a huge database. I was wondering how to implement it correctly without corrupting the DB.

  • Did you think about setting up a test environment with a database of test data of which can be corrupted?
    – Bob Ortiz
    Jul 11, 2017 at 7:23

3 Answers 3


Run the active scans against a non-production environment (replica of production). Have a process/script to easily restore a fresh copy of the live database if you break your non-production database during the active scanning.

It is best practice to avoid unnecessary risk on the production site. Also, you can be much more aggressive with your penetration testing against a non-production environment.

You mentioned that your database is "huge". If it is way too large to feasibly copy to non-production in a reasonable amount of time, you could look into decreasing the size of the production database when you copy it into your non-production environment. This might include trimming the tables that have an excessive number of records that are not required for non-production testing purposes.


You shouldn't be running any tests against a live database, You should be using a segregated testing environment

  • This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
    – MiaoHatola
    Jul 11, 2017 at 9:54
  • Although CI presents challenges to implementing test environments, this is actually a valid reminder that destructive testing should not be done on production.
    – schroeder
    Jul 11, 2017 at 10:22
  • @MiaoHatola how is this answer any different to the one posted above except worded differently? The fact is the answer to this problem is not to run the test against a live environment but a testing environment which can be destroyed and rebuilt per test Jul 11, 2017 at 13:15
  • @JamesKirkby the OP asks how to do something, you are saying how not to, which to me feels not enough for an answer. My previous comment is an automated one, and might seem aggressive, sorry about that :)
    – MiaoHatola
    Jul 11, 2017 at 13:23

Always maintain a non-production environment of your application which is a replica of your production application. Always Maintain secure backup of your application to rebuild the application in non-production if required. All security tests & patching should be first completed on this non-production environment & only after it's success/failure should they be implemented on production environment.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .