DevSecOps · 6 min read · Log Academy training team

How to build security into a CI/CD pipeline

CI/CD security means building automated checks into every stage of your delivery pipeline. A practical rollout order: secret scanning first, then dependency analysis (SCA), then SAST, followed by container image minimisation and signing, and finally admission policies in Kubernetes. The key rule: every check must produce a result that is clear, explainable and fixable.

What is CI/CD security, and why is the pipeline itself a target?

The job has two halves: checking the code the pipeline ships, and protecting the pipeline itself. The second half is often forgotten. Yet the build server holds cloud keys, registry passwords and the right to deploy to production. To an attacker, that is a more attractive target than the application.

The OWASP Top 10 CI/CD Security Risks list paints the picture well: insufficient flow control, dependency chain abuse, poisoned pipeline execution, poor credential hygiene and missing artefact integrity validation. In other words, pipeline security is not about installing one scanner — it is about defending the whole software supply chain. That makes it a core part of modern cybersecurity work.

In what order should you add security checks?

The most common mistake is switching on every tool in a single day. Hundreds of old findings surface at once, the build turns red and the team disables the check. Durable pipeline security starts with cheap, precise checks and moves forward in stages.

1. Secret scanning: finds API keys, tokens and passwords committed to the repository. It is the cheapest and most valuable step — run it both before commit (pre-commit hook) and in the pipeline.
2. Dependency analysis (SCA): flags known vulnerabilities (CVEs) and licence risks in the libraries you use. The fix is often just a version bump.
3. SAST: looks for dangerous patterns such as SQL injection or unsafe deserialisation in your own code. It is noisier, so start with a small rule set and grow it gradually.
4. Container image: minimal base image, non-root user, image scanning, SBOM and signature.
5. Kubernetes admission policies: only workloads that follow the rules and carry a valid signature are allowed into the cluster.

What matters is the order, not the tool. The same logic works equally well in GitLab CI, GitHub Actions or Jenkins.

How do you shrink and sign a container image?

The fewer packages an image contains, the fewer vulnerabilities a scanner will find and the fewer tools an attacker can use. Use a multi-stage build to keep compilers out of the final image, choose a minimal or distroless base and run the container as a non-root user. Pin the base image by digest rather than by tag, so different content cannot arrive under the same name.

Signing comes next. With cosign from the Sigstore project, the image is signed after the build and an SBOM and build provenance are attached to it. Production can then answer the question “did our pipeline really build this image?” with evidence.

Which risks do Kubernetes admission policies close?

An admission controller is a mechanism that inspects a request to the Kubernetes API server before the object is persisted. A validating check rejects requests that break the rules, while a mutating one can modify them. This is exactly where the image signed in the pipeline gets verified.

• Allow only signed images from your own registry.
• Forbid privileged mode, hostPath and host networking.
• Require CPU and memory limits on every container.
• Reject the “latest” tag — accept only a specific version or digest.

Don't switch policies straight to enforce mode. Run them in audit mode first, see which existing workloads violate them, fix those, and only then move to blocking.

How do you triage findings so the team doesn't turn checks off?

Securing a pipeline usually fails for organisational rather than technical reasons. A check that blocks every build, explains nothing and is full of false positives gets disabled fast. This is the biggest point of friction between security teams and developers. A triage process prevents it.

• Create a baseline: move existing findings to a separate backlog and block only on newly introduced critical and high findings.
• Make every finding clear: which file, which line, why it is risky and how to fix it.
• Let developers mark a false positive in code with a reason — and review those marks regularly.
• Give exceptions an owner and an expiry date; an expired exception blocks the build again.
• Leaked secrets follow a separate rule: deleting them from code is not enough, rotate the key immediately.

How do SLSA and NIST SSDF frame this work?

Tools change; frameworks stay. SLSA (Supply-chain Levels for Software Artifacts) describes how trustworthy a build process is in levels. In version 1.0, Build L1 requires that provenance exists, L2 that it is signed by a hosted build platform, and L3 that the build runs on a hardened, isolated platform.

NIST SP 800-218, the Secure Software Development Framework (SSDF), takes a broader view and groups practices into four areas: prepare the organisation, protect the software, produce well-secured software and respond to vulnerabilities. Mapping each pipeline check to one of these groups gives you a ready answer when an auditor asks “why is this step here?”.

Frequently asked questions