Claude CodeandClaude Sonnet 5
4c47e151f3
CI (SIAX Cloud) / integration (push) Skipped
masterplan-lock / check (push) Successful in 6s
masterplan-lock / check (pull_request) Successful in 6s
Security Scan (SIAX Cloud) / security (pull_request) Successful in 24s
Security Scan (SIAX Cloud) / security (push) Successful in 49s
CI (SIAX Cloud) / security (push) Successful in 53s
CI (SIAX Cloud) / quality (push) Successful in 1m20s
CI (SIAX Cloud) / security (pull_request) Successful in 20s
CI (SIAX Cloud) / quality (pull_request) Successful in 53s
CI (SIAX Cloud) / integration (pull_request) Successful in 1m0s
Fleet-wide CI-speed pass: none of 0pt's push/pull_request-triggered workflow jobs capped their own runtime, so a hang (network stall, runaway process, stuck polling loop) burns a runner slot until Gitea's own default kicks in. Added job-level timeout-minutes sized to what each job actually does: cd.yml deploy 20 (bounded ~10min signed-artifact poll + setup) ci.yml quality 30 (typecheck/test/build) ci.yml integration 45 (multi-service: live OpenSearch + ClickHouse) ci.yml security 15 (single trivy fs scan) security.yml security 15 (single trivy fs scan) masterplan-lock.yml check 10 (single dependency-free shell check) release.yml release 45 (docker build/push + full G17 SBOM/scan/attest/verify chain) Deliberately NOT included in this PR: a concurrency: block for ci.yml/security.yml/masterplan-lock.yml's push+pull_request double- trigger. ci.yml's own `integration` job comment already documents, measured live (runs 28904/28906), that "Gitea currently ignores workflow concurrency" on this fleet, and the repo's real fix for the resulting double-run-on-shared-service-containers problem is the self-identifying-container pattern already in that job, not a concurrency group. Adding an inert concurrency: block here would give false confidence that the duplicate-run problem is handled when it measurably is not. Left for a follow-up decision once that fleet-wide finding is resolved. Part of a fleet-wide CI-speed pass (timeout-minutes audit). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
40 lines
1.6 KiB
YAML
40 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
|
|
timeout-minutes: 15
|
|
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 .
|