Skip to Content
Scanning & DetectionFalse Positive Management

False Positive Management

Not every detection is accurate. Slim.io provides suppression rules that let you mark findings as false positives and prevent them from reappearing in future scans. This keeps your findings feed clean and actionable without losing audit history.

How Suppression Works

When you mark a finding as a false positive, Slim.io creates a suppression rule based on the finding’s characteristics. On subsequent scans, new findings that match an active suppression rule are automatically suppressed — they are still recorded internally for audit purposes, but they do not appear in your active findings or trigger governance policies.

New Finding Detected → Check against active suppression rules → Match found → Finding suppressed (hidden from active view) → No match → Finding reported normally

Suppressed findings are never deleted. They are retained in the scan record with a “suppressed” status, so you always have a complete audit trail of what was detected and why it was dismissed.

Suppression Scopes

Suppression rules can be scoped at three levels to give you precise control:

ScopeSuppresses Matches InExample Use Case
GlobalAll resources across all connectorsA test SSN pattern (000-00-0000) that appears everywhere
ResourceA specific resource (file, table, bucket)A known configuration file that contains example data
ColumnA specific column in a specific tableA test_ssn column in a QA database

Narrower scopes take priority. If a global rule would suppress a finding but a resource-level rule explicitly allows it, the finding is reported.

Creating Suppression Rules

From the Dashboard

  1. Navigate to the finding you want to suppress
  2. Click Mark as False Positive
  3. Choose the suppression scope (Global, Resource, or Column)
  4. Optionally set an expiration period
  5. Add a reason (required) — this is recorded in the audit log

Via the API

POST /api/v1/suppressions { "finding_type": "SSN", "pattern": "000-00-*", "scope": "resource", "resource_id": "res_abc123", "reason": "Test data in QA environment", "expires_in_days": 90 }

Expiration

Suppression rules can be configured with an expiration period. After the specified number of days, the rule automatically expires and matching findings will be reported again in future scans.

ExpirationBehavior
None (default)Rule remains active indefinitely until manually deleted
30 / 60 / 90 / 180 / 365 daysRule expires after the specified period
CustomSet any number of days via the API

Review your suppression rules periodically. A rule created for a test environment may no longer be appropriate if that environment is repurposed for production data.

Managing Suppression Rules

All active suppression rules are visible in the dashboard under Settings > Suppressions. From there you can:

  • View all active and expired rules with their scope, reason, and creation date
  • Edit the expiration period or reason for an existing rule
  • Delete a rule to immediately stop suppressing matching findings
  • Export rules as JSON for backup or migration

Via the API

# List all active suppression rules GET /api/v1/suppressions # Get a specific rule GET /api/v1/suppressions/:id # Delete a rule DELETE /api/v1/suppressions/:id

Fail-Open Design

The suppression system is designed to fail open. If the suppression engine encounters any error — database timeout, malformed rule, internal exception — findings are not suppressed. This means:

  • A broken suppression rule will never cause a real finding to be hidden
  • If the suppression system is unavailable, all findings are reported normally
  • You may see temporarily increased finding counts during suppression system issues, but you will never miss a real finding

Fail-open is a deliberate safety decision. For a data security platform, it is always better to over-report than to silently hide findings due to a system error.

Audit Trail

Every suppression action is recorded in the audit log:

EventRecorded Details
Rule CreatedWho created it, scope, pattern, reason, expiration
Finding SuppressedWhich finding, which rule matched, scan ID
Rule ExpiredRule ID, expiration date
Rule DeletedWho deleted it, deletion reason

Audit records are immutable and retained according to your data retention policy.

Last updated on