Full Containment – Do we have to treat software like Ebola?

The need to contain software and systems is likened to containing diseases like Ebola and COVID due to their potential threats. Examples of security risks include repojacking, Docker malware, and cloud breaches.

A Level-4 biocontainment lab has sealed doors, negative air pressure, and staff in full hazmat suits before anyone so much as touches the sample. Nobody argues that’s overkill. Nobody skips a step because the deadline is tight.

Now compare that to how you install your last dependency. pip install. docker pull. npm install. No suit, no seal, no second thought.

I ended up thinking about that gap because of a conversation with a friend the other day. We were talking about system design, going back and forth on where things tend to go wrong, and at some point he just said it outright: we need to contain systems and software like Ebola. I laughed the first time he said it. Then I sat with it for a minute, and it stopped being funny.

Viruses, like Ebola and COVID-19, and software share the same defining trait: you don’t know if it’s a threat until it’s too late. We contain diseases precisely because they’re highly contagious and can kill before symptoms show. COVID-19 didn’t just make people sick — it halted civilization for a year. Software has that same blast radius now, and almost nobody treats it that way.

How do we deal with Software?

So, how do we deal with software? We install it because we need it, but let’s consider some examples:

• Programmers use libraries directly from GitHub — if they’re not careful, they could end up using a compromised repository.
• CI/CD pipelines often pull from Docker Hub — this can lead to using malicious binary blobs hosted there.
• Company data is moved to the cloud — Microsoft and other cloud providers are under constant attack. The question isn’t whether they are vulnerable but rather, can we be certain that something won’t become an issue?

It’s paranoid. It’s also correct — recent years have produced a long, growing list of security breaches and supply chain attacks. Vigilance about security, safety, and privacy isn’t optional anymore; it’s the baseline.

Security, Safety, and Privacy

We all understand these concepts to some extent:

• Privacy — the right not to be observed.
• Security — measures taken to prevent bad things from happening.
• Safety — measures taken in case something bad happens.

These goals can sometimes contradict each other. For example, when traveling by airplane, you give up some privacy for security by revealing your name and presenting ID at the terminal.

So how do we handle this with computers?

In the digital world, encryption like SSL ensures the privacy of data in transit, but this applies to both you and potential attackers.

Can a computer secure/defend itself?

No — not reliably, and not by design. Every current architecture assumes the software running on it isn’t actively hostile to itself. That assumption is the vulnerability.

What can we do?

We need to treat every piece of software and every system like Ebola. You wouldn’t let a stranger walk into a BSL-4 lab without a suit, training, and a reason to be there. You let an unpinned GitHub Action pull whatever a maintainer pushed last night straight into production.

1. Isolation — properly isolate systems in the network.
2. Partition infrastructure — for example, authentication systems should be partitioned so a breach has limited reach.
3. Use well-known communication channels — ensure communication is clear and trusted.
4. Diversify operating systems — don’t rely solely on Linux or Windows.
5. Simplify software — the OpenBSD project’s doas utility does the same job as sudo, but with only around 300 lines of code compared to sudo’s 3000+.

None of this is exotic. It’s the same discipline a biocontainment lab applies as a matter of routine — we’ve just never decided software deserves the same seriousness.

The supply chain attack on Linux systems via systemd and XZ belongs in this story too: a single maintainer position, quietly captured over years, became a backdoor into a huge share of the internet’s servers. That was 2024. Here’s what’s happened since.

2026 Update: The Same Logic Now Applies to AI

Since this was first written, the containment argument has only gotten stronger — and the same pattern now clearly extends to AI agents and tooling, not just traditional software.

Supply chain attacks escalated and started overlapping:

• Between April 21–23, 2026, three separate campaigns hit npm, PyPI, and Docker Hub within 48 hours — the same “it spreads across ecosystems before anyone notices” pattern the Ebola comparison was making in the first place.
• In May 2026, GitHub confirmed a breach of roughly 3,800 internal repositories traced back to a compromised VS Code extension in the TanStack npm ecosystem (attributed to the “TeamPCP” group), which also hit UiPath, OpenSearch, and Guardrails AI packages.
• In March 2026, attackers compromised Aqua Security’s own Trivy vulnerability scanner and used it to push malicious images to Docker Hub carrying a credential harvester for cloud keys, SSH keys, and Kubernetes tokens — malware distributed by a security tool.
• Microsoft’s Storm-2949 incident (May 2026) showed a single compromised identity escalating into a cloud-wide breach purely through stolen credentials — no exploit, no payload, no malware at all.

And now: AI as a new attack surface. The same containment principle applies just as much to AI agents and coding assistants:

• Prompt injection is now the dominant agentic-AI risk. OWASP’s 2026 LLM Security Report recorded a 340% surge in prompt injection attacks — and unlike classic vulnerabilities, there is no reliable way for an LLM to distinguish trusted instructions from untrusted content it merely reads. It’s the same isolation problem this post has been about all along, just moved up a layer.
• MCP tool poisoning is the new repojacking: adversarial instructions hidden in a tool’s description or a config file (a poisoned .cursorrules, CLAUDE.md, or MCP server) can get an otherwise well-behaved agent to exfiltrate data or run arbitrary commands, simply because the agent treats that text as trusted context.
• The fix is the same containment logic as always: don’t give an agent broader access than the single task requires, treat anything an agent reads (files, tool descriptions, web content) as untrusted input, and assume any given AI tool or MCP server could be the compromised link — because eventually, one will be.

Ebola gets a sealed room and a hazmat suit. Your CI/CD pipeline gets a green checkmark. That’s not caution — that’s the absence of it.

Related Content

Repojacking

• Millions of Malicious Repositories Flood GitHub
• Hackers Abusing GitHub to Evade Detection
• Critical GitHub Vulnerability Exposes…
• Repojacking Attack on GitHub Repositories
• GitHub links repo breach to TanStack npm supply-chain attack (2026)
• Disrupting supply chain attacks on npm and GitHub Actions — The GitHub Blog (2026)

Docker spreads Malware

• Attacks on Docker with Millions of Malicious Repositories Spread Malware and Phishing Scams
• Trivy Hack Spreads Infostealer via Docker, Triggers Worm and Kubernetes Wiper (March 2026)
• No Off Season: Three Supply Chain Campaigns Hit npm, PyPI, and Docker Hub in 48 Hours (April 2026)

Clouds

• Microsoft Azure Hit With the Largest Data Breach in Its History
• Microsoft, Brad Smith on China Hack, Congress
• How Storm-2949 turned a compromised identity into a cloud-wide breach — Microsoft Security Blog (May 2026)

AI Hacking

• Prompt injection still drives most agentic AI security failures in production — Help Net Security, on OWASP’s 2026 LLM Security Report
• Microsoft Warns Poisoned MCP Tool Descriptions Can Make AI Agents Leak Data (June 2026)
• MCP Tool Poisoning: Adversarial Hijacking of AI Agent Workflows — Cloud Security Alliance

APIs / Storage

Jails

• Containers, Zones, Jails, VMs

Defining Security: The Difference Between Safety & Privacy

• Defining Security: The Difference Between Safety & Privacy — Lysa Myers, Security Researcher, ESET
• Data Security & Privacy: The Risks of Not Playing by the Rules
• Deciphering the GDPR: What You Need to Know