BLUF: Three incidents surfaced in the same week: a pharmaceutical company breached through cloud infrastructure it didn’t operate, a supply chain attack that passed every cryptographic check built to catch it, and a multi-state utility campaign that succeeded partly because the victims didn’t know what assets they had. None of these organizations failed a compliance audit. All three got breached anyway. The distance between those two facts is the story.

Most security programs are built to defend a boundary the organization can see and control: its own network, its own endpoints, its own cloud tenant. That boundary still matters. But an increasing share of the incidents that actually hurt organizations are starting somewhere else, in infrastructure a vendor operates, a dependency a maintainer controls, or an asset nobody remembered was still running. Three cases from the past few weeks make the pattern hard to ignore.

The Breach Amgen Didn’t Cause and Can’t Avoid Owning

Amgen disclosed that attackers exfiltrated proprietary data and protected health information, not from its own systems, but from third-party-managed cloud environments. The company caught the activity in July. Manufacturing, supply, and financial systems were untouched. The likely vector, still publicly unconfirmed, points to compromised single sign-on credentials, a pattern consistent with the group known as ShinyHunters.

Here is the part worth sitting with: Amgen still faces HIPAA notification obligations and SEC disclosure requirements, even though it did not directly control the infrastructure that was breached. Data ownership and data liability are not the same question, and they don’t travel together just because a vendor is holding the storage.

For any organization that has moved sensitive data into a partner’s environment, whether through a cloud provider, a SaaS platform, or an outsourced data function, this sets a precedent worth reading closely. Regulators and shareholders are not going to ask who operated the servers. They’re going to ask who owned the data. Vendor contracts that don’t clearly answer that question in advance are answering it after a breach instead, which is the most expensive time to find out.

This is also where technical due diligence earns its keep. Assessing a partner’s compliance certifications tells you what they’ve promised to do. It doesn’t tell you what happens when their SSO gets compromised, or whether your data sits somewhere their contract lets them store it that you never approved. Those are different questions, and only one of them gets asked in a typical vendor questionnaire.

The Supply Chain Attack that Passed Every Check Designed to Catch it

A compromised GitHub account controlling a handful of popular caching libraries, Keyv, Cacheable, flat-cache, and file-entry-cache, led to malicious commits across 444 packages and 1,381 versions. Combined, those packages account for roughly two billion monthly installs. The payload ran automatically during a standard npm install, harvesting CI/CD tokens, AWS credentials, Kubernetes configs, and crypto wallets from every environment that pulled it in.

The technical detail that separates this from a routine credential leak is the command infrastructure. The attackers used a blockchain-directed command channel built on Ethereum smart contracts, letting them rotate their infrastructure without ever touching or recompiling the malware itself. Standard indicators of compromise, the kind built from known-bad IP addresses or file hashes, are far less useful against a system designed to move without changing its code.

And this is the detail that should sit uncomfortably with any team relying on package signing as a control: the cryptographic provenance checks all passed. The malicious code genuinely came from the legitimate build pipeline, because the pipeline itself had been compromised upstream. A signature verification answers one question, whether a package came from where it claims to have come from. It does not answer whether that source can be trusted, because in this case the source was real and still dangerous.

Organizations that treat “our dependencies pass provenance checks” as equivalent to “our dependencies are safe” have a gap between those two statements that this attack walked straight through.

The Utilities that Couldn’t Audit Assets They Didn’t Know Existed

A coordinated campaign against water systems escalated from more than 30 Minnesota utilities to at least 12 states. Attackers exploited unauthenticated access on port 44818 to reach Rockwell Automation MicroLogix programmable logic controllers, changing credentials and altering the ladder logic that governs physical equipment. Forescout’s research identified 4,407 exposed devices globally, 65 percent of them in the United States.

Two details matter more than the headline count. First, the mode nearly every small water utility runs accepts CIP connections without authentication at all, which means the vulnerability wasn’t a misconfiguration at any single utility so much as a default nobody had reason to question. Second, 70 percent of the exposed US controllers sit on mobile carrier networks, a pattern that points to shared managed-service-provider configurations replicating the same weakness across utilities that have never spoken to each other.

Underneath both of those is a harder problem: these utilities cannot secure assets they don’t know exist. Investigators found abandoned servers dating to 2019, still carrying valid certificates and forgotten DNS records, sitting quietly inside networks nobody had inventoried in years. An asset inventory that misses ghost infrastructure isn’t a weak security posture. It’s a blind spot that makes posture impossible to assess accurately in the first place.

What this Changes About How an Assessment Gets Scoped

Put the three cases next to each other and a single shape emerges. Amgen was exposed through infrastructure a partner operated. The npm ecosystem was exposed through a dependency chain whose trust model assumed a compromised source couldn’t produce a validly signed package. The water utilities were exposed through assets nobody had cataloged and configurations replicated silently across a shared vendor’s client base. In each case, a standard audit scoped to the organization’s own environment would have missed the actual point of failure.

That has a direct implication for how assessments and questionnaires get built. A vendor risk questionnaire that asks about certifications and policies is asking a different question than “what happens to our data if your SSO is compromised.” A dependency audit that checks package signatures is asking a different question than “what happens if the legitimate source itself is compromised.” An asset inventory built from what IT remembers deploying is asking a different question than “what is actually reachable on this network right now.”

None of this means compliance work is wasted effort. Examiner findings, board reporting, and audit trails all serve real purposes, and organizations that skip them create their own problems. But compliance answers the question “did we follow the process we said we’d follow.” It was never designed to answer “would this stop someone who is actually trying to get in,” and the gap between those two questions is exactly where Amgen, the npm ecosystem, and a dozen state’s worth of water utilities all got hit.

The organizations that come out ahead of this pattern aren’t the ones with the cleanest compliance reports. They’re the ones asking what an attacker would actually find if they started from outside the boundary the audit was scoped to, in the vendor’s cloud, in the dependency tree, in the corner of the network nobody’s looked at since 2019. That’s a harder question to answer, and a much more useful one.