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

Assessing third-party dependency and supply-chain risk for an application means treating every dependency, direct or transitive, as something you've implicitly extended trust to, and building the process around continuously validating that trust rather than checking it once at adoption time.

SBOM as the foundation

Generate an SBOM for every build, capturing the full dependency tree with exact versions, since you can't assess risk in what you can't enumerate; this becomes the input every other step in this process queries against.

Static and dynamic SCA

Static SCA checks the SBOM's package list against known-vulnerability databases without running anything, catching the majority of known issues cheaply and continuously. Dynamic SCA (or reachability analysis layered on top of static SCA) checks whether the application's actual code paths call the specific vulnerable function, distinguishing a theoretically-present risk from a practically-exploitable one, which matters directly for prioritization.

Version pinning and dependency-update policy

Pin dependencies to exact versions via a lockfile rather than a semver range, so upgrades are deliberate, reviewed events rather than silent automatic changes; pair this with a defined update policy (routine dependency bumps reviewed and merged on a regular cadence, versus emergency patches for actively-exploited critical vulnerabilities fast-tracked outside the normal cadence).

Transitive dependencies and private packages

Transitive dependencies need the same SBOM-and-SCA coverage as direct ones, since a vulnerability several levels deep in the tree is just as reachable if the code path calls into it; private, internally-published packages need the same treatment as public ones in this pipeline, since an internal package can also become outdated or compromised (a stolen internal-registry credential publishing a malicious internal package update is a real, if less commonly discussed, variant of the same risk class).

The full loop

flowchart LR
  SBOM[Generate SBOM] --> StaticSCA[Static SCA scan]
  StaticSCA --> Reach[Reachability analysis]
  Reach --> Prioritize[Prioritize by severity + reachability]
  Prioritize --> Fix[Pinned version bump or emergency patch]
  Fix --> SBOM

This is a continuous loop, not a one-time assessment, since new CVEs get disclosed against already-adopted dependencies with no code change on your side, meaning the SBOM and SCA scan need to re-run on a recurring cadence against dependencies that haven't changed, not just at the moment a dependency is first added.

Trade-offs

Pinning every dependency by exact version and gating every upgrade through review adds real process overhead compared to letting semver ranges auto-update; that overhead buys control over exactly what code is running at any moment, which is the property this entire risk-assessment process depends on, since you cannot meaningfully assess the risk of a dependency tree that silently changes underneath you between assessments.

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.

Filtering a SARIF file by severity and suppression list is fundamentally a tree-shaped transformation: preserve the overall document structure and tool metadata, and only filter the leaf-level results array inside each run.

import json


def filter_sarif(sarif, min_severities=("error", "high"), suppress_rule_ids=None):
    suppress_rule_ids = set(suppress_rule_ids or [])
    allowed = {s.lower() for s in min_severities}

    filtered = json.loads(json.dumps(sarif))  # deep copy, never mutate the caller's object

    for run in filtered.get("runs", []):
        results = run.get("results", [])
        kept = []
        for result in results:
            rule_id = result.get("ruleId")
            if rule_id in suppress_rule_ids:
                continue
            level = str(result.get("level", "")).lower()
            if level not in allowed:
                continue
            kept.append(result)
        run["results"] = kept

    return filtered

Key structural decisions

The function deep-copies the input via a round-trip through json.dumps/json.loads rather than mutating the caller's dictionary in place, since a filtering function that silently mutates its input is a common source of confusing bugs elsewhere in a larger tool that assumed the original SARIF object was untouched. The runs array itself, and each run's tool metadata, is preserved exactly as received; only the results array within each run is replaced with the filtered subset, which is what 'preserve the runs array and tool metadata' in the requirement actually means in terms of the transformation's shape.

Severity and suppression logic

A result is kept only if its ruleId is NOT in the suppress list AND its level is in the allowed severity set; both conditions are checked independently (via early continue statements) rather than combined into one large boolean expression, which keeps the logic readable and makes it straightforward to add a third filtering condition later without restructuring the whole check.

Verified

Executed a five-case test suite against a realistic sample SARIF document with four results across a mix of severities and one suppressed rule ID: confirmed the default filter keeps only error/high results; confirmed a specific suppressed rule ID is excluded even when its severity would otherwise pass; confirmed the tool metadata and top-level version field are preserved unchanged; confirmed the original input object is genuinely untouched after calling the function (checked via a separate deep-copy comparison); confirmed an empty result set is returned correctly when no results match the given severity filter at all. All five passed.

Trade-offs

The function assumes level (rather than a tool-specific severity field some SARIF producers may use instead) is where severity is expressed; some SAST tools populate a properties.severity field instead of or in addition to level, so a production version of this function would need to check both fields or accept a configurable field path, rather than hardcoding level as the only source of truth for severity.

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.

A secret is any credential that grants access to something (an API key, a database password, a private signing key, an OAuth token) where possession of the value itself is the entire authorization check. General configuration (a timeout value, a feature flag, a log level, a service's hostname) describes how the system should behave but grants no access on its own.

Concrete examples

• Secrets: a database connection password, an AWS access key, a third-party API token, a TLS private key, a webhook signing secret.
• Configuration: a request-timeout value, a retry count, a feature-flag boolean, a public API base URL, a log-verbosity level.

Why secrets need special handling

The practical distinction is blast radius on exposure: if a configuration value leaks (say, into a public log or a committed file), nothing bad happens by itself; at worst it reveals an implementation detail. If a secret leaks the same way, whoever finds it can immediately act as your application, which might mean reading a production database, calling a paid third-party API on your account, or impersonating your service to another system entirely. Secrets also need a lifecycle configuration values don't: rotation, expiry, and revocation, since a leaked secret needs to be actively invalidated, while a leaked configuration value just needs to be corrected.

Three practical controls

1. Store secrets in a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, or equivalent), never in environment variables baked into a config file or committed alongside application configuration. This keeps secrets out of version control by construction and gives you a single place to rotate and audit access.
2. Inject secrets at runtime via short-lived, scoped credentials (an OIDC (OpenID Connect)-issued token exchanged for a temporary cloud credential) rather than long-lived static keys checked into a pipeline's configuration. A short-lived credential that leaks has a bounded window of usefulness to an attacker; a static key that leaks is valid until someone notices and manually revokes it.
3. Run automated secret scanning on every commit and every build artifact, so a secret that accidentally ends up in code, a log line, or a built container image is caught and flagged for rotation before it reaches a public or widely-accessible location, rather than relying on developers to notice manually.

The trade-off

Treating every string that looks sensitive as a secret (over-classifying configuration as secret) adds unnecessary rotation and access-control overhead to values that don't need it; the practical test is always 'does possessing this value alone grant access to something', and applying that test consistently is what keeps the secrets-management overhead proportionate to the actual risk.