> For the complete documentation index, see [llms.txt](https://docs.xygeni.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xygeni.io/xygeni-scanner-cli/xygeni-cli-overview/mute-rules/server-side-rulesets.md).

# 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
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.