When the Blueprints Leave the Building

Colin Murphy | Chief Hacking Officer

For most of the last decade, breach disclosures have been read through one filter: how many records, how many people, how big a notification batch. That’s still the default frame. It’s increasingly the wrong one.

Pull up the last few weeks of disclosures and look at what actually moved.

Itron (the smart-meter vendor whose roughly 110 million connected meters sit on electric, gas, and water utility networks) filed an 8-K saying an unauthorized third party reached its internal corporate IT. Customer environments untouched. Take the day-one language at face value, set it aside, keep reading.

Trellix (the EDR/XDR vendor that came out of the McAfee Enterprise + FireEye merger) confirmed someone accessed a portion of its source-code repository. No evidence of code modification. No evidence of distribution-pipeline impact. Yet.

ALUPCO, the largest aluminum extruder in the Middle East, got hit with INC ransomware. Standard double-extortion leak set on the surface (HR, finance, customers, contracts) but for an industrial manufacturer that mix is also a proxy for design specs, tooling parameters, and the operating fingerprint of the production line.

And underneath all of it, a supply-chain hit on four SAP-ecosystem npm packages (the “Mini Shai-Hulud” name is sticking) that pulled GitHub tokens, npm tokens, AWS/GCP/Azure keys, SSH keys, Kubernetes secrets, and CI/CD env vars straight out of any build pipeline whose CI happened to run an SAP CAP install during the window. OX Security found stolen credentials in 1,200+ repos and counting.

None of these are PII breaches in any useful sense. The thing that walked out the door was the blueprint.

The closed-source moat

Open-source software is built against a stated threat model: assume the adversary has the code. That assumption shapes everything downstream. Least privilege. Hardened defaults. Scoped credentials. Signed builds, attestations, public bug bounties. Vulns surface continuously, in the open, with friendly and unfriendly researchers showing up in roughly equal proportion. The patch cadence is brutal but it’s at least honest.

Closed-source proprietary products operate under a different and mostly unspoken assumption: that the secrecy itself is a layer of defense. Firmware, EDR internals, PLC and HMI code, medical-device controllers, the contents of a semiconductor design vault. All of it sits behind the implicit promise that black-box research is hard enough, slow enough, and expensive enough that most adversaries won’t bother. That difficulty has functioned as a soft moat for decades. Vendors knew it. Customers paid extra for it. Regulators across OT, medical devices, defense, and semis have always quietly accepted it whenever the answer to “how do you know it’s secure?” was “the vendor attests.”

When the source repo, or the firmware build pipeline, or the signing infrastructure, or the design files exfiltrate to an adversary, that moat doesn’t erode. It just goes away.

The attacker isn’t reverse-engineering anymore. They’re reading. They can audit an EDR’s detection logic for bypass paths the way the vendor’s own red team would. They can fuzz a smart-meter firmware build with the symbols intact. They can trace authentication code paths in a PLC the way the engineer who wrote it did. Two weeks of work where black-box research takes two years, and weeks or months ahead of the vendor’s next patch cycle.

That’s the asymmetry. It is not abstract.

What the next eighteen months plausibly look like

Take this as a thought experiment, not a forecast.

For closed-source products whose IP has leaked, adversaries will start finding n-days before the vendors do. The patch gap doesn’t widen because vendors slow down. It widens because the offensive side just got faster, and defenders, dependent on advisories, never know to look in the first place.

OT concentration risk becomes a board conversation the way cloud concentration already is. A breach at a single hardware vendor stops being a vendor incident and becomes a quiet shadow over every utility, hospital, factory, or grid operator running that gear. “Customer environments weren’t touched” can be true today and untrue eighteen months from now, once whatever was taken finishes its trip through the secondary market.

The compliance ground shifts under the regimes that lean hardest on closed-source secrecy. OT, medical devices, defense, semis. The places where “we can’t open it up” has always been the answer to “how do we know it’s secure” are the same places IP exfiltration breaks the model. Expect SEC, NIS2, FDA, and the sector regulators to start treating vendor IP loss as a forward-looking disclosure obligation rather than a one-off embarrassment.

State actors already work this way. Criminal ecosystems follow where state actors lead; ransomware-as-a-service was the prototype for what’s coming. The plausible next step is initial-access brokers selling stolen vendor source as a precondition for targeted exploitation campaigns against that vendor’s customer base. Not creds. Source.

And attribution gets worse. When a foreign actor exploits a closed-source vuln they discovered from stolen code, the defender’s telemetry shows a novel exploit against a “patched” product. Threat intel files it under “an unknown campaign.” The connection back to the original IP theft (which may have happened years earlier, at a vendor the defender doesn’t even know is in their supply chain) almost never gets made.

None of these are hypotheticals. They’re the natural extrapolation of incidents already on the public record this month.

The simple part

The reflexive industry response is going to be more frameworks. More zero-trust slides. SBOM mandates. Post-quantum migrations. Vendor risk questionnaires that gain another dozen pages. All of these have merit. None of them is the answer to this problem.

The answer is much more boring and a lot harder to actually do.

Know exactly who and what can reach your crown jewels inside your network, and treat that surface like the front door of the business. Because it is.

Crown jewels in the specific sense: the source-code repos for the products you ship, the firmware build pipelines, the code-signing infrastructure and release artifact stores, the design files and PLM systems and tooling configs, the customer configuration databases and tenant-segregation control planes, and the credentials, tokens, and certs that let machines do any of the above unattended.

Then the unflattering question. Who and what currently has a path to each of those? Not the org-chart answer. The actual one. Every human identity, every service account, every CI runner, every contractor laptop, every third-party SaaS integration, every break-glass admin, every dormant API key from the 2019 migration that nobody got around to rotating. Every system, including the ones the inventory doesn’t know about.

Most organizations have never finished that inventory. The ones that have, find it stale by Tuesday.

What follows is well-known and unglamorous. JIT instead of standing privilege. Scoped, short-lived tokens instead of long-lived secrets. Ephemeral build environments. Hardware-backed signing keys. Separation of duties between code-write and release. Attestation on every artifact that hits production. Continuous monitoring of the access plane itself, not just the assets behind it.

For an OT asset owner, the picture gets uncomfortable fast: the historian, the engineering workstation with the PLC project files, the SCADA vendor’s always-on support tunnel that nobody has touched in three years. Every one of those is a path that was already risky enough, but with stolen vendor source code, it can end with a controller writing a value it shouldn’t.

None of this is novel. It will not be on a conference keynote slide. It is, however, the only control set that maps cleanly to the threat the recent disclosures actually represent.

The Itron, Trellix, ALUPCO, and SAP-npm incidents are not interesting because of their individual scope. They are interesting because they are early entries on what will be a long list of incidents whose real damage shows up nowhere in the breach notification. It shows up later, in the products that get exploited eighteen months out by adversaries who learned the bugs from the source.

If you read those disclosures and the only question you walked away with was “is my data on the leak site,” you read them wrong.

The right question is much simpler, and a lot harder to answer: do you actually know who, and what, can reach the things that matter most inside your own network, today, right now, by name, by system, by token, by path?

If the answer takes more than a week to get to, that’s the answer.


Frenos is the industry's first simulated OT penetration testing platform, combining digital twin technology with SAIRA, an AI reasoning agent that thinks like an adversary to reveal every attack path in your OT environment, risk-free.

Learn more at frenos.io.


Frenos will explore the impacts Mythos has in OT security in its May 11 webinar, “Blind to the Blast Radius: Why the AI Era’s Biggest Risk Is the Infrastructure Powering It,” featuring Dragos CEO Rob Lee and former NSA Director of Cybersecurity Rob Joyce. Register here.