Your engineering team is starting its day. A security feed pings with a new CVE: a popular HTTP client, an AI infrastructure library, a container scanner you run in every CI pipeline. The first question that matters is not how bad is it or who fixed it. It is the simplest one, and it is the one that is hardest to answer quickly: "Are we running this? Where? In how many places?"
For most teams, the honest answer is: "we will get back to you in a few hours." Sometimes days.
That delay is where the breach actually happens.
The Pain Nobody Talks About In Their Product Demos
Supply chain incidents are not usually contained by speed of patching. They are decided by speed of knowing. The malicious version is already running in your build pipeline, your container registry, your production cluster, by the time the advisory goes public. What matters next is how fast your team can answer three questions:
- Which of our workloads contain the affected artifact?
- Which of those are running right now, in which clouds and clusters?
- What secrets or data did the compromised code have access to during the exposure window?
The friction is that the inventory needed to answer those questions lives in eight different places. Your package.json and lockfiles say one thing. Your build system resolved something slightly different. Your container registry cached a specific digest. Your Kubernetes helm releases reference image tags that may or may not point to the same digest. Your compute instances are running whichever AMI or disk image they were launched from, which may not match any of the above. Your CI pipeline pulled third-party actions whose tags have since been rewritten.
Reconciling those eight views is an engineering exercise. On a typical team that does not have a continuously-refreshed runtime inventory, it takes anywhere from a morning to several days. A senior engineer drops whatever they were working on. They open kubectl, open the registry UI, grep through a bunch of repos, try to remember which deployment uses which helm chart. Hours pass. Meanwhile, the attacker's window is still open.
This is the real operational cost of a supply chain incident. Not the fix. The lookup.
March and April 2026: A Concentrated Wave of Compromises
The last five weeks have demonstrated, with unusual clarity, how hard this problem has become. These are all publicly disclosed incidents with assigned CVEs or vendor advisories.
Trivy, trivy-action, setup-trivy -- March 19, 2026 (CVE-2026-33634, CVSS 9.4). The open source container and supply chain scanner itself was compromised. Version 0.69.4 and the associated GitHub Actions were trojanized; 75 of the 76 trivy-action tags and 7 of the setup-trivy tags were force-pushed to malicious versions. The malicious code -- self-described in the payload as "TeamPCP Cloud stealer" -- dumped the GitHub Actions runner's process memory and harvested SSH keys, cloud credentials, and Kubernetes secrets. Root cause: a privileged Personal Access Token had been stolen from an earlier pull_request_target workflow exploit, and the rotation after discovery was incomplete. The triage question for thousands of security teams: "how many of our CI pipelines installed Trivy or the Trivy Actions during the window, and what secrets did those runners have access to?"
Axios -- March 30-31, 2026. The maintainer's npm account was compromised via an email change after credential theft. Versions 1.14.1 and 0.30.4 were published with a hidden dependency (plain-crypto-js@4.2.1) that deployed the WAVESHAPER.V2 backdoor across Windows, macOS, and Linux through a post-install script. Axios is one of the most heavily used HTTP libraries in the JavaScript ecosystem -- on the order of 70 to 100 million weekly downloads. The compromise was attributed to UNC1069, a North Korea-nexus, financially motivated threat actor. The triage question: "which of our web services, CI builds, and npm-consuming tools pulled the bad versions, and what environments did those builds run in?"
LiteLLM -- March 24-26, 2026. Versions 1.82.7 and 1.82.8 of the widely used AI infrastructure library (roughly 3.4 million downloads per day) were backdoored via stolen PyPI publish credentials, attributed to TeamPCP. The triage question: "which of our ML services and AI-adjacent tools pulled the compromised versions, and what provider API keys or customer data did they touch?"
Telnyx -- March 27, 2026. Versions 4.87.1 and 4.87.2 of the Telnyx Python package were published with malicious code, by the same threat actor, via the same attack pattern: compromised publish credentials from the Trivy PAT theft.
Cascading npm campaign -- April 2026. TeamPCP used the stolen credentials from the Trivy compromise to publish malicious versions of 47 or more npm packages across multiple scopes, tracked as CanisterWorm. Later variants injected a post-install hook that stole tokens and re-published from the installing developer's machine, turning every install into a propagation event.
Every one of these incidents shares the same structure. Somebody with legitimate publishing rights was compromised. The compromise propagated downstream for hours or days before public disclosure. And once disclosure hit, every affected team had to answer the same question -- fast -- from an inventory they did not have centralised.
What The Industry Built, And What It Still Misses
The industry has converged on a handful of patterns to shorten the lookup.
Software Bills of Materials (SBOMs) are the standardized answer: a machine-readable inventory of components in a build. Generate one, diff it against a vulnerability database, see your exposure. Standards like CycloneDX and SPDX have made SBOMs a compliance expectation. The weakness is that most SBOMs are generated from declared manifests, not built artifacts, so a binary installed by a postinstall script, a package substituted during lockfile resolution, or a base image with its own undeclared contents quietly drops off the inventory. That weakness is exactly what the March 2026 attacks exploited -- WAVESHAPER.V2 in Axios ran via a post-install script, which a manifest-only SBOM would have missed entirely.
Runtime-extracted SBOMs close that gap by inspecting the actual built artifact or running image. They are slower to produce but accurate -- and crucially, they see what post-install scripts actually left behind.
Vulnerability databases have diversified past CVE. OSV.dev has become the practical cross-ecosystem standard for open source advisories, aggregating feeds from npm, PyPI, Go, Maven, crates.io and more. OpenSSF maintains a malicious packages feed specifically for known-bad publications. Exploit probability scoring and lists of actively exploited vulnerabilities decide what to prioritize when you have a backlog. A team that consults only one source consistently misses advisories that land first on another.
Kubernetes Bill of Materials (KBOM) is the newer sibling -- an inventory of workloads, images and helm releases in a cluster. Without one, "what container images are in production right now" has no authoritative answer beyond whatever the engineering team remembers.
Competent security teams know these patterns. The hard part is stitching them together into something that actually answers "am I affected" in seconds instead of hours.
What VikingCloud Does About It
We will not claim to prevent the next upstream compromise. No external tool can. What we do is collapse the lookup from hours of manual reconciliation to seconds of querying an already-built inventory.
Continuous runtime inventory. Every cloud account you connect is scanned on a recurring schedule. Container images across AWS, Azure and GCP. Virtual machine disks. Serverless bundles. Kubernetes workloads. For each, we produce a runtime-extracted SBOM by looking at the built artifact -- so postinstall binaries, base-image contents, and resolved lockfile versions all land in the same inventory. For Kubernetes, you get a downloadable KBOM per cluster that answers "what images are running, where, since when."
Continuous comparison against real-time advisory sources. The inventory is cross-checked against OSV.dev for open source advisories, OpenSSF's malicious packages feed for known-bad publications, and industry exploit-probability signals for prioritization. When a new CVE hits, the answer to "are we affected" is already in the database. You do not have to start a search; you have to read a result.
Correlated issues, not duplicate alerts. A library compromised in twelve container images across three accounts surfaces as one actionable issue, not twelve parallel tickets. Affected clouds, affected workloads, exposure signal, and the suggested remediation are on one page.
The outcome is not "we catch attacks before they happen." We do not. The outcome is that the window between CVE disclosure and "we know exactly where we are affected" shrinks from a morning to a minute. Every minute of that window saved is credentials not exfiltrated, logs not leaked, and engineers not pulled off their real work.
What This Means For Your Team
The March and April 2026 wave is not the last one. The TeamPCP and UNC1069 campaigns have made it clear that supply chain compromise is now a well-resourced, repeatable operation. Your defense is not going to be preventing the next compromise -- it will be how fast you can answer "am I affected" when it lands.
Teams that answer in minutes contain and rotate before the window closes. Teams that answer in days become a disclosure. You cannot read every commit of every package every maintainer publishes. You can know exactly what is running in your environment, what got added in the last hour, and what just got flagged by the vulnerability community. That is the fair fight, and it is one you can win.
Start your 14-day free trial to see your cloud and Kubernetes inventory in minutes, or book a demo if you would prefer we walk through the platform with your team.