Supply chain
Developers and tinkerers often run package installs at home on machines that also touch email, banking, family photos or work. Package managers can execute code during install. That tiny convenience gap is large enough to drive malware through.
Short version
Treat npm, pnpm, bun, pip, composer and one-line install scripts as code execution, not content download. Especially on a home machine with real accounts logged in.
Source imagery
Swipe examples
Image 1/3
Image 2/3
Image 3/3
Install path
This is why the page is blunt about package installs. The risky part is not reading a README. It is running setup inside the same user profile that holds real accounts.
Looks useful. Copy the setup command.
npm, pnpm, bun, pip or Composer resolves dependencies.
preinstall, install or postinstall can run before you inspect much.
Shell tokens, SSH keys, browser sessions and files become the prize.
The project lives away from useful secrets, so a bad install has less to steal.
A fast command from a README can still run code faster than a human can read the dependency tree.
Explain the jargon
Tap a term for the plain-English version and the practical move. No fake mystique, just the bit that changes what you do at home.
Swipe the terms one at a time below desktop width. Glossary cards can get wordy, and squeezing three of them into a tablet row helps nobody.
A package-manager hook that can run during install, such as preinstall, install or postinstall.
Do this: Check package.json and dependency changes before installing unfamiliar projects.
Convenience commands that fetch and run a package quickly. That speed is the point, and also the risk.
Do this: Run unknown tools in a container, VM or throwaway profile rather than your main daily-use account.
The set of accounts, files, tokens and sessions a mistake can reach from where you ran the command.
Do this: Keep browser sessions, SSH keys, cloud tokens and work material out of untrusted dev environments.
Read these as three short household checklists. They stay stacked below desktop width so the action text does not get squeezed.
Self-check questions
Use these quick checks to find the next practical fix. The useful answer is not perfect security; it is whether the safer path is obvious when someone is tired, embarrassed or in a hurry.
On phones, swipe one question at a time. Use the first uncomfortable answer as the next household fix, not as a lecture.
Before running npm, pnpm, bun, pip, Composer, curl|bash, npx or bunx, what can this command reach from this shell?
Good sign: The command runs in a container, VM, spare profile or low-value account with no saved browser sessions or sensitive tokens.
Watch for: A fast demo install on the daily laptop can see far more than the project folder if scripts run.
Are SSH keys, cloud tokens, package tokens, password-manager access or work credentials available in this terminal or browser profile?
Good sign: Secrets are outside the test environment, and the project cannot casually read home directories, agents or synced folders.
Watch for: Home dev machines often have the exact mix malware likes: email open, cloud synced, keys loaded and curiosity high.
What changed in package scripts, lockfiles or installer instructions since the last trusted run?
Good sign: Lifecycle hooks and new dependencies are checked before install; serious projects use frozen lockfiles.
Watch for: Postinstall output that flashes by quickly is still code execution, not harmless setup theatre.
Full guidance
A practical supply-chain risk model for home developers: what runs, why postinstall scripts matter, and how to keep hobby code away from sensitive accounts.
Swipe one guidance note at a time below desktop width. The receipt cards appear first; these notes are the deeper explanation, not a wall to skim in one go.
Note 01/03
JavaScript package managers support lifecycle hooks such as preinstall, install and postinstall. They are useful for legitimate build steps. They are also a direct path for a malicious package to run code during install, before the developer has opened the project.
Note 02/03
Home development machines are messy by design: personal email open, browser sessions saved, cloud drives synced, SSH keys loaded, family documents nearby. That makes a malicious package install more than a developer inconvenience; it can become account theft or work-adjacent exposure.
Note 03/03
Use isolation first: dev container, VM, separate OS user, throwaway test machine or at least a separate browser/profile. For serious projects, use lockfiles, frozen installs, registry controls and deliberate review of dependency/script changes. For quick experiments, assume the blast radius is the whole user profile unless you isolate it.
Scenario
Swipe one real-world mess at a time
Scenario 1/1
A developer clones a promising weekend AI tool and runs npm install on the same laptop used for work email, banking and cloud storage.
Better response
Worse habit
Treating postinstall output as harmless setup noise because the demo looked useful.