CI/CD & Supply Chain Security Articles

Standing CI permissions are a liability. JIT mints production permissions only at deploy time, with explicit approval and short lifetime.

Bots that update dependencies are great until one auto-merges a malicious release. The defaults are safe-ish; the configuration that makes them production-safe is more deliberate.

Four identity types, four very different scope/lifetime/permission models. Pick wrong and you ship the wrong-shaped credential to every CI run for years.

Keyless signing eliminates long-lived signing keys by issuing short-lived certificates from Fulcio and recording signatures in the Rekor transparency log. Cosign wires it into CI/CD.

Container-based CI runners share a host kernel. Firecracker and Kata give each job its own kernel and a fresh VM — large blast-radius reduction, modest cost.

OIDC federation between CI and cloud removes long-lived secrets. The trust policies that grant the access are the new attack surface, and most are too loose.

Hand-clicking branch protection rules across 200 repos guarantees drift. Terraform + the github provider + a shared module makes it auditable, reviewable, and reversible.

Most build pipelines run with unrestricted outbound internet. A single compromised dependency exfiltrates secrets, tokens, and source code in seconds.

Attackers no longer need to breach you directly when they can compromise a vendor, open-source library, or managed service provider that you trust. A single poisoned dependency can cascade into thousands of downstream organisations. This article covers the controls that detect and contain supply chain compromise.

Static credentials in CI/CD pipelines are the leading cause of secret sprawl. Teams store long-lived API keys, database passwords, and cloud provider.

SBOM generation is easy, run Syft, get a list of every package in your container image.

Terraform state files contain every secret, IP address, and configuration detail of your infrastructure in plaintext JSON.

Container registries store the most sensitive artifacts in your deployment pipeline.

CI/CD pipeline definitions live alongside application code in Git.

Helm values files control security-critical Kubernetes fields like security contexts, image references, and resource limits. Without schema validation, a single misconfigured value can deploy a privileged container or pull an unscanned image.

CI/CD runners are the most privileged, least monitored components in most infrastructure.

Helm is the dominant package manager for Kubernetes, but most teams install charts without verifying provenance, pass unvalidated values that end up...

Helm charts pulled from public repositories are unsigned, unverified, and executed with whatever permissions their templates request. This article covers OCI-based chart storage, cosign signing and verification, chart mirroring for airgapped environments, and Kyverno policies to enforce signed charts.

Build artifacts pass through multiple stages between source code and production deployment.

GitHub Actions is the most widely used CI/CD platform, but its security model is scattered across dozens of documentation pages.

Dependency confusion and typosquatting attacks exploit the gap between "I declared a dependency" and "I verified the dependency I got." Version pinning...

Two builds from the same source code should produce the same container image. In practice, they almost never do.

GitOps centralizes deployment authority in Git repositories. Tools like ArgoCD and Flux watch Git repositories and reconcile cluster state to match...

Without provenance, you cannot prove where a container image came from, what source code it was built from, or whether the build process was tampered...