Build passed2m 14s
For CTOs, engineering managers and developers
Security patches that arrive as finished work, not tickets.
Patchflare opens one pull request per finding that has already built, passed your tests and rescanned clean. Your team reviews it like any other PR, asks for changes in a comment, and merges when ready.
The problem in your words
What the patch queue costs you today.
A patch is a project
Upgrade, fix the breaking change, wait for CI, untangle the transitive dependency that came with it. Multiply by every critical advisory.
Bump bots create review debt
A PR that changed a version number and broke the build is not help. It is a ticket with extra steps, and the team learns to ignore them.
Nobody owns the queue
In a monorepo the finding belongs to everyone, so it belongs to no one. Ownership is settled in the sprint planning meeting after the SLA has passed.
One more tool in CI
Every security tool wants a workflow file, a runner, a token, and a Slack channel. Each one is a maintenance obligation.
The pull request
It already builds. It already passes your tests.
Before a PR is opened, the agent has run your install, your build and your test suite in a clean environment and rescanned the tree. The results are on the PR. If it cannot get there safely, it says so instead of opening something broken.
- One finding, one PRSmall, reviewable, revertible. Dependency files only, unless a major upgrade needs a call-site change, which is shown and explained.
- Talk to it in the reviewComment @patchflare with a constraint, a version, a preference. The agent revises the branch and re-runs the checks.
- Learns your repositoryInstall commands, test commands, pinning conventions and past lessons carry into the next job.
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 mergeDoneRepository 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
Control
On your schedule, on your repositories, at your pace.
Enroll the repositories you choose. Scan on a schedule in your time zone or on demand. Patch on demand, one finding at a time, and see exactly what the agent did and when.
- Per-repository enrollment and rolesWho can run the agent, who can grant exceptions, who may trigger follow-ups from a PR comment.
- Human-friendly referencesPAY-142 in Slack, in the PR title and in standup. Search it, link it, close it.
- Every session is a timelineWhat was run, what passed, what the scope gate checked, how long it took.
Architecture
A GitHub App, a control plane, and runners that cannot reach anything else.
No agents in your infrastructure, no CI changes, no long-lived tokens. The runner clones with a scoped token, does the work, pushes a branch and is destroyed.
- Nothing to install or maintainUninstalling the GitHub App removes Patchflare completely.
- Deterministic scope gateA rule-based check, not a model, decides whether the diff stayed in bounds.
- Model provider with no training on your codeAnthropic's commercial API; prompts hold manifests, advisories, release notes and relevant call sites.
Proof
What an agent session looks like from the inside.
Every step is timed and recorded. This is the session behind the pull request above, including the scope-gate check that runs before anything is opened.
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
Questions
What people in your role ask
Answers to the questions that come up in the first conversation.
security@patchflare.com for anything not answered here.
How many pull requests will we get?
As many as you ask for. Patching is on demand per finding today; scheduled auto-patching for low-risk updates is on the roadmap and will be opt-in per repository.
What happens when the tests fail?
The PR is not opened. The session ends with the failing output and the agent's explanation, and the finding stays in the queue with that context attached.
Does it work with our monorepo?
Yes. Findings are tracked per manifest path, so a vulnerable package in services/payments is a different finding from the same package in services/web, and each PR touches one of them.
Can it be limited to certain repositories?
Install the GitHub App on selected repositories and enroll only those. Enrollment, scheduling and agent triggers are all per repository.
Try it on one repository.
Early access starts with a single repository and no payment details. See a real pull request on your code before you decide anything.
@patchflare 9.0.2 drops Node 14, which we still run in the batch worker. Can you stay on the 8.x line?