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.

Classifying pipeline controls as preventive, detective, or corrective gives a framework for reasoning about coverage: a set of controls that's all preventive with no detective backstop, or all detective with no corrective response, both have gaps a mixed set wouldn't.

The three categories, for code signing and deployment approvals

Preventive, for code signing: requiring a valid signature as a precondition for an artifact to even be published to the registry, so an unsigned artifact structurally cannot enter the delivery path at all. For deployment approvals: an admission-controller rule that refuses to schedule any workload not accompanied by a recorded approval, making an unapproved deployment structurally impossible rather than merely discouraged.

Detective, for code signing: a scheduled audit comparing every artifact currently in the registry against its expected signature, catching a case where a signing key was somehow bypassed or a signature was later found to be invalid, after the fact. For deployment approvals: reviewing deployment logs after the fact to confirm every production deployment during a given period actually had a corresponding, valid approval record, catching a case where the preventive control was somehow circumvented.

Corrective, for code signing: automatically quarantining or revoking trust in any artifact discovered (via the detective control) to lack a valid signature, and triggering a rebuild-and-resign from a known-good source. For deployment approvals: automatically rolling back a deployment discovered to have been applied without the required approval, restoring the last approved, known-good state.

Instrumenting for audit evidence

Each layer generates its own log: the preventive control logs every signature-verification pass/fail decision at the moment of enforcement; the detective control logs the results of every scheduled audit run, including any discrepancy found; the corrective control logs every automatic remediation action taken, tied back to the specific detective finding that triggered it. An auditor reviewing this instrumentation can see not just that a control exists on paper, but that it actually fired (or didn't need to) across a specific period, which is a meaningfully stronger form of evidence than a policy document describing what the control is supposed to do.

Why this framework matters beyond just classification

A pipeline relying only on preventive controls (signature required to publish, approval required to deploy) has no way to detect a case where the preventive control itself was somehow bypassed (a bug in the enforcement logic, or a path around it nobody anticipated); the detective layer exists specifically to catch that gap, and the corrective layer exists to make sure a detected gap doesn't just sit as an open finding but actually gets remediated.

Trade-offs

Building all three layers for every control (rather than relying on prevention alone) is more implementation and operational work, but it's the difference between a control that's ASSUMED to be working and one that's VERIFIED to be working, since a preventive control with no detective check behind it is, from an audit-evidence perspective, indistinguishable from a control that quietly stopped working months ago.

Secrets end up in Git history or CI artifacts through a small number of well-known paths, and each one has its own concrete, checkable prevention control rather than a single blanket fix.

Leakage vectors and controls

A developer commits a secret directly into source code (a hardcoded API key, a .env file checked in by accident). Prevention: a pre-commit hook running a secret-detection tool (gitleaks or trufflehog) that blocks the commit locally before it ever reaches the remote, plus a server-side push-protection check as a backstop for the developer who bypasses or doesn't have the local hook installed.

A secret leaks into CI build logs (an environment variable printed by a verbose build step, or a script echoing its own inputs for debugging). Prevention: enable the CI provider's built-in log masking for any value sourced from a secrets store (most CI systems mask a value automatically once it's referenced as a secret), and explicitly discourage set -x or verbose debug flags in scripts that handle secret-bearing environment variables.

A secret gets baked into a built artifact or container image (a config file with a real credential copied into the image during a multi-stage build, rather than injected at runtime). Prevention: scan every built artifact and container layer for secret patterns before it's published, and enforce a runtime-injection pattern (secrets manager, sidecar, or environment variable set at deploy time) rather than baking any credential into the image at build time.

Historical leakage, meaning a secret that was committed and later removed, but still exists in the Git history of an old commit. Prevention: run a periodic (for example nightly) scan of the FULL Git history, not just the current HEAD, since deleting a file in a later commit does not remove it from history; and gate any change that widens a repository's exposure (making a private repository public, adding an external collaborator, connecting a new third-party integration) on that full-history scan passing clean first, so a secret from years ago cannot be newly exposed the moment access to the repository widens.

If a secret is found in a log or artifact

The response is always rotate first, investigate second: revoke and reissue the credential immediately, since the window between detection and rotation is exactly the window an attacker could exploit, and only afterward investigate how it leaked and whether it was actually accessed by anyone unauthorized. A secret found by the historical scan gets the same treatment: it must be treated as compromised and rotated, not merely scrubbed from history, since history rewrites don't help once a repository has been cloned elsewhere, and the safe assumption is that any exposed secret has already been seen.

Trade-offs

