Why Runtime Security Is the Only Defense That Matters for Your CI/CD Pipelines
What Is a Pipeline Threat?
Every modern software organization depends on CI/CD pipelines to build, test, package, and distribute their products. These pipelines consume hundreds—sometimes thousands—of third-party components: open-source libraries, container base images, build tools, compiler plugins, and cloud-hosted services. Each of these components represents a trust boundary. And each trust boundary is an attack surface.
A pipeline threat is a compromised third-party component, toolchain, or service that executes malicious code within your CI/CD pipeline at build time. This is not a theoretical risk category invented by security vendors. It is an operational reality that 91% of application security organizations experienced software supply chain breaches in the last twelve months, according to research by Data Theorem and Enterprise Strategy Group.
The impact of a pipeline threat is not limited to a single failed build. Once malicious code executes inside your pipeline, it can disclose build secrets and credentials such as API keys, cloud tokens, and signing certificates. It can compromise the integrity of your build artifacts by injecting backdoors, cryptominers, or surveillance payloads into the software you ship to your customers. It can establish Advanced Persistent Threats (APTs) by installing remote access tooling, self-hosted runners, or kernel modules that survive long after the initial build completes. And it can facilitate the theft of digital currency—the first Shai-Hulud campaign alone resulted in approximately fifty million dollars in stolen cryptocurrency.
Sonatype’s State of the Software Supply Chain report documented a staggering 156% year-over-year growth in malicious packages targeting build pipelines. This is not a trend line. It is an exponential threat curve, and the industry is woefully unprepared.
Inventory and Provenance Will Not Protect You
Let us be direct: Software Bill of Materials (SBOM), digital signatures, and provenance technologies do nothing to prevent the introduction or execution of malicious software in your pipeline. They are inventory and attestation mechanisms. They tell you what was used and where it came from. They do not—and cannot—tell you what it did when it ran.
An SBOM catalogs the components in your software. A digital signature verifies the authenticity and integrity of a package at rest. Neither mechanism operates at runtime. Neither mechanism observes, restricts, or prevents the behaviors a component exhibits when it executes inside your pipeline. By the time the security community or the industry at large determines that a specific package version is malicious and adds it to a blocklist, it is already too late. The malware has already executed. The secrets have already been exfiltrated. The build has already been poisoned. Cataloging something as “malicious” after the fact does not reverse the damage.
The SLSA Gap
Supply-chain Levels for Software Artifacts (SLSA) is arguably the most comprehensive framework the industry has produced for software supply chain security. Its threat model, documented at slsa.dev, enumerates threats across the entire software development lifecycle—from source integrity to build process to artifact distribution. SLSA makes meaningful contributions to source provenance and build integrity.
But the SLSA framework has a critical limitation that is often overlooked. Examine its threat model closely. The mitigations for dependency threats—the category most directly relevant to pipeline threats—rely on provenance verification and source attestation. These controls answer the question: “Did this artifact come from where it claims to come from?” They do not answer the question: “What did this artifact do when it executed in my build environment?”
Consider the practical reality. Every threat that SLSA aims to prevent through provenance and attestation can only be leveraged after the threat has already been executed—and only if someone noticed. If a legitimate maintainer account is compromised (as happened in Shai-Hulud), the malicious package has valid provenance. If the attacker uses a Remote Dynamic Dependency to fetch the payload from an external server at install time (as PhantomRaven does), the package itself appears clean. If the malicious code is hidden in invisible Unicode characters (as GlassWorm demonstrates), no code review will catch it. In all three cases, SLSA attestations pass. The package is signed. The provenance is valid. And the malware runs.
SLSA itself acknowledges this limitation. Its specification explicitly designates runtime behavior enforcement as outside its current scope. This is not a criticism of SLSA—it is a recognition that provenance and inventory address one dimension of supply chain security while leaving the most dangerous dimension—what happens at runtime—completely unaddressed.
Three Attacks That Changed Everything
The second half of 2025 and early 2026 witnessed a dramatic escalation in the sophistication and scale of pipeline threats. Three campaigns in particular demonstrate exactly why static, point-in-time defenses are categorically insufficient.
Shai-Hulud: The Self-Replicating NPM Worm
First identified in September 2025 by Palo Alto Networks Unit 42, the Shai-Hulud worm represented a paradigm shift in supply chain attacks. Unlike traditional one-off malicious packages, Shai-Hulud was a self-replicating worm that spread autonomously through the npm ecosystem without direct operator intervention after initial deployment.
The attack chain began with phishing campaigns that compromised npm maintainer accounts. Once a single package was infected, the worm would execute during the npm install lifecycle, harvest GitHub and npm credentials from the local filesystem and environment variables, scan for AWS, GCP, and Azure cloud credentials using the legitimate secrets-discovery tool Trufflehog, exfiltrate all stolen credentials to attacker-controlled endpoints, and then use the victim’s own npm publishing tokens to automatically infect up to 100 additional packages maintained by that developer.
The November 2025 “Shai-Hulud 2.0” variant escalated further. It compromised 796 unique npm packages totaling over 20 million weekly downloads. It affected packages from major organizations including Zapier, PostHog, and Postman. The worm executed during the preinstall phase—meaning the malicious code ran before any tests or security checks could execute. It registered infected machines as self-hosted GitHub Actions runners, giving attackers persistent remote code execution capabilities. And it included a destructive failsafe mechanism that would attempt to wipe the user’s home directory if containment was detected.
Runtime behaviors exhibited: Outbound network connections to attacker-controlled servers (webhook.site, GitHub API). Filesystem reads of credential files (.npmrc, .gitconfig, .env, SSH keys). Filesystem writes to inject malicious code into other packages. Process execution of Trufflehog and Bun runtime for evasion. Registry API calls to publish compromised package versions.
PhantomRaven: Invisible Malware Through Remote Dynamic Dependencies
First documented in October 2025 by Koi Security and tracked through four additional waves by Endor Labs into February 2026, PhantomRaven introduced a delivery mechanism that rendered traditional package scanning almost entirely useless.
The technique, called Remote Dynamic Dependencies (RDD), exploits a feature of npm’s dependency resolution. Instead of listing dependencies as package names with version ranges, the attacker specifies a direct HTTP URL to a tarball hosted on an attacker-controlled server. When a developer runs npm install, npm itself retrieves the malicious payload from the external URL as part of its standard dependency resolution. The packages themselves contained nothing but benign “Hello World” scripts. The malware was never in the npm registry at all.
Across all four waves, over 200 malicious packages were published using more than 50 disposable npm accounts and accumulated tens of thousands of downloads. The campaign employed slopsquatting—registering package names that AI coding assistants like GitHub Copilot and ChatGPT commonly hallucinate, ensuring that developers who relied on AI-suggested dependencies unknowingly installed the malware.
Runtime behaviors exhibited: Outbound HTTP, POST, and WebSocket connections to command-and-control servers for data exfiltration. Filesystem reads of .gitconfig, .npmrc, environment variables, and CI/CD tokens from GitHub Actions, GitLab CI, Jenkins, and CircleCI. System fingerprinting including IP address, hostname, operating system, and Node version. Credential harvesting across multiple CI/CD platforms.
GlassWorm: Invisible Code, Unkillable Infrastructure
Discovered in October 2025 by Koi Security and tracked through multiple expansion waves into March 2026 by Aikido and Socket, GlassWorm is the most technically sophisticated pipeline threat observed to date. As of March 2026, over 433 compromised components have been identified across GitHub repositories, npm packages, and VS Code/OpenVSX extensions.
GlassWorm’s signature innovation is its use of invisible Unicode characters—specifically Unicode variation selectors and Private Use Area (PUA) characters—to hide executable JavaScript in plain sight. These characters produce no visual output in any code editor, IDE, or diff tool. To a developer performing code review, the injected lines appear as blank whitespace. To the JavaScript interpreter, they are fully executable code. This is not obfuscation. This is invisibility. As Koi Security’s CTO wrote: “The malware is invisible.”
GlassWorm’s command-and-control infrastructure uses the Solana blockchain. The malware queries specific blockchain transactions whose memo fields contain instructions pointing to the next-stage payload. Because blockchain transactions are immutable and decentralized, this C2 infrastructure is effectively impossible to take down. The attacker can update payload locations simply by publishing a new transaction.
The final-stage payload, dubbed the ZOMBI module, transforms each infected workstation into a node in a criminal network. It harvests NPM, GitHub, OpenVSX, and Git credentials for automated self-propagation. It drains funds from 49 different cryptocurrency wallet extensions. It deploys SOCKS proxy servers and hidden VNC servers for persistent remote access. It performs network reconnaissance to map internal corporate networks. And it uses WebRTC and the BitTorrent DHT network for decentralized peer-to-peer communication that bypasses traditional firewalls.
Runtime behaviors exhibited: Outbound network connections via HTTP, WebRTC, and BitTorrent DHT to decentralized C2 infrastructure. Blockchain queries to the Solana network for command retrieval. Filesystem reads and writes across credential stores, wallet data, and SSH keys. Process execution to install the Node.js runtime, deploy VNC servers, and establish SOCKS proxies. Memory-resident execution of the multi-stage payload chain. System-level persistence through init.json and self-hosted runner registration.
The Common Thread: SBOM Saw Nothing
In every one of these attacks, an SBOM would have faithfully recorded the presence of the infected package. A digital signature would have validated its integrity at rest. SLSA provenance attestations would have confirmed its origin. And none of these controls would have prevented a single byte of malicious code from executing. The packages were “legitimate”—they came from real maintainer accounts, they were published to real registries, and they passed every static check. The threat was not in what the packages were. The threat was in what they did.
Runtime Security Is Not Optional. It Is Mandatory.
The three attacks described above share a pattern that should alarm every security leader. Despite radically different delivery mechanisms—npm lifecycle hooks, Remote Dynamic Dependencies, and invisible Unicode injection—all three campaigns relied on the same categories of malicious runtime behavior to achieve their objectives.
Every one of them made unauthorized outbound network connections. Shai-Hulud exfiltrated credentials to webhook.site and the GitHub API. PhantomRaven transmitted stolen data via HTTP, POST, and WebSocket connections to rotating C2 domains. GlassWorm queried the Solana blockchain and established peer-to-peer channels over WebRTC and BitTorrent DHT. In a legitimate CI/CD build, the set of required outbound connections is finite and predictable: your package registry, your artifact store, your cloud provider APIs. Any connection outside that known set is suspicious. Any connection to webhook.site, a random attacker domain, or the Solana blockchain from inside a build pipeline is unequivocally malicious.
Every one of them attempted to read and exfiltrate sensitive files. All three campaigns targeted credential files (.npmrc, .gitconfig, .env), cloud provider credentials (AWS, GCP, Azure), CI/CD tokens (GitHub Actions, GitLab CI, Jenkins, CircleCI), and SSH keys. GlassWorm additionally targeted cryptocurrency wallet data. A legitimate build process has no reason to read your .npmrc publishing token, your SSH private keys, or your cloud credentials directory. These filesystem access patterns are inherently anomalous in the context of a build.
Every one of them executed unexpected processes. Shai-Hulud downloaded and executed Trufflehog and the Bun JavaScript runtime. PhantomRaven executed its payload through npm’s dependency resolution mechanism. GlassWorm installed Node.js runtimes, deployed VNC servers, and established SOCKS proxies. None of these process executions are expected in a standard build workflow.
The conclusion is inescapable: if you cannot observe and enforce what happens inside your build at runtime, you cannot defend against pipeline threats. Point-in-time scanning, dependency auditing, SBOM generation, and provenance verification are necessary layers of a defense-in-depth strategy. But they are not sufficient. Without runtime enforcement, they are guardrails on a bridge with no deck.
eBPF: Kernel-Level Visibility and Enforcement at Scale
If runtime security is mandatory, the next question is: how do you achieve it at the kernel level, across heterogeneous build infrastructure, without imposing unsustainable operational overhead? The answer is eBPF.
What Is eBPF?
Extended Berkeley Packet Filter (eBPF) is a technology built into the Linux kernel that allows sandboxed programs to run in kernel space without requiring kernel module modifications or system reboots. Originally designed for packet filtering, eBPF has evolved into a general-purpose programmable framework for observing and controlling system behavior at the lowest level of the operating system.
eBPF programs attach to hooks in the kernel. These hooks are triggered whenever specific system events occur—a file is opened, a network connection is initiated, a process is executed, memory is mapped, a kernel module is loaded. Because eBPF operates at the kernel level, it sees everything. No userspace evasion technique—process injection, fileless execution, LD_PRELOAD hijacking, or container escape—can hide from the kernel. If it happens on the system, eBPF can observe it.
How eBPF Stops Pipeline Threats
The Linux kernel exposes a set of Linux Security Module (LSM) hooks that eBPF programs can attach to for mandatory access control enforcement. Two hooks are particularly relevant for pipeline threat prevention:
socket_connect — This hook is invoked every time a process attempts to establish a network connection. An eBPF program attached to this hook can inspect the destination address, port, and protocol, then allow or deny the connection based on a security policy. In the context of pipeline security, this means every outbound connection attempt from every process in the build is visible and enforceable. If your build policy says “this pipeline may only connect to registry.npmjs.org, ghcr.io, and s3.amazonaws.com,” then any connection to webhook.site, a Solana RPC endpoint, or an attacker’s C2 domain is rejected at the kernel level before the TCP handshake completes.
file_open — This hook is invoked every time a process attempts to open a file. An eBPF program attached to this hook can inspect the file path, the requesting process, and the access mode (read, write, execute), then allow or deny the operation. For pipeline security, this means unauthorized reads of .npmrc, .gitconfig, SSH key directories, cloud credential files, or cryptocurrency wallet data are blocked before the file descriptor is returned to the calling process.
The enforcement model is straightforward: derive a baseline policy from observed legitimate build behavior, tailor it to the specific pipeline’s requirements, then enforce it. Any deviation from the policy—an unexpected network connection, an unauthorized file read, an unapproved process execution—is rejected at the kernel level, the action is thwarted, and a violation event is generated for triage and incident response.
Why eBPF Is Superior to Alternatives
Kernel-level enforcement cannot be bypassed from userspace. Traditional endpoint security tools that operate in userspace can be evaded by techniques like LD_PRELOAD hijacking, ptrace injection, or process hollowing. eBPF programs run in the kernel and enforce policy before the system call returns to the calling process. The malware never gets the opportunity to execute the malicious action.
Per-pipeline policy granularity. Unlike operating system hardening approaches that apply broad rules across all workloads, eBPF-based enforcement can apply different policies to different pipelines on the same host. A Node.js frontend build has a different legitimate behavior profile than a Rust backend build or a container image build. eBPF allows each pipeline to have its own tailored mandatory access control (MAC) policy.
Comprehensive visibility across the entire build host. eBPF provides visibility into network connections, filesystem operations, process executions, memory mappings, kernel module loads, container operations, and privilege escalation attempts—all from a single instrumentation framework. There is no gap between “what the security tool can see” and “what the attacker can do.”
No kernel module required. Unlike traditional kernel security modules that require custom kernel builds, eBPF programs are loaded dynamically and run in a verified sandbox. This means deployment does not require kernel recompilation, system reboots, or maintenance windows. Sensors can be deployed into existing CI/CD workflows as a pipeline step.
Auditability and traceability. Every enforcement decision—every allowed action and every denied action—can be traced back to the specific pipeline, the specific build event, the specific process, and the specific policy rule. This creates a complete audit trail that OS-level hardening and network-based controls simply cannot provide.
Endura Security: Build With Confidence
At Endura Security, we built our platform on a fundamental conviction: the software supply chain cannot be secured without runtime enforcement inside the pipeline. Inventory tells you what you have. Provenance tells you where it came from. Endura tells you what it did—and stops it if the answer is wrong.
Endura deploys an eBPF-based Sensor directly into your CI/CD pipeline workflows. The Sensor attaches to Linux kernel hooks to provide complete visibility into every network connection, file operation, process execution, and kernel interaction that occurs during a build. There is no blind spot. There is no userspace evasion path. If it happens on the build host, Endura sees it.
The deployment model is designed for operational reality. You install the Sensor by adding a single step to your existing pipeline configuration. No agents on permanent infrastructure. No kernel modules. No container image modifications. The Sensor runs in “derive” mode to automatically observe your build’s legitimate behavior and generate a baseline security policy. You tailor that policy to your pipeline’s specific requirements. Then you switch to “enforce” mode to implement pipeline-specific mandatory access control. From that point forward, any unauthorized network connection, file access, process execution, or privilege escalation is rejected at the kernel level, the build is stopped, and a violation event is generated for triage.
It Works Wherever You Build
Endura supports eleven CI/CD providers including GitHub Actions, GitLab CI, Jenkins, TeamCity, Azure Pipelines, AWS CodeBuild, CircleCI, CloudBees CI, Bamboo, Argo CD, and TravisCI. Whether your builds run in ephemeral cloud-hosted runners or on shared on-premises build servers, Endura provides the same kernel-level visibility and enforcement.
This is especially critical for organizations running Jenkins and TeamCity deployments where multiple builds share the same host. In these environments, a compromised build in one pipeline can potentially access secrets, artifacts, and credentials belonging to other pipelines on the same machine. Endura’s per-pipeline policy enforcement ensures that each build operates within its own mandatory access control boundary, regardless of what else is running on the host.
Endura supports twelve Linux distributions across multiple versions, including Red Hat Enterprise Linux, Ubuntu, Debian, Amazon Linux 2023, SUSE Enterprise Linux, and Alpine Linux. The Sensor is available as RPM, DEB, and TGZ packages, and can be deployed as a Kubernetes DaemonSet via Helm chart. The Team Server is fully containerized and deployable in both cloud and 100% on-premises configurations.
Regardless of Where You Are With SLSA
Endura does not require you to have achieved any specific SLSA level. Our platform operates independently of your provenance and attestation infrastructure. If you have robust SLSA compliance, Endura adds the runtime enforcement dimension that SLSA explicitly leaves unaddressed. If you are early in your SLSA journey, Endura provides immediate, actionable security for the highest-impact threat vector—malicious code executing in your pipeline—while you build out your broader supply chain security posture.
The Gap Is Real. The Solution Exists.
Shai-Hulud, PhantomRaven, and GlassWorm are not isolated incidents. They are the new normal. The software supply chain has become the most consequential attack surface in modern software development, and the industry’s dominant security paradigm—inventory, provenance, and static scanning—is architecturally incapable of addressing the threat.
Pipeline threats operate at runtime. They make network connections. They read files. They execute processes. They exfiltrate data. None of these behaviors are visible to an SBOM. None of them are prevented by a digital signature. None of them are detected by SLSA provenance attestations.
eBPF provides the kernel-level visibility and enforcement required to detect and prevent these behaviors at the point of execution. It is the only technology that operates at a layer of the system where evasion is not possible, where per-pipeline policy granularity is achievable, and where complete auditability is a built-in capability rather than an afterthought.
At Endura Security, we are not asking you to replace your existing security investments. We are asking you to close the gap that they cannot. Build with confidence.
Sources
Palo Alto Networks Unit 42, “Shai-Hulud Worm Compromises npm Ecosystem in Supply Chain Attack,” November 2025. https://unit42.paloaltonetworks.com/npm-supply-chain-attack/
Datadog Security Labs, “The Shai-Hulud 2.0 npm worm: analysis, and what you need to know,” November 2025. https://securitylabs.datadoghq.com/articles/shai-hulud-2.0-npm-worm/
Microsoft Security Blog, “Shai-Hulud 2.0: Guidance for detecting, investigating, and defending against the supply chain attack,” December 2025. https://www.microsoft.com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending-against-the-supply-chain-attack/
Check Point Research, “Shai-Hulud 2.0: Inside The Second Coming, the Most Aggressive NPM Supply Chain Attack of 2025,” November 2025. https://blog.checkpoint.com/research/shai-hulud-2-0-inside-the-second-coming-the-most-aggressive-npm-supply-chain-attack-of-2025/
Endor Labs, “The Return of PhantomRaven: Detecting Three New Waves of npm Supply Chain Attacks,” March 2026. https://www.endorlabs.com/learn/return-of-phantomraven
BleepingComputer, “New PhantomRaven NPM attack wave steals dev data via 88 packages,” March 2026. https://www.bleepingcomputer.com/news/security/new-phantomraven-npm-attack-wave-steals-dev-data-via-88-packages/
NowSecure, “PhantomRaven NPM Supply-Chain Attack: How Remote Dependencies Hide Malware,” March 2026. https://www.nowsecure.com/blog/2026/03/13/phantomraven-npm-supply-chain-attack-how-remote-dependencies-hide-malware/
Koi Security, “GlassWorm: First Self-Propagating Worm Using Invisible Code Hits OpenVSX Marketplace,” October 2025.
BleepingComputer, “GlassWorm malware hits 400+ code repos on GitHub, npm, VSCode, OpenVSX,” March 2026. https://www.bleepingcomputer.com/news/security/glassworm-malware-hits-400-plus-code-repos-on-github-npm-vscode-openvsx/
The Hacker News, “GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers,” March 2026. https://thehackernews.com/2026/03/glassworm-supply-chain-attack-abuses-72.html
Aikido Security, “Glassworm Returns: Invisible Unicode Malware Found in 150+ GitHub Repositories,” March 2026. https://www.aikido.dev/blog/glassworm-returns-unicode-attack-github-npm-vscode
SLSA v1.2, “Threats & Mitigations.” https://slsa.dev/spec/v1.2/threats
Data Theorem & Enterprise Strategy Group; Sonatype State of the Software Supply Chain.
CISA, “Widespread Supply Chain Compromise Impacting npm Ecosystem,” September 2025. https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
Top comments (0)