Branch protection on `main` requires exactly two status contexts:
CI (SIAX Cloud) / security (push)
CI (SIAX Cloud) / quality (push)
The `security` half could not fail. All three Trivy invocations in this
repo ran with `--exit-code 0`, so the scanner reported findings to stdout
and then exited 0 regardless.
Measured on main @4514d97, 2026-09-08, same scanner (Trivy 0.73.0), same
target, only the flag differing:
A --exit-code 0, clean tree -> exit 0
B --exit-code 0, planted AWS secret access key -> exit 0 (DETECTED
as CRITICAL in the report, gate still green)
C --exit-code 1, same planted secret -> exit 1
D --exit-code 1, probe removed -> exit 0
B is the defect: the required context reported success while the scanner
had a CRITICAL secret in hand. D is why this is safe to land now -- the
tree is clean today, so flipping the flag does not open the gate red.
(PR #19 measured 19 HIGH findings on 2026-08-11; those dependencies have
since been updated on main, 142 commits later.)
The other required context, `quality`, was verified real and left alone:
a planted type error fails `pnpm run typecheck` (exit 2) and a planted
failing assertion fails `pnpm run test` (exit 1, 945 passed baseline).
nightly.yml carried the same flag. A nightly scan exists to catch CVEs
published against code that did not change; with `--exit-code 0` it could
never raise that alarm.
Not fixed here, needs an owner decision: services/scrapers/requirements.txt
uses `>=` ranges only. Trivy's pip scanner cannot resolve unpinned
specifiers, so it omits the file from the scan entirely -- it never appears
as a target. Pinning those same floors with `==` surfaces 3 HIGH findings
(aiohttp CVE-2025-69223, aiohttp CVE-2026-69244, lxml CVE-2026-41066).
Deliberately NOT suppressed with `--skip-dirs`, which would turn a
measurable blind spot into declared policy.
Job names are unchanged, so both required context strings are preserved.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
39 lines
1.6 KiB
YAML
39 lines
1.6 KiB
YAML
name: Security Scan (SIAX Cloud)
|
|
|
|
# Security scanning on every push/PR + weekly re-run.
|
|
#
|
|
# This job runs the same Trivy invocation as ci.yml's `security` job and
|
|
# previously carried the same defect: `--exit-code 0` meant it could report
|
|
# success while holding a CRITICAL finding (measured 2026-09-08 with a
|
|
# planted AWS secret key -- detected, still exit 0). Its context
|
|
# "Security Scan (SIAX Cloud) / security" is NOT in branch protection's
|
|
# required list, so this one never gated a merge either way; it is fixed
|
|
# here so a green tick on this workflow means what a reader assumes it
|
|
# means. See ci.yml's `security` job for the measurement and for the
|
|
# services/scrapers unpinned-requirements coverage gap.
|
|
#
|
|
# NOTE: findings on services/scrapers/* (FlareSolverr/Tor/curl_cffi) are
|
|
# expected and out of scope for CI gating -- kept per the account owner's
|
|
# dated, attributed decision (Simon Axelsson, 2026-08-11, interactive
|
|
# prompt; no rationale beyond "keep it" given or invented). See SECURITY.md
|
|
# and docs/compliance/GOLDEN-STANDARD-REPORT.md control C6 for full context.
|
|
on:
|
|
push:
|
|
branches: ["**"]
|
|
pull_request:
|
|
workflow_dispatch:
|
|
schedule:
|
|
- cron: "0 5 * * 1" # weekly Monday re-scan
|
|
|
|
jobs:
|
|
security:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
- name: Install Trivy
|
|
run: |
|
|
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin
|
|
- name: Trivy fs scan (vuln + secrets -- fails on HIGH/CRITICAL)
|
|
run: |
|
|
trivy fs --scanners vuln,secret --severity HIGH,CRITICAL --exit-code 1 .
|