Secure Software Delivery: DevSecOps, Pipeline, and Supply Chain Security Questions

This admission policy enforces two independent security properties on any container about to run in the cluster: that its image comes from a trusted source, and that it can't run with root privileges.

package kubernetes.admission

import rego.v1

allowed_registries := ["mycompany.registry/", "gcr.io/mycompany/"]

deny contains msg if {
	some container in input_containers
	not image_from_allowed_registry(container.image)
	msg := sprintf("container %q uses image %q from a non-approved registry", [container.name, container.image])
}

deny contains msg if {
	some container in input_containers
	not runs_as_non_root(container)
	msg := sprintf("container %q is not enforced to run as non-root", [container.name])
}

image_from_allowed_registry(image) if {
	some prefix in allowed_registries
	startswith(image, prefix)
}

runs_as_non_root(container) if {
	container.securityContext.runAsNonRoot == true
}

runs_as_non_root(container) if {
	container.securityContext.runAsUser != 0
}

input_containers := input.request.object.spec.containers

The two rules, and why non-root has two paths

The registry rule checks the image reference's prefix against an explicit allowlist, denying anything that doesn't match one of the two approved registries; this closes the same trust gap discussed for the supply-chain capstone elsewhere in this topic, enforced here at the actual point a container is scheduled, not just earlier in the pipeline. The non-root rule accepts EITHER of two ways a Pod spec can express "don't run as root": the explicit runAsNonRoot: true flag, or an explicit runAsUser set to any non-zero UID; a policy that only checked one of these two equivalent expressions would incorrectly deny a container that's actually correctly configured via the other path, which is why both are modeled as alternative ways to satisfy the same underlying rule.

Comments explaining the logic

The input_containers binding pulls directly from the Kubernetes AdmissionReview object's standard shape (request.object.spec.containers), which is the same structure every admission webhook receives regardless of what specific resource triggered the review, as long as it has a pod spec. Each deny rule is independent, meaning a container that fails BOTH checks produces two separate messages, giving the developer full visibility into everything wrong at once rather than surfacing one issue, requiring a fix, then surfacing the next.

Verified

Evaluated with opa eval against two fixture AdmissionReview payloads: a container using an unapproved registry (docker.io/library/nginx) with no non-root enforcement correctly produced both deny messages; a container using an approved registry with runAsNonRoot: true correctly produced an empty result.

Trade-offs

