Why does a geolocation-gated destructive payload in a dependency evade CI and code review?

## Conditional sabotage Sabotage that fires unconditionally is discovered within minutes, because it breaks the maintainer's own tests. Sabotage designed to survive is **gated**: the hostile branch executes only when the running host satisfies some predicate. Predicates seen in this class of attack include the host's timezone or locale, a region inferred from an address lookup at runtime, the machine's hostname or username, the presence or absence of environment markers that indicate a build agent, whether a debugger or an instrumented runtime is attached, and whether the current date is past a chosen threshold. The consequence is uncomfortable: **the people best placed to see the payload are the people least likely to trigger it.** The maintainer's own pipeline runs in a data centre with a neutral locale. The researcher's sandbox is a fresh container in a cloud region, with CI environment variables set, which is exactly the shape the gate is written to exclude. Everyone who runs it in a lab sees benign behaviour and reports the package clean. The victims are ordinary developer and end-user machines, which is precisely where the asset sits: files and data on those machines. ## Why reading the source is weaker evidence than it feels There are two distinct failure modes, and a strong answer separates them. **Failure mode one: the reviewer read a different thing than the consumer runs.** Review happens on the repository. Consumption happens on a published artifact fetched from a registry. Nothing in the fetch inherently proves the artifact was built from the commit you read; that link is exactly what provenance exists to establish, and most ecosystems historically did not require it. A maintainer can publish an artifact containing code that never appeared in a public commit. This is why "I looked at the repo and it was fine" is a weak claim about a tarball. **Failure mode two: humans do not read everything with equal attention.** Even where artifact and source agree, sabotage prefers the parts of a diff that reviewers skim: minified or bundled output committed into the tree, generated files, test fixtures stored as binaries or base64 blobs, and scripts that run at install or build time. A gate is small — a few lines that look like feature detection, telemetry, or a locale-dependent formatting decision — and the destructive part can be assembled at runtime from pieces that individually look innocuous. Obfuscation is not required; plausibility is enough. ## What actually surfaces it No single technique is sufficient, so name several and say what each buys: - **Behavioural observation in a representative environment.** Run the install and the first use with filesystem and network activity recorded, on a host that looks like a victim rather than a build agent: real locale, real timezone, no CI markers. This will not defeat every gate, but it defeats the lazy ones and it is repeatable. - **Diff the published releases, not the tags.** Compare the previous published artifact against the new one, file by file. This catches content that exists only in the artifact — the class that source review structurally cannot see. - **Treat install-time and build-time hooks as code execution.** Any dependency whose installation runs a script has already executed arbitrary code before your tests started. Knowing which of your dependencies do this narrows where to look sharply. - **Insist on the artifact-to-source link.** Where the ecosystem supports it, requiring that a published artifact carry a verifiable statement of the source and build it came from removes failure mode one entirely, and forces sabotage back into the public commit history where review at least has a chance. - **Watch for the trigger conditions themselves.** Code in a formatting or logging library that consults the host's region, the system time in a comparison, or an environment variable that indicates automation is a signal disproportionate to its size. It is not proof, but it is where to look first. ## The judgment to demonstrate The honest position is that conditional sabotage by a legitimate maintainer is a **detection and containment** problem, not a prevention problem. You reduce the population of dependencies that can execute code at install time, you delay adoption of brand-new versions so that the community has time to find the payload, you constrain what a build or a developer machine can reach, and you keep the ability to answer "where is this version running" quickly. Claiming that a scan or a sandbox run proves a package clean is the answer that fails the question, because the whole design of a gated payload is to make exactly that claim false.