Add CI security scan pipeline (code, dependency, secret)#13
Merged
Conversation
Runs on every PR and push to develop/main: - code-scan: CodeQL Python analysis, results in the repo's code scanning alerts. - dependency-scan: actions/dependency-review-action (fails PRs that introduce high-severity vulnerable or license-incompatible deps) plus pip-audit against the actual installed dependency tree, PR-only since dependency-review compares base vs head. Upgrades pip/setuptools before auditing -- verified locally that a stock venv's bundled setuptools 59.6.0 carries three CVEs of its own, which would fail every run on bootstrap tooling rather than this project's real dependencies. - secret-scan: Gitleaks, full history fetch, push and PR. Also enabled at the repo level (not a file change, so not in this diff): secret scanning, secret scanning push protection, and Dependabot security updates -- all were "disabled", including secret scanning, which is normally free and on by default for public repos. None of these are required status checks yet -- the "Protect develop" ruleset has no required_status_checks rule, so right now these run and report but do not block a merge. That needs a separate ruleset update.
|
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. |
Both new jobs failed immediately on PR #13's first run: - gitleaks/gitleaks-action requires a paid GITLEAKS_LICENSE for org-owned repos (bawbel is an org; the free tier is personal-account only). Switched to calling the gitleaks CLI directly -- the tool itself is fully open source (Apache-2.0), only the GitHub Action wrapper has the org-licensing gate. Version pinned (8.30.1) for reproducible runs rather than resolved at run time. - dependency-review-action needs the repo's Dependency graph feature enabled; it wasn't. Enabled via the vulnerability-alerts API (repo setting, not a file change). Running gitleaks against this repo's actual history (locally, before wiring it back in) found 6 "leaks" -- all in tests/test_m2_policy.py, which deliberately contains fake JWT/GitLab-PAT strings as fixtures for policy/manifest.py's own secret-scan detector, not real credentials. Added .gitleaks.toml with a path-scoped allowlist for that one file rather than disabling the check; verified locally it suppresses exactly those six and nothing else ("no leaks found").
Splits ci.yml into three separate workflow files (code-scan.yml, dependency-scan.yml, secret-scan.yml) -- GitHub's native workflow badges are per-workflow-file, not per-job, so a combined workflow can't produce three distinct badges. Same jobs, same triggers, just separated so each has its own README badge. README additions: - Badges for the three new security scans, pointing at develop (where they actually run continuously; main doesn't have them yet). - The gate.yaml sample from DESIGN.md 3.1, since the Quickstart section referenced --config gate.yaml several times without ever showing what one looks like. Verified against the real config loader (bawbel_gate.mux.config.load_config), not just pasted in -- it parses cleanly. CHANGELOG.md: Keep a Changelog format, single [Unreleased] section. No version has been tagged yet, so there's nothing to backdate against; the M0-M7 build stays in README's milestone table rather than being itemized here. Covers everything since that baseline: the multiplexer fix, hub fixes, console dashboard, governance docs, PyPI packaging, and this CI security pipeline.
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
Every merge previously had zero automated security scanning -- no CI ran on PRs
at all (the only workflows were release-triggered publish and a push-to-main/
schedule-only Scorecard run). This adds a pipeline that runs on every PR and
push to
develop/main:Scanning alerts tab.
actions/dependency-review-action(fails PRs introducinghigh-severity vulnerable or license-incompatible dependencies) plus
pip-auditagainst the actual installed dependency tree. PR-only, sincedependency-review compares base vs head. Upgrades
pip/setuptoolsfirst --verified locally that a stock venv's bundled
setuptools 59.6.0carries threeCVEs of its own; without the upgrade this would fail every run on bootstrap
tooling, not this project's real dependencies.
Also enabled at the repo level (not part of this diff, a settings change):
secret scanning, secret scanning push protection, and Dependabot security
updates. All three were
disabled, including secret scanning, which isnormally free and on by default for public repos.
Not done here: making these required checks
The "Protect develop" ruleset has no
required_status_checksrule, so rightnow these scans run and report but do not block a merge on failure. Adding that
needs a separate ruleset update once these jobs have run at least once (GitHub
requires a status check to have reported before it can be selected as
required).
Test plan
pytest-- 327 passedpre-commit run --all-files-- cleanpip-auditrun locally in a clean venv against the actual.[dev,ops]install -- clean after the pip/setuptools upgrade step