Dependabot alerts are disabled, which is why 14 advisories had to be found by hand in #13 #17

Nothing is currently vulnerable. I ran bundler-audit check --update against Gemfile.lock at upstream/main (99a9167) and got No vulnerabilities found across 1233 advisories. #13 did its job. This issue is about the machinery that was supposed to have caught those 14 advisories and didn't.

The finding

$ gh api repos/codenamev/agentic/dependabot/alerts
{"message": "Dependabot alerts are disabled for this repository.", "status": "403"}

That's why #13 exists in the form it does. Fourteen advisories across faraday, uri, concurrent-ruby, addressable and rexml were sitting in the lockfile, and they surfaced because somebody typed bundler-audit by hand, not because GitHub said anything. The faraday ones mattered: faraday is ruby-openai's transport, so it's on the path every LLM call in this gem takes.

A private repo with alerts off is a choice. A public gem with alerts off is a smoke detector with the battery out.

The fix is two checkboxes

Settings → Advanced Security (or Settings → Code security, depending on how the UI has landed this month):

1. Dependabot alerts turns the notification on.
2. Dependabot security updates turns alerts into PRs that actually fix the thing.

I can't flip either. No admin rights on this repo, and it isn't expressible in a file, which is exactly why it's an issue and not a PR.

A second thing I noticed, offered as a hypothesis rather than a claim

.github/dependabot.yml landed on 2026-08-13 with a weekly bundler group. Since then: 40 gems are behind (bundle outdated), including ruby-openai 7.1.0 → 8.3.0, and Dependabot has opened exactly one PR, #9, from the github-actions ecosystem. Zero from bundler.

My best guess, and I'd put it around 60%: the bundler updater couldn't run at all. Until #13 merged on 2026-08-18, the lockfile held faraday-multipart 1.0.4, whose gemspec declares required_ruby_version < 4. Dependabot's bundler job runs on current Ruby, so bundle install would have failed on every attempt, and a bundler job that can't install the bundle opens no PRs and says nothing where you'd see it. #13 lifted that ceiling. If the theory holds, next Monday's run produces a bundler PR on its own and no further action is needed.

Worth watching rather than acting on. If Monday comes and goes with no bundler PR, the update logs under Insights → Dependency graph → Dependabot will say why, and I'll pick it up on the next deps pass.

Related

• Patch 14 security advisories with conservative lockfile bumps #13 — the manual patch this should have made unnecessary
• The Advisories workflow PR, which adds a scheduled bundler-audit sweep. That's belt-and-braces, not a substitute. It has a real weakness the checkbox doesn't: GitHub disables scheduled workflows after 60 days of repository inactivity, which is precisely the quiet stretch when an untouched lockfile goes stale. Alerts have no such failure mode. If you only do one of the two, do this one.

Filed by the loop:deps session. Labels: loop:deps, status:analyzed.