Okay, so we rolled out GitHub Advanced Security across our main repos about a year ago, with Dependabot alerts and secret scanning enabled. The big question for us was: would automated fixes actually work, or would this just create more noise for the dev team?
After 12 months of data, here’s the breakdown for our ~200 critical production repos:
* **Dependabot-generated PRs** directly resolved about **30%** of the vulnerability alerts. These were mostly straightforward version bumps for minor/patch releases in non-breaking dependencies. It was a nice, silent win.
* The remaining **70%** required developer intervention. The reasons usually fell into a few buckets:
* Breaking changes in major version updates (Dependabot can open the PR, but a dev needs to assess and test).
* Transitive dependencies buried deep in the chain where the fix wasn't a simple bump.
* Alerts in legacy or archived code that needed to be triaged and often remediated by rewriting a small module.
* "Patch available" alerts where the patch version hadn't been pushed to our ecosystem's package manager yet.
The real value for us wasn't just the auto-fixes. It was the **workflow integration**. Having the alerts and PRs right in the repo, linked to the code, meant security debt didn't get lost in a separate dashboard. Our devs could tackle a few as part of their sprint work.
Biggest lesson? You can't just "set and forget." We had to:
* Tune the alert severity levels to avoid noise.
* Set clear SLAs for the team on reviewing and fixing critical/high alerts.
* Use the **`dependabot.yml`** file to configure update schedules and commit messages.
For anyone starting out, I'd say temper expectations on the auto-fix percentage—but the visibility and enforced process are worth it. Curious if others have seen a similar split, or if you've gotten your auto-fix rate higher with specific configs!
~jennam
Less hype, more data.
That 70% breakdown for developer intervention rings so true. I'd add one more bucket to your list: **false positives or low-severity alerts in non-production code**, like in a one-off build script or a local dev environment config. Our team spent a fair bit of time just learning to triage those confidently and adjust alert severity to keep the signal clean.
The workflow integration point you're making is exactly it. The metric that ended up mattering most for us wasn't the auto-fix rate, but the **mean time to acknowledge** an alert. Just having them centralized and tagged in the PR/issue flow cut that down from weeks to, often, hours. Even when a human had to step in, the process was already moving.
You're spot on about the importance of mean time to acknowledge. That's the real process efficiency gain, and it mirrors what we see in marketing automation when alerts from monitoring tools hit a centralized dashboard. Noise is inevitable in any automated system.
The "false positives in non-production code" bucket is a critical learning curve. adjusting severity for those scenarios is a temporary fix, though. The better long-term play is refining the scopes in your dependency graph or security policies to exclude dev-only toolchains from critical alerting altogether. This reduces the triage load at the source.
Your data point about moving from weeks to hours for acknowledgement is the true ROI. It shifts security from being a post-release audit to a parallel workflow.
Show me the data
That's a really solid breakdown. The 30% silent win is exactly the kind of efficiency gain you hope for - it's pure cost avoidance on developer hours.
Your point about > the patch version hadn't been pushed to our ecosystem's package manager yet is one that really stings sometimes. It's like Dependabot is yelling at you for something you can't actually fix yet, which creates this weird holding-pattern anxiety. We ended up creating a custom label in the alert list for those, just so the team knew they were acknowledged but blocked externally.
Numbers don't lie – vendors do.