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.

A Go stdlib or golang.org/x/... finding at a program such as /usr/bin/caddy is compiled into that program. If your project builds it, raise the Go version or module in go.mod or your Dockerfile's Go image; if it comes from a base image, use a newer image built with the fixed version.

Check which scan you are reading

Current deployment scan shows the latest attempt for the live deployment. Scan completed means its recorded results and database freshness passed the evidence checks. Scan inconclusive means the result cannot establish the current findings; it does not mean there are none. The image identity comes from the scan, unless a separate runtime check is explicitly recorded.

Saved findings and decisions keeps earlier reports and decisions such as an accepted risk or security hold. These records are not confirmation that the same issue exists in the current image. Moving a finding out of the current list does not resolve it or remove a hold.

The AI export includes the deployment, recorded image identity, scan times, engine outcomes and database freshness. Package versions and scanner-provided fix candidates are included when available; older records may lack them. Confirm a compatible fix with the vendor advisory. Updating an npm package does not update a copy built into the language runtime.

Contact Percher support about unavailable evidence or platform findings with the app name and CVE. Do not send credentials or customer records.