This policy checks only the FIRST container in a pod spec implicitly through the some container in input_containers iteration, which actually does correctly check every container in a multi-container pod (including init containers if they're included in the same array in your admission review shape); the real limitation is that it doesn't separately address initContainers, which live in a different field of the pod spec and would need their own explicit check if your threat model requires equally strict treatment of init containers.

A security gate is a checkpoint in the CI/CD pipeline where a security or compliance finding can affect whether a change proceeds, and the central design choice for any gate is whether it's a hard gate (blocking) or a soft gate (advisory).

Hard versus soft gates

A hard gate blocks the merge or deploy outright when its condition fires; nothing proceeds until the finding is fixed or an explicit, documented exception is granted. A soft gate surfaces the finding (a warning, an automatically-created ticket) but allows the change to proceed regardless, trading immediate enforcement for preserved velocity.

When to adopt each

Adopt a hard gate for findings where the confidence is high and the risk of shipping is genuinely severe: a confirmed secret in a commit, or a CRITICAL, reachable vulnerability with a known exploit, since the cost of blocking (a short delay while it's fixed) is clearly lower than the cost of shipping it. Adopt a soft gate for anything with a meaningfully higher false-positive rate or lower-confidence signal (a MEDIUM-severity SAST finding whose reachability is unclear), where blocking would impose a real velocity cost against uncertain actual risk.

Measuring the impact on security posture and velocity

For security posture, track whether soft-gate findings are actually getting resolved over a reasonable time window (not just generated and ignored), since a soft gate that never leads to a fix is providing visibility without any actual risk reduction. For velocity, track the time added to a typical pull request by the hard gates specifically (since those are the ones that can actually stop work), watching for the gate becoming a growing source of delay as the codebase and its dependency surface grow over time.

The trade-off in practice

A program dominated by hard gates ships the most defensible security posture on paper but risks the alert-fatigue and gate-erosion pattern discussed elsewhere in this topic if the gates aren't well-tuned; a program dominated by soft gates preserves velocity but risks findings quietly accumulating in an unenforced backlog with no real pressure to fix them. The healthiest programs use a small number of well-tuned hard gates for the highest-confidence, highest-severity findings, and route everything else through soft gates with a real, tracked follow-through mechanism, rather than treating 'hard gate' as the default setting for every category of finding regardless of its actual confidence and severity.

A Software Bill of Materials is a complete, machine-readable inventory of every component (direct and transitive dependencies, their versions, and often their cryptographic hashes) that went into building a given artifact. Its value as a security control, not just an inventory, is that it turns 'do we use the vulnerable package' from a multi-hour, panicked repository-grepping exercise during an active incident into a query that returns an answer in minutes.

Why it matters as a control, not just a list

The value shows up specifically at the moment a new CVE is disclosed against a widely-used package: without a pre-generated SBOM, answering "which of our production artifacts include this package, and at which version" means searching source repositories and build logs across however many services exist, under time pressure. With an SBOM generated at build time and stored centrally, that same question becomes a lookup against an existing inventory rather than a live investigation, which is exactly the difference between a controlled response and a fire drill.

Artifact signing and SLSA

Artifact signing (using cosign with Sigstore) cryptographically attests that a specific artifact was produced by a specific, trusted build pipeline, and that it hasn't been tampered with since. Sigstore's keyless signing uses short-lived certificates issued by its Fulcio certificate authority, tied to an OIDC (OpenID Connect) identity (the CI provider's own OIDC token) rather than a long-lived private key an engineer or pipeline has to manage and protect; this removes the operational burden and the leak risk of long-lived signing keys.

SLSA (Supply-chain Levels for Software Artifacts) defines a maturity ladder for how trustworthy a build's provenance claims are, from SLSA 1 (provenance exists but isn't verified) up through higher levels requiring the provenance to be signed and the build to run on a hardened, tamper-resistant build platform; generating unsigned provenance only reaches SLSA level 1, since signing is what makes the provenance claim actually trustworthy rather than just self-reported.

Example workflow

flowchart LR
  Build[Build artifact] --> SBOM[Generate SBOM]
  SBOM --> Sign[Sign artifact + attach provenance]
  Sign --> Publish[Publish to registry]
  Publish --> Verify[Verify signature + SBOM at deploy time]
  Verify -->|pass| Deploy[Deploy]
  Verify -->|fail| Block[Block deployment]

Trade-offs

Generating an SBOM and signing every artifact adds a small amount of build-time overhead and requires a place to store and query the resulting inventory and attestations; that overhead is worth it specifically because the alternative, reconstructing this information after the fact during an active incident, costs far more time exactly when time matters most.

SAST, DAST, and SCA answer three different questions, and a mature pipeline runs all three because none of them substitutes for the others.

What each one analyzes

• SAST (static application security testing) reads your own source code without running it, looking for patterns like SQL built from string concatenation, missing input validation, or insecure use of a crypto API. It runs on your first-party code.
• DAST (dynamic application security testing) attacks a running instance of the application from the outside, the way a real attacker would: sending malformed requests, probing for injection, checking for missing security headers, without any knowledge of the source.
• SCA (software composition analysis) does not analyze your code at all; it reads your dependency manifest and lockfile and checks every third-party package (including transitive dependencies) against known-vulnerability databases.

Where each runs best

SAST belongs early, ideally at pull-request time, because it needs no running environment and gives feedback in minutes on the exact line that introduced the problem. DAST needs a deployed, running target, so it typically runs against a staging environment post-merge or nightly rather than blocking every PR; running it synchronously on every PR would make the pipeline too slow and would require standing up a full environment per PR. SCA can run at PR time (fast, since it is just a manifest lookup) and again nightly against the full dependency tree, because a package that was clean yesterday can have a new CVE disclosed against it today with no code change on your side at all.

False-positive and false-negative trade-offs

SAST tends toward false positives: it flags patterns that look dangerous even when surrounding logic makes them safe, which is why untuned SAST rollouts generate alert fatigue. DAST tends toward false negatives on business-logic flaws (it can only find what it thinks to attack, and it will not understand your specific broken authorization logic without configuration) but has very few false positives, because if it successfully exploits something, that is a real, exploitable finding, not a pattern match. SCA's failure mode is different again: high-confidence on 'is this exact package version listed in a CVE database' but blind to whether your code actually calls the vulnerable function at all, which is why mature SCA programs add reachability analysis on top of the raw CVE match.

Example tools

Semgrep or CodeQL for SAST, OWASP ZAP for DAST, and Trivy, Snyk, or Dependabot for SCA are common concrete choices for each category.

Policy-as-code means security and compliance rules are written and enforced as version-controlled, testable code, evaluated automatically against a proposed change, rather than living as a document a human has to remember to check.

A simple example rule

In plain terms: deny any pull request whose commit contains a secret-scanning finding, or an SCA finding at HIGH severity or above. Expressed as a Rego-style rule:

deny contains msg if {
	input.sca_findings[_].severity == "HIGH"
	msg := "blocked: high-severity SCA finding present"
}

deny contains msg if {
	count(input.secret_findings) > 0
	msg := "blocked: secret detected in commit"
}

Tools that enforce this kind of rule

Open Policy Agent (OPA), often paired with Gatekeeper for Kubernetes admission control, and HashiCorp Sentinel (commonly used with Terraform Cloud/Enterprise) are two widely-adopted engines for exactly this pattern: writing the policy once as code, then evaluating it automatically wherever a relevant change is proposed, whether that's a pull request, a Terraform plan, or a Kubernetes deployment request.

Why this is preferable to a document

A written policy document requires a human to remember to check it and to interpret it consistently; policy-as-code evaluates the exact same logic every time, on every proposed change, without depending on any individual reviewer's memory or interpretation, and because it's code, it can be tested (does this policy correctly block the case it's meant to block, and correctly allow the case it's meant to allow) the same way any other piece of software is tested before it ships.

Trade-offs

Writing policy as code requires someone with the skill to write and test that code, which is a real barrier compared to writing a plain-language policy document; the payoff is that the enforced behavior and the documented intent can never drift apart the way a document and actual practice quietly can over time, since the code IS the enforcement.