Ctadel

Suppress or ignore a finding

Some findings are accepted risks, intentional configurations, or known false positives. Ctadel supports both per-finding ignores and tenant-wide ignore rules with full audit trails.

When to ignore vs resolve

ActionUse when
RESOLVEDYou fixed the underlying issue and the next scan should confirm.
IGNOREDThe finding is correct but you accept the risk or it is intentional.

RESOLVED is set automatically by the next scan when the rule no longer matches; it is never set as OPEN automatically. So IGNORED is the right verb for accepted risks.

Per-finding ignore

  1. Open the finding's detail panel.
  2. Click Status, Ignore.
  3. Pick a reason from the dropdown:
    • False positive
    • Accepted risk
    • Compensating control in place
    • Out of scope (intentional)
    • Other (free text)
  4. Optionally set a TTL: 7d, 30d, 90d, never.
  5. Add a free-text note (recommended for audits).
  6. Save.

The finding moves to IGNORED status. It will not re-open until either the TTL expires or you manually re-open it.

TTL behaviour

When the TTL fires:

  • The next scan re-evaluates the rule.
  • If the underlying issue is gone, the finding stays out (the issue is fixed).
  • If the issue is still there, the finding flips to OPEN and you triage again.

never is acceptable but discouraged, the auditor question is "when did you last review this exception?".

Tenant-wide ignore rule

For repeating false positives, build an ignore rule instead of ignoring each finding.

  1. Open Policies, Suppression Rules, New rule.
  2. Pick the detector (CSPM, KSPM, ...).
  3. Pick the matching criteria:
    • Rule key (one specific rule).
    • Resource pattern (regex on resource ID, e.g. arn:aws:s3:::demo-.*).
    • Tag pattern (cloud-native tags like Environment=demo).
    • Severity threshold (e.g. ignore all LOW for this category).
  4. Reason + optional TTL.
  5. Save.

The rule applies to existing OPEN findings (which become IGNORED) and to all future findings that match.

Audit trail

Every ignore action is logged with:

  • Who did it.
  • When.
  • The reason.
  • The optional note.
  • The TTL.

The audit log is exportable from Settings, Users & Roles, Audit log. Auditors appreciate clean exception lists, so do future you.

Common pitfalls

  • Mass-ignore on day one. Ignoring 200 findings to make the dashboard look clean is the worst thing you can do. Triage first, ignore after.
  • No reason. "Other" with no note creates ambiguity for the next reviewer. Always write the why.
  • Wildcards on resource patterns. Match exactly what you mean. .* matches every resource, which is rarely what you want.

What's next