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.

DevSecOps means security is a shared responsibility built into every stage of the software delivery lifecycle, rather than a single gate a centralized team applies right before release. In a traditional model, developers hand off a finished feature to a separate security team that runs its own scans and reviews days or weeks later, often after the design and even the deployment date are already locked in. In DevSecOps, developers absorb the cheap, fast checks themselves (local static analysis, dependency scanning on their own laptop, threat-modeling their own design), while a smaller central security function keeps the things that genuinely benefit from centralization: enterprise key management, threat intelligence, incident response coordination, and the policies that gate a promotion.

What actually changes: people, process, technology

• People: security stops being 'someone else's job'. Developers own fixing the findings on their own code; security engineers shift from being gatekeepers to being platform builders and consultants who make the secure path the easy path.
• Process: security activities move from a single late gate to many small checks distributed across the lifecycle (design review, pre-commit hooks, PR-time SAST/SCA, pre-deploy policy checks, post-deploy monitoring), each cheap enough to run continuously.
• Technology: security tooling is embedded in the same CI/CD pipeline developers already use, with results surfaced in the same pull request instead of a separate portal nobody checks.

Who owns what

• Developers: fixing SAST/SCA findings in their own code, writing secure code in the first place, running fast local checks before pushing.
• Platform/security engineering: building and maintaining the scanning infrastructure, setting policy thresholds, owning centralized secrets and key management, running incident response.
• Both together: threat modeling for a new design, deciding what should block a merge versus what should be advisory.

Benefits and common pitfalls

The benefit most organizations actually realize is faster feedback: a vulnerability found in a PR costs a few minutes to fix; the same vulnerability found in a post-release audit costs a meeting, a hotfix branch, and a redeploy. The most common pitfall is rolling out every scanner at once with hard-blocking gates and no tuning, which produces alert fatigue and gets the whole program quietly disabled by frustrated teams within a quarter. A second common pitfall is treating DevSecOps as 'buy a scanner and bolt it onto the pipeline' without changing who owns fixing what it finds, which just recreates the old centralized-gate model with extra tooling cost.

The workflow below runs Trivy's filesystem scanner against a Node.js repository on every pull request, uploads the full findings as a SARIF artifact for later triage, and then fails the job specifically when a CRITICAL-severity vulnerability is found, using two separate Trivy invocations so the artifact upload always succeeds even when the gate fails.

name: dependency-scan

on:
  pull_request:
    branches: [main]

jobs:
  sca:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4

      - name: Run Trivy filesystem scan
        uses: aquasecurity/trivy-action@v0.24.0
        with:
          scan-type: fs
          scan-ref: .
          format: sarif
          output: trivy-results.sarif
          severity: CRITICAL,HIGH
          exit-code: '0'

      - name: Upload SARIF report
        uses: actions/upload-artifact@v4
        with:
          name: trivy-sarif-report
          path: trivy-results.sarif

      - name: Fail on CRITICAL findings
        uses: aquasecurity/trivy-action@v0.24.0
        with:
          scan-type: fs
          scan-ref: .
          severity: CRITICAL
          exit-code: '1'
          format: table

Why two scan steps instead of one

A single Trivy invocation with exit-code: 1 would fail the job immediately on a CRITICAL finding, which means the SARIF upload step never runs, since GitHub Actions stops the job on a failing step by default. Running the SARIF-producing scan first with exit-code: 0 (never fails) guarantees the full report is always archived as an artifact for triage, and the second, narrower CRITICAL-only scan is what actually gates the merge. This two-step pattern is the practical answer to 'how do I both fail the build AND keep the evidence', which a single combined step cannot do without extra continue-on-error plumbing that obscures the actual gating logic.

Verified

This workflow parses as valid YAML (verified with PyYAML): one job, four steps, pull_request trigger on main; on parsing as a YAML boolean key is a known PyYAML quirk that does not affect GitHub's own workflow parser, which treats on as a reserved workflow keyword regardless. Checked aquasecurity/trivy-action's published tags via the GitHub API: the action only publishes v-prefixed tags (v0.24.0, v0.25.0, etc.); an unprefixed @0.24.0 reference does not exist and GitHub Actions would fail to resolve it at run time with "unable to find version". The action reference has been corrected to @v0.24.0 in both steps above, and actions/checkout@v4 and actions/upload-artifact@v4 were also confirmed to exist as real tags.

Trade-offs

The severity: CRITICAL,HIGH on the first scan (broader than the gate) is deliberate: it means the SARIF artifact captures HIGH-severity findings for visibility even though they don't block the merge, giving the team a queue of near-term work without slowing anyone down today.

A third-party library with a potential licensing or security exposure needs two genuinely different investigation tracks, since a license risk and a security risk have different consequences, different owners, and different urgency profiles, even though they can arrive from the same discovery.

Investigating the risk

For the licensing angle, determine the library's actual license terms and whether your product's distribution model (SaaS, on-prem, bundled with a commercial product) triggers any specific obligation that license imposes (a copyleft license's source-disclosure requirement behaves very differently for a SaaS product than for shipped, distributed software, for instance); this genuinely needs a legal read, not just an engineering judgment call, since license interpretation carries real business risk if guessed wrong. For the security angle, follow the same investigation steps discussed throughout this topic: confirm the CVE or vulnerability is real and reachable in your specific usage, not just present in the dependency tree.

Proposing remediation options

For a licensing exposure, options typically include: negotiating a different license or commercial agreement with the maintainer or a company managing the license, replacing the library with a differently-licensed alternative, or, if the risk is deemed acceptable after legal review, formally documenting the accepted risk with legal sign-off rather than leaving it as an unresolved, unowned question. For a security exposure, the options follow the same version-bump-or-replace pattern used elsewhere in this topic for dependency vulnerabilities.

Communicating trade-offs to product and legal

Product needs to understand the SHIPPING SCHEDULE impact of each option (a license replacement might require meaningful engineering time that could push a release date; a security patch might be nearly free), framed in terms of the actual trade-off rather than technical jargon; legal needs the FACTUAL specifics of how the library is actually used and distributed, since a license risk assessment depends entirely on those usage facts, which legal can't determine on their own without engineering input.

Implementing a remediation plan while minimizing shipping disruption

If the chosen remediation is a library replacement (the highest-disruption option), stage it the same way any other risky dependency change would be staged: behind a feature flag or in a non-critical-path service first, validating the replacement's behavior matches before rolling it out to the full, critical-path usage; if the remediation is a version bump or a documented accepted-risk decision, the disruption is minimal and can proceed on a normal cadence.

Trade-offs

Documenting an accepted licensing risk with legal sign-off, rather than insisting on replacing every library with any theoretical licensing question, is a legitimate outcome when legal genuinely concludes the risk is acceptable given the specific usage; the key discipline is that this has to be an explicit, owned, legal-reviewed decision, not a default that happens by simply not addressing the question at all.

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.