ci: add CodeQL and ZAP baseline scanning - #525
Merged
Merged
Conversation
Soft-launch posture: both scanners report findings but do not fail the build. Trivy is already wired into docker-build.yml and is left untouched. - codeql.yml: Swift + JS/TS matrix on push/PR/weekly. Swift runs in the swift:6.3-jammy container (matches swift-tests.yml). JS/TS run excludes Public/jupyterlite/** (generated output). SARIF uploads to the Security tab via the analyze action. - zap-baseline.yml: weekly + workflow_dispatch only (no PR trigger). Brings up docker compose with AUTH_MODE=local + ENABLE_NON_SSO_AUTH_MODES=true, waits on /health, runs zaproxy/action-baseline@v0.12.0 with -a (alpha passive rules), fail_action: false. Opens issues on findings. Server logs uploaded as an artifact for debugging. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
CodeQL Swift analysis is macOS-only as of CodeQL 2.25 — the unified ubuntu-latest matrix in the previous commit fails fast with "Swift analysis is only supported on macOS runner images." Split into two files so the JS/TS half can keep running cheaply on Linux while Swift gets the macOS runner it requires. - codeql-js.yml: ubuntu-latest, every push/PR/weekly. Same posture as before. - codeql-swift.yml: macos-latest, paths-filtered to Sources/**, Tests/**, Package.swift, Package.resolved, and the workflow itself. Weekly cron still runs full scan. Uses swift-actions/setup-swift@v2 with swift-version 6.3 to match swift-tools-version in Package.swift. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
swift-actions/setup-swift@v2 doesn't have Swift 6.3 in its version catalog — first run on the macOS CodeQL job failed with "Version '6.3' is not available". SwiftyLab/setup-swift is the actively maintained fork; v1.14.0 (Apr 2026) supports the current Swift line. Package.swift pins swift-tools-version:6.3 so we can't fall back to an older toolchain. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Swift build on macOS fails because a transitive SPM dependency (swift-configuration) calls Data.bytes, an API that exists in swift-foundation but not in Apple's Darwin Foundation. Rather than yak-shave the toolchain, switch to CodeQL's buildless Swift extractor (build-mode: none). Trade-off documented in the workflow comment: buildless is experimental and may produce less complete results than tracing extraction, but it works without a build and runs in a few minutes instead of 17+. Also bump github/codeql-action from v3 to v4 in both workflows to clear the Node 20 deprecation warning. v4 ships the same CodeQL bundle as v3; the difference is Node 24 runtime. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tried three configurations on the original PR thread:
1. ubuntu-latest matrix entry → CodeQL refuses ("Swift analysis
is only supported on macOS")
2. macos-latest + swift build → fails compiling swift-configuration:
Data.bytes only exists in
swift-foundation, not Apple's
Darwin Foundation
3. macos-latest + build-mode: none → "Swift does not support the none
build mode"
The Darwin-vs-swift-foundation gap is structural and will keep biting
us as transitive deps adopt swift-foundation-only APIs, even if we
patch around the current swift-configuration issue. Ship without
Swift SAST for now; revisit if/when CodeQL ships a Linux Swift
extractor or Apple closes the Foundation gap.
JS/TS CodeQL on Linux continues to run on every PR; ZAP baseline
runs weekly. Trivy in docker-build.yml is unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
JimWallace
added a commit
that referenced
this pull request
May 17, 2026
The runner service had a bare `environment:` key with no value, which older docker compose versions tolerated as a no-op but newer versions reject with: validating docker-compose.yml: services.runner.environment must be a mapping This surfaced when the new ZAP baseline workflow (added in #525) tried to run `docker compose up` in CI. The runner doesn't actually need any env vars passed via compose — RUNNER_WORKER_ID and RUNNER_MAX_JOBS are referenced in the `command:` block and substituted from the shell at parse time. Remove the empty key entirely. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds two new CI security workflows. Trivy is already wired into docker-build.yml so it is intentionally not duplicated.
What was already present in
.github/workflows/docker-build.yml— builds the image, runsaquasecurity/trivy-action@v0.35.0against the locally-built image on every PR + push to main (CRITICAL only,exit-code: 1,ignore-unfixed: true, table output, no SARIF upload).swift-tests.yml,test-coverage.yml,jupyterlite.yml,release.yml— unrelated to security scanning.What Dependabot is monitoring (no changes here)
swift,docker, andgithub-actionsecosystems, weekly Monday — see .github/dependabot.yml.Soft-launch posture
main, PRs targetingmain, and weekly (Mon 06:00 UTC) onubuntu-latest. SkipsPublic/jupyterlite/**(generated). SARIF lands in the Security tab. Nofail-on-severityyet. First-run baseline: zero alerts.workflow_dispatch. No PR trigger — too slow and noisy to gate every PR. Brings updocker composewithAUTH_MODE=local+ENABLE_NON_SSO_AUTH_MODES=true, polls/health(60s timeout), runszaproxy/action-baseline@v0.12.0with-a,fail_action: false. Opens an issue on findings. Server logs uploaded as an artifact.docker-build.ymlunchanged.Known gap: no CodeQL Swift
Three configurations were attempted during this PR; all failed:
ubuntu-latestmatrix entrymacos-latest+swift buildswift-configuration:Data.bytesonly exists inswift-foundation, not Apple's Darwin Foundationmacos-latest+build-mode: noneThe Darwin-vs-
swift-foundationAPI gap is structural and will keep biting us as transitive deps adopt swift-foundation-only APIs, even if we patch around the currentswift-configurationissue. Shipping without Swift SAST for now. Revisit if/when CodeQL ships a Linux Swift extractor or Apple closes the Foundation gap.Actions are pinned to
@v4for CodeQL action (Node 24)github/codeql-action@v4clears thenode20deprecation warning. v4 ships the same CodeQL bundle as v3 — the only difference is Node 24 runtime.Verification done locally
yamllib —actionlint/PyYAML not installed locally).permissions:blocks.pull_request_target.analyze@v4step has noif:guard.Follow-up checklist
.zap/rules.tsvignores for CI-only false positives (Cookie Without Secure Flag will fire because CI runs HTTP).container-scan.ymlthat complementsdocker-build.yml's Trivy step with HIGH-severity coverage, SARIF upload, and a weekly cadence.swift-foundationparity.Test plan
workflow_dispatchonce to verify the docker-compose-up / health-wait / scan / teardown loop end-to-end.🤖 Generated with Claude Code