/sota-devsecops

name: sota-devsecops
description: >-
  State-of-the-art DevSecOps and software supply chain security (2026). Applies when building or auditing CI/CD pipelines, GitHub Actions workflows, supply chain controls, SBOM generation, SAST/secret-scanning gates, dependency management, container builds, container/artifact registries, IaC (Terraform), GitOps, deployment strategy, and a pre-commit hook that passes locally but fails in CI. Trigger keywords: CI/CD, pipeline, GitHub Actions, supply chain, SBOM, SAST, dependency, container build, container registry, registry security, Zot, Harbor, ECR, GAR, ACR, GHCR, immutable tags, pull-through cache, IaC, Terraform, deployment, provenance, SLSA, cosign, dependabot, renovate, unused dependency, unreached dependency, dead dependency, dependency removal, unmaintained upstream, pre-commit, local vs CI. Use for BOTH setting up new pipelines and auditing existing ones. Not for application code vulnerabilities (use sota-code-security) or in-cluster runtime hardening (use sota-kubernetes).

SOTA DevSecOps & Supply Chain Security

Purpose

This skill encodes the 2026 state of the art for securing the path from source code to running workload: pipeline hardening, dependency and artifact supply chain, build integrity, analysis gates, IaC/deployment security, and runtime policy enforcement. It is defensive: every rule exists to prevent a real, named class of compromise (token theft, workflow injection, dependency confusion, tag mutation, state leakage, bypassable gates).

Two operating modes. Pick one explicitly at the start of the task.

BUILD mode

Use when creating or extending pipelines, Dockerfiles, Terraform, GitOps configs, or dependency tooling.

1. Identify which stages of the source-to-production path the task touches (source → CI → build → artifact → deploy → runtime) and read the matching rules files from the index below BEFORE writing config. 2. Default to the most restrictive option that works: read-only tokens, OIDC over stored keys, SHA pins, digest pins, frozen lockfile installs, non-root distroless runtime. Loosen only with a written reason in a comment. 3. Every gate you add must be a **required** check that fails closed. A scanner whose job is `continue-on-error: true` is documentation, not a control. 4. Ship the verification path with the signing path: if you generate provenance/signatures/ SBOMs, also wire the consumer (admission policy, `gh attestation verify`, cosign verify in CD). Unverified attestations are dead weight. 5. State assumptions you could not verify (org settings, branch protection, registry config) at the end of your work so the operator can confirm them.

AUDIT mode

Use when reviewing existing pipelines, workflows, Dockerfiles, IaC, or dependency posture.

Process: enumerate workflows/build files/IaC; for each, walk the relevant Audit checklist at the end of every rules file; report findings in the format below; do not report style nits as security findings.

Severity conventions

| Severity | Meaning | Examples | |---|---|---| | **Critical** | Remote compromise of pipeline, secrets, or artifacts is achievable now by an external party | `pull_request_target` checking out PR head with secrets; script injection from PR title into `run:`; long-lived cloud admin keys in repo secrets used by fork-triggered workflow; unauthenticated registry push | | **High** | Compromise achievable by a contributor, or a single upstream event away | Actions pinned to mutable tags; no branch protection on default branch; CI token with `write-all`; no lockfile / unfrozen installs; Terraform applies from un-reviewed plans with admin creds | | **Medium** | Weakens defense in depth or detection | Missing SBOM/provenance; scanners non-blocking; no drift detection; mutable image tags in deploy manifests; no secret-scanning push protection | | **Low** | Hygiene, hardening headroom | Missing `.dockerignore`; unpinned dev-only tooling; verbose CI logs; missing CODEOWNERS on workflows |

Severity is judged by *reachability*: who can trigger the path (anonymous > fork PR author > org member > admin) and what it yields (secrets/artifact write > code exec in CI > info leak).

Finding format

[SEVERITY] <short title>
File: <path>:<line>
Issue: <what is wrong, one or two sentences>
Attack path: <who exploits it and how — concrete, not theoretical>
Fix: <exact config change, with snippet when short>
Rule: <rules file # and section>

End every audit with: counts per severity, the top 3 fixes by risk reduction per effort, and an explicit list of what was OUT of scope (org settings, registry config, runner infra you could not see).

Rules index

| File | Read this when... | |---|---| | [rules/01-pipeline-security.md](rules/01-pipeline-security.md) | Writing or auditing CI workflows: GITHUB_TOKEN permissions, OIDC to cloud, SHA-pinning actions, `pull_request_target` / fork PR handling, script injection, self-hosted runners, branch/environment protection, signed commits, workflow-file ownership, proving the pipeline has ever executed (run it locally against a fresh clone; skipped and platform-refused runs both look like "CI exists"); **AI coding agents as CI actors (§1.5a)** — and why §1.5's `env:` fix is a *shell* defence that does not apply to a sink which interprets the value | | [rules/02-provenance-signing.md](rules/02-provenance-signing.md) | Artifact integrity: SLSA levels, build provenance, in-toto attestations, Sigstore/cosign keyless signing, GitHub artifact attestations, npm/PyPI trusted publishing, release and tag integrity, verification at deploy time | | [rules/03-dependencies.md](rules/03-dependencies.md) | Anything touching package manifests or lockfiles: frozen installs, dependency review gates, dependency confusion and registry scoping, typosquatting and malicious-package indicators, SBOM (CycloneDX/SPDX), vuln scanning with osv-scanner/grype, VEX and triage discipline, Renovate/Dependa