Suppression Management

Why Suppression Matters

Not every finding in a pentest report requires remediation. Some findings are false positives — the agent identified something that looks like a vulnerability but is actually mitigated by controls the agent cannot observe (a WAF rule, an upstream proxy, or a compensating control). Other findings represent accepted risks — the organization has evaluated the risk, determined it falls within their risk appetite, and chosen not to remediate.

Without suppression, these findings reappear in every repeat pentest, cluttering reports and consuming triage time. TurboPentest's suppression system lets you mark specific findings so they are filtered from future reports, keeping your results focused on new and actionable vulnerabilities.

How Suppression Works

TurboPentest's suppression system operates at the finding fingerprint level. Each finding has a cryptographic fingerprint derived from its vulnerability characteristics — the vulnerability type, affected endpoint, and exploit signature. When you suppress a finding, you are telling the platform: "I have evaluated this specific vulnerability on this specific target, and I do not want it to appear in future reports."

A suppression record consists of four fields:

User ID — The user who created the suppression. This establishes accountability for who made the risk decision.

Target URL — The target domain the suppression applies to. Suppressions are scoped to a specific target, not global. Suppressing a finding on example.com does not suppress the same fingerprint on staging.example.com.

Fingerprint — The unique identifier of the finding being suppressed. This ensures the suppression applies only to the exact vulnerability, not to similar-looking findings on different endpoints.

Reason — An optional but strongly recommended text field explaining why the finding was suppressed. This is your audit trail.

The combination of user, target URL, and fingerprint forms a unique constraint. You cannot create duplicate suppressions, and each suppression is attributable to a specific person.

Creating Suppressions

When reviewing a scan's findings, you can suppress any finding by providing a reason. Common suppression categories include:

False Positive — The finding does not represent a real vulnerability. For example, an agent may flag a reflected input that is actually processed through a server-side sanitizer the agent could not detect. Your reason might be: "Input is sanitized by server-side DOMPurify before rendering. Verified in code review."

Accepted Risk — The vulnerability is real but the organization has decided not to fix it. Your reason should document the risk decision: "IDOR on user profile photos. Business decision: profile photos are considered public data. Risk accepted by CISO on 2025-01-15."

Compensating Control — A security control outside the scan's visibility mitigates the finding. For example: "XSS on /legacy-form. Mitigated by Cloudflare WAF rule CF-2024-XSS-001 which blocks the payload in production."

Not Applicable — The finding targets functionality that does not exist in the production environment. For example: "Debug endpoint /admin/phpinfo.php only present in staging. Not deployed to production."

Expiration

Suppressions can include an optional expiration date through the expiresAt field. An expiring suppression tells the platform: "Suppress this finding until this date, then let it reappear." This is useful for:

Deferred remediation — You plan to fix the issue but not immediately. Setting an expiration ensures the finding resurfaces when the planned fix date arrives, preventing it from being forgotten.

Temporary compensating controls — A WAF rule is in place while the team develops a permanent fix. The suppression expires when the temporary control is scheduled for removal.

Risk review cycles — Your organization reviews accepted risks periodically. Setting suppressions to expire at the next review date ensures each risk decision is re-evaluated on schedule.

If no expiration is set, the suppression persists indefinitely until manually removed.

Managing Suppressions

Good suppression management follows these principles:

Always provide a reason. A suppression without a reason is a liability. Six months from now, no one will remember why a critical finding was suppressed. The reason field is your institutional memory.

Use expiration dates for non-permanent decisions. If you are not 100% certain a suppression should be permanent, add an expiration. It is far better to re-evaluate a suppression than to silently carry an accepted risk forever.

Review suppressions regularly. Suppressions should be audited periodically. Compensating controls change, team members leave, and risk appetites evolve. A suppression created a year ago may no longer be appropriate.

Scope suppressions narrowly. Suppressions apply to a specific target URL and fingerprint. Do not attempt to work around this scoping — if the same vulnerability type appears on a different endpoint, it deserves its own evaluation.

Track who suppresses what. Every suppression records the user who created it. This accountability is essential for compliance frameworks that require documented risk acceptance (SOC 2, ISO 27001, PCI DSS).

Suppression vs. Severity Override

TurboPentest offers two mechanisms for adjusting how findings appear: suppression and severity override. Understanding when to use each is important.

Suppression hides the finding from future reports entirely. Use suppression when the finding is a false positive, an accepted risk, or not applicable. The finding still exists in the database but is filtered from view.

Severity Override changes the finding's displayed severity level without hiding it. Use severity override when the finding is real but the automated severity does not match your assessment. For example, a medium-severity XSS on an internal-only admin page might be overridden to low because only trusted administrators can access it.

Both mechanisms record who made the change and when, maintaining a complete audit trail. The key difference is visibility: suppressed findings disappear from reports, while overridden findings remain visible with their adjusted severity.

Impact on Finding Continuity

Suppressed findings interact with the finding continuity system in a specific way. When a repeat pentest discovers a finding that matches a suppressed fingerprint for the same target, the finding is still recorded in the database with its continuity status, but it is filtered from the report view. This means:

• Your finding continuity data remains accurate even for suppressed findings
• If you remove a suppression, the full history of that finding across pentests is still available
• Suppression does not delete data — it controls visibility