Custom Rules

ScanSuite runs your own rules alongside its scanners: Semgrep rules in static analysis, and Nuclei templates in web and infrastructure scans. They live on the Rules page (sidebar, Library), together with the suppression rules triage creates. The page has three tabs: Custom rules, Suppressions and Git sources.

Creating a rule

Click New rule and choose what to start from:

zoom_inEnlarge

The editor holds the rule as YAML. Start from: offers ready-made starters, and the rule is checked by its engine as you write, so a rule the engine rejects shows the error before you save. The Details tab sets the rest:

Click Save. Check: the editor says Valid Semgrep rule or Valid Nuclei rule, and the rule is listed on the Custom rules tab. The Runs in scans switch decides whether the rule is used; a rule the engine rejects cannot be switched on. The History tab keeps every saved version, which you can compare or load back into the editor. Delete removes the rule and its history; the findings it reported stay on the Vulnerabilities page.

A rule synced from a Git source shows a banner: its YAML is changed in the repository, while its switch, scope, packs and tests are yours to set here.

Testing a rule

The Test tab keeps samples with the rule, each marked Should match or Should not match. For Semgrep, a sample is a piece of code, and the samples run on every save. For Nuclei, a sample is a captured HTTP response, and the template runs against a local copy of it, never a real host. Run tests runs them on demand.

The Try tab runs the rule once without a scan, and stores nothing: a Semgrep rule on a product's repository, a Nuclei template against a URL. The Nuclei try sends real requests, so it is only allowed against a target the team may scan.

Generating a rule with AI

The AI assist tab writes a new rule or changes the one in the editor. Say what it should catch or change, then give it the evidence:

• for a Nuclei template, the HTTP request and HTTP response that show the vulnerability;
• for a Semgrep rule, the Language, the Vulnerable code and, optionally, Safe code it must not flag.

Click Generate. The draft is validated and tested before you see it, and the response or vulnerable code becomes a test sample. Click Apply to editor, review the rule, and save it.

zoom_inEnlarge

An AI provider must be configured for this — see AI providers and cost.

The rules list

The Custom rules tab lists every rule with its switch (On), Rule, Engine, Severity, Applies to, Open findings and Updated.

Import, export and Git sources

Import takes Semgrep rule files and Nuclei templates as .yaml or .yml, or a .zip of them, up to 10 MB, and shows a preview before anything is saved. Each file is marked Ready, Already in the library, Invalid or Not a rule; only the ready ones are imported. Two options:

Export downloads the rules.

On the Git sources tab, Add a repository of rules:

Click Add and sync. Check: the source is listed with its rule count, and the message says how many rules were added, updated and removed. Every Semgrep rule file and Nuclei template under the folder becomes a rule. Sync now adds new files, updates changed ones and removes rules whose file is gone. Remove stops syncing: the rules stay in the library and become editable, unless you tick Also delete its rules.

Running the rules

To run a scan against the saved rules, switch on the Custom Rules scanner in the relevant scan section — it is available for static, web and infrastructure scans. Under the switch, the form says how many rules will run for the chosen product, and lets you limit the run to some packs. When no active rule applies to the product, the scanner is skipped.

What your rules find is always stored on the Vulnerabilities page, whether or not the scan also exports to DefectDojo. A Semgrep rule matching a file gives one finding for that file, listing every matching line.

Suppression rules

A suppression rule stops AI SAST reporting one vulnerability class in a file, a folder or a whole repository; it also applies to custom rule findings. You create one while ruling out a finding: on the Vulnerabilities page, False positive… offers Don't report this class here again — see Vulnerability Management. Suppressed classes are not analysed in later scans, so they cost no AI budget.

The Suppressions tab lists every rule:

zoom_inEnlarge

Retire ends a rule: the class is reported again where the rule covered it. A rule past its expiry date stops applying on its own. A product's rules are also listed on the Settings tab of its page.

Suppressed names

The Suppressed names card, also on the Suppressions tab, lists the vulnerability names a product no longer stores, whichever scanner reports them. You add one with Suppress by name… on the Vulnerabilities page, which also deletes the existing findings of that name; see Vulnerability Management, "Suppress a noisy check".

Remove asks first, then lets scans store findings of that name again. The findings deleted with it do not come back. A product's suppressed names are also listed on its page.