JonKazama-Hellion/security-workflows
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
Jon Kazama
2026-05-09 11:53:36 +02:00
parent c9a8000a84
commit c0d2b12b4f
2 changed files with 30 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitea/workflows/security-scan.yml
+20 -3
View File
@@ -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
# findings at or above the chosen severity exist.
run: semgrep scan --config=${{ inputs.semgrep-config }} --error --severity=ERROR --severity=WARNING
# without requiring an account. --error makes the job fail when ERROR
# findings exist. WARNING-level rules still run for visibility but do
# 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
+10 -3
View File
@@ -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