# 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.

{% hint style="info" %}
For the descriptor YAML format used by these rulesets, see [Mute Descriptor Format](/xygeni-scanner-cli/xygeni-cli-overview/mute-rules/descriptor-format.md). For the end-user workflow (auto-discovery, `--mute` option, precedence, guardrail behavior), see [Mute Rules](/xygeni-scanner-cli/xygeni-cli-overview/mute-rules.md).
{% endhint %}

## List all rulesets

```bash
xygeni util mute --list
```

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

## Download a ruleset

```bash
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

```bash
# 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

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

## Enable / disable a ruleset

```bash
# 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 `#`:

```bash
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](/xygeni-scanner-cli/xygeni-cli-overview/mute-rules.md#precedence)).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.xygeni.io/xygeni-scanner-cli/xygeni-cli-overview/mute-rules/server-side-rulesets.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.