Point-in-Time Review Cannot Detect an Attack That Unfolds Over Time

# Point-in-Time Review Cannot Detect an Attack That Unfolds Over Time ## Claim A review that inspects an artifact at one moment cannot see an attack whose malicious step happens at a different moment, so review cadence — not review quality — sets what a repository can catch.  ## Evidence **Source**: [[3. Resources/Readwise/Articles/Anatomy of a WordPress.org Supply-Chain Attack The Six Ways In]] — Anchor Host > [!quote] > The repository is a snapshot. The attack is a movie. Four of the six documented entry vectors are defined by *when* they happen rather than by what the code does, and each of them presents clean at review time by design: - **Account takeover or a lapsed author domain** — the plugin was benign when reviewed. Ownership changed afterward. - **Plugin purchase** — the code passed review under one owner and shipped its payload under the next. - **A rogue update channel** — the reviewed artifact and the delivered artifact are simply not the same file. - **Dormancy plus version poisoning** — the plugin behaves for years, then ships `6.0.8` after `6.0.9` so update logic skips the clean release. Only the day-one hostile submission and the insider case are visible to a snapshot at all, and both can hide behind the concealment techniques the same investigation documents — payloads in `.dat`, `.key`, `.gzs`, and `.bin` files that PHP-oriented scans do not read, plus a `wp-config.php` loader that survives deleting the plugin entirely. The scale follows from the temporal property rather than from sophistication: one DNS lookup unwound a **13-year campaign across 44 public plugins** — a company dissolved while its malware kept shipping, because nothing in the pipeline re-asks a question it already answered once. ## Scope & conditions - **Holds** for any gate applied once to an artifact that continues to be distributed and updated afterward: plugin and extension directories, package registries, app stores, vendor security questionnaires, SOC 2 attestations. - **Requires** that distribution continue past the review. A one-shot artifact reviewed once has no gap. - **Breaks** where the delivery channel is itself verified per-fetch — checksum verification against a signed manifest turns "trust the version" into "hash the file," which is the specific countermeasure the source names. - **Weakens** where ownership transfer is itself an event that triggers re-review. Most of these vectors are ownership changes wearing different clothes. - **Does not follow** that review is worthless. It catches the day-one hostile case, which is the highest-volume one. It just cannot be the only control. ## Links - [[3. Resources/Permanent Notes/Supply-Chain Defense Tracks Bad Actors Not Bad Code]] — because extends: this says *why* actor-tracking is the right unit. Code is a snapshot property; an actor persists across the timeline the attack actually uses. - [[3. Resources/Permanent Notes/Update Signatures Prove Provenance Not Freshness]] — because extends: a signature is exactly the narrow, time-bound guarantee that these attacks route around. Valid signature, hostile new owner. - [[3. Resources/Permanent Notes/Auditing the Build Not the Install Is What Makes Personal-Scale Coverage Possible]] — because applies-in: moving the check to the build catches the reviewed-artifact-is-not-the-delivered-artifact case directly. - [[3. Resources/Permanent Notes/An Open Marketplace Turns Extensibility Into Liability Without an Owned Security Layer]] — because extends: the liability is temporal. An open marketplace is a commitment to keep vouching for things you reviewed years ago. - [[3. Resources/Permanent Notes/Practical Obscurity Is an Economic Property Not a Technical One]] — because applies-in: dormancy is practical obscurity used offensively — the plugin is not hidden, just not worth anyone's attention until it is. - [[3. Resources/Permanent Notes/Declaring Readiness Is Not Becoming Ready]] — because extends: a passed review, like a declared flag, is read as an ongoing property when it is only ever a statement about one moment. - [[3. Resources/Permanent Notes/Silent Failures Cost More Than Loud Ones]] — because extends: version poisoning is silent by construction — update logic reports success while skipping the clean release. - [[3. Resources/Permanent Notes/An Audit Trail Is Trustworthy Only When It Is a By-Product of the Work]] — because extends: a per-fetch checksum is a by-product record; a passed review is a record kept about the work. - [[WordPress Hosting Security Stack MOC]] — because applies-in. ## Implications - Ownership transfer should be treated as a security event requiring re-review, not as metadata. Four of six vectors collapse into that one control. - `wp core verify-checksums` and its plugin equivalents matter more than their obscurity suggests, because hashing the delivered file is the only check that does not trust a version number. - Version-ordering logic deserves explicit adversarial testing. "Ships 6.0.8 after 6.0.9" is a bug in the updater's assumptions, not in any plugin. - Removal is not remediation while a `wp-config.php` loader persists. Incident response that deletes the plugin and stops has verified nothing. - The generalizable audit question for any registry: what re-asks the review question, on what cadence, and what triggers it early? ## Open Questions - What is the smallest set of trigger events — ownership change, domain lapse, dormancy past N months, maintainer inactivity — that would have caught the 13-year campaign early? - The investigation found 44 public plugins against 56 seen internally. What explains the visibility gap, and is it a disclosure policy or a detection limit? - Does continuous re-scanning of the whole directory beat event-triggered re-review on cost, or is the event-driven version strictly better? ## Source - [[3. Resources/Readwise/Articles/Anatomy of a WordPress.org Supply-Chain Attack The Six Ways In]] — the six vectors, the snapshot-versus-movie framing, and the verify-checksums countermeasure