Files
0pt/.gitea/workflows/nightly.yml
T
Simon AxelssonandClaude Opus 5 1322d26fac
Security Scan (SIAX Cloud) / security (push) Successful in 17s
CI (SIAX Cloud) / security (push) Successful in 25s
CI (SIAX Cloud) / integration (push) Failing after 31s
CI (SIAX Cloud) / quality (push) Successful in 34s
fix(ci): make the required security gate capable of failing
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>
2026-09-08 01:16:08 +02:00

49 lines
1.7 KiB
YAML

name: Nightly (SIAX Cloud)
# Nightly full-gate re-run so CI exercises the repo even without pushes:
# quality gate + advisory security scan. Fails loudly on regressions
# introduced outside push-triggered runs (e.g. dependency drift).
on:
workflow_dispatch:
schedule:
- cron: "0 4 * * *" # daily 04:00 UTC
jobs:
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: "22"
- name: Enable corepack + pin pnpm@9
run: |
corepack enable
corepack prepare pnpm@9 --activate
- name: Install (frozen lockfile)
run: pnpm install --frozen-lockfile
- name: Typecheck (blocking)
run: pnpm run typecheck
- name: Test (blocking)
run: pnpm run test
- name: Lint (advisory)
continue-on-error: true
run: pnpm run lint
- name: Build (blocking)
run: pnpm run build
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
# A nightly scan exists to catch CVEs published against code that did
# not change. With `--exit-code 0` it could never report failure, so it
# could never raise that alarm -- the one job whose entire purpose is
# detection was the one guaranteed to stay green. Fixed 2026-09-08.
- name: Trivy fs scan (vuln + secrets -- fails on HIGH/CRITICAL)
run: |
trivy fs --scanners vuln,secret --severity HIGH,CRITICAL --exit-code 1 .