Pre-commit hooks add a small amount of friction to every commit (a moment's pause while the scan runs) in exchange for catching the leak at the cheapest possible point, before it ever reaches a shared remote; skipping local hooks in favor of only a server-side check still catches the leak, but only after it has already reached the remote repository, which several tools and CI systems may have already cloned or cached by the time it's caught.

Findings from SAST and DAST tools arrive in different shapes (different severity scales, different identifiers for the same underlying weakness, different confidence signals), and a system that just concatenates them produces a flood of duplicate-looking tickets that erodes trust in the whole pipeline.

Data model

A canonical finding record needs at minimum: a normalized CVE or CWE identifier where one exists, the affected package or file path, a normalized severity on one consistent scale (rather than trusting each tool's own scale directly), the evidence (the specific line, request, or dependency that triggered the finding), the source tool, and a stable fingerprint used for deduplication.

Normalization rules

Each tool's native severity gets mapped onto one shared scale (for example CRITICAL/HIGH/MEDIUM/LOW) via a per-tool mapping table maintained by the security team, since 'HIGH' from one SAST tool and 'HIGH' from a DAST tool do not necessarily represent the same real-world risk. Package and path identifiers get normalized to a canonical form (resolving symlinks, stripping tool-specific path prefixes) so the same file reported by two different tools maps to the same record.

Deduplication and conflicting severities

The fingerprint for deduplication should combine the normalized location (file plus line range, or package plus version) with the normalized weakness category (CWE), not the raw tool-specific rule ID, since two different tools often use different rule IDs for the same underlying weakness. When two tools disagree on severity for what fingerprints as the same finding, take the higher of the two by default (a false negative from erring toward caution is cheaper than a false negative from erring toward dismissal) but surface both scores in the merged record so a human reviewer can see the disagreement rather than having it silently resolved.

Enrichment and prioritization

Enrich each normalized finding with exploitability metadata from exploit-db or the NVD's own exploit-maturity field, and assign priority as a function of normalized severity, exploitability, and (where available) whether the code path is actually reachable at runtime; assignment to an owner follows code-ownership data (the same signal a CODEOWNERS file already encodes) rather than a generic security-team queue, since the person who owns the code can act on the finding fastest.

Trade-offs

This system is worth building once an organization is running enough distinct scanners that manual triage across tool-specific dashboards has become the bottleneck; for a single team running one SAST and one SCA tool, the normalization and dedup machinery is more overhead than the problem it solves, and a simpler per-tool triage process is the right call instead.

A pre-merge security-gate checklist for pull requests needs to combine what can be automated (and therefore should never depend on a human remembering to check it) with what genuinely still needs a human's judgment, since collapsing that distinction either overloads reviewers with mechanical checks or under-automates things a human shouldn't have to catch manually every time.

Automated checks

Secret scanning on the diff, SCA on any changed dependency, SAST on changed files, and IaC misconfiguration scanning on any changed infrastructure definition, all running automatically on every PR without requiring a reviewer to remember to trigger them.

Manual reviews

A human reviewer still needs to assess things automation can't reliably judge: whether the CHANGE's actual business logic introduces an authorization gap (does this new endpoint correctly check the caller has permission for the specific resource, a check that's context-dependent in a way a generic scanner can't fully verify), and whether a third-party contribution's overall intent looks legitimate, beyond just what the automated scans flagged.

Required approvals and artifact verification

At least one reviewer with context on the affected area (not just any available reviewer) should approve before merge, and, for changes affecting the delivery pipeline itself or producing a released artifact, the artifact's signature and SBOM generation should be verified as part of the same gate, so a build that skips signing is caught here rather than discovered later at deploy time.

Considerations for third-party contributions

A pull request from an external, untrusted contributor needs the automated checks to run in an isolated context that doesn't expose organization secrets to the PR's own code during the CI run (the poisoned-pipeline-execution risk discussed elsewhere in this topic), and the manual review for an external contribution should weight more heavily toward understanding what the change actually does, since an external contributor hasn't built up the same track record of trust as an internal team member.

Enforcing without slowing developers down

The automated checks should complete fast enough (minutes, using the incremental/changed-file scanning techniques discussed elsewhere) that they don't become the bottleneck; the manual-review requirement should be scoped to a single required approver for routine changes, reserving a heavier, multi-reviewer requirement specifically for changes touching the pipeline's own security-relevant configuration or a genuinely high-risk area of the codebase, rather than applying the heaviest review bar uniformly to every single change regardless of its actual risk.

Trade-offs

A checklist this granular (separating automated from manual, and tiering the manual-review requirement by actual risk) takes more upfront design work than a single, uniform 'get one approval and pass CI' rule; that design work pays off by keeping the gate proportionate, catching genuinely risky changes with real scrutiny while not imposing that same heavy scrutiny on routine, low-risk changes that would otherwise slow the whole team down unnecessarily.