I once worked in a project that vendored most of its third-party dependencies, it was a culture shock at first, but damn, after a while it was so nice being able to work just by building from local source, with normal tooling like `make`, instead of pulling a shitton of deps from the outside world. Made me realize how much "webdev culture" did a disservice to software engineering as a whole.
Caching proxies are a decent middle ground like Artifactory. AWS might support that (maybe only on certain repo types?)
Generally you can also configure rules in your internal package cache about what to do if a package is missing from the cache/hasn't been pulled yet. They also commonly integrate automaticaly CVE tracking and pull statistics so they give a nice "heads up" what everyone is using even if it's a local PoC
As an added bonus, they can also lower bandwidth bills like in expensive cloud environments when you can co-locate the proxy close to CI/build machines.
You mean there's no excuse for cooldowns? Yeah, there is. Security consultants have for years been saying that you need to always keep your dependencies updated. This is often parroted without any context of whether a package needs to be updated or not.
And what's a proper cooldown? 1 day? 3 days? 1 week? 1 month? If you have a vulnerability, now you're exposed during that cooldown period. There's no straight forward or easy answer here.
I am speaking from my own experience here with having to sit in during these discussions where security "advice" is provided to the development team without understanding what it entails or any tradeoffs. I found that keeping things relatively secure is hard work and needs to be a part of culture.