Server-Side Mute Rulesets

Named mute rulesets can be stored on the Xygeni server so teams can share a single source of truth for suppressions across projects. Any scan can then reference a ruleset by name with --mute '#name' — the scanner fetches the ruleset YAML from the server at scan time.

Server-side rulesets are managed from the CLI with the xygeni util mute family of commands.

For the descriptor YAML format used by these rulesets, see Mute Descriptor Format. For the end-user workflow (auto-discovery, --mute option, precedence, guardrail behavior), see Mute Rules.

List all rulesets

xygeni util mute --list

Displays a table with ruleset names and their enabled/disabled status.

Download a ruleset

xygeni util mute --get --name my-ruleset

Downloads the ruleset YAML and saves it locally as <scannerDir>/my-ruleset.xygeni.mute.yml.

Upload a ruleset

# Upload a new ruleset
xygeni util mute --upload --name my-ruleset --file path/to/rules.yml

# Upload and overwrite an existing ruleset
xygeni util mute --upload --name my-ruleset --file path/to/rules.yml --override

Remove a ruleset

xygeni util mute --remove --name my-ruleset

Enable / disable a ruleset

# Enable
xygeni util mute -e --name my-ruleset

# Disable
xygeni util mute -d --name my-ruleset

Disabled rulesets remain stored on the server but are rejected when referenced by a scan.

Using server-side rulesets in scans

Reference a server-side ruleset by prefixing its name with #:

xygeni scan --mute '#my-ruleset'

The scanner fetches the ruleset YAML from the server at scan time and applies it exactly like a local .xygeni.mute.yml file.

When to use named rulesets vs. in-repo .xygeni.mute.yml

• Named server-side rulesets are ideal for cross-project or organization-wide suppressions managed by a central security team — for example, "allow these known corporate test secrets everywhere" or "set severity to info for this internal CWE in all projects".

• An in-repo .xygeni.mute.yml is ideal for project-specific suppressions that should live and evolve with the code — for example, "SAST findings in this project's src/test/** are accepted".

The two can be combined: run the scan with --mute '#corp-baseline' and keep a .xygeni.mute.yml in the repo for project-local additions (auto-discovered when enableConfigurationMutes is true). However, only one mute descriptor is applied per scan — when both are available, the explicit --mute argument wins over auto-discovery (see Precedence).