Ability to group suppressions in suppressions.xml

[magal000]

Hello, thanks for your work on this project!

Is your feature request related to a problem? Please describe.
In my use case I work with a large project where there is a lot of suppressions. An effort is made to keep the suppressions grouped together based on different categories, such as if they are temporary suppressions or permanent (as well as other things). This grouping is now done with comments and whitepsace in the suppressions.xml.

• If we take the temporary suppressions in my case as an example: The until attribute should be put on all temporary suppressions individually. In my case the same date is used for all temporary suppressions.
  It would thus be convenient and less error prone to be able to put them in a group where the until attribute is specified on group level.

• In my case there is also a need to generate documentation (where the xml file itself won't suffice) about what suppressions have been made. In this case it would also be advantegous if suppressions could be put into related groups. Then that information could be easily transformed using xslt.

Describe the solution you'd like
A new version of the suppression schema (1.4) with an optional suppressionGroup element could be created.

• The suppressionGroup element contains suppressions.
• All attributes that can be used on a suppressioncan be used on suppresssionGroup as well. The attributes of the suppressionGroup are applied to all suppression elements it contains. If attributes are defined in a suppression element anyway, then those overide that of the group.
• The suppressionGroup also has a name attribute. It also has a notes element for documentation similar to a suppression.
• The suppressionGroup element is optional. Suppressions should still be able to be individually listed. Making any xml written according to schema 1.3 valid according to schema 1.4 as well.
• Only the parsing of the suppressions.xml is changed. Internally OWASP will represent SuppressionRule the same, and will not be aware of any groups.

Describe alternatives you've considered

• Considered if internal representation of SuppressionRule should be aware of the any groups, but didn't want to change that. Perhaps it could beneficial for some output of the application.
• Considered if suppression inside a suppressionGroup should not be allowed to override attribute set on group level, perhaps making it less likely to make manual errors. But thought that the override principle follows other patterns in computing, such as inheritance in programming languages.

[aikebah]

As an alternative approach (not stating your proposal for change wouldn't be a good idea, but offering an approach you can readily use with the current version): It is possible to configure multiple suppression files (one for each of your logical groups) allowing for separate handling/constraints for each of those rulesets.

In my daytime job we have a centrally managed and published (internal https server) suppressions file with several permanent suppressions for libraries that would not fit a FP mitigation in ODC itself that we use in addition to a local project suppression-file (we have no need for more finegrained control, but you can add as many suppressionfiles as you like, they will all be merged together in the internal set of suppression rules)