Not choosing is not an option, it leads to this ‘max severity score’ ‘vulnerability’.
But to your point docker secrets are a thing and have been available for a while. And a publicly exposed phpinfo has been a severe dataleak since before time began.
Neither of these are unknown or new. They're just an unfortunate composite enabled by containers.
I'd much prefer pulling credentials from a file or pulling down credentials based on properties that the application is oblivious to. There's risks to using files too, but in my experience, environment variables are used a bit more carelessly.
The issue i see being exploited is that the owncloud codebase contains this function, and its in the unit/integration tests, which shouldnt be in production code (or should be inaccessible at least).
That all being said, the real issue here is that there are sysadmins and devops people who are deploying php.ini configurations to production that allow the use of phpinfo (and probably other functions too), by not explicitly denying those functions, which is totally something the php configuration supports, and is absolutely something that should be done, as there are a number of unsafe php functions.
https://www.php.net/manual/en/ini.core.php#ini.disable-funct...
If the environment is safe, don’t expose it, functions that expose it are unsafe and should be documented as unsafe and unavailable in production.
If the functions are normal, the environment is unsafe, don’t store secrets there.
You have to make a choice, it can’t be half of both. That is the real issue.