Add semgrep-exclude-rules input, drop WARNING-severity-as-failing

Two changes for noise reduction and per-repo control:

1. New optional input `semgrep-exclude-rules` (comma-separated rule
   IDs). Lets a consumer skip rules that are context-specific false
   positives (e.g. SQLi rules in a local-only plugin with SqlParameter-
   bound values).

2. Semgrep now only fails the build on ERROR-severity findings.
   WARNING-level rules still run for visibility but do not block.
   Keeps the noise floor low while still surfacing concerns.

Both are opt-in for consumers, default behaviour stays scan-everything.

.gitea/workflows/security-scan.yml

@@ -17,6 +17,11 @@ on:
         required: false
         type: string
         default: 'auto'
+      semgrep-exclude-rules:
+        description: 'Semgrep rule IDs to exclude, comma-separated (e.g. csharp.lang.security.sqli.csharp-sqli)'
+        required: false
+        type: string
+        default: ''
 
 jobs:
   semgrep:
@@ -36,9 +41,21 @@ jobs:
 
       - name: Run Semgrep scan
         # --config=auto pulls language-appropriate rule packs from semgrep.dev
-        # without requiring an account. --error makes the job fail when
+        # without requiring an account. --error makes the job fail when ERROR
-        # findings at or above the chosen severity exist.
+        # findings exist. WARNING-level rules still run for visibility but do
-        run: semgrep scan --config=${{ inputs.semgrep-config }} --error --severity=ERROR --severity=WARNING
+        # not fail the build (they would dominate the noise).
+        # Per-repo rule exclusion via the semgrep-exclude-rules input.
+        env:
+          EXCLUDE_RULES: ${{ inputs.semgrep-exclude-rules }}
+        run: |
+          args="--config=${{ inputs.semgrep-config }} --error --severity=ERROR"
+          if [ -n "$EXCLUDE_RULES" ]; then
+            for rule in $(echo "$EXCLUDE_RULES" | tr ',' ' '); do
+              args="$args --exclude-rule=$rule"
+            done
+          fi
+          echo "Running: semgrep scan $args"
+          semgrep scan $args
 
   trivy:
     name: Trivy Vulnerability Scan

README.md

@@ -34,18 +34,25 @@ Both jobs run in parallel. Either failing fails the calling workflow.
 
 ## Tuning per consumer
 
-The reusable workflow accepts two optional inputs:
+The reusable workflow accepts three optional inputs:
 
 ```yaml
 jobs:
   scan:
     uses: JonKazama-Hellion/security-workflows/.gitea/workflows/security-scan.yml@main
     with:
-      severity: 'CRITICAL'         # default 'CRITICAL,HIGH'
+      severity: 'CRITICAL'                # default 'CRITICAL,HIGH'
       semgrep-config: 'p/owasp-top-ten'   # default 'auto'
+      semgrep-exclude-rules: 'csharp.lang.security.sqli.csharp-sqli,javascript.express.security.audit.express-cookie'
 ```
 
-`severity` is the Trivy threshold, `semgrep-config` swaps the rule pack (e.g. `p/owasp-top-ten`, `p/javascript`, `p/csharp`).
+| Input | Default | What |
+|---|---|---|
+| `severity` | `CRITICAL,HIGH` | Trivy severity threshold for failing the build |
+| `semgrep-config` | `auto` | Semgrep rule pack (e.g. `p/owasp-top-ten`, `p/javascript`, `p/csharp`) |
+| `semgrep-exclude-rules` | `` (empty) | Comma-separated Semgrep rule IDs to skip in this repo. Useful for context-specific false positives, e.g. SQL-injection rules in a local-only plugin where the SQL strings come from code constants and the values are bound via SqlParameter. |
+
+Note that Semgrep is configured to fail the build only on `ERROR`-severity findings. `WARNING`-level rules still run for visibility but do not block, which keeps the noise floor low.
 
 ## Pinning