I have seen this solved by shipping an 'omnibus' style package which includes all the required dependencies that can't be met in RHEL, supplied in the application RPM. These additional libraries are installed into a directory outside the standard RHEL filesystem structure / search paths to avoid conflicts (eg. /opt/vendor/app). The problem with this approach is that it doesn't really solve too much.. the libraries you can get from RHEL can come from RHEL packages, and the libraries you need specific versions for can come from your alternate directory. These libraries that you ship still pose a potential security risk as the OS administrator/owner will not be receiving errata notifications with for the libraries you shipped (unless you as a vendor keep on top of it, and regularly ship newer versions of your omnibus package).

This is really one of the problems docker style containers were developed to solve (and why they found popularity), essentially shipping all your bespoke dependencies in a container for your application. You could look at shipping your application in a container, but depending on the application, this may limit your audience. With this method you end up in a similar situation to the omnibus package as the container will need to be updated to make sure all included dependencies/libraries stay secure/updated.

There have been more recent attempts to solve this problem with Modularity/Boltron in Fedora, but this hasn't been implemented in mainstream RHEL yet.