You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
Dependabot alerts turns the notification on.
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.
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.
Nothing is currently vulnerable. I ran
bundler-audit check --updateagainstGemfile.lockatupstream/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
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-auditby 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):
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.ymllanded on 2026-08-13 with a weeklybundlergroup. 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 thegithub-actionsecosystem. 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 declaresrequired_ruby_version < 4. Dependabot's bundler job runs on current Ruby, sobundle installwould 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
Advisoriesworkflow PR, which adds a scheduledbundler-auditsweep. 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:depssession. Labels:loop:deps,status:analyzed.