You Are on the Front Line: Why "We're Not a Target" Is the Most Dangerous Myth in Your Company

Supply-chain worms, AI-weaponized attacks, and state actors funding wars with stolen cloud credentials have converged into one phenomenon. On a digital battlefield there are no civilians — and as engineers, we are on the front line.

A digital world map of network nodes with national borders dissolved, a blast-radius ripple propagating from a single node across continents

If you’ve been following the news this year, you’ve probably noticed that several things are happening at once. Package registries are being weaponized — npm has seen wave after wave of self-propagating worms that steal credentials. GitHub’s own infrastructure and trust mechanisms have been abused to distribute malware. Artificial intelligence is writing more code than at any point in history — and is simultaneously being used to build the attacks. There are wars in Ukraine and the Middle East. Cartels and state security forces fight in the open. Failed states like North Korea hack openly, as a matter of national budget.

It is tempting to file these as separate headlines. They are not. They are the same phenomenon seen from different angles: the cost of attacking has collapsed, and the distance that used to protect you no longer exists.

The 20th-century mental model is dead

For most of the last century, a war on the other side of the world did not touch you. It was “too far away.” Geography was a shield. A conflict in another hemisphere was somebody else’s problem, separated from your business by an ocean and a border.

The internet erased the borders. AI mass-multiplied the blast radius.

An attacker no longer needs to be near you, speak your language, or even know you exist. Automated tooling — increasingly written and operated with AI — scans the entire internet continuously, tries billions of stolen credential pairs, and crafts convincing phishing at industrial scale. AI became the thermonuclear weapon of digital war: it doesn’t make attackers smarter so much as it makes attacks infinitely cheaper to launch and infinitely wider in reach. Digital wars are a real battlefield, and that battlefield has no overseas edition. It runs on the same cloud, the same registries, the same dependencies you ship to production.

“We’re not a target” is the dangerous fallacy

Here is the sentence I hear from business owners, CTOs, and CISOs in our region, and it worries me every time: “That’s something Google, Microsoft, or Apple worry about, because that’s over there in the US or Europe. We’re too small to be a target.”

That is exactly backwards.

A group of North Korean operators will not hesitate for a second to steal your identity, extract your AWS credentials, and spin up thousands of high-core virtual machines to mine cryptocurrency — crypto that funds Kim’s missiles. They don’t care what your company does, where it is, or how small it feels. To an automated credential-stealer, you are not a company with a mission. You are a valid set of cloud keys.

Saying “we’re not a target” on this battlefield is like standing on the front line and announcing you’re going out to play ball, because you are not a military objective. War is war. On a digital battlefield there are no civilians — only systems that are hardened and systems that are not.

We’ve seen it up close

This is not theory for us. A company we work closely with had its cloud credentials stolen. Over a single weekend, the attacker used those keys to spin up roughly 3,600 virtual machines of 128 cores each and pointed every one of them at crypto mining. By Monday the bill exceeded US$60,000 — charges the company was liable for. One of our engineers spent the entire weekend regaining control of the account, shutting it down machine by machine, and we worked with AWS afterward to negotiate the bill down. The damage was contained, but we felt it in real time.

Anatomy of the cascade: one forgotten door without MFA leads to stolen credentials, thousands of VMs, and a crypto-mining bill

The entry point was not a Hollywood zero-day. It was one forgotten door: a single set of credentials that should have been deactivated, without multi-factor authentication. The kind of door any organization can leave open without noticing — which is precisely the point. The attacker didn’t break a wall. They walked through a door nobody was watching.

It’s personal for me too. Years ago — back in 2019 — credentials for a SaaS I used were compromised. The vendor never told anyone. Because I had reused that password elsewhere, the attackers immediately tried it against my Gmail, my LinkedIn, my other accounts. What saved me was a login alert that arrived in time. Since that day I’ve used a different password for every service, stored in a password manager (Bitwarden), with MFA everywhere. That was years ago, and the threat has only accelerated since.

Why it’s worse now, technically

