Autonomous security patching for GitHub

Vulnerabilities in. Verified pull requests out.

Patchflare finds vulnerable dependencies, patches them in an isolated environment, proves the fix with your build, your tests and a rescan, then opens a pull request your team approves.

Request a demo See how it works

Nothing to install in CIHumans approve every mergeEvidence attached to every fix

acme / payments-api· pull request #2841Example

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"

✓

Build passed2m 14s

✓

184 tests passedRepository test suite

✓

Rescan cleanAdvisory no longer present

Opened by Patchflare · evidence attached · awaiting your reviewHuman approves the merge

CISO · application security

I run security

Exposure ordered by real exploitation, SLA conformity you can put in front of the board, and a vendor you can review.

See what changes for you →CTO · engineering managers · developers

I run engineering

Pull requests that already build and pass your tests, one finding at a time, on your schedule, with a human on every merge.

See what changes for you →Head of GRC · GRC analysts

I own compliance

Evidence that connects a finding, the fix, the verification and the approver, exported for any period in PDF, XLSX or CSV.

See what changes for you →

How it works

From finding to verified fix, with the evidence at every step.

Scanners create queues. Version-bump bots open pull requests and hope. Patchflare does the engineering work in between, and records it.

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 source

2 · 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 date

3 · 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 gate

4 · 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 · rescan

5 · 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 · conversation

6 · 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 met

Prioritised by real exploitation

Fix what attackers are using, before what merely scores high.

Every finding carries its CVSS source, whether the CVE is in CISA's Known Exploited Vulnerabilities catalogue, and its EPSS exploitation probability. Attention is ordered by those signals; severity and SLA deadlines never change because of them.

SLA policy per severitySeven days for critical, thirty for high, versioned, with a conformity score over the trailing ninety days.
Exceptions with a reason and an expiryAccepted risk, false positive or won't fix. The clock pauses, the record shows who and why, and it comes back when the exception expires.
Slack when it mattersA new known-exploited finding, an SLA breach, a daily digest. Not a message per version bump.

Dashboard· Acme Corp · 14 repositoriesExample

Open findings

311

302 actionable

Known exploited

CISA KEV · 1 ransomware

Due this week

2 past SLA

SLA conformity

A · 96%

trailing 90 days

Top at-risk

Ranked by known exploitation and EPSS, not severity alone

PAY-142KEVjsonwebtoken@8.5.1 · CVE-2022-23529EPSS 43%2d overdue

WEB-77KEVdjango@4.1.13 · CVE-2026-11423EPSS 19%due in 3d

CHT-9Highlangchain-core@1.0.2 · CVE-2026-20817EPSS 12%due in 7d

Why not a bot

A scanner tells you. A bump bot guesses. Patchflare proves.

What each approach actually hands your engineers when a critical advisory lands on a Friday afternoon.

When a vulnerability is found	Scanner	Version-bump bot	Patchflare
What you receive	A finding and a ticket	A PR that changed a version number	A PR that built, passed your tests and rescanned clean
Major upgrades with code changes	Not attempted	Opens the bump; CI fails	Reads release notes, adapts call sites, or escalates with context
Prioritisation	Severity	Newest first	Known exploited, EPSS, severity, then SLA deadline
Review conversation	—	Close and wait for the next bump	Comment @patchflare; the agent updates the branch
Proof after merge	Next scan, whenever	—	Post-merge rescan marks the finding verified and freezes the SLA outcome
Audit evidence	Export findings	Git history	Finding, fix, verification and approver in one record, PDF/XLSX/CSV

Evidence, not archaeology

Every fix leaves a record an auditor can follow.

One reference per finding, PAY-142, that your team can say out loud. Behind it: the scan that found it, the pull request that fixed it, the build and test output, the rescan, the approver and the SLA outcome.

See the compliance workflow

Sep 1 · 05:00

Detected — PAY-142Scheduled scan · CVE-2022-23529 · CVSS 3.1 9.8 (critical) · in CISA KEV since 2023-01 · SLA clock started, due Sep 8

Sep 2 · 09:14

Patched — PR #2841jsonwebtoken 8.5.1 → 9.0.2 · scope gate passed · build 2m14s · 184 tests · rescan clean

Sep 2 · 11:02

Reviewedjmartin asked for the 8.x line; agent moved to 9.0.0 · checks re-run · approved by jmartin

Sep 3 · 08:40

MergedMerged into main by jmartin · post-merge rescan queued

Sep 3 · 09:05

Verified fixedRescan of main: advisory absent · SLA outcome met (2 of 7 days) · record frozen

Coverage

Auto-patches five ecosystems today. Scans and tracks many more.

Coverage is explicit, so you always know what Patchflare will fix and what it will track until it can.

Ecosystem	Package managers	Coverage
JavaScript / TypeScript	npm · pnpm · yarn	Auto-patch
Python	pip · requirements · uv · Poetry	Auto-patch
Go	Go modules	Auto-patch
Java / JVM	Maven · Gradle	Auto-patch
Rust	crates.io · Cargo	Auto-patch
Ruby, PHP, .NET and 15+ more	Detected from lockfiles and manifests	Scan and track

Questions

What teams ask before the first call

Straight answers to the questions procurement, security review and engineering leads raise first.

security@patchflare.com for anything not answered here.

Does Patchflare merge code automatically?

No. Your team reviews and approves every merge. Patchflare does the remediation and verification work, then hands you a pull request with the evidence, or a clear escalation when judgement is needed.

Which AI model is used, and does it train on our code?

Patch agents use Anthropic's Claude models through the commercial API, which does not train on customer data. Your repository is checked out only inside a single-use runner for the duration of one job and is not retained afterwards.

Do we have to install anything in CI?

No. Patchflare connects as a GitHub App. Patch jobs run in isolated environments outside your CI, one repository at a time, with no long-lived repository credentials inside the environment.

How does Patchflare decide what to work on first?

Findings are ordered by risk: vulnerabilities in CISA's Known Exploited Vulnerabilities catalogue first, then EPSS exploitation probability, then severity, then the nearest SLA deadline. Severity itself comes from CVSS with the source recorded on every finding.

Can it handle major dependency upgrades?

Yes. When a major upgrade needs code changes, the agent reads release notes, inspects affected call sites and makes mechanical adaptations. If the change is not safe to automate it escalates with context instead of guessing.

What ecosystems are covered today?

Automated patching covers JavaScript and TypeScript, Python, Go, Java and the JVM, and Rust. Other ecosystems are scanned and tracked while automated remediation coverage expands.

What happens after we request a demo or early access?

You get a reply from a person within one business day. Demos take thirty minutes on your repositories or ours. Early access starts with one repository and no payment details; pricing is agreed before anything is billed.

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.

Request a demo Request early access