Skip to main content
Percher is still being built and account creation is paused — get notified when it opens.

Security scanning

Automatic CVE scanning + alerts

Ask your agent
Review my app's security findings, explain what is actually exposed, and fix the safest high-priority items first. Show me the planned changes before redeploying.Read the guide at percher.app/docs/security-scanning
How it works, with exact details

Percher scans every image it builds for known vulnerabilities (CVEs), and keeps watching your live apps after they ship, so a CVE disclosed next week still reaches you. Findings live in your app's Security tab, sorted by how much they matter:

  • Red: a critical vulnerability with a fix available that is either reachable from the internet or on CISA's list of vulnerabilities known to be exploited in the wild. Handle this one first.
  • Yellow: a high-severity vulnerability with a fix available, or a critical one that is neither internet-reachable nor known-exploited. Update when you're ready.
  • Green: low or medium severity, or anything with no fix released yet. Nothing to do — it escalates automatically if a fix lands.

A red finding starts a 14-day clock from the day it turns red, and you're emailed when that happens. If it is still red after the window and it is on the known-exploited list, percher.run takes the app offline until it's patched — a self-hosted Percher does this only if its operator enables it. You can submit a remediation deploy while it's held: its image must be free of red findings that are yours to fix before Percher swaps traffic to it, and the hold lifts once the post-swap canary passes. Red findings in the base image Percher chose for you don't block it — those are ours, so you may still see one listed after the hold lifts.

Each finding names the CVE, the affected component, and where it lives in your image (the exact binary or node_modules path), so you can tell whether it's your dependency or a build tool you can drop. A common surprise: a stdlib finding is usually a Go binary like esbuild bundled into node_modules by your toolchain, not a server component.

Percher only emails you about red findings, the ones genuinely worth acting on. Lower-severity findings stay in the dashboard, not your inbox. The email carries the fix version and a ready-to-paste prompt for your AI assistant, so the upgrade and redeploy are one step.

CVEs in the base image and language runtime Percher chose for you are handled centrally by Percher. They're never counted against your app, never block your deploy, and never land in your inbox.

To clear a finding, upgrade the affected dependency and redeploy. The next scan confirms it's gone and the finding resolves automatically.