Oracle recently made a gift to all middleware engineers who operate in "security-first" environments. Government contractors should love it as much as I do, especially if you are adopting or already have continuous ATO.
Everyone who works with good old on-prem technologies has used OPatch utility. Database or Middleware, you run it one way or another every time you need to apply fixes or improve overall security posture and get your servers off the security scanner list. One of the strong sides of the tool is the ability to make a smart rollback and restore the system to the previous state if something goes wrong. To achieve this OPatch keeps the records in the hidden folder under $ORACLE_HOME/.patch_storage.
We may think that patch was applied and the product installation is safe, but all those security scanners think differently. They detect the folder content and mark the system as vulnerable anyways. Until recently, you had only two options - manually archive impacted patch folders, or use OPatch to clean up the patch cache. Both approaches mean that you can't roll back your system to the previous state (cleanup) or need to make unarchive the patch cache before operating on the installation.
With the recent OPatch versions, you have a third, convenient, and safe way to keep your patch cache operable and get off the radars. The name of the game is obfuscation. There is massive functionality addition to the opatch util command. Those new functions allow you to clean up the patch cache and move it to the other location, clean it up, backup and restore, and more. Unfortunately, I can't tell when those new functions were introduced, but they emerged somewhere between 13.9.4.2.5 and 13.9.4.2.11.
My personal favorite is the command:
$ $ORACLE_HOME/OPatch/opatch util ObfuscateIt makes the patch storage content unrecognizable to one's eye, and all previously vulnerable libraries and files are no longer detectable as a vulnerability.