That isn't the issue.
The issue is many customers are now requiring a list and security scan of every library your product uses.
Open source generally has resulted in a very large stack of dependencies from a very large number of projects. Checking every one of those for CVE's, and constantly monitoring them for new CVE's is not a trivial amount of work. In addition, the "patch frequently" model of open source means having to do new security reviews frequently, greatly increasing the level of work.
A lot of commercial dependencies effectively do that work for you. They may have a giant dependency tree, but they've provided a sort of bill-of-materials you can use instead of having to do your own search. They also tend to release far less often.
It would be good for the higher-level open source libraries to provide a similar bill-of-materials-like thing, so that we don't make every user have to check every dependency. And so that you don't tell your customer you don't use a particular library only to find it's 7 levels deep in the dependency tree, but only when installed on 3 versions of Red Hat that a particular customer uses.
Also, often small libraries ends up growing and expanding into swiss-army-knife projects. You aren't using the library for those features - Literally what happened with log4j. We need to maintain a much more UNIX approach and keep the libraries focused. Why did we need the ability to execute code in a logging library? Shouldn't that have been a separate package?
Lastly, some customers are rather unhappy if one of those dependencies is maintained mostly by people in certain countries. Which is usually not to hard to replace when it's a direct dependency. But when it's many levels deep you're going to end up with an open source project that doesn't want to change to an equivalent dependency, a customer that refuses to let it be installed, and a company that will never want to spend the money to maintain a fork of something so far from their core business.