TL;DR: DevSecOps pipelines sign malware because signing and security gating are decoupled. A cryptographic signature ends up attesting to a build state the scanner never re-verified. The fix isn't adding more scanners. It's rebuilding gate logic around actual business risk, exploitability, and reachability. Then bind SBOMs, scan results, and signatures into a single attestation chain.

Key Takeaways: - A pipeline that's "working as configured" can still bless malware when signing sits downstream of waivers and overrides. - Three structural gaps drive this: time-of-check vs time-of-use, transitive dependency blindness, and severity-as-risk collapse. - A security quality gate should fail builds on unacceptable business risk, not generic CVSS thresholds.

Your security pipeline isn't broken. It's working exactly as configured. That's the problem.

Malware can be cryptographically blessed by DevSecOps tooling. It happens when the unsigned-to-signed handoff becomes the weak link. The scanner ran. The gate passed. The key signed. The artifact shipped. The malware arrived with a valid signature.

What's structurally wrong here? The answer sits in the supply chain security model most teams inherit. Scanning produces a report. Gating makes a pass/fail decision. Signing happens downstream as a final cryptographic seal. Each step works in isolation. Together, they create a trust chasm.

A scanner might detect a malicious dependency. A waiver might excuse it. The build keeps moving. By the time the signing service touches the artifact, the gate's risk context is long gone. The signature attests to a build state the gate never re-verified.

This decoupling between detection and attestation is the structural reason malware reaches production with valid signatures. The pipeline did its job. The design of the pipeline was the actual failure. Our DevSecOps implementation guide treats this as a foundational design problem, not a tooling one.

The tools fired. The alerts triggered. The waivers were applied. The cryptographic stamp at the end turned a contested artifact into a trusted one. Most teams respond by adding more scanners. The real issue is upstream.

Three structural gaps turn security tooling into a rubber stamp.

These gaps aren't configuration mistakes by individual teams. They're baked into how most security gates are designed today.

Gap 1: Time-of-check vs time-of-use. Scanning runs against an earlier artifact state. The build that gets signed can pull in newer, unverified layers between the scan and the signature. A malicious base image change applied during final assembly can sneak through. The scan completed before the change landed.

Gap 2: Transitive dependency blindness. Outdated third-party libraries and end-of-life language runtimes slip through when SBOM best practices aren't enforced. Datadog's State of DevSecOps report identifies these same categories, outdated libraries and end-of-life runtimes, as the source of exploitable gaps. The gate has no inventory to evaluate them. The image looks clean because the gate is blind to depth, and it can't fail what it can't see.

Gap 3: Severity-as-risk collapse. Gates fail only on configurable thresholds that engineers tune to reduce noise. A "block on critical CVSS" rule treats a critical in a test-only dependency the same as one in a network-facing service. Known-bad code gets waived, the gate passes, and the signing service happily attests to the result.

The problem isn't that teams don't know these gaps exist. The problem is that image scanning strategies are usually bolted on as reporting layers. They aren't enforced as pre-signing prerequisites. Scanning tells you something is wrong. Signing tells the world everything is right. Those two signals travel in opposite directions.

Until the signing stage refuses to operate without a current, gate-validated risk decision, the architecture itself is the vulnerability. The next section shows why "fail on critical severity" makes the problem worse.

The standard "block on critical CVSS" approach treats every critical finding as equally dangerous. It isn't.

A critical CVE in a test-only dependency isn't the same risk as a critical in a network-facing service handling PII. CVSS measures severity, not exposure. Severity without reachability context is exactly why malware gets signed. The gate fires on the wrong axis, the waiver looks reasonable, and the build moves forward.

Here's the deeper issue. Overrides and waivers almost always happen after scanning but before signing. The developer reviews the critical CVE, decides it's acceptable for this build, applies a waiver, and the pipeline continues. The cryptographic signature then attests to a build state that no longer matches the artifact the scanner originally inspected.

This is the core failure mode. The security quality gate principle is clear: a build should fail only when it introduces unacceptable business risk, not when it matches a severity bucket. That means the gate needs three inputs that CVSS alone can't provide: - Exploitability: is there a public PoC, or is this theoretical? - Reachability: does the vulnerable code path actually run in this artifact? - Business context: is this artifact network-facing, handling regulated data, or test-only?

When the gate makes a decision on these inputs, the signature that follows is meaningful. When it makes a decision on severity alone, the signature is a lie the pipeline tells downstream consumers.

The alternative isn't more gates layered on top. It's a different kind of gate. One that makes a risk decision before the signing key ever touches the artifact.

The shift is architectural. You need to redesign the signing stage so the cryptographic key is the last thing to move, not the first.

Move the signing key out of the CI runner and into a gate-controlled signing service. This service refuses to sign when the gate's risk criteria aren't met. The CI runner builds, the scanner reports, the gate decides. Only then does the signing service accept a request. The key is no longer a passive tool the pipeline can call. It's a guarded primitive the gate must unlock.

Gate criteria should combine exploitability, reachability, and business context, not just CVSS score. A practical gate policy might look like:

