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.
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).
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.
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.
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.