Security in CI/CD Pipelines: CNPA practice questions

A CI/CD pipeline is a privileged system: it reads source code, holds credentials, builds the artifacts that will run in production and often has the power to deploy them. Securing it serves two goals, finding vulnerabilities early and proving that what runs in production is exactly what was built from reviewed source.

The first goal is what DORA's pervasive security capability calls shifting left: integrating security objectives into daily work instead of testing at the end, when flaws are expensive to fix. In a pipeline that means static analysis of code, scanning dependencies and container images for known vulnerabilities, checking infrastructure and Kubernetes manifests against policies, and failing the build when a rule is broken. The Platforms White Paper lists static analysis of code and artifacts, runtime analysis and policy enforcement among a platform's security services, so teams inherit these checks through the golden-path pipeline rather than each wiring them up.

The second goal is supply chain integrity. SLSA is a set of incrementally adoptable guidelines for supply chain security, established by industry consensus, useful both to producers and to consumers deciding whether to trust a package. Its build track defines levels: Build L0 offers no guarantees, Build L1 means provenance exists showing how the package was built, Build L2 means signed provenance generated by a hosted build platform, and Build L3 means a hardened build platform. Sigstore makes signing practical. A client such as Cosign signs an artifact, Fulcio issues a certificate tied to an OpenID Connect identity, and the signing event is recorded in Rekor, an append-only transparency log, which allows keyless signing without long-lived key pairs. Kubernetes signs its own release artifacts with cosign keyless signing and publishes a Software Bill of Materials (SBOM) that users can verify; an SBOM lists the components inside an artifact so that newly disclosed vulnerabilities can be matched against it later.

Deployment completes the chain. Admission policies, for example Kyverno's image verification, can require that only signed images from approved registries run. Images should be referenced by digest, because a digest is an immutable hash of the content while a tag can be moved. GitOps reduces exposure as well: when an agent inside the cluster pulls changes, the CI system no longer needs credentials for the production cluster.

Pipeline hygiene matters as much as tools. Secrets belong in a secret manager and are injected at run time with the narrowest scope, never committed or printed to logs. Build jobs get only the permissions they need, third-party components and base images are pinned, and changes to pipeline definitions are reviewed like any other code.

Misconceptions include treating a vulnerability scan as complete supply chain security, assuming a signed image is safe (a signature proves origin, not the absence of flaws), and believing a private registry makes provenance unnecessary.

At associate level, expect questions on SLSA build levels, what each Sigstore component does, what an SBOM is for, where in the pipeline a control belongs, and why digests are safer than tags.