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

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.

At the scale of thousands of developers and hundreds of teams sharing one CI/CD platform, the RBAC (role-based access control) and tenant-isolation model has to assume that some tenant's job will eventually be compromised, and design so that compromise stays contained to that one tenant.

Secrets isolation

Each team (tenant) gets its own namespace in the secrets manager, with access policy scoped so a job running under tenant A's identity cannot read tenant B's secrets even if both run on the same shared platform; this is enforced by the secrets manager's own path-based policy engine, tied to each tenant's distinct service identity, not by a shared credential everyone happens to use responsibly.

Artifact repository separation

Similarly, each tenant's build artifacts live in a logically separate repository namespace with its own access policy, so a compromised or malicious tenant cannot read or overwrite another tenant's published artifacts; shared base images or common libraries that legitimately need to be available across tenants live in an explicitly-designated shared, read-only namespace rather than every tenant having implicit read access to every other tenant's artifacts.

Quota enforcement

Each tenant gets resource quotas (CPU, concurrent job count, storage) enforced at the platform layer, so one tenant's runaway or abusive job can't starve the shared runner fleet for every other tenant; without this, a single team's misconfigured or hostile workload becomes an availability incident for the entire platform.

Identity integration and onboarding

Identity ties back to the organization's SSO/IdP, so a developer's platform access follows their actual employment and team membership rather than a separately-managed platform-specific account that can drift out of sync when someone changes teams or leaves. Onboarding a new team should be a self-service, automated flow (request a new tenant namespace, get scoped secrets and artifact-repository access automatically provisioned) rather than a manual ticket to the platform team for every new team, since manual onboarding doesn't scale to hundreds of teams.

Cross-tenant shared libraries and operator privileges

Shared libraries live in a dedicated, explicitly-shared, read-only namespace that every tenant can read but only a small, trusted publishing group can write to, giving controlled reuse without every tenant needing write access to shared infrastructure. Platform operators (the small team running the shared infrastructure itself) hold a distinctly higher, separately-audited privilege tier than any individual tenant, since an operator's own credentials, if compromised, could affect every tenant at once; operator access should itself be scoped as narrowly as possible and require stronger authentication (hardware-key-backed MFA) given the blast radius a compromised operator credential represents.

Trade-offs

This level of per-tenant isolation (separate namespaces, separate quotas, separate secrets scoping) costs real engineering effort to build and maintain relative to one shared, unsegmented pool; it's worth that cost specifically at this scale, where the number of tenants makes a single compromised or misbehaving team's blast radius, if unisolated, large enough to be a genuine platform-wide incident rather than a contained one.

A widely-used npm package flagged as containing malicious code needs a response that separates 'stop the bleeding right now' from 'understand our actual exposure', since those need different speeds and different people.

Immediate containment

Block the malicious package version from being installed anywhere going forward (a registry-level block or an internal proxy denylist entry), and, if the malicious behavior is understood well enough to know its indicators (a specific network callback, a specific file it writes), add a detection rule for those indicators across running production systems in parallel with the containment step, not sequentially after.

Dependency audit and impact analysis

Query the organization's SBOM inventory (assuming one exists; if not, this step becomes a much slower manual repository search, which is exactly the scenario an SBOM is meant to prevent) for every service that includes this package, at which version, and whether it's a direct or transitive dependency; a transitive dependency several levels deep is just as exploitable as a direct one if the vulnerable code path is actually reachable, so the audit needs to check reachability, not just presence.

Hotfix rollout or dependency replacement

For services confirmed to include the malicious version, the fix is either pinning to the last known-good version (if a clean version predates the compromise) or fully replacing the dependency if the compromise makes the entire package untrustworthy going forward (a maintainer account compromise, for instance, might mean even future "clean" releases need scrutiny before being trusted again). Roll this out with the same staged, canary-first approach as any other production change, even under incident pressure, since an untested emergency fix rolled out everywhere at once risks creating a second incident.

Notification

Notify internal stakeholders (service owners, whose services are confirmed affected) and, depending on severity and whether customer data or systems were plausibly exposed, external stakeholders (customers, if the malicious package had a plausible path to affecting them) with a timeline sized to actual confirmed impact rather than worst-case speculation communicated as fact.

Long-term supply chain controls

Lockfile pinning (committing exact resolved versions, not just semver ranges) prevents an automatic, silent upgrade to a compromised version in the future. Checksum verification (validating a downloaded package's hash against a known-good value before installation) catches a tampered package even if its version number looks unchanged. Reproducible builds, where feasible, let you independently verify that a package's published source actually produces the artifact being distributed, catching a case where the published source looks clean but the distributed binary doesn't match it.

Trade-offs

Pinning exact versions via a lockfile trades away the convenience of automatically picking up minor security patches without any action, in exchange for control over exactly when and what gets upgraded; the mitigation for that trade-off is automated SCA scanning of the pinned versions, so a known vulnerability in a pinned dependency still surfaces for a deliberate, reviewed bump rather than silently persisting forever.

Integrating DAST safely into CI/CD for services that depend on third-party APIs and internal-only endpoints means the scan target itself introduces risk beyond the usual 'does this take too long' concern DAST placement discussions usually focus on.

Avoiding flaky results from external partners

Run DAST against a staging environment configured to use STUBBED or mocked responses for any third-party API dependency, rather than the actual live third-party service, since a live third-party dependency's availability, rate limits, or unrelated changes would make DAST results non-deterministic and unreliable as a gating signal; a stub that returns realistic, controlled responses keeps the scan's pass/fail outcome tied to your own application's behavior, not to a partner's uptime on any given day.

Protecting credentials used by DAST tools

The DAST tool itself typically needs authenticated access to properly test authenticated parts of the application, meaning it holds a real (or realistic test) credential; that credential should be scoped to the staging environment specifically, rotated on the same cadence as any other pipeline secret, and never be a credential that also has access to the production third-party account, since a DAST tool is itself effectively an automated, credentialed client making requests, and its credential deserves the same handling rigor as any other pipeline secret discussed throughout this topic.

Ensuring DAST doesn't cause harmful side effects in production

DAST must never run against production directly for a service where its probing (submitting forms, testing injection payloads, triggering workflows) could cause a real side effect (an actual email sent, an actual charge processed, actual data mutated); this is why DAST runs against a staging environment with fully isolated infrastructure, including isolated internal-only endpoints, rather than staging environments that happen to share a database or downstream integration with production. For internal-only endpoints specifically, make sure the staging environment's network topology actually mirrors production's internal segmentation, since testing an internal endpoint in an environment where it's accidentally reachable in a way production wouldn't allow gives a false sense of what's actually exposed.

Trade-offs

Stubbing third-party dependencies for DAST makes the scan reliable and fast but means DAST won't catch an integration-specific vulnerability that only manifests when interacting with the REAL third-party service's actual behavior; that gap is an accepted trade-off for CI-integrated DAST specifically, with a periodic, separate, less-frequent scan against a fully-live staging environment (accepting its slower, less-deterministic nature) as a supplementary check for exactly the integration-specific risk the stubbed version can't catch.

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.