chore: remove suppression rules that were deleted from the generatedSuppression branch

[jeremylong]

These suppressions were copied into the base suppression file and then deleted or updated from the generated suppression file. Note that the deletions are all part of a consolidation that occurred within the generated suppression file. See #8118 for the utility used to make these changes.

This change should be released in combination with #8116

---

Removed 37 obsolete suppressions from core/src/main/resources/dependencycheck-base-suppression.xml

=== Removal Summary ===
Suppressions removed based on changes from commits:

81c68b0 - fix(fp): Consolidate false positive suppressions for graphql-java (#8095)
Date: 2025-11-10 23:35:54 +0800
URL: 81c68b0
Removed 21 suppression(s)

767778f - fix(fp): FP per issue #5945 (#7272)
Date: 2024-12-24 22:01:10 +0800
URL: 767778f
Removed 2 suppression(s)

f065359 - fix(fp): Better FP fix per issue #7250
Date: 2024-12-18 19:13:49 +0100
URL: f065359
Removed 7 suppression(s)

5fa08fc - fix(fp): FP per issue #6812
Date: 2024-07-06 11:28:29 -0400
URL: 5fa08fc
Removed 1 suppression(s)

743b3a1 - fix(fp): FP per issue #6138 and #6139 (#6140)
Date: 2023-11-27 21:09:07 +0800
URL: 743b3a1
Removed 1 suppression(s)

81e149c - Update generatedSuppressions.xml
Date: 2023-01-07 13:58:15 +0100
URL: 81e149c
Removed 2 suppression(s)

a78157e - chore: release suppressions to core
Date: 2022-12-09 05:55:14 -0500
URL: a78157e
Removed 3 suppression(s)

37 total suppression(s) removed from 7 commit(s)

[jeremylong]

@chadlwilson this goes along with #8116 which you assigned to yourself. There will be one more PR like this to remove duplicate suppression rules - but I'm holding off on generating it until this is merged to avoid merge conflicts.

[chadlwilson]

Can you summarise the actual methodology used across these to determine which things are "obsolete"? Are these ones ONLY those that which have also been subsequently removed and/or edited in generated suppressions?

It seems to be

• deleting some duplicates which happen to have been edited on generatedSuppressions before they were "copied" to base after that
• as well as some edited on generatedSuppressions after they were copied to base, and perhaps removed from generatedSuppressions.

What's the end goal here after this commit and "removing duplicate suppression rules" - would users need to have latest generatedSuppressions to be at a state without regression in their suppressions? (I think that is probably OK, but good to understand what we're willing to compromise on.

The code for the actual tools is quite large and messy to review IMHO - I'm guessing it is AI generated.

[chadlwilson]

In any case this particular PR LGTM, no downside from merging these.

[jeremylong]

the code that generated the changes is in #8118. You are correct, this change removes from the base suppression xml any rules that were copied into the base and then later modified or removed in the generatedSuppression branch. This is trying to cleanup things that were in the history. The next PR will be removing straight duplciates between the two files - but that PR needs to happen after this one. Once completed we should have little to no duplication between the two suppression files.

[chadlwilson]

Yeah, that code is impenetrable to me, sorry 😅 it's not really factored for review to decouple string and output manipulation and XML logistics from actual logic which is why I was just trying to understand what your target end state and "invariants" are (don't modify this, do modify that).

I infer you're intending to treat generated/hosted/published suppressions as canonical and only edit base. There might be a small number of cases where a suppression in generated was promoted to base and then edited in base but I imagine that's a low number and possibly difficult to reconcile intent anyway.

[jeremylong]

Long term intent:

• base: suppression rules are added manually
• generated: mostly automated rules are added, some manual cleanup/corrections is fine. Included in each release during the build process.
• hosted: created from the generated after every update - for those working online this is a way to get the latest suppressions automatically.