The IBM X-Force Threat Intelligence Index dropped some numbers that should make any infrastructure-minded developer uncomfortable.
44% increase in incidents caused by vulnerability exploitation. Nearly 40,000 new vulnerabilities reported — 13,000 more than the year before. 56% of tracked vulnerabilities exploitable without authentication. Supply chain compromises up 4x over five years. Ransomware groups up 49%.
If you’re building tools that touch other people’s infrastructure, these numbers aren’t abstract. They’re a checklist of things you might be getting wrong.
We build git-steer — an MCP server that manages GitHub repositories autonomously. It patches dependencies, opens PRs, and runs daily across every repo in your organization. That’s a significant trust surface. When we read the X-Force report, we looked at our own tooling and asked an uncomfortable question: are we practicing what we preach?
The answer was: not entirely. Here’s what we fixed.
1. We weren’t scanning ourselves
git-steer scans all your repos for CVEs every day. It was not scanning itself.
That’s the supply chain problem in miniature. The X-Force report flagged a 4x increase in supply chain and third-party compromises — attackers targeting where software is developed and deployed. A tool that manages your repos is exactly the kind of target that makes a supply chain attack worthwhile.
We added a CI workflow (ci.yml) that runs npm audit at high severity on every push to main and every pull request. If a vulnerability gets introduced into git-steer’s own dependencies, it gets caught before it ships.
The lesson from X-Force: your security tooling is part of your attack surface. Treat it accordingly.
2. One token to rule them all — until it didn’t
The heartbeat workflow ran on a single org-wide installation token. One token, all repos, valid for an hour. If that token leaked or was misused, every managed repo was exposed simultaneously.
The X-Force report emphasized treating identity as critical infrastructure — unique credentials, just-in-time access, scoped to exactly what’s needed right now.
The security-sweep.yml workflow already did this right: it generated a scoped token per repo. The heartbeat’s CLI scan step didn’t. We fixed that — each repo now gets its own JIT token scoped to only the permissions needed for that specific operation. When the scan is done, the token expires and the blast radius goes back to zero.
3. We weren’t looking for leaked secrets
We were scanning for vulnerable dependencies. We were not scanning for secrets that had already walked out the door.
56% of vulnerabilities in the X-Force report required no authentication to exploit. The corollary: if a secret gets committed to a repo, an attacker doesn’t need to crack anything — they just read the file.
The heartbeat now runs a secret scanning report across all managed repos on every daily run, using GitHub’s secret scanning API. It surfaces open alerts by type (not value — we’re not logging your secrets) and flags any repo with exposed credentials for immediate action.
4. Dependabot is reactive. We needed to be faster.
Dependabot is good. It’s not instant. There’s a lag between a CVE being published and GitHub’s advisory database picking it up and surfacing it as a Dependabot alert. During that window, you’re exposed and don’t know it.
We integrated OSV.dev — the Open Source Vulnerability database — directly into git-steer’s security scan. For every package Dependabot is already tracking, we now also query OSV’s batch API to check for CVEs that haven’t made it into GitHub’s advisory database yet. Anything new gets surfaced in the scan output alongside the Dependabot results.
This is the “discover and test for vulnerabilities continuously” recommendation from X-Force, taken one step further: don’t wait for your scanner to catch up to the threat intelligence.
The Full Picture
Here’s where git-steer’s security posture stands now:
| Layer | Before | After |
|---|---|---|
| git-steer itself | No automated audit | npm audit on every PR and push |
| Token scope | Org-wide token for all operations | JIT per-repo scoped tokens |
| Secret exposure | Not monitored | Daily secret scanning across all repos |
| CVE coverage | Dependabot only | Dependabot + Code Scanning + OSV.dev |
| Fix automation | Manual or scheduled | Scan → fix PRs → auto-merge, daily and on-demand |
The X-Force numbers are a reminder that the threat landscape doesn’t wait for your next sprint. Neither should your security tooling.
git-steer is an open-source MCP server for GitHub repository management. github.com/ry-ops/git-steer
