Should I run a vulnerability scan on Production or Staging environment?
Before you start a vulnerability scan or pentest, it is important to choose the environment you want to target. Choosing between a production or non-production environment is a balance to find between getting the most out of the pentest and reducing the risks.
Below is a summary of the pros and cons for each alternative:
You get a security assessment of the real target, which is available to users and to potential attackers
Allows testing of the whole application with all the features, interactions between features, integrations with third-party services etc. (which may not always be configured in a staging environment)
It can measure and evaluate the security checks implemented to detect attacks
Some tests could add junk data, fill up forms, modify data, create pop-ups etc. which may be visible to other users
Due to the simultaneous requests, the target may experience some slowing of processes and increased response time
If your target is vulnerable to email flooding or mass mailing attacks, it is possibly that a good number of emails may be sent as a result of the testing
Creation of extraneous data if forms/input fields are involved
Temporary downtime due to the nature or volume of requests
Potential cost implications in case of interactions with paid APIs or integrations
If you have any paid APIs or integrations, sending requests to them during tests might incur costs. It would be helpful if you could inform us about such services, so that we can avoid sending requests unnecessarily or, if necessary, do so in a controlled manner.
It does not impact the users, data or interfere with the activity of the target
Since there might be fewer restrictions on a staging environment, some vulnerabilities might be further exploited - and result in uncovering more vulnerabilities
It allows the testing of latest developments that have not been released in production yet
If the staging environment configuration is different from the production environment, there might be some false positives due to relaxed security controls
Some vulnerabilities may not be detected if the configuration or features are different
If you do not have a staging environment already, you may have to configure one
If you go for a vulnerability scan of a staging environment, it is strongly recommended to set up a target that is identical to your production environment
We've seen a mixed approach work best. Regular vulnerability scans can be run on a staging environment which may be very vulnerable initially. Then patch the vulnerabilities based on the findings, and run another scan to ensure correct resolution. Once the changes are deployed to the production environment, you can request our team to conduct the re-scan (only available in Pentest plan) on your production environment.
If you would like to know more about the impacts and risks, or discuss specific conditions and restrictions - please reach out to your account manager or create a support ticket.
Below is a summary of the pros and cons for each alternative:
Production Environment
Pros
You get a security assessment of the real target, which is available to users and to potential attackers
Allows testing of the whole application with all the features, interactions between features, integrations with third-party services etc. (which may not always be configured in a staging environment)
It can measure and evaluate the security checks implemented to detect attacks
Cons
Some tests could add junk data, fill up forms, modify data, create pop-ups etc. which may be visible to other users
Due to the simultaneous requests, the target may experience some slowing of processes and increased response time
If your target is vulnerable to email flooding or mass mailing attacks, it is possibly that a good number of emails may be sent as a result of the testing
Creation of extraneous data if forms/input fields are involved
Temporary downtime due to the nature or volume of requests
Potential cost implications in case of interactions with paid APIs or integrations
If you have any paid APIs or integrations, sending requests to them during tests might incur costs. It would be helpful if you could inform us about such services, so that we can avoid sending requests unnecessarily or, if necessary, do so in a controlled manner.
Staging Environment
Pros
It does not impact the users, data or interfere with the activity of the target
Since there might be fewer restrictions on a staging environment, some vulnerabilities might be further exploited - and result in uncovering more vulnerabilities
It allows the testing of latest developments that have not been released in production yet
Cons
If the staging environment configuration is different from the production environment, there might be some false positives due to relaxed security controls
Some vulnerabilities may not be detected if the configuration or features are different
If you do not have a staging environment already, you may have to configure one
If you go for a vulnerability scan of a staging environment, it is strongly recommended to set up a target that is identical to your production environment
We've seen a mixed approach work best. Regular vulnerability scans can be run on a staging environment which may be very vulnerable initially. Then patch the vulnerabilities based on the findings, and run another scan to ensure correct resolution. Once the changes are deployed to the production environment, you can request our team to conduct the re-scan (only available in Pentest plan) on your production environment.
If you would like to know more about the impacts and risks, or discuss specific conditions and restrictions - please reach out to your account manager or create a support ticket.
Updated on: 01/10/2024
Thank you!