← 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. 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 · ★ 8 · AI & Automation · score 75
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