Skip to main content

Vulnerability testing policy for applications on Pega Cloud

Suggest edit Updated on January 24, 2022

Pegasystems permits Pega Cloud services clients and Pega Cloud for Government clients (hereinafter referred to as "Pega Cloud" clients) to conduct security assessments for applications on Pega Cloud as needed, when such assessments are preauthorized and performed within the guidelines described in this article.

Pegasystems allows application-tier vulnerability scanning when Pega Cloud clients need to assess and report on the security of their cloud-delivered applications, client-directed development, and related services for the purposes of internal audit or compliance programs.

Environments that can be tested

Pegasystems permits Pega Cloudclients to conduct application vulnerability tests on their Pega Platform applications that are deployed in Preproduction (large sandbox) and Production environments. Pega Cloud clients are not permitted to conduct application vulnerability tests on any trial environments.

Pegasystems also permits Pega Cloud clients to conduct application vulnerability tests on their Pega applications that are deployed in Development and Test (small sandbox) environments. However, Pega Cloud clients must realize that Development and Test environments, by definition, are more open than Production environments, and can identify issues that will not be present in Production environments.

Testing should focus on Pega Cloud clients’ applications rather than the Development environment. Testing of the Development environment itself is not recommended for several reasons:

  • The Development environment, by design, allows for software development and modification of the running system. (For example, clients can unlock RuleSets in a Development and Test environment, as development is still occurring and engineers are still making changes to rules. In a Production environment, RuleSets should be locked.) Testing in non-Production environments might find vulnerabilities that are inherent to a Development and Test environment. Testers and scanners will find issues in the Development environment that would be high risk in a Production environment, but that are necessary on a Development system.
  • Penetration testing can damage the system being tested. It can include the application rules themselves. Be sure to completely back up your applications before doing any testing.
  • The Pega Platform portals, such as AppStudio and DevStudio, are much larger in scope than most user-facing applications, and take more time and expense to test.

Do not use Development and Test environments for production services or for hosting sensitive or production data.

Policy Terms and Conditions

Each requestor must abide by and agree to the following terms that Pegasystems outlines before being authorized to conduct any security assessment or penetration testing. All Security Testing must comply with the Pegasystems Security Testing Term and Conditions.

Security Testing (the "Testing"):
  1. The client must submit a service request to notify Pega of the vulnerability testing.

    For more information, see Initiate a Pega Support request in Vulnerability Testing Process.

  2. Testing is limited to the services, network bandwidth, requests per minute, instance-type, and duration outlined in this agreement, the client's services agreement.
  3. The client is only permitted to test their Pega applications. The client is not permitted to attempt to penetrate beyond their applications, or to attempt to breach the Pega Cloud infrastructure or supporting services.
  4. The client is responsible for any damages to Pega Cloud or other Pega Cloud clients that are caused by their penetration testing activities.
  5. If the client discovers any vulnerabilities or other security issues which are rated “very high” or “critical” within any Pega Cloud in the course of their security assessment, they must report this issue directly to Pegasystems within 24 hours of discovery. The client may continue their tests, but is not permitted to further exploit or test against any suspected critical or high vulnerability or other security issue.

    For more information on how to report an issue, see Reporting a finding in the Vulnerability Testing Process.

  6. Upon completion of their testing, the client must submit an executive summary report (at minimum) to Pega GCS via a Service Request through the Support Portal, and request a review of the findings. Sending a full report is recommended.
  7. Distribution of the report beyond Pegasystems and the client is subject to mutual written agreement.
  8. To extend or modify the agreed-upon testing period, the client must submit a new request.

Permitted Services: Using Security Assessment Tools and Services

You have many public, private, commercial, and/or open-source tools and services to choose from for performing a security assessment of the client’s Pega Cloud environments. The term "security assessment" refers to all activity engaged in for the purposes of determining the efficacy or existence of security controls, such as:

  • port-scanning
  • vulnerability scanning/checks
  • penetration testing
  • web application scanning

The client is not limited in their selection of tools or services to perform a security assessment of their Pega Cloud environments. However, the client is prohibited from utilizing any tools or services in a manner that perform Denial-of-Service (DoS) attacks or simulations of such against any Pega Cloud environments, their own or otherwise. For a list of prohibited activities, see the next section.

A security tool that solely performs a remote query of your Pega Cloud environments to determine a software name and version, such as "banner grabbing," for the purpose of comparison to a list of versions known to be vulnerable to DoS, is not in violation of this policy.

Additionally, a security tool or service that solely crashes a running process on the client’s Pega Cloud environment, temporary or otherwise, as necessary for remote or local exploitation as part of the security assessment, is not in violation of this policy. However, this tool cannot engage in protocol flooding or resource request flooding, as mentioned in the Prohibited Activities section.

A security tool or service that creates, determines the existence of, or demonstrates a DoS condition in any other manner, actual or simulated, is expressly forbidden.

Some tools or services include actual DoS capabilities as described, either silently/inherently if used inappropriately or as an explicit test/check or feature of the tool or service. Any security tool or service that has such a DoS capability, must have the explicit ability to disable, disarm, or otherwise render harmless, that DoS capability. Otherwise, that tool or service cannot be employed for any facet of the security assessment.

It is the sole responsibility of the Pega Cloud client to: (1) ensure the tools and services employed for performing a security assessment are properly configured and successfully operate in a manner that does not perform DoS attacks or simulations of such, and (2) independently validate that the tool or service employed does not perform DoS attacks, or simulations of such, prior to conducting the security assessment of any Pega Cloud environments. This Pega Cloud client responsibility includes ensuring that contracted third parties perform security assessments in a manner that does not violate this policy.

Furthermore, the client is responsible for any damages to Pega Cloud environments or other Pega Cloud clients that are caused by the client’s testing or security assessment activities.

Prohibited Activities

Some penetration-testing activities could trigger a number of security events or affect resources for other clients. Therefore, activities that can damage resources or cause harm to any clients’ environments are prohibited, including but not limited to the following activities:

  • DNS zone walking
  • Denial of Service (DoS), Distributed Denial of Service (DDoS), Simulated DoS, Simulated DDoS or other activity with the intent to overload, flood, or spam any part of the services.
  • Port flooding
  • Protocol flooding (for example, SYN flooding, ICMP flooding, UDP flooding)
  • Request flooding (login request flooding, HTTP request flooding, API request flooding)
  • Testing of environments, domains, or URLs not specifically contracted by the client
  • Excluding the uploading of an EICAR file to test anti-malware or anti-virus effectiveness
  • Intentionally sending, injecting, or uploading a virus or a corrupt file, Trojan horse or worm
Did you find this content helpful? YesNo

100% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Ready to crush complexity?

Experience the benefits of Pega Community when you log in.

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us