When you import food into a country, it doesn't go straight to supermarket shelves. It sits in a customs quarantine while inspectors check it for pests and contamination. Only after it clears does it enter the supply chain. Until then, it's treated as guilty until proven safe.
The Quarantine pattern applies the same discipline to digital assets you receive from outside — packages from a public registry, container images from an external registry, data files from a partner. Instead of trusting them the moment they arrive, you park them somewhere isolated, run your checks, and only then let the rest of your system touch them.
The problem
Most builds pull dependencies straight from a public registry. A typical web app has hundreds of them, and when a build asks for "the newest 2.4.x" of a library, it gets whatever was published most recently — by whoever controls the maintainer's account at that moment.
That's the trap. Attackers don't need to break into your systems if they can break into a maintainer's account and publish a poisoned version: one that works exactly like the last release, plus a hidden install script that steals secrets. Your build downloads it, runs it, ships it. The core mistake is treating "published" as "trusted": without a deliberate gate, the first thing that ever examines the new code is your own pipeline, by running it.
Step through one ordinary release and one hijacked one below, and predict where the poisoned version ends up before you see it.
How it works
You introduce two distinct locations. New external assets are copied only into a quarantine store — an isolated registry, bucket or folder that no build or service reads from. Landing there triggers a validator: an automated process that runs whatever checks the asset type demands. For packages and images that usually means verifying the signature, scanning for known vulnerabilities (CVEs), scanning for malware, and checking the licence against your policy.
If every check passes, the validator promotes the asset by copying it into the trusted feed, the only place your builds are allowed to read. If anything fails, the asset stays in quarantine, nothing downstream can see it, and an alert fires.
The key move is that builds never wait on the scan. They simply can't see anything that hasn't been promoted, so while a new release is being checked — or after it fails — they keep getting the last version that passed. Step through the same two releases with a quarantine in place, predict what the build gets, then use Compare to replay the run without it.
A hijacked release of a library you use is published at 09:00. You have a quarantine with signature and malware checks, and the release fails both. What does your 10:00 build, which asks for the newest version, get?
Make the trusted feed unwriteable except by the promoter. The pattern only holds if there's no back door — if any build can still fall back to the public registry, or any person can push straight into the trusted feed, the quarantine becomes theatre. Block direct internet access from build agents, and lock permissions so the validator is the only thing that can move an asset across the boundary.
A clean vulnerability scan doesn't mean a clean package. CVE scanners only know about problems someone has already reported, and a poisoned release is usually hours old — there's nothing to report yet. That's why the hijacked version in the scene passed the CVE check and was caught by its signature and the malware scan. Combine checks that look for known problems with checks that look for unusual ones: missing or mismatched signatures, new install scripts, and a short cooling-off period before promotion, since many hijacked releases are spotted and pulled within hours or days. And keep rescanning what's already in the trusted feed, because new vulnerabilities are found in old versions every week.
When to use it
Quarantine earns its keep whenever you ingest assets you didn't author and can't fully trust: third-party packages, externally built images, user uploads, partner data drops. It complements a gatekeeper, which screens incoming requests, by doing the same job for incoming content. When the publisher is an external party, pairing it with federated identity lets you record exactly who submitted what, so a rejected asset is traceable back to its source.
The trade-off is latency and an extra moving part: assets aren't usable the instant they arrive, and you now run and monitor a validation pipeline. Teams sometimes find that frustrating when they need an urgent fix from upstream, so give the promoter a reviewed fast-track rather than an off switch. For content you generate yourself in a trusted pipeline, the overhead buys little. But for anything crossing your trust boundary from the outside, a quarantine zone is a cheap way to keep one bad release from becoming a production incident.
Your team adds a quarantine registry with a malware scan, but builds are configured to fall back to the public registry whenever a version isn't in the trusted feed. What does that fallback do to the protection?