Install-Time Execution

## Installing is running code Most people picture dependency installation as a download: fetch an archive, verify a hash, unpack it into a directory. In several ecosystems that picture is wrong. A package can declare **install hooks** - scripts the package manager is contractually obliged to run as part of installing that package. In the npm ecosystem the best known is `postinstall`; other ecosystems have their own equivalents, and some have none at all. Where they exist, adding a dependency to your manifest is an agreement to execute that publisher's code on your machine. This is why malicious-package campaigns reach so reliably for the install hook. The attacker does not have to convince anyone to call a function, to import a module, or to ship the package to production. They only have to be present in a resolved tree that somebody installs. ## What the hook actually gets A hook is an ordinary process started by the package manager. It inherits, by default: - **The identity that ran the install.** On a laptop, that is the developer's user account, with their SSH agent, their cloud session and their browser profile on the same disk. On a build runner, it is the job's identity. - **The environment block.** Every variable the shell or the CI job exported, including tokens injected as secrets. Log masking hides a secret's *text in the output*; it does not remove the variable from the process environment. - **The filesystem.** The source checkout, the home directory, config files, and any cache or workspace directory the job writes. - **Network access**, unless something outside the package manager stops it. - **Time, unconditionally.** The hook runs for every install of that package, on every machine, regardless of whether anything ever imports it. ## The ordering problem Dependency installation sits near the front of almost every pipeline, because everything downstream needs a resolved tree. Tests need it. Linters need it. Most dependency scanners need it too - they inspect what was actually resolved. That produces an uncomfortable ordering: **the hook has already run by the time your protective steps begin.** A scanner that flags a malicious package after installation is telling you about code that executed minutes ago. It is a detective control reporting on a completed event, not a preventive one. Changing that means deciding something *before* the install: resolving metadata without executing, quarantining or reviewing new packages at ingest, or refusing to install at all until a name and version clear a gate. ## Transitive reach A typical application resolves a direct dependency list you can read in a minute and a transitive closure of hundreds or thousands of packages that no one has read. Every one of those may carry a hook, and every hook runs with the same privileges. There is no privilege gradient by depth: the package manager does not care that a package arrived five levels down. This is why 'we review our dependencies' is usually a claim about the manifest, not about the tree. ## Ecosystem variation Install-time execution is a property of the ecosystem and even of the artifact format, not a universal law. Some package managers run nothing at install, so a fetched module sits inert until a build or an import touches it. Some run code only when a package carries a native extension that has to be compiled locally. Others run a build backend whenever the artifact is source rather than pre-built. The practical rule is to check per ecosystem rather than carrying a habit across languages, because the wrong assumption is silent in both directions. ## What this does not mean It does not mean install hooks are the only execution point. A package that runs nothing at install still runs its module body when something imports it, and can still run code during a build. Removing install hooks narrows a window; it does not turn an untrusted package into a trusted one. It also does not mean the risk is exotic. The vector is cheap, needs no interaction, works on laptops and runners alike, and executes before the machinery most teams believe protects them.