Suppressing Findings

Not every finding needs to gate a PR. Secbez supports several ways to suppress findings you have reviewed and decided to accept, defer, or classify as a false positive.

Server-side suppression

From a finding's detail pane on the dashboard:

1. Click Suppress.
2. Choose a reason: false positive, accepted risk, won't fix, or duplicate.
3. (Optional) Add a comment for future reviewers.
4. (Optional) Pick a scope: this finding only, this rule on this file, or this rule across the repository.

Server-side suppressions persist across scans, do not require code changes, and are recorded in the audit log.

Inline suppression markers

For per-line suppressions kept in source, Secbez recognizes inline markers in code comments. Two forms are supported, in JS/TS (//) and Python (#):

// secbez-ignore SEC.SQLI.RAW_QUERY_TEMPLATE_LITERAL — query is on a static admin-only path
db.$queryRaw(adminQuery);

// secbez-ignore-next-line SEC.SQLI.RAW_QUERY_TEMPLATE_LITERAL — query is on a static admin-only path
db.$queryRaw(adminQuery);

The marker can reference a specific rule ID. A reason after the rule ID is recommended; markers without a reason are still honored but are flagged in the dashboard for review.

Baseline tracking

The first full scan on a repository establishes a baseline — every finding it produces is marked pre-existing. Subsequent scans:

• Flag new findings introduced by changes — these are the ones that gate the PR.
• Track baseline findings in the dashboard but never gate PRs on them.

This keeps PR review focused on net new risk and avoids burying contributors under existing tech debt.

You can re-baseline at any time after a remediation sweep — the new baseline becomes the floor for future PRs.

Re-opening suppressed findings

If a suppressed finding is later considered important (e.g., the surrounding code changed and the suppression no longer applies), you can re-open it from the dashboard. The finding returns to open and is included in the next policy evaluation.

The audit log records the suppression, the re-open, and the user who took each action.

Bulk operations

The findings feed supports bulk suppress, bulk re-open, and bulk export. Bulk suppress is useful for retiring a class of findings after a framework upgrade closes them all (e.g., switching from raw SQL to a query builder).

Best practices

• Prefer server-side suppression with a clear reason. It is easier to audit than inline markers.
• Don't suppress without an evidence note — it makes future re-evaluation harder.
• Re-baseline only after a real remediation effort. Re-baselining to "make the dashboard green" is how teams lose visibility into their backlog.