Question
TD Bank Group
CA
Last activity: 2 Jun 2016 8:24 EDT
Running Fortify Scans against Pega generated code
Our company's policy is to have all produced/generated code scanned through the Fortify tool to ensure compliance with Security Best Practices.
With Pega, the code generated is stored in the PRGenJava folder, but we are looking for a way to:
1. Isolate the code generated for a specific version of an application
2. Ensure that we have generated all the code that could be generated (ran) by a user.
Is there a way to achieve those 2 things?
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Pegasystems Inc.
US
see this similar questions: Re: HP Fortify and Pega 7.1.x. Tom Conner, can you follow up on any questions Patrick may have?
Pegasystems Inc.
US
Patrick,
Is this for a system in development or is this a system in production? In the first case, I would suggest working with your engagement lead to get the support that you need. If it is the latter case, I would suggest filing an SR and working with GCS on this activity.
One thing that will help to determine the complexity of doing the scan is determining what are the types of users are meant in question 2. If these users are only going to be generating work objects, then it should be much easier than if the users are going to be developing rules. If the users are only generating work objects, which is the far more common case in my experience, then the java generated prior to go live should only change when you update your application. In this case, it should be a fairly straight forward process to scan the code (although scanners do need to be tuned to avoid generating false positives and to avoid missing valid findings). However, if the users can develop rules then your generated java can change whenever a rule is created, modified, or deleted. In this case, a scan would have to done regularly against the production system or you would have to determine what java could be generated from the rules which users could create, modify, or delete, and if there is way to have the rules generate undesirable java.
Matt
TD Bank Group
CA
Hi,
We are looking at scanning code from Production or QA, not from a dev environment. So users would only be working on work objects, but our understanding is that there is no way to guarantee that 100% of the code a user could possibly access gets generated. We can write automated test scenarios to try and trigger all the conditions that would cause code to be generated, but we cannot really have a 100% coverage (unless I am missing something).
For #1, I don't see any answer as to how we could isolate the code for a specific version of an application (we have multiple Pega applications that run on the same instance/rulebase).
Hi Patrick,
Let me expand a little on Matt's comments.
You've hit on some of the difficulties of doing static analysis on generated code. It is difficult to determine which specific generated classes are tied to which access groups / operators, so it's difficult to narrow the scope of scanning to just your particular application. So your question 1 doesn't have an easy answer.
As for question 2, you'd want to run through a full set of tests of your application, or you could try the static assembler.
But before you get too deep into that, I'd urge you to reconsider whether Fortify is the best way to ensure security of your generated code. Fortify does not come with an understanding of Pega APIs and may miss things as a result. Furthermore, you may get a number of low confidence findings which may be false positives.
Please consider using the Rule Security Analyzer, which ships with Pega7. That tool has a few scans that work on your custom written code. This finds some of the same vulnerabilities that Fortify looks for, including cross-site scripting, SQL injection, and XML Entity Expansion vulnerabilities.
Tom
TD Bank Group
CA
I have suggested the use of Rule Security Analyzer, but this tool only scans manually created "code" and our Security department is not comfortable yet with the fact that the Pega generated code is safe.
I will take a look at the static assembler.
GovCIO
US
Hi Tom,
This is really good info shared. May I know whether this "Rule Security Analyzer" is a licensing tool from Pega?
Thanks,
Ravi Kumar.
It's a security tool in the developer portal menu.
Tom
GovCIO
US
Hi Tom,
If you are talking about the above mentioned then I am aware of it and I agree that it comes as a part of Pega from V6.x onwards. As far as my knowledge, this tool works with in the context of our Pega custom code built by the developer while working on a project. Basically, this feature runs within the context of our Pega app layer.
Thanks,
Ravi Kumar.
Yes Ravi, that's correct. It scans the custom code using one of the regular expressions designed to catch a certain type of vulnerability or noteworthy coding pattern.
I take it from your question that like Patrick, you are looking for assurance on the security of Pega code, not just your custom code. Is that correct?
Tom
GovCIO
US
Yes Tom. You are correct. Not only Pega side but also to scan the security defects using Fortify, WebInspect etc.
Thanks,
Ravi Kumar.
TD Bank Group
CA
Hi,
Do you know if the Static Assembler generates the code for everything within an application including the "dormant/dead" code that will never be executed?
Thanks,
TD Bank Group
CA
Anybody?
Pegasystems Inc.
US
Patrick,
I do not believe that we ship any dead code. If you are looking for a way to scan to the code which is stored in the database then it should be possible. I would recommend filing an SR for that.
Matt
TD Bank Group
CA
Matt,
I was not referring to shipped code, but "developed" code from our application.