Honestly, I'd say npm install is the riskiest five seconds of your day now that typosqatting is so common. It's the potential moment a attacker's code gets a chance to run on your laptop or your CI runner.
This is not theoretical anymore. It has happened several time, at a huge scale! Some incide
In 2017, The Slovak National Security Office flagged ten fake Python packages. One fake package was urllib,instead of urllib3.
They also collected the system's data! news link
npm's official record listed 13 releases of a fake package called crossenv for the real pkg cross-env. Funfact if you today run npm view crossenv, it returns 0.0.2-security. This is apparantly a placeholder npm put in its place.
19.7% AI generated code samples had package names that doesn't exist. Yes, in 2025 USENIX Security study checked 2.23 million AI-generated code samples. If I were an atatcker, I'd register those names and wait. This is called slopsquatting.
After reading about these attacks, I'd the first thing is to have my own investigation. Here are my findings. Enjoy the blog further:
This is for developers, SREs, DevOps engineers, and the people who review their pull requests. Run these before you add a package you have not used before:
1. Exact spelling and ecosystem
Read the name letter by letter against the project's own docs. Then ask the registry if it exists.
npm view cross-env name version
python3 -m pip index versions requests
**A missing name returns E404 on npm, or No matching distribution found on pip. **
2. Publisher and repo link
Check who owns the package. Then check where it says its code lives.
npm view cross-env maintainers repository.url
curl -s https://pypi.org/pypi/requests/json | python3 -c "import sys,json; i=json.load(sys.stdin)['info']; print(i['version'], i['project_urls'])"
** 3. The Package age and publish history **
You can use this to check about the package's record-
npm view cross-env time.created time.modified
npm view cross-env time
curl -s https://pypi.org/pypi/requests/json | python3 -c "import sys,json; r=json.load(sys.stdin)['releases']; print(min(f['upload_time_iso_8601'] for v in r.values() for f in v))"
The red flags would be spotted if: (a) it's been created recently, but has a famous name (b)there's a new maintainer on an old package.
4. Weekly downloads vs. the real project
Another interesting thing that you can do while patrolling is to compare the lookalike with the project it resembles.
curl -s https://api.npmjs.org/downloads/point/last-week/cross-env
curl -s https://pypistats.org/api/packages/requests/recent
Low count, new package => normal.
Low count, fake package for a famous name => suspicious.
For your example: pypistats excludes known mirrors and updates once a day. (Ref: PyPI Stats API)
5. Install scripts
Here's my observation. Many legitimate packages have a script. I understood this from the hidden install scripts are how the September 2025 Shai-Hulud worm ran its code.
npm view esbuild scripts.postinstall
6. Lockfile diff
One new dependency can pull in many. As a developer, you must never skip reading what changed.
git diff origin/main -- package-lock.json
git diff origin/main -- package-lock.json | grep -E '^\+.*"hasInstallScript"'
npm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1 --diff-name-only
Look for names you did not expect, and any added "hasInstallScript": true. For Python, do the same with git diff requirements.txt. npm diff docs
They're merely the checks, but do not really make any install "safe". These are the following limitations:
• A real package published by a real maintainer whose account was compromised will pass all six checks.
• A lockfile poisoned before anyone noticed will look normal in a diff.
• Malicious code that lives in a package's runtime JavaScript, not in an install script, is not stopped by ignore-scripts.
I came across this blog- What Is Typosquatting? Attacks, Examples, and AI Risks. by CleanStart.
In this, you can checkout the for the org-level version of this checklist.
It's also my first blog here. Please share your love in comments!❤️