Rule packs and custom rules strategy
We are in the process of implementing Fortify across all the projects in the company. Each project will have their own Fortify Application Versions. They will all have build servers that provide .fpr files to a central SSC. We are unsure how to handle rule-packs and custom rules in this environment,
As I understand it, the rulepacks are used by the SCA when scanning. But they are also installed on the SSC. Is this solely for the purpose of distribution, or are the rulepacks also used when merging the .fpr file to the Application in the SSC? Are the rulepacks used when generating the reports? In either case, how is version mismatch handled? What would be a good strategy for managing renewing of rulepacks on the build machines?
Some of our projects have created Custom Rules - mainly to filter false positives. Currently they are installed on the SSC and automatically distributed to all users that update rulepacks. This means that the custom rules are global across all projects. But some projects have different security profiles and requirements, and will not accept other project's custom rules. Would it be a solution to just install the custom rules on the individual project's build machines? Would it make sense to checkin the custom rule into the source tree? How would the SSC react to some artifact containg some custom rule which is not installed to the SSC?
Re: Rule packs and custom rules strategy
Rules in SSC are used for distribution only. Metadata should be the same as on SSC so this is why updating Rules in SSC makes sense as the metadata are updated at the same time
For custom rules you could keep them separate just on the necessary SCA machines. On the other site most custom rules are depending on package, class and function name depending on the language so the risk 2 projects would be affected by the same custom rules as long as they are not using the same library is low.