Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Eljakani/ward/llms.txt

Use this file to discover all available pages before exploring further.

Ward allows you to override rule behavior without editing the original rule files. You can disable specific rules or change their severity levels through the config.yaml file.

​
Why Use Overrides?

Rule overrides are useful when you want to:
  • Suppress false positives — Disable rules that don’t apply to your project
  • Adjust severity — Downgrade or upgrade rule severity for your context
  • Maintain upgradability — Keep built-in rules intact while customizing behavior
  • Team standards — Enforce team-specific severity levels across projects

​
Override Configuration

Overrides are configured in ~/.ward/config.yaml under the rules section:
config.yaml
rules:
  disable: []
  override: {}

​
Disabling Rules

There are two ways to disable rules:

​
Method 1: Disable List

Add rule IDs to the disable array:
config.yaml
rules:
  disable:
    - DEBUG-001
    - DEBUG-002
    - AUTH-001
Disabled rules are completely excluded from scans. They won’t appear in reports or count toward severity totals.

​
Method 2: Override with enabled: false

Disable individual rules in the override map:
config.yaml
rules:
  override:
    DEBUG-001:
      enabled: false
    AUTH-001:
      enabled: false
Both methods are functionally equivalent. Use disable for simple lists, or override when you also want to change severity.

​
Changing Severity

Modify a rule’s severity level without disabling it:
config.yaml
rules:
  override:
    DEBUG-002:
      severity: low
    CRYPTO-003:
      severity: info
    AUTH-001:
      severity: high
Severity changes affect filtering via the severity config option and --fail-on CLI flag.

​
Valid Severity Levels

  • critical — Most severe, usually exploitable vulnerabilities
  • high — Serious security issues that should be fixed soon
  • medium — Moderate security concerns
  • low — Minor issues or best practices
  • info — Informational findings, not security-critical

​
Combined Example

Here’s a complete example showing both disabling and severity changes:
config.yaml
rules:
  # Disable these rules entirely
  disable:
    - DEBUG-001  # dump() calls — we use this in development
    - DEBUG-002  # dd() calls — we use this in development
  
  # Customize severity for specific rules
  override:
    CRYPTO-003:  # md5/sha1 usage
      severity: low  # downgrade from medium (we use md5 for non-security checksums)
    
    AUTH-001:  # missing middleware
      severity: critical  # upgrade from high (our security policy)
    
    SECRETS-001:  # hardcoded passwords
      enabled: false  # disable (alternative to 'disable' list)

​
Override Processing

Ward applies overrides during rule loading (internal/config/rules.go:115-140):
  1. Load all rules — From ~/.ward/rules/ and custom_dirs
  2. Apply disable list — Remove rules in rules.disable
  3. Apply override map — For each rule in rules.override:
    • If severity is set, replace the rule’s severity
    • If enabled: false, exclude the rule (same as disable)
  4. Return final rule set — Only enabled rules with adjusted severities

​
Common Use Cases

​
Disable Debug Rules in Development

config.yaml
rules:
  disable:
    - DEBUG-001  # dump()
    - DEBUG-002  # dd()
    - DEBUG-003  # var_dump()
    - DEBUG-004  # print_r()

​
Downgrade Crypto Warnings

If you use MD5/SHA1 for non-security purposes (e.g., cache keys, ETags):
config.yaml
rules:
  override:
    CRYPTO-001:  # md5()
      severity: info
    CRYPTO-002:  # sha1()
      severity: info

​
Upgrade Auth Issues to Critical

Enforce strict authentication standards:
config.yaml
rules:
  override:
    AUTH-001:  # missing auth middleware
      severity: critical
    AUTH-002:  # missing rate limiting
      severity: critical
    AUTH-003:  # loginUsingId() without validation
      severity: critical

​
Disable False Positives

If a rule produces false positives for your codebase:
config.yaml
rules:
  disable:
    - INJECTION-003  # eval() — we never use eval()
    - XSS-002  # {!! !!} — we sanitize before using

​
Per-Project Overrides

Per-project .ward.yaml config is planned but not yet implemented. Currently, all overrides are global via ~/.ward/config.yaml.
Until per-project config is available, you can:
  1. Use custom_dirs — Load project-specific rules from ./ward-rules/
  2. CI environment — Use different ~/.ward/config.yaml files per CI job
  3. Baseline suppression — Use --baseline to suppress known findings per project

​
Severity Filtering

Override severity affects global severity filtering:
config.yaml
severity: medium  # only report Medium, High, Critical

rules:
  override:
    DEBUG-002:
      severity: low  # this rule is now BELOW the threshold, won't be reported
If you downgrade a rule’s severity below the global severity threshold, findings from that rule won’t appear in reports.

​
CI Fail Thresholds

Override severity also affects --fail-on behavior: 
ward scan . --fail-on high
If you upgrade a rule to critical or high, it will trigger failures. If you downgrade to low or info, it won’t.

​
Viewing Active Rules

To see which rules are active after overrides, check the scan report’s rule list or run ward scan with verbose logging.
The JSON report includes all findings with their effective severity: 
{
  "findings": [
    {
      "id": "DEBUG-002",
      "severity": "Low",  // overridden from Medium
      ...
    }
  ]
}

​
Override vs. Custom Rules

Use CaseOverridesCustom Rules
Disable built-in rule✅ disable: [RULE-ID]❌ Not applicable
Change severity✅ override.RULE-ID.severity❌ Must edit rule file
Add new rule❌ Not applicable✅ Create .yaml in ~/.ward/rules/
Modify pattern❌ Not supported✅ Edit rule file
Team-wide changes✅ Share config.yaml✅ Share rule directory
Rule of thumb:
  • Use overrides for tweaking existing rules without editing files
  • Use custom rules for adding new checks or heavily modifying patterns

​
Example: Staging vs. Production

You can use different override configurations for different environments: Staging (lenient):
~/.ward/config.staging.yaml
severity: low
rules:
  disable:
    - DEBUG-001
    - DEBUG-002
  override:
    CRYPTO-001:
      severity: info
Production (strict):
~/.ward/config.production.yaml
severity: medium
rules:
  disable: []  # no disabled rules
  override:
    AUTH-001:
      severity: critical
    SECRETS-001:
      severity: critical
Then swap config files based on environment: 
cp ~/.ward/config.production.yaml ~/.ward/config.yaml
ward scan .

Build docs developers (and LLMs) love

Get started for freeTalk to us