← ClaudeAtlas

sota-devsecopslisted

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, and deployment strategy. 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. 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).
martinholovsky/SOTA-skills · ★ 18 · AI & Automation · score 78
Install: claude install-skill martinholovsky/SOTA-skills
# 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