Vulnerabilities in GitHub repositories are like holes in Swiss cheese. They show up randomly within each scan or slice, and when layered together in different ways, they can align into openings visible from one side to the other.
Stale dependencies, code flaws, exposed keys — they add up over time. And before long, there are too many to keep straight. Beyond a certain point, the natural response is to fix only the criticals, or worse, ignore the Security tab altogether. But somewhere, someone is looking for where the holes line up in an opening they can exploit.
At Providence, there is an AI-powered chat tool built to help teams identify and close these holes before they ever line up. It is called VIPR, short for Vulnerability Impact Prioritization Report, and it gathers every alert a repository holds, weighs the effort and impact of each fix, and orders the whole into a plan a team can finish.
No alert gets left behind.
Toward Zero
VIPR begins with the repository as the source of truth. Every pull request opened by Dependabot or Renovate, every GitHub Advanced Security alert, every finding from any other supported scanner, including any that VIPR might run itself — nothing gets triaged until every hole is accounted for.
With the full inventory in hand, each finding gets sized up by its severity rating. A critical alert with a safe patch is an easy merge, compared with one that demands a major version migration through a forest of peer dependencies.
But severity alone doesn't say what a fix will take, so VIPR tags each finding with what the rating leaves out: the effort to fix it, the risk of breaking something, and the fix it can be clustered with.
With these tags, VIPR does something unique. It prioritizes findings into waves, ordered by impact:
-
Wave 1: Dismissibles. False positives, accepted risk, infeasible fixes. Every dismissal gets a reason.
-
Wave 2: Quick Wins. Safe Dependabot or Renovate pull requests — patches and minor version bumps that have already passed the automated tests.
-
Wave 3: Related Batches. Findings that share a root cause: one transitive dependency, one published vulnerability (CVE), one package family. Fix once, close many.
-
Wave 4: High Impact, Medium Effort. Critical and high severity issues with clear fixes and manageable risk.
-
Wave 5: Heavy Lifts. Major upgrades, deprecated APIs, architectural changes. These need their own plan.
As the waves clear, one by one, the repository looks less like a stack of unaccounted-for holes and more like a plan someone is working, steadily and verifiably, toward zero.
Running It
VIPR runs from a command line interface like GitHub Copilot CLI, an app like the Copilot app, or a chat panel in a desktop code editor like VS Code. Three prompts do the work, each a different cut of the same process.
/vipr runs the full workflow end to end — discovery, assessment, grouping, and planning — and writes the report fresh. The full run can propose merges and dismissals, but only with confirmation. It explains each finding, weighs the options, and lays out the choices for a human to refine, decide, and act on.
/vipr discover runs only the discovery phase, a snapshot of every alert and bot pull request the repository currently holds, without writing the full report.
/vipr plan skips discovery and works from what is already known, assessing and grouping the findings into waves and writing or updating the report.
A fourth prompt, /vipr help, lists the modes and what each one asks for.
Where It Works
VIPR works on any GitHub repository, but it is especially useful on the ones with the largest, most complex, and fastest-growing number of holes such as those running Node or Java-based applications where dependency graphs tangle easily. One outdated package pulls a chain of hidden, insecure transitive vulnerabilities, each a fresh hole behind the one before. A simple "just upgrade" rarely stays simple.
VIPR maps those relationships so the team can see what will actually break before remediation starts.
And some repositories carry a risk that generic severity scores don't register. When a codebase processes protected health information, a vulnerability's reach changes: a breach can touch patients, not just the business.
VIPR gives that risk extra weight when it sorts the waves.
How It Spread
VIPR began with engineers on Providence's Clinical, Revenue Cycle and Analytics team, who built it to zero their exposure across a portfolio of 70 repositories. It mapped 1,200 alerts, tracked progress as the work got done, and documented everything in a way that made handoffs easy. The backlog shrank to near zero, stayed there, and no code broke along the way.
Cybersecurity noticed and invited VIPR into five enterprise repositories with the most alerts — codebases still in production, still processing data, still serving users, yet neglected because the remediation load was too great.
In total, VIPR gathered more than 6,400 alerts, leaving each repository with a VULNERABILITY_IMPACT_PRIORITIZATION_REPORT.md showing what is known, what is being done, and what can be safely dismissed and why.
One team adopted VIPR as their standard security workflow. Another read the report and chose to archive rather than maintain their repository. The rest remained unresponsive, but the standing changed between them and Cybersecurity. A plan sat in each owner's repository now, naming the first safe step. Anyone who opened the repo could see it. Anyone who didn't act could be asked why.
Enterprise Information Systems noticed too. One team in this group had a repository with 25 open Dependabot pull requests and 350 alerts. The team's developers had been cherry-picking the easy fixes for months, leaving the more complex PRs and alerts stagnant since the day they first appeared.
When they let VIPR loose on the repo, it batched alerts by shared root cause, showed what could be readily dismissed, and flagged what needed testing. This clarity encouraged the engineers to make short work of the backlog, closing all but a handful of low-risk alerts in a matter of hours.
Freed from the labor and angst of managing security debt, the team took on something they had also been putting off for months: migrating from Git Flow to trunk-based development.
Before the Holes Line Up
GitHub repositories hold thousands of alerts, and more appear every day — new dependencies, new advisories, new keys left somewhere they shouldn't be. Left unaddressed, they accumulate, and it only takes a few holes lining up once for an attacker to get through.
Once inside Providence's systems, what's at stake is not just reputation or data but patient care — the devices at the bedside, the specialists on call, the treatments underway.
With VIPR in the loop, the exposure changes. Each alert closed is one less vector for a breach. Each one that remains has been dismissed, accepted, or explained. There by choice, not by avoidance. Security stops being an afterthought, a background anxiety, or an impediment to deep work.
Experience the difference a smart security workflow can make. Start with a look at what's already there. Run /vipr discover and see where your repo stands.