Adopt an attestation model. The signature binds to an SBOM hash, a scan result hash, and a gate decision. Any post-hoc change to the artifact invalidates the attestation. This is the pattern that container signing with Sigstore enables. The image digest, SBOM, and provenance become a single verifiable claim. The attestation patterns that emerge from this approach make trust auditable, not assumed.

Make waivers expire and require re-signing. A "temporary" exception should never become a permanent backdoor. If the waiver lapses without a new gate decision, the artifact is effectively unsigned. Downstream admission controls should reject it.

This is the architectural shift: gate logic is the product, not the scanner output. The same logic shows up in adjacent trust problems. As we covered in why your API gateway JWT checks are opening doors, a token that attests to a state the verifier never re-checked is a fancier way to lie.

This design only holds up if three primitives operate as a single system. SBOM, image scanning, and container signing must reinforce each other rather than run as three disconnected tools.

The three primitives have to reinforce each other. Each one alone is a checklist item. Together, they're a trust boundary.

SBOM as the source of truth. Generate a signed SBOM at build time. Store it in a tamper-evident registry. Require the gate to look up the SBOM before signing the image. A clear SBOM tools comparison helps here. Syft, CycloneDX, and SPDX generators each have tradeoffs in coverage and ecosystem fit. The point isn't which tool. It's that the SBOM is the artifact's component identity.

Image scanning tied to the SBOM, not the build. Run continuous scanning against the deployed image. Send delta alerts when new CVEs affect components already in production. A build-time scan only proves the image was clean at one moment. The container image scanning layer needs to run on a schedule and on every dependency change in the upstream feed.

Signing as an attestation, not a stamp. Use Sigstore/Cosign or equivalent to bind the image digest, SBOM hash, and scan result into a single verifiable signature. Cosign's predicate support makes this practical:

A concrete gate step that ties it all together:

The gate fails the pipeline if the SBOM is unsigned. It also fails when any reachable dependency has a known exploit with a public PoC. The same goes for a scan result older than the SBOM. Each rule maps to a real failure mode from the gaps above.

When the gate logic reflects actual risk and the primitives reinforce each other, the threat model itself changes.

The shift isn't philosophical. It's operational, and it's measurable.

Malware stops being signed at the source. Downstream runtime detections aren't fighting against a cryptographically blessed binary. EDR, admission controllers, and policy engines can reject unsigned artifacts by default because "signed" actually means something.

Post-mortems change shape. Instead of "we didn't know this was in the build," teams say "the gate correctly rejected this, here's the override log, and here's the new attestation chain." The conversation moves from detection to governance.

Supply chain risk becomes auditable. Every signed artifact carries an attestation chain: SBOM, scan result, gate decision, waiver history. The DevSecOps maturity model advances from "we scan" to "we attest."

Treating every artifact as hostile isn't paranoia. It's the only model that scales as supply chain attacks grow more sophisticated. The signing key becomes a guarded primitive, not a convenience.

Q: Why would a DevSecOps pipeline sign malware in the first place?

A: Because the signing stage and the security gate are usually decoupled. Scanning produces a report, the gate makes a pass/fail decision, and signing happens downstream. The cryptographic signature attests to a build state the gate never re-verified.

Q: What is a security quality gate in DevSecOps?

A: A security quality gate is a policy check that fails a build when it introduces unacceptable business risk. It fails on risk, not on a generic severity threshold. It combines exploitability, reachability, and business context. Signing is gated on a risk decision, not a CVSS score.

Q: How does an SBOM help prevent supply chain attacks?

A: An SBOM gives you a verified inventory of every component in your artifact. When the gate consults the SBOM before signing, you can fail builds that include known-vulnerable or end-of-life dependencies. You stop them from propagating with a valid signature.

Q: What is container signing and why does it matter for DevSecOps?

A: Container signing cryptographically binds an image digest to an attestation chain. The chain typically includes an SBOM, a scan result, and a gate decision. It matters because it makes the trust claim auditable. Any post-build tampering or component swap invalidates the signature. Downstream consumers can reject unsigned or stale artifacts.

Q: How often should container images be rescanned in a DevSecOps pipeline?

A: At minimum, every deployment and on a continuous schedule. Daily is common for images already in production. A build-time scan only proves the image was clean at one moment. Rescanning against the live SBOM catches new CVEs in dependencies that were acceptable when the image was originally signed.

The gate logic is the product. Levitation works with security-critical teams on the redesign.

Research and references cited in this article:

• DevSecOps in 2026: Best Practices for Secure CI/CD Pipelines
• 5 DevSecOps Tools for Securing CI/CD Pipelines in 2026 - Opsera
• Top 10 DevSecOps Best Practices For 2026 | Octopus Deploy
• State of DevSecOps - Datadog
• What Are DevSecOps Pipelines? - DeployHub
• Understanding Container Image Signing in DevSecOps - Medium
• A Comprehensive Guide to SBOM (Software Bill of Materials) in DevSecOps - DevSecOps School
• Automating Software Trust: SBOMs, Code-Signing and the Modern Supply Chain
• DevSecOps and SBOM: Enhancing DoD Software Supply Chain Security
• PDF DevSecOps for a DoD Software Factory: 6 Best Practices ... - Carahsoft
• DevOps Supply Chain Security: A Case for DevSecOps | Anchore
• Software Supply Chain Security: Finally, a Common Standard?