For CISOs and application security

Know your real exposure. Close it inside the SLA. Prove both.

Patchflare ranks findings by known exploitation and EPSS, runs an SLA policy you set, and turns every fix into a verified record. The queue gets shorter without your engineers hating you.

The problem in your words

What the patch queue costs you today.

Severity is not risk

Hundreds of highs, three of them actually exploited in the wild. CVSS alone cannot tell you which three, so the team patches alphabetically and the board asks why the exploited one was still open.

The SLA is a spreadsheet

Seven days for critical is policy. Whether it happened is a manual reconciliation of tickets, PRs and scan dates the week before the audit.

Chasing is the job

AppSec spends its time asking engineering for status, re-verifying fixes by hand and explaining why a version bump PR broke the build.

Exceptions live in email

Risk acceptances are decided in a thread, never expire, and nobody can list them when the auditor asks.

Prioritisation

Known exploited first. Then EPSS. Then severity.

Every finding shows its CVSS source, whether the CVE is in CISA's Known Exploited Vulnerabilities catalogue, and its EPSS probability, refreshed daily. The dashboard and Slack alerts lead with those signals; severity and SLA deadlines stay what your policy says.

  • Top at-risk, explainedThe dashboard tells the reader why a High sits above a Critical, so nobody has to defend the ordering.
  • Known-exploited alertsA Slack message the day a CVE you carry enters the KEV catalogue, with the federal due date.
  • Search and filter by ref, CVE, KEV, EPSS, SLA stateOne queue across every repository, no exports needed.
Dashboard· Acme Corp · 14 repositoriesExample
Open findings
311
302 actionable
Known exploited
3
CISA KEV · 1 ransomware
Due this week
12
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
Finding PAY-142· acme / payments-apiExample
PAY-142

CVE-2022-23529

GHSA-27h2-hvpr-p74q · jsonwebtoken 8.5.1
Critical · 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

SLA policy

Set the policy once. Read the conformity score every morning.

Per-severity deadlines, versioned, applied to every open finding. Breaches alert; a daily digest lists what is due; a conformity band over the trailing ninety days tells you how the program is doing.

  • Materialised clock per findingStarted at detection, paused by an exception, frozen at verified fix. No re-computation surprises.
  • Exceptions with reason and expiryAccepted risk, false positive, won't fix. Who, why, until when. Automatic pause while no fixed version exists.
  • Per-repository scoreSee which teams meet the policy and which need help before it becomes a finding of its own.

Vendor review

An agent that can only ever open a pull request.

Single-use runners with no standing credentials, scoped GitHub tokens, a deterministic scope gate, human approval on every merge, and a model provider that does not train on your code. The full packet is on the Security & trust page.

  • Nothing in your CINo workflow files, no self-hosted runners, no secrets to rotate.
  • Least-privilege GitHub AppInstall on selected repositories; per-repository control of who may trigger the agent.
  • Questionnaire-readyArchitecture, permissions and data handling written down at /security. Ask us for the rest.
Patchflare architecture: your GitHub, the Patchflare control plane, and single-use runners that hold no standing credentialsYOUR GITHUBYour repositoriesPatchflare installed as a GitHub AppSelected repositories onlyShort-lived token per jobYou review and merge every PRPATCHFLARE CONTROL PLANEScanner, scheduler, SLAFindings, evidence, reportsEncrypted at rest, audit trailNo source code retainedSlack and email alertsSINGLE-USE RUNNEROne repository, one jobNo cloud credentials insideIsolated networkDestroyed when the job endsModel API, no training on codeGitHub Appjob, resultsThe runner clones with a scoped token, opens the pull request, then the environment is destroyedNEVERA tool in your CI · a long-lived token in a runner · a merge without a human · training on your code · a change outside dependency files

Proof

One finding, from detection to verified fix, as you would show it to the board.

This is the record behind a single reference. Every line is an event Patchflare wrote, with actor and timestamp.

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

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.

Does this replace our scanner?

Patchflare scans dependencies itself and merges Dependabot findings, so for dependency vulnerabilities it replaces the scanner queue. It does not do SAST, secrets or container scanning; findings from those tools stay where they are today.

Can we keep our own severity policy?

Severity comes from CVSS with the version recorded, or from the advisory label if you prefer that source. Exploitation signals never change severity; they change order. SLA deadlines are yours to set per severity.

Who can accept a risk?

Anyone with the repository manager role. The exception records their name, reason and expiry, pauses the SLA clock, shows in every report, and comes back automatically when it expires.

What do we get for the vendor review?

The Security & trust page covers architecture, permissions, data handling and retention. Email security@patchflare.com for questionnaires and assessment reports.

See your exposure ranked by real exploitation.

A thirty-minute demo on one of your repositories. Bring your security questionnaire.