How do ignore rules work?

An ignore rule is an administrator action with its own API. It is deliberately not a policy key, because it does something different: it suppresses the action, never the scan and never the record of the finding. That distinction is what makes an ignore list auditable instead of a blindfold.

The four kinds

• path_glob — a path pattern relative to the scope, for example a generated cache directory
• signature — a specific signature or rule ID that misfires in your environment
• hash — one exact file, by SHA-256
• user — a specific account

Adding, listing and removing

shelltrap ignore add --scope domain --scope-id 42 --kind path_glob \
  --value 'cache/**' --note 'generated cache'
shelltrap ignore list
shelltrap ignore remove <id>

Always write a --note. In six months the note is the only thing that tells you whether the rule is still needed.

Prefer the narrowest scope that works

A hash ignore for one file is safer than a path glob for a directory, and a domain-scoped rule is safer than a global one. A broad path_glob on something like wp-content/** takes the action away from the exact place attackers put webshells.

Ignore rule or false-positive report?

They solve different problems and are often used together:

• An ignore rule is local and immediate. It quiets one host now.
• A false-positive report to us fixes the rule for everyone: a confirmed false positive is released by SHA-256 in the next signed signature generation, which every server picks up at its next feed refresh.

If a rule misfires on software that many people run, report it. See "How do I report a false positive?".

One thing an ignore rule cannot do

The known-good hash allowlist does not blindly override a path-context hit, and neither should your ignore rules. A known-good file in an uploads directory is still worth a finding, because the interesting fact is the location, not the bytes.

Changing a rule

The ignore API supports create and delete but has no atomic update. A change therefore creates the fully validated new rule first, checks the returned ID strictly, and only then deletes the old one. If that delete fails, the plugin tries to compensate by removing the new rule and reports the failure visibly. This is documented rather than hidden because it is the kind of edge you want to know about before it surprises you.