I agree and disagree. Traditionally a lot of shared libraries are in the OS and quite good at not breaking things, you can run windows update or apt-get upgrade and apps shouldn't break. Breakages generally happen in higher level libraries, but that is a cultural issue more than a technical one. If more care is put into the interface and managing breaking changes then it is doable. But regardless of how libraries are being deployed "move fast and break things" is not an attitude I want from the developers of them.
Most language specific package managers I've used do a terrible job of telling developers which packages are obsolete and no longer supported or of what the ramifications for updating a package is. Most libraries in these repositories don't even support previous versions.
> Bundled dependencies are easy to handle from a security perspective.
But not from a user or corporate perspective. I shudder to think at how many old and unpatched libraries are currently in use in the corporate world where the have an attitude of "deploy, then don't touch until we request a feature". It's an uphill battle to even upgrade when there are no compatibility issues, if they need development time to update then they're likely to stick to an old version forever.
Users are unlikely to upgrade as well for various reasons, so if a shared library is bundled with an app it is unlikely to be patched.
Bundled dependencies are easy to handle from a security perspective.
Build stamping tells you what CLs are contained (or just go by monotonically incrementing number if it's bundled deps). Someone commits the CL that fixes the dependency. In any sane bundled system, this increments that number. You say that any binary in prod must be something past that CL (which can be verified using the build stamping). Done.
If it's running, it's fixed. Modify to have whatever grace period you want. The same works for shared dependencies, of course.
In practice, both shared dependencies and static dependencies have tradeoffs, but security is not one of them. Both can be and should be easy to make secure in the sense of "make sure it contains the fix".
Both may require app redeployment in practice, and expecting them not to is not a good strategy right now (for most programming languages)