Skip to main content
Suppression rules tell Odin not to raise specific vulnerability patterns during PR Reviews. Use them to mute false positives, accepted risks, or patterns that are intentional in your codebase (for example, raw HTML rendering in a static blog generator, or test code that purposely uses weak crypto). Open Ignored findings from Settings > Ignored findings on the Agentic whitebox page.

​
Where rules come from

Rules can be created two ways:
  • Manual: you create them on this page when you know a pattern shouldn’t be raised
  • Auto-learned: when your team ignores the same suggestion across multiple PRs and you’ve enabled auto-suppression in Configuration, Odin creates a rule automatically once the threshold is hit
Each rule shows its source so you can tell at a glance whether it came from the team or was learned from PR dismissals.

​
Creating a rule

Click New Rule (or press c from the page) to open the creation dialog.
Use file patterns to scope rules narrowly. For example, suppress sql-injection only in tests/** rather than globally — that way Odin still flags it in production code paths.

​
Managing rules

From the rules list you can:
  • Filter by source (Manual / Auto-learned) and status (Active / Disabled)
  • Enable or disable a rule with the toggle — disabling lets you pause a rule without losing it
  • Delete a rule permanently from the Actions column — Odin resumes raising findings that match it on the next PR

​
Adding a file pattern

A rule only applies to the files it covers, so it needs a file pattern before it can be approved or switched on. Auto-learned rules arrive without one. Click Add file pattern in the rule’s File pattern column (or in its actions menu), enter the files it should cover, and save. Then approve it or switch it on. If you try to approve or switch on a rule that has no pattern, the same dialog opens for you. If you’re a member and the rule is already on, adding a pattern pauses it until an admin approves the change.

​
Best practices

  • Document the reason clearly. Future you (and your teammates) will thank you when reviewing why something was suppressed.
  • Prefer narrow scope: repository-scoped rules with file patterns are safer than organisation-wide rules.
  • Review auto-learned rules periodically. They’re created from real dismissal patterns, but they can encode bad habits if your team is over-dismissing.
  • Disable rather than delete if you’re not sure — disabled rules can be re-enabled later, deleted ones can’t.