Earlier quoted context omitted.
You will also not get very far in engineering if you have a production incident, someone proposes a thing that will mitigate it partially but significantly, and you insist that we can't deploy that mitigation because we need to do the multi-year project that will actually fix it instead. Even if we still need that project, we also need that mitigation. Sure, solve the problem of "auditing and trusting codebases". Go…
Feel free to turn it off yourself, just don't be surprised when the attackers switch tactics. And don't make life harder for everyone else by pushing it as mandatory. (if you want a better mitigation: don't automatically update dependencies in CI. At a minimum have a cooling-off period that you only bypass on manual review. This is not hard to implement and at least gives some time for alarm bells to be sounded befor…
I also blocked a proposed mandatory dependabot at work a few months back because I didn't like the way it created a pipeline for any hacker to push a hacked dependency straight into someone's codebase. I'm lifting my objection now that dependabot is defaulting to a 3-day cooldown, though the code bases I'm managing I'm setting to 7 days. (Not to be behind everyone else; I'd be fine if everyone joined me at 7 days. I don't really accept the freeloading objection, there's plenty of entities scanning things now no matter what cooldown you set. I just think 3 is a little tight to expect the full discovery and remediation to take place.)
So, whatever sort of "but it's really hard! I bet you don't do it yourself" implications you may be trying to draw fall very flat. Or whatever you may have been trying to imply about trusting this step but not trusting others... no, I do defense in depth. Giving up on defense in depth because one step isn't enough... well, I think I've probably played the "you won't get very far in engineering" card enough, but hey, here's one last time.