Build passed2m 14s
Product
Six stages. Evidence at every one.
Patchflare is a GitHub App plus a control plane plus single-use runners. This page walks the whole path a vulnerability takes, from the scan that finds it to the rescan that proves it gone.
1 · Patchflare
Scan
Scheduled or on demand across every enrolled repository. Findings are deduplicated with Dependabot and keep their state: new, fixed, reopened.
→ finding · CVE · CVSS source2 · Patchflare
Prioritise
Known-exploited (CISA KEV) first, then EPSS, then severity, then the nearest SLA deadline. Exceptions pause the clock with a reason and expiry.
→ risk order · SLA due date3 · Patchflare
Patch
An agent upgrades the dependency in a single-use, credential-less runner. Major upgrades get release-note-driven code adaptations or an escalation.
→ diff · scope gate4 · Patchflare
Prove
Your build, your test suite, then a rescan of the patched tree. Nothing ships as a pull request until all three pass.
→ build log · tests · rescan5 · your team
Review
A pull request with the evidence attached. Comment @patchflare to ask for a different version or approach; the agent updates the branch.
→ PR · conversation6 · Patchflare
Verify
After merge, a rescan of the default branch confirms the advisory is gone and freezes the SLA outcome for the record.
→ verified fixed · SLA met1 · Scan and 2 · Prioritise
One queue, ordered by what is actually dangerous.
Scheduled scans run in your organisation's time zone; on-demand scans run when you ask. Findings from Patchflare's scanner and Dependabot are merged into one record per package, version and advisory.
- Severity with provenanceCVSS 3.1, 3.0, 4.0 or 2.0 in that order, falling back to the advisory label. The source is stored on the finding.
- Exploitation signals, refreshed dailyCISA KEV membership, ransomware association and EPSS probability, shown on every finding and used to order the queue.
- Human-friendly referencesPAY-142 instead of a UUID. Searchable, linkable, and the same in Slack, the UI and reports.
PAY-142
CVE-2022-23529
GHSA-27h2-hvpr-p74q · jsonwebtoken 8.5.1Critical · CVSS 3.1 9.8Known exploitedEPSS 43% · p97SLA due in 5d
DetectedScheduled scan · Sep 1 · SLA clock started (critical: 7 days)Sep 1
PatchedPR #2841 opened · build, 184 tests, rescan cleanSep 2
MergedApproved by jmartin · post-merge rescan queuedSep 3
VerifiedRescan of main confirms the advisory is gone · SLA metSep 3
Exception: none · counts as actionableAdd exception
DoneRepository prepared · playbook loaded · pnpm install00:14
DoneUpgrade applied · release notes read · 3 call sites adapted01:08
DoneVerification passed · build · 184 tests · rescan clean03:42
DoneScope gate · dependency files only · no unrelated changes03:44
ReviewPull request opened · evidence attached · awaiting your approval03:51
3 · Patch and 4 · Prove
An agent that does the engineering, inside a box it cannot leave.
Each job gets a fresh runner with a scoped, short-lived token for one repository and nothing else. The agent learns the repository's playbook, applies the upgrade, then runs your build and tests and rescans the result.
- Deterministic scope gateChanges must stay within dependency files and the call sites a major upgrade requires. Anything else fails the job.
- Escalates instead of guessingWhen a safe automatic path does not exist, the session ends with a written explanation, not a broken PR.
- Playbooks per repositoryInstall commands, test commands, pinning conventions and past lessons carry forward to the next job.
5 · Review and 6 · Verify
A pull request you can talk to. A merge you always make.
The PR carries the diff, the build and test results and the rescan. Comment @patchflare with a constraint and the agent revises the branch. After you merge, a rescan of the default branch marks the finding verified and freezes the SLA outcome.
- One finding per pull requestSmall, reviewable, revertible. No omnibus upgrade PRs.
- Follows CI and reviewFailing checks and review comments come back to the agent while the session is open.
- Verification state is visibleVerifying, awaiting rescan, or verified fixed. Never a silent “merged”.
PAY-142CriticalKnown exploited · CISA KEVEPSS 43%
Fix CVE-2022-23529 in jsonwebtoken
Open Patchflare wants to merge 1 commit into main · dependency files only
package.json+1 −1
12- "jsonwebtoken": "^8.5.1"
12+ "jsonwebtoken": "^9.0.2"
184 tests passedRepository test suite
Rescan cleanAdvisory no longer present
Updated to jsonwebtoken 8.5.1 → 9.0.0, the lowest fixed version that keeps Node 14 support. Build and 184 tests pass again; rescan is clean. Pushed to this branch.
Opened by Patchflare · evidence attached · awaiting your reviewHuman approves the mergeFindings in period
418
14 repositories
Resolved
371
verified by rescan
SLA met
94%
policy v3 · critical 7d
Exceptions
9
with reason and expiry
RefFindingDetectedFixedSLA
PAY-142CVE-2022-23529 · jsonwebtoken · criticalSep 1Sep 3Met
WEB-61CVE-2026-31872 · fast-uri · highAug 12Aug 20Met
CHT-4CVE-2026-18871 · chromadb · criticalAug 3—Exception
Every row links to the finding's evidence: scan, PR, build and test output, rescan, approver.
Reporting
Compliance reports for any period, in the format your auditor asked for.
Pick a period and the repositories. Patchflare replays the event history to show what was open, what was fixed, how quickly, and which exceptions applied. PDF for the auditor, XLSX for the analyst, CSV for your own tooling.
Architecture
What touches your code, and what never does.
Three parts, one of them disposable. The full data-handling detail is on the Security & trust page.
See it on your repositories.
A thirty-minute demo on your code or ours, or early access starting with one repository. No payment details, no self-serve signup.
@patchflare 9.0.2 drops Node 14, which we still run in the batch worker. Can you stay on the 8.x line?