As I always say - you don't _have_ the vulnerabilities, you have reports of vulnerabilities.
Has anoyne in your organization bothered to check the vulnerabilities descriptions? And verify if there is any (significant) risk from them? Remember that risk is affected by potential loss as well as exposure and severity. Just because something lights up on Nessus, doesn't mean that it constitutes a noteworthy risk. I'm in no way trying to downplay any specific single vulnerability because I didn't dig throught them to check what they are about but it's about the whole process itself. If your "vulnerability management" consists only of "ok, something in our Nessus report is not green - time to scowl the admin team to make it green again", it's fundamentally broken.
Having said that - for all we know, Splunk has a custom agreement with openssl maintenance team and products ship with custom versions of the library. They might or might not have backports of fixes and/or functionality differences vs. stock versions. This also means that deducing the existence of vulnerabilities just by comparing version numbers is very unreliable in this case.
And finally - you can't manually do anything with libraries shipped with Splunk products - they are part of the whole package and vulnerabilities (if applicable to the product) will usually be addressed as soon as possible and fixed versions should ship with next Splunk/SOAR/UF release.
