Suppression rules tell Mjolnir 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 Suppression Rules from Pentests > Mjolnir > Suppression Rules in the sidebar.
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 Mjolnir Configuration, Mjolnir 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.
| Field | Description |
|---|
| Scope | Apply the rule to a single repository or across the entire organisation |
| Repository | When scope is repository, the full owner/repo name from GitHub |
| Category | The vulnerability category (e.g. injection, authorisation) |
| Vulnerability type | The specific type within that category (e.g. sql-injection, idor) |
| File pattern | Optional glob to restrict the rule to matching paths (e.g. tests/**, src/legacy/*.ts) |
| Reason | Why this pattern is acceptable. This is required and gets shown to teammates reviewing the rule. |
Use file patterns to scope rules narrowly. For example, suppress sql-injection only in tests/** rather than globally — that way Mjolnir 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 — Mjolnir resumes raising findings that match it on the next PR
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.