Three shifts compound each other:

AI collapsed the cost of attacking. Cred-stuffing, phishing, and vulnerability discovery that once required skilled human effort now run automatically, at scale, around the clock, against everyone — including you.

The supply chain turned your dependencies into an attack surface. This is the part too many teams underestimate. The npm worms were not the finale — they were the tip of the iceberg. It started with npm because JavaScript has one of the most widely used dependency ecosystems on earth, which means the biggest blast radius. The same model threatens every package manager behind it: Composer (PHP), Go modules, PyPI (Python), and more.

And it’s no longer hypothetical for PHP. On May 22, 2026, a supply-chain attack hit the popular laravel-lang Composer packages — 233 compromised versions — by abusing GitHub’s tag system to point version tags at a malicious fork. The payload was a two-stage credential stealer that harvests exactly what you’d fear: AWS, GCP, and Azure keys, SSH keys, browser-stored passwords, crypto wallets, Docker and Kubernetes credentials. A single poisoned dependency, pulled by composer update, reaching directly for your cloud keys — the same keys that, in the story above, became 3,600 mining machines.

And consider the root of trust itself. When a platform as central as GitHub is breached and reassures everyone that “only our internal repositories were affected — customer repos are safe,” that should not fully calm you. Those internal repositories are the software that runs the platform every one of us depends on. How long before a bug discovered in GitHub’s own internal code is weaponized to reach customer repositories — and supply-chain attacks live not in a handful of poisoned packages, but in every repo? The boundary between “their internal systems” and “your code” is far thinner than the reassurance suggests.

Credential reuse plus missing MFA is the actual front door. Not the cinematic exploit — the boring, human gap. Most breaches walk in through a reused password, a leaked token, or an account no one deactivated.

When “stay current” stops being safe

There is a deeper rupture here, almost philosophical. For the entire history of software, the cardinal rule was simple: stay current — the latest version is the safest, because it carries the newest patches. Supply-chain attacks invert that rule. When the attack lives inside a freshly published version — a poisoned laravel-lang release, a trojanized npm update — pulling the latest is precisely how you get compromised. For the first time at scale, being up to date can be the thing that makes you vulnerable. And it doesn’t stop at small libraries: the same logic reaches the Linux kernel and the largest FOSS projects on earth — the code running quietly underneath almost everything. When the foundation itself is a potential vector, “just update” is no longer a strategy on its own.

What this reveals is uncomfortable but clarifying. In a supply-chain war, security stops being a product you buy and becomes a question of alliances and circles of trust — the same way trust works in wartime. Who maintains this package? Who signed this release? Whose provenance do you actually verify? Which dependencies earned your trust, and which did you adopt because they were convenient? Defending modern software means curating that circle deliberately: pinning and reviewing dependencies, verifying signatures and provenance, minimizing what you pull in, and knowing the humans behind the code you run.

As engineers, we are on the front line

This is the shift I want every owner, CTO, and CISO to internalize: digital security stopped being “Google, Microsoft, and Apple’s problem over there.” If you write, deploy, or operate software, you are on the front line, whether you volunteered or not. Preparing and training for it is not optional hygiene anymore; it’s the job.

I don’t say this to frighten anyone. I say it because it is going to get worse before it gets better, and because the difference between being affected and being collateral damage is preparation. It is a matter of days — not years — before we start seeing cases very close to home: people we know hit by breaches, scams, and digital theft.

The good news is that the discipline that protects you is largely unglamorous and within reach today: multi-factor authentication everywhere, a unique password per service in a password manager, least-privilege access, immediate deactivation of departed employees’ accounts, regular credential audits, dependency pinning and review, and infrastructure described as code you can actually audit — no black boxes, nothing only one person understands. That last principle is what we call the Glass Box, and it exists precisely so that when the battlefield reaches you, you can see every door and know which ones are closed.

The war is digital, and it’s already here. The only real question is whether you’ll meet it prepared.

Ready to Get Started?

Let's discuss how we can help you achieve your goals.

Contact Us