CodeGuards v1
// signal

Stop fighting the same false positive: per-repository policies that actually stick

Every codebase has its own rules. Generic suppressions don't survive a refactor. Per-repo memory does — accept once, leave a note about the internal policy, and the same pattern stops nagging the team forever.

signal 2026-01-21 · ~4 min read

The false-positive tax

The fastest way to lose a team's trust in a security tool is to make them argue with the same finding twenty times. Each time the bot reopens the same conversation, the team's average opinion of the bot drops a notch. Eventually they mute it. After that, even the real findings die in the muted channel.

Why platform-wide rules don't work

The classic answer is "add a rule to the global config". This breaks for two reasons:

  • Repos differ. What's a placeholder fixture in billing-fe is a real secret in payments-core. A platform-wide ignore lowers the bar everywhere.
  • Reasons fade. A global rule with no context becomes a config diff nobody remembers approving. Six months later nobody can say why it was added.

What works: per-repo memory with a written reason

CodeGuards scopes suppressions to the repository they were accepted in. Mark the finding once, leave a one-line note ("placeholder used in unit tests" / "covered by gateway-level WAF rule" / "internal admin-only route, auth boundary above"), and the same pattern stops being reported on that repo from then on.

The same pattern in a different repo still gets flagged. Your tolerance for an internal admin tool doesn't lower the bar for the public payments service.

Why this also helps the audit

The note isn't just for muting the bot — it's exactly the artefact a control owner is supposed to record when they accept a finding as "covered by a compensating control". Author, timestamp, reason. Not because you're optimising for the audit, but because being clear about why a finding was accepted is just good engineering hygiene.

Mistakes happen — and they should be reversible

Suppressions are not one-way doors. Restore the rule any time the policy changes, and historical verdicts are recomputed so the dashboard reflects the new stance. If the team's tolerance shifts (or someone leaves and the original rationale stops applying), you don't have to live with the old decision forever.

Back to field notes