Anyhow, this is useful to rollout dependabot.yaml config at scale: https://github.com/github/evergreen
A one-off project of mine tries to improve supply-chain license management for projects [1]. I got bit once by an MIT licensed project that accidentally took a GPL dependency a couple versions later. That was a pain to notice without analyzing transitive dependencies. Never again.
Just like with AWS SaaS offerings: All they need to do is have something basic, satisfying 80% customers, requiring little maintenance on their end.
For example, at some point GitHub introduced a change that prevented CI builds triggered by forks from accessing secrets in CI variables. This made sense from a security perspective (although I would have a preferred a hard failure instead of variables silently being set to empty), but it also applied to all Dependabot PRs, which I have to assume wasn't intended behaviour. It really seemed like different teams at GitHub weren't talking to each other. An issue was opened about this and got quite heated, but wasn't really resolved (except for some ugly workarounds) before it was locked for becoming too uncivil.
I wonder if they fixed it since.
Your read on the situation is spot on, and no, it doesn't look like it's been "fixed" (mostly because "fixing it would re-introduce the same potential vulnerability).
The current workflow where dependabot just spams an endless stream of PRs is not optimal. I don't need any new features from dependabot, I just want a better UI.