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

Threat-modeling the pipeline itself, rather than the application it ships, means treating the pipeline as a genuinely privileged system in its own right, since it routinely holds the credentials needed to deploy to production and often runs code it doesn't fully trust.

Assets and trust boundaries

The key assets are: the source repository (what determines what gets built), the CI runners (which execute arbitrary build-defined code), the secrets and signing keys the pipeline holds, and the artifact registry and deployment target (the ultimate destination an attacker wants to reach). Trust boundaries sit wherever untrusted or less-trusted input meets a more-trusted execution context: an external contributor's pull request meeting a runner that has repository write access or secrets access is the sharpest boundary, since a malicious PR is attacker-controlled input running inside a context that may hold real credentials.

Likely attackers and top threats

A plausible attacker profile ranges from an external contributor submitting a malicious pull request, to an attacker who has compromised a legitimate contributor's credentials, to an attacker who has compromised a third-party dependency or CI action the pipeline trusts. The top five threats, roughly in order of how often they show up in real incidents: (1) runner compromise via a malicious build step, letting an attacker read whatever secrets that runner had; (2) supply-chain poisoning via a compromised dependency or third-party action; (3) a malicious pull request triggering a workflow with elevated permissions (the poisoned-pipeline-execution pattern, particularly via triggers like pull_request_target that grant a fork's PR access to secrets); (4) leaked long-lived credentials granting broader access than a short-lived credential would; (5) a compromised signing key letting an attacker produce artifacts that appear legitimately trusted.

Mitigations, prioritized by impact and effort

Highest impact, lowest effort: pin all third-party actions to an immutable commit SHA (addresses threat 2 directly, cheap to implement, no ongoing operational cost). Next: avoid or tightly restrict dangerous trigger patterns like pull_request_target for anything that doesn't strictly need it (addresses threat 3, requires an audit of existing workflows but no new infrastructure). Then: move to ephemeral, least-privilege runners and short-lived, scoped credentials (addresses threats 1 and 4, moderate effort since it may require re-architecting how credentials are issued). Highest effort, addressing the residual risk in threat 5: keyless, OIDC (OpenID Connect)-backed signing removes the long-lived signing key from the picture entirely, closing that threat at the cost of migrating existing signing infrastructure.

Trade-offs

Prioritizing by impact-versus-effort rather than tackling every threat with equal urgency means some real risk (the signing-key compromise threat) stays partially open longer, since it's genuinely the most expensive to fully close; that's an honest, deliberate sequencing choice rather than an oversight, made explicit so stakeholders understand exactly what residual risk remains at each stage of the rollout.

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.

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.

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.

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.