What is the difference between an install tamper attack and a runtime-compromise worm in open-source packages?

An install tamper attack modifies code during installation so malicious logic is planted before the package is widely used. A runtime-compromise worm stays dormant until execution and then spreads or activates during normal operation. The first attacks the trust boundary of package installation, while the second abuses live execution and propagation paths.

How the two attack patterns differ in where they take hold

An install tamper attack acts during installation or packaging, so the compromise is planted before normal use begins. A runtime-compromise worm waits until the package executes, then uses the live environment to spread or trigger additional behavior. That difference matters because one abuses the installation trust boundary, while the other abuses execution and propagation paths already in motion.

The install-tamper pattern is often about modifying what gets installed, what code runs from setup hooks, or what artifact users receive. The runtime worm is about what happens after the package is already present, when it can observe imports, process state, network reachability, or local privileges and then extend itself.

Because the attack point is different, defenders should expect different evidence. Installation compromise is usually surfaced through build-time integrity checks, package provenance issues, or unexpected script behavior at install time. Runtime compromise is more likely to appear as abnormal execution flow, new outbound connections, self-propagation, or activity that only becomes visible once the package is exercised.

What changes in trust, execution, and propagation

Install tamper is fundamentally a software supply-chain integrity problem. The attacker is trying to alter the package before the consumer trusts it, so the malicious logic becomes part of the initial install path or the delivered artifact itself. That means the control question is whether the package you installed is still the package you intended to install.

Runtime-compromise worms are different because they rely on live execution. Once the package is loaded, the malicious code can use the runtime context to persist, expand, or infect related environments. In open-source ecosystems, that can mean abusing package manager behavior, dependency loading, shared developer environments, CI runners, or application plugin paths.

In practice, the two attack types can overlap in outcomes but not in mechanics. Both can lead to secret theft, lateral spread, or downstream compromise, but install tamper usually wins by corrupting the entry point, while a runtime worm wins by exploiting what the package can do after execution has started.

Why the distinction matters for detection and response

The distinction changes what you inspect first. If you suspect install tampering, examine the published artifact, release process, install scripts, dependency transitive closure, and whether the package hash or provenance changed unexpectedly. If you suspect a runtime worm, focus on observed behavior in staging or production, especially process spawning, network activity, file writes, token access, and replication into adjacent systems.

Response also differs. Install tamper usually pushes you toward quarantining the release, revoking the artifact, and rotating any secrets exposed during installation or bootstrap. Runtime compromise usually requires stopping execution, containing affected hosts, reviewing propagation paths, and identifying which runtime credentials or sessions the package could reach before it was detected.

The practical takeaway is that package trust cannot be treated as a single checkpoint. You need both pre-execution integrity controls and post-execution behavioral detection, because each attack class breaks a different part of the software trust chain.

Risk and Threat Considerations

Both patterns are dangerous because open-source packages are often trusted in bulk and installed with broad access. Install tampering can silently seed malicious logic into downstream environments, while a runtime worm can turn a legitimate package into a propagation vehicle after deployment. The risk increases when packages run in build systems, developer workstations, or shared automation environments.

Failure mechanism: Install tamper succeeds when the packaging or installation step is trusted more than the artifact’s integrity, and a runtime worm succeeds when execution context gives the malicious code room to spread, call home, or abuse local privileges.

Impact: The result can be secret exposure, poisoned builds, compromised dependency chains, or lateral spread into other projects and environments, often before normal security monitoring sees the abuse.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while SLSA, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SLSA	Supply chain integrity	Open-source package tampering is a software supply-chain integrity issue.
Recommendation — Require provenance and integrity checks before accepting released packages.
MITRE ATT&CK	T1554 — Compromise Client Software Binary	Tampered packages and runtime worms abuse trusted software paths to gain execution.
Recommendation — Map package compromise indicators to trusted-software abuse and hunt for execution anomalies.
CIS Controls v8	CIS-2 — Inventory and Control of Software Assets	Package compromise defense depends on knowing what software and dependencies are deployed.
Recommendation — Maintain an inventory of approved packages and remove unapproved or suspicious dependencies.
NIST SP 800-53 Rev 5	SI-7 — Software, Firmware, and Information Integrity	Install tamper directly targets integrity of software delivered to users.
	SA-12 — Supply Chain Protection	Package tampering and wormed dependencies are supply-chain compromise scenarios.
Recommendation — Validate package integrity before installation and detect unauthorized changes to software artifacts. Apply supply-chain controls to verify package provenance and trusted sources.

Practitioner Guidance

What to verify: Treat installation-time and execution-time signals as separate evidence streams. A clean install log does not prove a package is safe at runtime, and a harmless-looking package name does not prove the artifact was not tampered with before publication.

Decision rule: If the failure is in the published artifact or install path, prioritize provenance and artifact integrity review first. If the package is already executing and showing spread behavior, move immediately to containment and runtime forensics rather than waiting for package reconstruction.

Practitioner takeaway: The best defense is not a single “safe package” assumption, but a layered model that checks what was delivered, what was executed, and whether the code can propagate beyond its original trust boundary.