Risk Assessment Summary
Three of the five recommendations have the same basic mitigation. ENV01-J, ENV02-J, and ENV03-J all show
as the complaint example. They differ in other stuff to be done or considered. If we are are looking to minimize the number of recommendations this is a place to start. My quick read is that ENV01-JandENV02-Jare sufficiently close that a single recommendation may be possible.ENV03-Jseems pretty different to me. If we are not trying to find a smallest set of recommendations this comment can be safely ignored
That is a good observation. However, we are separating the topics because they differ significantly. Moreover, this helps tool vendors enforce the guidelines.
Other notes: Currently, the guidelines are arranged in no particular order. Once the wiki is more stable, they will be reordered for ease of reading.
Something similar is happening in the rules with respect to the following mitigation.
It appears in ENV31- J, ENV32-J, and ENV33-J. I believe that it may be possible to write a single rule in the form of Do and opposed to three rules in the form of Do not. Furthermore the new rule, like the three old ones, seems suitable for automated detection. I'll wait for some guidance before adding more comments of this sort.
Yes these are very similar in their goal. In fact, applications should not grant other privileges if they are not required. AllPermission, Reflection and Classloading have been separated because these are some of the more dangerous permissions. This separation consumes more space but is better for clarity. For example, the severity of all these guidelines differ (high to low): AllPermission, Classloading and Reflection. A program that grants permissions to trusted code to create a classloader or permits reflection is better than the one that uses AllPermission.
Perhaps ENV 3,4,5 should be clubbed into a single guideline now.