SpyVsSpy, of which I am a member, is a security team for PRPC development. People will often tag posts with the team name to make sure that we notice, as far as I know you are the first customer to realize that the tag is also a link to the team's private mesh area and click on the link.
The code base for core PRPC has been run against many tools including AppScan, VeraCode, CLM, BlackDuck, etc. Some of these tools are used by us internally and some of these are even run as part of the build process. Other tools have been run by customers. I would suggest that you work with your Account Executive and GCS to see what can be shared and what you can run against your application. Most of these scanning tools produce similar results and unfortunately many of the results are false positives not actual issues. The tools producing many false positives is not specific to PRPC it happens for a lot products because of the way that tools operate. Many tools will record the traffic from a user performing normal operations as a baseline and will then replay the normal traffic slightly altered. If during the course of running the slightly altered traffic, the responses from the altered traffic does not match the baseline traffic exactly, the tool records this as a result. Often the result is not an actual issue but an error screen informing a user of invalid input. This results in a high result count, which to those unfamiliar with how these tools work, seems to indicate that there are a multitude of issues. For example, one tool that we ran produced results claiming that it could access 20 admin pages for an application because it had tried 20 URLs with admin appended to them and received page not found errors. If you do run a scan tool, please check that the results and eliminate any false positives that you can before contacting GCS.
re: Some of these tools are used by us internally and some of these are even run as part of the build process.
I assume also that these have been run against the rules as well?
(Nonwithstanding the point that many of these tools are ill-suited to Pega code... and this sort of exercise if often done because companies have an enterprise license with code scanners, and there's no apparent added cost to scanning Pega)
We understood that the Pega rules(Java Classes) were run against the tools. Do we have any official document which can be shared with the customers?
Pega applications are becoming road blockers for getting the security clearances from security advisers. It would be good & easier for the Pega customers if Pega can share or publish a white paper about its policy which can be used by the customers to get clearance.