CI/CD security
The security-review record for the CICDv2 execution surface: the inner-job Docker-in-Docker container, per-tenant nftables isolation, dispatch authorization, the job-token lifecycle, the outer-image allowlist, and the dependency scanners that run inside pipelines. The rest of the CI/CD set describes how to author and run pipelines; these three pages state what has been verified about the platform that executes them, at which evidence tier, and what is still unverified or uncovered.
Read them when clearing a release gate, when running the kernel-level probes that a review sandbox cannot issue, or when judging whether the supply-chain scanning in front of a pipeline is sufficient for a given repository. The CICDv2 threat model lives in the system documentation set under architecture/security/.
Pages
- Findings index — The reference record of CICDv2 security
findings, each with severity, status, component, operator action, and a severity
scale calibrated to release-gate impact rather than raw CVSS. F1 (the bundled
seccomp profile permitted
mount(2), leaving the/proc-mount block dependent on AppArmor) is fixed; F2 (live-host probes not yet executed) and F3 (feed-reactive npm-worm coverage) are open at Medium, so the gate stands clear at zero open Critical and zero open High. - Manual checklist execution — How to execute the
six manual CICDv2 security checks against the source, recording per item the code
path, the verification mode (static, unit-test, or live-probe-pending), the Go test
that pins the behaviour, and the verdict. All six items pass at the static plus
unit-test tier; items 1, 2, 3, and 6 —
nsenterhost-path visibility, the per-tenantnftruleset, the cross-tenant dataplane drop, and the/proc-mount block — still need kernel-level probes on a live host. - Shai-Hulud variant coverage — Gap analysis of the Software Composition Analysis pipeline against the Shai-Hulud family of self-propagating npm worms, enumerating five variants against a per-scanner coverage matrix. Coverage of the original postinstall-trampoline variants is reactive only — exactly what the trivy, OSV-Scanner, and dependency-check feeds carry, leaving the first 24 to 72 hours of a campaign undetected — while the CI-token exfil, dependency-confusion, and workflow-injection follow-on variants are not caught by any scanner in the registry, the SBOM store performs no advisory analysis, and the internal npm registry runs no scan at publish time. The embedded bundle-SHA blocklist scanner ships and raises a High finding on a known-bad payload digest; the npm lifecycle-script signature class and the registry publish-time tarball hook remain open recommendations.