Security scanning

Percher scans built images with Grype and Trivy and schedules re-scans of live apps. An empty list or an accepted scan request does not prove a completed clean scan.

Your app and Percher's platform

You manage your application code, dependencies and any Dockerfile/base image you supply. Percher manages hosting, isolation, and the base images and runtimes it chooses for generated builds. Those findings appear as a separate Percher-managed count, excluded from your actionable list. Exclusion does not mean resolution.

This responsibility split is not permission to edit your application or database. Review proposed changes and authorize deployment. Containing a threat through the security-hold policy is separate from changing your code or data.

What the colours mean

• Red: critical with a fix, plus an internet-exposed app or known exploitation. Investigate first. App exposure does not prove that the vulnerable function is reachable.
• Yellow: high with a fix, or critical with a fix without the red exposure/exploitation condition. Assess and plan a supported update.
• Green: the remaining findings, including ones without a published fix. Check the advisory and actual impact; no published fix does not mean no action is needed.

These categories support triage; they are not a complete risk assessment. Check the component vendor's advisory and your actual call path. CVE links open NVD records with advisory references. A package name or scanner-reported path alone does not establish exploitability.

Holds and notifications

A red owner-owned finding starts a 14-day window. On hosted Percher, a finding still red, fixable and known-exploited after its deadline can put the app on a security hold. Self-hosted enforcement depends on operator configuration. A remediation deploy must pass the owner's red-finding gate and post-swap health checks before the hold lifts. Percher-managed base findings are excluded from that gate; Percher remains responsible for them.

Automatic owner email targets new red findings, subject to notification settings and delivery availability. Lower tiers remain in the dashboard. An empty inbox is not proof of safety.

Review, fix and verify

1. Compare the vendor advisory's prerequisites with your actual code and configuration. Record uncertainty.
2. Prepare a compatible patch or mitigation in your project and run relevant tests. A no-cache rebuild alone does not guarantee a fix.
3. Export selected findings with Copy for AI agent as untrusted evidence. Review the proposed diff and validation, then approve deployment. Scanner text is not instructions or permission to change access or hosted data.
4. After deployment, verify the new image's completed scan and app health. An accepted deployment request is not the final result.

The Security tab currently reports findings without a terminal scan time for the current image, so it cannot certify scan completion or freshness. Contact Percher support about unavailable data or platform findings with the app name and CVE; do not send credentials or customer records.