Package Scanning Rules Library

Why it matters

A binary cannot be code-reviewed from the tarball. It is the easiest place to hide a stealer or loader, and scanners that only read text never open it.

How to verify manually

• npm pack <pkg>@<version> --ignore-scripts && tar -tzf <pkg>-<version>.tgz | grep -viE "\.(js|cjs|mjs|ts|json|md|txt|map)$"
• tar -xzf <pkg>-<version>.tgz && find package -type f -exec file {} + | grep -E "ELF|PE32|Mach-O"
• sha256sum the file and look the hash up in a malware-intelligence service before executing anything.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Native-addon packages ship compiled code on purpose (esbuild, swc, sharp, better-sqlite3, python wheels with compiled extensions). Rule out: the binary is documented, comes from the vendor's own project, matches its release assets by hash, and the package is on the expected platform-specific optionalDependencies layout.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1129: Shared Modules
• MITRE ATT&CK T1027: Obfuscated Files or Information
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

A native addon runs with full process privileges and can do anything the user can. For a utility library it is unneeded risk and a convenient way to hide behaviour from JavaScript-level review.

How to verify manually

• tar -tzf <pkg>-<version>.tgz | grep -E "\.node$|binding\.gyp"
• file package/**/*.node; strings -n 8 <file>.node | grep -iE "http|/\.ssh|/etc/|token"

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Performance-critical packages (crypto, image, database drivers) legitimately use addons. Rule out: the README explains why, the source is in the repository, and prebuilt files are downloaded from the vendor's release assets.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1129: Shared Modules
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Payloads hidden in assets avoid text-based scanning. Unpacking and running them at install or first use is a loader technique.

How to verify manually

• tar -tvzf <pkg>-<version>.tgz | sort -k3 -n | tail -15 # biggest files first
• file package/<suspicious>; binwalk package/<suspicious> # embedded data?
• grep -rnE "readFileSync\(.*(\.dat|\.bin|\.zip|\.png|\.woff)|unzip|extractAll|zlib\.(inflate|gunzip)" package

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

WASM modules, bundled fonts, databases of timezones or locale data and compressed lookup tables are normal. Rule out: the asset type matches its extension (file agrees), it is read by the feature that needs it, and nothing executes its content.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1027: Obfuscated Files or Information
• MITRE ATT&CK T1140: Deobfuscate/Decode Files or Information
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Disguising an executable as an image or text file defeats reviewers who skim the file list and tools that classify by extension.

How to verify manually

• tar -xzf <pkg>-<version>.tgz && find package -type f \( -name "*.png" -o -name "*.jpg" -o -name "*.txt" -o -name "*.css" \) -exec file {} + | grep -vE "image|text"

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Some images and CSS files embed data URIs or have unusual headers, and ZIP-based formats (.docx, .jar) carry PK headers by design. Rule out: the extension and content type agree for that format.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1036.005: Masquerading: Match Legitimate Name or Location
• MITRE ATT&CK T1027: Obfuscated Files or Information

Why it matters

A new workflow runs with the repository's secrets. Adding one (often named innocuously) is a way to exfiltrate CI secrets and persist after the package is removed.

How to verify manually

• grep -rnE "\.github/workflows|\.gitlab-ci|\.circleci|Jenkinsfile|azure-pipelines" package
• git log --all --diff-filter=A --name-only -- .github/workflows # new workflow files you did not add

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Scaffolding tools (create-*, generators, init commands) write workflow files, on explicit command and into the new project. Rule out: it runs only from a user-invoked generator, not an install hook or import.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• OWASP Top 10 CI/CD Security Risks (Dependency Chain Abuse, Poisoned Pipeline Execution, Insufficient Credential Hygiene)
• GitHub docs: security hardening for GitHub Actions

Why it matters

Inside a CI run the process can mint cloud credentials, read repository secrets and publish packages. A dependency that checks it is in CI and reaches for these is targeting the pipeline, not the developer.

How to verify manually

• grep -rnE "ACTIONS_ID_TOKEN|ACTIONS_RUNTIME|GITHUB_ACTIONS|process\.env\.CI\b" package
• Run builds with step-security style egress monitoring or an allow-listed network, and review any unexpected destinations.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Test frameworks and reporters read CI to adjust output (colors, reporters, retries). Rule out: only the CI boolean is read and no token variable is touched.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1528: Steal Application Access Token
• MITRE ATT&CK T1552.001: Unsecured Credentials: Credentials In Files
• OWASP Top 10 CI/CD Security Risks (Dependency Chain Abuse, Poisoned Pipeline Execution, Insufficient Credential Hygiene)
• GitHub docs: security hardening for GitHub Actions

Why it matters

A fork's pull request can then execute with the project's secrets. This is a common route by which a package's release pipeline is hijacked and a malicious version is published legitimately.

How to verify manually

• In the repository: grep -rn "pull_request_target" .github/workflows
• Look in the same workflow for actions/checkout with ref: ${{ github.event.pull_request.head.sha }} followed by npm install, npm test or any script step.
• Check the workflow's permissions: block and whether secrets are passed to that job.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

pull_request_target is safe for labelling or commenting workflows that never check out or run PR code. Rule out: the job does not execute code from the PR, and permissions are read-only.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• GitHub Security Lab: preventing pwn requests
• OWASP Top 10 CI/CD Security Risks (Dependency Chain Abuse, Poisoned Pipeline Execution, Insufficient Credential Hygiene)
• GitHub docs: security hardening for GitHub Actions

Why it matters

A static token can be stolen and used from anywhere. Mutable action references let someone else change what your release job runs. Both weaken the guarantee that a release came from reviewed code.

How to verify manually

• In the repository: grep -rnE "NPM_TOKEN|PYPI_API_TOKEN|NODE_AUTH_TOKEN|id-token: *write|uses: .*@(main|master|v[0-9])" .github/workflows
• npm view <pkg>@<version> dist.attestations # trusted publishing produces attestations
• git log -p -- .github/workflows | head -200 # recent edits before the release

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Plenty of maintainers still use tokens, and tag-pinned actions are common. This is a hygiene note about how much to trust the release, not a malicious indicator.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• npm docs: generating provenance statements
• PyPI docs: trusted publishers
• OWASP Top 10 CI/CD Security Risks (Dependency Chain Abuse, Poisoned Pipeline Execution, Insufficient Credential Hygiene)
• GitHub docs: security hardening for GitHub Actions

Why it matters

Attackers who obtain a developer token often use the code host itself as a drop box and to run their workflows. Seeing that artefact on the maintainer's account is evidence the token was used by someone else.

How to verify manually

• gh repo list <owner> --limit 100 --json name,createdAt,visibility
• gh run list --repo <owner>/<repo> --limit 20
• Review the account security log and token list; revoke and rotate every token that could have been exposed.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Maintainers do create test repositories and scheduled workflows. Rule out: you recognise each item, and creation times line up with known activity.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1078: Valid Accounts
• MITRE ATT&CK T1528: Steal Application Access Token
• OWASP Top 10 CI/CD Security Risks (Dependency Chain Abuse, Poisoned Pipeline Execution, Insufficient Credential Hygiene)

Why it matters

Libraries read the specific variables they document (NODE_ENV, DEBUG, HTTPS_PROXY). Enumerating the whole environment sweeps up cloud keys, CI tokens and API secrets without having to know their names.

How to verify manually

• grep -rnE "Object\.(keys|entries|values)\(process\.env\)|JSON\.stringify\(process\.env\)|\.\.\.process\.env" package
• grep -rnE "os\.environ(\.copy\(\)|\)|\.items)" <extracted-python-package>

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Config loaders (dotenv, cross-env, env-cmd), test runners and build tools pass the environment to child processes. Rule out: the data never goes to a network call or a file outside the project, and the package is a known tooling dependency.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1552.001: Unsecured Credentials: Credentials In Files
• MITRE ATT&CK T1005: Data from Local System
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Reading secrets and then talking to the network is the definition of an infostealer. The sink is the proof: it separates "uses an API key" from "ships every key somewhere".

How to verify manually

• grep -rnE "process\.env" package | head -50 # then follow each hit to see whether it reaches a request
• Run the package inside a network-isolated VM or container with a canary secret in the environment (CANARY_TOKEN=pcx-test) and watch egress with tcpdump or a deny-all firewall log.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

SDKs read an API key from the environment and send it as an Authorization header to their own documented API. Rule out: the destination host belongs to the vendor that issued that key, and only that one variable is read.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

Seen in the wild

crossenv (2017): a typosquat of cross-env that sent environment variables to a remote server.

References

• MITRE ATT&CK T1552.001: Unsecured Credentials: Credentials In Files
• MITRE ATT&CK T1041: Exfiltration Over C2 Channel
• MITRE ATT&CK T1567: Exfiltration Over Web Service
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Publish tokens let an attacker push trojanised releases of every package the victim maintains, which is how one compromise becomes dozens. Registry credentials are the pivot of self-propagating supply chain worms.

How to verify manually

• grep -rniE "\.npmrc|\.yarnrc|\.pypirc|_authToken|NPM_TOKEN|NODE_AUTH_TOKEN|TWINE_PASSWORD" package
• npm token list # on your own account: revoke anything you do not recognise

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Publishing and release tools (semantic-release, np, changesets, twine wrappers) read these on purpose. Rule out: the package is a documented release tool, you installed it for that purpose, and the read is not followed by a request to a host other than the registry.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

Seen in the wild

eslint-scope 3.7.2 (July 2018) was published with stolen maintainer credentials and its install script sent the user's .npmrc to a remote host.

References

• MITRE ATT&CK T1552.001: Unsecured Credentials: Credentials In Files
• MITRE ATT&CK T1528: Steal Application Access Token
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Cloud keys turn a developer machine into an account takeover and a billing event. They are high-value, stored in well-known paths and rarely rotated, so stealers go straight to them.

How to verify manually

• grep -rnE "\.aws|\.azure|gcloud|\.kube|\.docker/config|AWS_SECRET|GOOGLE_APPLICATION_CREDENTIALS" package
• Check the package category: an SDK for that cloud has a reason, a string utility does not.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Official cloud SDKs, Terraform/CDK helpers and deployment CLIs read these files by design. Rule out by confirming the package is the vendor's own (scope, publisher, repository) and the paths are read through the SDK's documented credential chain.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1552.001: Unsecured Credentials: Credentials In Files
• MITRE ATT&CK T1552.005: Unsecured Credentials: Cloud Instance Metadata API
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Private keys give lateral movement into servers and source hosting. known_hosts and config map where those keys work, so the attacker knows what to try.

How to verify manually

• grep -rnE "\.ssh|id_rsa|id_ed25519|id_ecdsa|known_hosts" package
• In a sandbox with a decoy key (ssh-keygen -f ~/.ssh/decoy), watch file access: sudo strace -f -e trace=openat -p <pid> or auditd on ~/.ssh.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

SSH client libraries (ssh2, node-ssh, paramiko) and git-over-ssh tooling read keys, but only a path the caller passes in. Rule out: the path is a function argument, not a hardcoded home-directory location.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1552.004: Unsecured Credentials: Private Keys
• MITRE ATT&CK T1005: Data from Local System
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Browser stores hold session cookies and saved passwords; wallet files hold funds. Neither is reachable by a legitimate library, so the path strings are close to proof of intent.

How to verify manually

• grep -rniE "Login Data|Local State|Cookies|logins\.json|wallet\.dat|keystore|Exodus|Electrum|Local Extension Settings" package

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Browser automation and test tooling (puppeteer, playwright, selenium wrappers) reference profile directories for their own throwaway profiles. Rule out: the path is a temp profile the tool creates, not the user's real profile directory.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1555.003: Credentials from Password Stores: Credentials from Web Browsers
• MITRE ATT&CK T1005: Data from Local System
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

A source-control token lets an attacker read private repositories, alter workflows and publish from CI. It is the usual next step after a developer-machine compromise.

How to verify manually

• grep -rniE "GITHUB_TOKEN|GH_TOKEN|GITLAB_TOKEN|git-credentials|gh auth token|credential fill|hosts\.yml" package
• Review the account audit log for token use from unfamiliar IPs after an install of the package.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Release and Git tooling (octokit wrappers, semantic-release, changesets) legitimately use these. Rule out: documented purpose, a token passed in by the caller, and requests only to the code host.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1528: Steal Application Access Token
• MITRE ATT&CK T1552.001: Unsecured Credentials: Credentials In Files
• OWASP Top 10 CI/CD Security Risks (Dependency Chain Abuse, Poisoned Pipeline Execution, Insufficient Credential Hygiene)

Why it matters

The compromise does not need to touch the target package's own code. Adding one small dependency moves the payload one hop down, where reviewers rarely look.

How to verify manually

• diff <(npm view <pkg>@<old> dependencies --json) <(npm view <pkg>@<new> dependencies --json)
• npm view <new-dep> time.created maintainers dist.unpackedSize

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Routine refactoring adds helper dependencies all the time. Rule out: the dependency is established, widely used, and the commit adding it is visible, reviewed and explained.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

Seen in the wild

event-stream (2018): flatmap-stream was added as a new dependency in a minor release.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• OWASP Top 10 2021 A06: Vulnerable and Outdated Components
• OWASP Top 10 CI/CD Security Risks (Dependency Chain Abuse, Poisoned Pipeline Execution, Insufficient Credential Hygiene)

Why it matters

Anything outside the registry skips its integrity metadata and takedown process, and a branch reference can change after review. Git dependencies can also run a prepare script at install.

How to verify manually

• npm view <pkg>@<version> dependencies --json | grep -E "git|http|file:|github:"
• jq ".dependencies, .devDependencies, .optionalDependencies" package.json | grep -E "git|http|file:|github:"

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Teams pin forks or unreleased fixes via git on purpose. Rule out: the reference is a full commit SHA on a repository you control or trust, not a branch or tag.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• npm docs: package.json
• npm docs: package-lock.json
• pip docs: secure installs (hash-checking mode)
• OWASP Top 10 2021 A08: Software and Data Integrity Failures

Why it matters

Not malicious, but it turns any future compromise of that dependency into an automatic install in your next build.

How to verify manually

• jq ".dependencies, .devDependencies" package.json | grep -E "\"(\*|latest|>=)"
• npm ci # installs exactly what the lockfile pins

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Libraries (not applications) legitimately use ranges; lockfiles in the consuming application pin them. Rule out: your application commits a lockfile and installs with npm ci.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• npm docs: package-lock.json
• OWASP Top 10 2021 A06: Vulnerable and Outdated Components

Why it matters

The lockfile is your pin. If an artifact changes under the same version, or resolves to a non-registry host, what you install is no longer what you reviewed.

How to verify manually

• git diff -- package-lock.json | grep -E "integrity|resolved"
• npm ci # fails if package.json and lockfile disagree
• npm audit signatures
• pip install --require-hashes -r requirements.txt

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Switching registries, mirrors or a lockfile regenerated on a different npm version legitimately changes resolved URLs and sometimes adds hashes. Rule out: the change is confined to resolved-host rewrites and integrity values for unchanged versions are identical.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• npm docs: package-lock.json
• npm docs: npm audit (including audit signatures)
• pip docs: secure installs (hash-checking mode)
• OWASP Top 10 2021 A08: Software and Data Integrity Failures

Why it matters

This is not a heuristic. Someone has already analysed and confirmed the package. Anything installed before the takedown may have run.

How to verify manually

• osv-scanner --lockfile package-lock.json # lists advisories including malicious-package entries
• npm audit
• Search your CI logs and developer machines for installs of the affected versions during the exposure window.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Advisories apply to specific versions. Rule out: your resolved version is outside the affected range, confirmed in the lockfile. Do not rule out a malicious-package advisory because the package "looks fine".

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• OWASP Top 10 2021 A06: Vulnerable and Outdated Components
• OWASP Software Component Verification Standard
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

A vulnerability is a bug someone can exploit; it is not malware. Keeping the two apart matters: a vulnerable package gets patched, a malicious one gets removed and incident-handled.

How to verify manually

• npm audit --json
• osv-scanner --lockfile package-lock.json
• pip-audit -r requirements.txt

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Advisories may not apply to your usage path or may be fixed in a newer version you already resolve. Rule out with the advisory's affected range and a reachability check.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• OWASP Top 10 2021 A06: Vulnerable and Outdated Components

Why it matters

Install hooks run with the installer's privileges before any review. Downloading a second stage at that moment keeps the payload out of the published tarball, so registry scanning sees a clean package while the real code arrives later and can change per victim.

How to verify manually

• npm view <pkg>@<version> scripts --json
• npm pack <pkg>@<version> --ignore-scripts && tar -xzOf <pkg>-<version>.tgz package/package.json
• tar -xzOf <pkg>-<version>.tgz package/<script-file-named-in-hook> | grep -nE "curl|wget|fetch|https?:|Invoke-WebRequest"

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Native-addon packages legitimately download a prebuilt binary at install (node-pre-gyp, prebuild-install, puppeteer, playwright). Rule out: the host is the vendor's own release host named in the README, the file is checksum-verified, and the same hook existed in the previous 3 versions. A first-ever download hook added in a patch release is not a false positive.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

Seen in the wild

ua-parser-js (October 2021): hijacked releases ran an install script that fetched and executed binaries.

References

• MITRE ATT&CK T1105: Ingress Tool Transfer
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• npm docs: scripts and lifecycle events
• OWASP Top 10 2021 A08: Software and Data Integrity Failures

Why it matters

This is the shortest path from "registry package" to "arbitrary remote code on a developer laptop or CI runner". Legitimate installers that do this are rare in libraries and are never a dependency of an application.

How to verify manually

• npm view <pkg>@<version> scripts.postinstall scripts.preinstall scripts.install
• npm pack <pkg>@<version> --ignore-scripts && tar -xzOf <pkg>-<version>.tgz package/package.json | grep -nE "\| *(ba)?sh|sh -c|\$\("

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Vendor CLIs that bootstrap themselves (a language toolchain installer wrapped as an npm package) do this on purpose. Rule out by confirming the package is the vendor's official one (publisher, repository, provenance) and that the URL is the vendor's documented install host. Everything else: no known benign reason.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1059.004: Command and Scripting Interpreter: Unix Shell
• MITRE ATT&CK T1105: Ingress Tool Transfer
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• npm docs: scripts and lifecycle events

Why it matters

Encoded or hidden PowerShell has no purpose in a build hook. It hides the command from a casual reader and from log review, and a platform guard means Linux analysis sandboxes see nothing.

How to verify manually

• npm pack <pkg>@<version> --ignore-scripts && tar -xzf <pkg>-<version>.tgz
• grep -rniE "powershell|pwsh|-enc|EncodedCommand|ExecutionPolicy|WindowStyle" package/package.json package/*.js package/scripts 2>/dev/null
• echo "<base64-argument>" | base64 -d | iconv -f UTF-16LE -t UTF-8 # read it, never run it

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Windows-focused build tooling can call PowerShell with plain, readable commands and no encoding or hidden window. Rule out by reading the full command: a literal, short, documented command is fine; a base64 blob never is.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1059.001: Command and Scripting Interpreter: PowerShell
• MITRE ATT&CK T1027: Obfuscated Files or Information
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Inline programs avoid shipping a visible .js file for scanners and reviewers to open. Combined with eval or a decode step it is a loader, not a build step.

How to verify manually

• npm view <pkg>@<version> scripts --json | grep -nE "node -[ep]"
• Copy the inline program to a file and read it in an editor; do not paste it into a shell.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Short node -e one-liners that print a version, check an engine or create a directory are common and harmless. Rule out: the program is under about 100 characters and contains none of eval, Function, child_process, base64 or a network call.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1059.007: Command and Scripting Interpreter: JavaScript
• MITRE ATT&CK T1027: Obfuscated Files or Information
• npm docs: scripts and lifecycle events

Why it matters

A lifecycle hook that spawns a shell is the mechanism almost every install-time payload uses. By itself it is only a capability; it turns malicious when the command is built from fetched or decoded data.

How to verify manually

• npm view <pkg>@<version> scripts --json
• npm pack <pkg>@<version> --ignore-scripts && tar -xzf <pkg>-<version>.tgz && grep -rnE "child_process|execSync|spawnSync|shell: *true" package --include=*.js --include=*.cjs --include=*.mjs

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

node-gyp builds, husky/lefthook git-hook setup, patch-package and tsc/rollup builds all spawn processes in install or prepare. Rule out: the command is a constant string naming a well-known tool that is a declared dependency.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• MITRE ATT&CK T1059.004: Command and Scripting Interpreter: Unix Shell
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• npm docs: scripts and lifecycle events

Why it matters

A package has no reason to alter files outside its own directory. These locations give the attacker persistence that survives uninstalling the package, or a path back in (SSH key, poisoned registry config).

How to verify manually

• grep -rnE "\.bashrc|\.zshrc|\.profile|authorized_keys|\.npmrc|crontab|LaunchAgents|systemd|CurrentVersion.Run" package
• After a suspicious install in a throwaway VM: diff ~/.bashrc ~/.zshrc ~/.ssh ~/.npmrc against a snapshot, and run crontab -l

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Shell-completion installers and CLI "setup" commands may append to a profile, but they do so on an explicit user command, not in an automatic install hook, and they print what they changed.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1546.004: Event Triggered Execution: Unix Shell Configuration Modification
• MITRE ATT&CK T1053.003: Scheduled Task/Job: Cron
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Not evidence of anything on its own. It marks the packages where install-time risk exists, so review effort goes where code can run before you read it.

How to verify manually

• npm query ":attr(scripts, [postinstall])" # in a project with node_modules
• npm view <pkg>@<version> scripts
• npm config get ignore-scripts

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Most hooks are benign (native builds, husky, telemetry opt-outs). Treat as a triage flag only. Rule out by reading the hook; if it is a single call to a known build tool, allow.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• npm docs: scripts and lifecycle events
• npm docs: ignore-scripts config
• OWASP Software Component Verification Standard

Why it matters

Account-takeover releases most often add exactly one thing: a lifecycle hook that runs the payload. A previously hook-free library gaining one is a much stronger signal than the hook alone.

How to verify manually

• npm view <pkg> versions --json
• for v in <old> <new>; do echo $v; npm view <pkg>@$v scripts --json; done
• npm pack <pkg>@<old> <pkg>@<new> --ignore-scripts; mkdir a b; tar -xzf <pkg>-<old>.tgz -C a; tar -xzf <pkg>-<new>.tgz -C b; diff -ru a b | head -200

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

A maintainer may add a native build step or a postinstall message deliberately, and the change will be in the changelog and the git history. Rule out: the same change is a commit in the public repository, tagged, reviewed, with the hook doing something the release notes explain.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

Seen in the wild

ua-parser-js (October 2021) and eslint-scope 3.7.2 (July 2018): both account-takeover releases added an install-time script that the previous version did not have.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• MITRE ATT&CK T1078: Valid Accounts
• npm docs: scripts and lifecycle events

Why it matters

Without a source link a reviewer has nothing to compare the artifact with, and typosquats usually omit it. Many honest private or tiny packages omit it too.

How to verify manually

• npm view <pkg> repository homepage bugs
• Search the registry description and README for a source link; check the maintainer's other packages.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Hobby and legacy packages often have no repository. Rule out: an otherwise consistent history, real adoption and a matching public repository found by name.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• OWASP Software Component Verification Standard
• npm docs: package.json

Why it matters

Throwaway malicious packages are not worth documenting. A README copied from the squatted target is part of the disguise.

How to verify manually

• npm view <pkg> description readme | head -40
• Search a distinctive sentence from the README to find the package it was copied from.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Internal helpers and early-stage libraries have sparse docs. Rule out: documentation and code agree, and other signals (history, maintainers, adoption) are healthy.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• OWASP Software Component Verification Standard

Why it matters

It signals the metadata was filled to pass a glance. The reader sees a link; nothing behind it can be audited.

How to verify manually

• npm view <pkg> repository.url homepage bugs.url
• git ls-remote <repo-url> # does it resolve?
• whois <homepage-domain> # created recently?

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Repositories get renamed, archived or deleted by honest maintainers, leaving stale links. Rule out: the repository moved (redirect, same owner) and an old release was built from it.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• OWASP Software Component Verification Standard
• MITRE ATT&CK T1036.005: Masquerading: Match Legitimate Name or Location

Why it matters

Inflated counts make a package look trusted, and genuine spikes show a campaign or an automated install fan-out.

How to verify manually

• npm view <pkg> time.created
• curl -s "https://api.npmjs.org/downloads/range/last-month/<pkg>" # look for a single-day spike
• Check the Dependents tab on the npmjs.com package page: a package with thousands of downloads and no dependents is odd.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Mirrors, CI caches and security scanners download new packages in volume, and a newly launched tool can really go viral. Rule out: coverage in the project's own channels and a public repository with commit history older than the package.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• OWASP Software Component Verification Standard
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Mass registration is how typosquat and dependency-confusion campaigns scale. The packages are cheap, disposable and often published in automated batches.

How to verify manually

• npm search --searchlimit 100 "maintainer:<user>"
• npm view <pkg-a> scripts; npm view <pkg-b> scripts # identical?
• Diff two tarballs: they should differ only in the name.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Template-based monorepo families, scoped component libraries and generated SDKs share structure by design. Rule out: they share one repository and documented release process.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• MITRE ATT&CK T1036.005: Masquerading: Match Legitimate Name or Location

Why it matters

Popularity is not safety, but widely used packages get looked at. A package nobody else uses has had no community review and is where a one-off malicious package sits.

How to verify manually

• curl -s "https://api.npmjs.org/downloads/point/last-week/<pkg>"
• npm view <pkg> time.created # combine with age: a new, unused package is the weak combination

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Plenty of valid niche or internal-turned-public packages have low numbers. This is an amber nudge, not a finding. Rule out by reading the code and checking the author.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• OWASP Top 10 2021 A06: Vulnerable and Outdated Components

Why it matters

Unmaintained code gets no security fixes and its registry account may be abandoned, which is a takeover target. The age alone says nothing about malice.

How to verify manually

• npm view <pkg> time.modified dist-tags.latest
• npm view <pkg> deprecated

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Small stable utilities need no updates for years. Rule out: the code is tiny, well understood and has no install hook or network use.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• OWASP Top 10 2021 A06: Vulnerable and Outdated Components

Why it matters

Attackers rely on a mistyped npm install or pip install, an AI-suggested name or a copied typo. Installs happen automatically in CI, so one typo in a manifest is enough.

How to verify manually

• npm view <pkg> name version time.created dist-tags repository.url
• npm view <popular-name> maintainers; compare to npm view <pkg> maintainers (should be unrelated for a typosquat)
• npm search <popular-name> --searchlimit 20 # see near-name neighbours
• pip index versions <pkg> # PyPI; compare normalised names, - _ and . are equivalent

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Many legitimate packages sit one edit from another (short names such as vue, zod, jest, next, ora; forks; ecosystem plugins). Rule out: independent repository with real history, a distinct purpose, a description that does not impersonate the popular package, and downloads that grew over time.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

Seen in the wild

crossenv (2017), a typosquat of cross-env.

References

• MITRE ATT&CK T1036.005: Masquerading: Match Legitimate Name or Location
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• OWASP Top 10 2021 A08: Software and Data Integrity Failures

Why it matters

Edit distance misses these because the name is far from the original in characters but close in meaning. A developer or an LLM looking for "the X helper" picks the squatted name.

How to verify manually

• npm view <combo-name> repository.url maintainers time.created
• Open the real project's README and package.json: does it name this package as an official companion? If not, treat it as unrelated.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Official companion packages follow the same pattern (@types/*, <name>-cli, <name>-plugin-*). Rule out: the real project's documentation links to it, the maintainers overlap, and the scope or repository belongs to the same organisation.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1036.005: Masquerading: Match Legitimate Name or Location
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Scopes are the namespace a team trusts. A lookalike scope borrows that trust, and a missing scope is exactly what dependency confusion exploits.

How to verify manually

• npm view @scope/pkg maintainers repository.url
• npm org ls <scope> # only for scopes you administer
• Compare the scope spelling character by character with the vendor's documentation.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Organisations sometimes register an unscoped alias for convenience, and personal scopes publish forks. Rule out: the vendor documents the alias and lists the maintainers.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• npm docs: about scopes
• MITRE ATT&CK T1036.005: Masquerading: Match Legitimate Name or Location
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

If the installer consults the public registry for a name that also exists privately, the highest version wins. The attacker needs only to guess or leak an internal name to get code execution on build servers.

How to verify manually

• npm view <internal-name> time.created versions # does a public package exist at all?
• npm config get registry; npm config ls -l | grep -i scope # is your internal scope pinned to your private registry?
• pip index versions <internal-name>; pip config list # check extra-index-url vs index-url
• Compare against your private registry's highest version for the same name.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

A real public package may share a generic name with an internal one by coincidence. Rule out: the public package is old, has real adoption and the maintainers have no connection to a name that appeared in your private manifests only.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

Seen in the wild

Alex Birsan's dependency confusion research (February 2021) executed code inside many large companies this way. torchtriton on PyPI (December 2022) did the same to PyTorch nightly installs through a pip extra index.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• OWASP Top 10 2021 A06: Vulnerable and Outdated Components
• OWASP Top 10 CI/CD Security Risks (Dependency Chain Abuse, Poisoned Pipeline Execution, Insufficient Credential Hygiene)
• npm docs: about scopes

Why it matters

Developers search the registry for "the SDK for X". Brand words make a squat look official, and AI coding assistants sometimes recommend names that were only invented by pattern.

How to verify manually

• npm view <pkg> maintainers repository.url homepage
• Check the vendor's own documentation for the official package name and scope.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Community wrappers and unofficial clients for well-known services are common and often legitimate. Rule out: the README says it is unofficial, the repository has history, and the code does only what it claims.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• MITRE ATT&CK T1036.005: Masquerading: Match Legitimate Name or Location
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Registry pages show repository stars and a link. Pointing the field at a famous repository makes a throwaway package look established. npm does not verify that the publisher controls the repo unless provenance is used.

How to verify manually

• npm view <pkg> repository.url gitHead
• In the repository, search for the package name in package.json and in the release workflow. If it is absent, the link is borrowed.
• npm audit signatures # a valid provenance attestation names the real source repository and workflow

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Monorepos publish many packages from one repository, so the root package.json will not match; legitimate forks also point at upstream. Rule out: the package lives in a subdirectory declared in repository.directory, or the release workflow publishes it.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• npm docs: generating provenance statements
• npm docs: npm audit (including audit signatures)
• MITRE ATT&CK T1036.005: Masquerading: Match Legitimate Name or Location

Why it matters

Language models sometimes invent package names that sound right. Attackers register those names and wait for a developer to run the suggested install command.

How to verify manually

• npm view <pkg> time.created dist-tags repository.url # created days ago, tiny history
• Search the library's own documentation for the name. If the docs do not mention it, do not install it.
• Open the package page on npmjs.com (Dependents tab) or deps.dev: a plausible helper nobody depends on is the pattern.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Brand-new but real packages exist and their authors announce them. Rule out: the author or project announced it, source is public with commit history older than the package, and the install count is not just the author's own.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• OWASP Top 10 2021 A06: Vulnerable and Outdated Components

Why it matters

Real services are reached by name. A numeric destination avoids DNS-based blocking and reputation lookups and is typical of throwaway command-and-control or exfiltration servers.

How to verify manually

• grep -rnE "([0-9]{1,3}\.){3}[0-9]{1,3}" package --include=*.js --include=*.cjs --include=*.mjs | grep -vE "127\.0\.0\.1|0\.0\.0\.0|localhost|version"
• whois <ip>; check the address in a threat-intel feed before connecting to it from anything.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Loopback and private ranges (127.0.0.1, 10.x, 192.168.x), documentation ranges in comments or tests, version strings that look like IPs, and public DNS resolver addresses (for example in a DNS library). Rule out by excluding those and confirming the remaining address is not used by request code.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1071.001: Application Layer Protocol: Web Protocols
• MITRE ATT&CK T1041: Exfiltration Over C2 Channel

Why it matters

Chat webhooks are free, TLS-protected, need no infrastructure and are rarely blocked on egress. Stealers use them as a drop box. A webhook URL embedded in a library is the attacker's mailbox.

How to verify manually

• grep -rniE "discord(app)?\.com/api/webhooks|api\.telegram\.org/bot|hooks\.slack\.com/services" package
• Example of what a defanged finding looks like: hxxps://discord[.]com/api/webhooks/<id>/<token>

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Notification libraries and chatbot SDKs call these APIs, but the webhook URL is supplied by the user at runtime. Rule out: the URL is a parameter or config value, not a literal hardcoded in the package.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1567: Exfiltration Over Web Service
• MITRE ATT&CK T1041: Exfiltration Over C2 Channel
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Paste sites serve as a movable payload host (stage two is a text file the attacker can edit); capture and tunnel hosts serve as exfiltration endpoints that need no domain registration.

How to verify manually

• grep -rniE "paste|transfer\.sh|file\.io|webhook\.site|requestbin|ngrok|trycloudflare|localtunnel" package | grep -vE "README|\.md:"
• Check whether the host is contacted at install time: npm install --ignore-scripts first, then run the hook by hand in a sandbox with network logging.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Developer tooling for sharing logs or exposing a local server mentions these services, and test fixtures may include them in strings. Rule out: it is a documented feature that runs on explicit user command.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1567: Exfiltration Over Web Service
• MITRE ATT&CK T1105: Ingress Tool Transfer
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

DNS passes through most egress controls. Encoding a username, hostname or token as subdomain labels leaks it to whoever runs the authoritative name server, and also confirms the install executed (a beacon).

How to verify manually

• grep -rnE "dns\.(lookup|resolve|promises)|nslookup|dig |gethostbyname" package
• Look for string building on the argument: `${os.hostname()}.${...}`. In a sandbox, log queries with a local resolver and look for long or high-entropy labels.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

DNS and networking libraries resolve names supplied by their caller, and some packages do a connectivity check against a fixed well-known name. Rule out: the name is fixed or user-provided, never assembled from machine data.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1071.004: Application Layer Protocol: DNS
• MITRE ATT&CK T1048: Exfiltration Over Alternative Protocol
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

No library has a reason to connect to a mining pool. It is resource hijacking: the victim pays the compute and power bill.

How to verify manually

• grep -rniE "stratum\+(tcp|ssl)|xmrig|cryptonight|coinhive|minexmr|nanopool|moneroocean" package
• On a machine that installed the package: top/htop for sustained high CPU from node or an unfamiliar binary.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Security research tooling, blocklists and documentation can contain pool names as data. Rule out: the strings sit in a blocklist or test fixture and nothing connects to them.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

Seen in the wild

ua-parser-js (October 2021): hijacked releases installed a cryptocurrency miner.

References

• MITRE ATT&CK T1496: Resource Hijacking
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Decode-then-execute exists only to hide what runs. Honest code does not need to conceal its own logic from the people who install it.

How to verify manually

• grep -rnE "eval\(|new Function\(|vm\.run|atob\(|fromCharCode|b64decode|exec\(" package
• Decode the blob offline into a text file (base64 -d blob.txt > out.bin; file out.bin; strings out.bin | less) and read it. Never feed it to node, python or sh.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Template engines, bundlers, REPLs, sandboxes and code generators use Function or vm with code they were handed. Rule out: the executed string comes from the caller's input, not from a literal embedded in the package.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

Seen in the wild

event-stream (2018): the flatmap-stream dependency carried an encrypted payload decrypted and run only inside a specific victim application.

References

• MITRE ATT&CK T1027: Obfuscated Files or Information
• MITRE ATT&CK T1140: Deobfuscate/Decode Files or Information
• MITRE ATT&CK T1059.007: Command and Scripting Interpreter: JavaScript

Why it matters

This is the compact "unpack and run" idiom. A long base64 literal passed to a command runner is a staged payload, not data.

How to verify manually

• grep -rnE "Buffer\.from\(.{40,}, *['\"]base64" package
• Decode to a file with base64 -d and read it as text. Check whether it is a script, an ELF/PE header (file <out>) or a URL.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Packages that embed small base64 assets (icons, WASM, fonts) decode them, but pass them to image or WebAssembly APIs, not to exec. Rule out by following the decoded variable to its sink.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1140: Deobfuscate/Decode Files or Information
• MITRE ATT&CK T1027: Obfuscated Files or Information
• MITRE ATT&CK T1059.004: Command and Scripting Interpreter: Unix Shell

Why it matters

These are the fingerprints of javascript-obfuscator style tools. Open source libraries have no reason to make their own logic unreadable; malware does, to defeat grep and human review.

How to verify manually

• grep -c "_0x[0-9a-f]\{4,\}" <file>
• Pretty-print a copy (npx prettier --write copy.js) and look for the string array and rotator at the top; do not run it.
• Compare with the repository: the same file in git should be readable source.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Some commercial or anti-tamper browser SDKs ship deliberately obfuscated bundles. Rule out: the vendor documents it, the package is from the vendor's own scope, and the obfuscated file corresponds to a build artifact in their repository.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1027: Obfuscated Files or Information
• MITRE ATT&CK T1140: Deobfuscate/Decode Files or Information

Why it matters

Unreadable shipped code that does not match the repository is how a reviewer is stopped from diffing a release. The repo looks clean; the tarball is not.

How to verify manually

• tar -xzf <pkg>-<version>.tgz && wc -l package/<main> && wc -c package/<main>
• git clone <repo> && git checkout <tag>; build the package from source and diff the output with the tarball (npm pack in the repo, then diff -r).

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Many legitimate libraries ship a minified browser bundle (dist/*.min.js). Rule out: it is in a dist folder, has a .map, matches a reproducible build from the tagged commit, and the unminified entry point is also present.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• MITRE ATT&CK T1027: Obfuscated Files or Information
• OWASP Top 10 2021 A08: Software and Data Integrity Failures

Why it matters

Assembling a module or function name at runtime defeats static greps for child_process, fs or eval. The only reason to hide the name is to evade the grep.

How to verify manually

• grep -rnE "require\( *[^'\"]|\[.{1,20}\]\.join\(|globalThis\[|__import__|getattr\(builtins" package

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Plugin systems, loaders, bundlers and test runners use dynamic require with a path the user provides. Rule out: the computed value comes from configuration or an argument, not from string fragments in the package.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• MITRE ATT&CK T1027: Obfuscated Files or Information
• MITRE ATT&CK T1059.007: Command and Scripting Interpreter: JavaScript

Why it matters

Bidirectional controls can make code display differently from how it executes (Trojan Source). Zero-width runs can carry an encoded payload that is invisible in a diff.

How to verify manually

• grep -rnP '[\x{202A}-\x{202E}\x{2066}-\x{2069}\x{200B}-\x{200D}\x{2060}]' package
• git diff --word-diff-regex=. with a viewer that shows control characters (cat -A, or an editor with "render control characters").

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Right-to-left language strings, emoji with zero-width joiners and localisation files legitimately contain these. Rule out: the characters are inside translation or emoji data, not in code or identifiers.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• Trojan Source (CVE-2021-42574): invisible bidirectional-text source code attacks
• MITRE ATT&CK T1027: Obfuscated Files or Information

Why it matters

Taking over trust that already has an install base is cheaper than building it. Maintainer handover, abandoned-package takeovers and hijacked accounts all look like a new name on an old package.

How to verify manually

• npm view <pkg> maintainers --json; npm view <pkg> time --json # compare dates to the maintainer changes you know about
• for v in <last-old> <first-new>; do npm view <pkg>@$v _npmUser; done # who actually published each
• npm owner ls <pkg>

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Healthy projects add co-maintainers and hand over to successors, usually with a public issue or announcement. Rule out: an announcement in the repository, the new maintainer has existing commits and a history on the project.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

Seen in the wild

event-stream (2018): the original maintainer passed publishing rights to a volunteer who later added the malicious flatmap-stream dependency.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• MITRE ATT&CK T1586.002: Compromise Accounts: Email Accounts
• MITRE ATT&CK T1078: Valid Accounts

Why it matters

A stolen token or account publishes as a different identity from the usual maintainer. A dormant package is a prime target because nobody is watching its releases.

How to verify manually

• npm view <pkg> time --json | tail -20
• for v in $(npm view <pkg> versions --json | jq -r ".[-5:][]"); do echo $v $(npm view <pkg>@$v _npmUser.name); done

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Teams rotate maintainers, a revived project may restart after years, and CI bots publish as a dedicated user. Rule out: the project announced the revival, the new publisher appears on the maintainers list, or provenance links the release to the repository's workflow.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1078: Valid Accounts
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Releases built from a developer machine or a stolen token skip the repository entirely. A release the public source never saw cannot have been reviewed.

How to verify manually

• npm view <pkg>@<version> gitHead repository.url
• git ls-remote --tags <repo> | grep <version>
• git cat-file -t <gitHead> # inside a clone

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Many maintainers tag differently (v prefix, a monorepo scheme, tags created after publish) and some publish from a release branch. Rule out: the commit exists, the tarball matches that commit (see PSR-PUB-006), and tags use a consistent pattern.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• npm docs: generating provenance statements
• OWASP Top 10 2021 A08: Software and Data Integrity Failures
• MITRE ATT&CK T1195.002: Compromise Software Supply Chain

Why it matters

A very high version wins resolution in dependency confusion and in loosely pinned ranges. A burst can mean iterating on a payload until it evades checks.

How to verify manually

• npm view <pkg> versions --json
• npm view <pkg> time --json # look for many entries within minutes

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Real major bumps and calendar versioning exist, and some projects publish many pre-releases while stabilising. Rule out: a changelog or release note explains the jump, and the tag exists in the repository.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• OWASP Top 10 2021 A06: Vulnerable and Outdated Components

Why it matters

The repository is what reviewers read; the registry artifact is what runs. Any code that exists only in the artifact bypassed review by definition.

How to verify manually

• npm pack <pkg>@<version> --ignore-scripts; mkdir pkg; tar -xzf <pkg>-<version>.tgz -C pkg
• git clone <repo> src && cd src && git checkout <tag> && npm ci --ignore-scripts && npm run build && npm pack --ignore-scripts
• diff -ru <built-package> ../pkg/package # package.json scripts and dependencies first, then any extra file

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Builds are not always reproducible (timestamps, minifier versions, generated files). Rule out: differences are limited to generated or compiled output and the package.json (scripts, dependencies, files) is identical.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1195.002: Compromise Software Supply Chain
• OWASP Top 10 2021 A08: Software and Data Integrity Failures
• npm docs: generating provenance statements

Why it matters

A maintainer who moved to trusted publishing rarely goes back. A release without attestation after a run of attested ones suggests it was published with a stolen token from outside the pipeline.

How to verify manually

• for v in <v1> <v2> <latest>; do echo $v; npm view <pkg>@$v dist.attestations --json; done
• npm audit signatures # in a project that depends on the package
• PyPI: the project file listing shows a provenance/attestation section for files published through a trusted publisher

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

A maintainer may publish a hotfix by hand or switch CI. Rule out: the project explains it in the changelog and the next release restores attestations.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• npm docs: generating provenance statements
• PEP 740: Index support for digital attestations
• PyPI docs: trusted publishers
• npm docs: npm audit (including audit signatures)

Why it matters

Provenance proves where a build ran, not that the code is safe. An attacker who controls a repository or a maintainer account can publish properly attested releases. The useful question is whether the origin matches the one you expect.

How to verify manually

• npm view <pkg>@<version> dist.attestations.url # then read the predicate: repository, ref, workflow
• Compare with the previous release's attestation: same repo, same workflow path, same ref pattern?

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Projects move repositories or rename workflows. Rule out: the change is announced and consistent across all of the project's packages.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• npm docs: generating provenance statements
• PyPI docs: trusted publishers
• OWASP Top 10 2021 A08: Software and Data Integrity Failures

Why it matters

Registry accounts are recoverable by email. A lapsed domain turns into account takeover without breaking any password or 2FA, and the package keeps its good name and install base.

How to verify manually

• npm view <pkg> maintainers --json # note the email domains
• whois <domain> # creation date after the package's first release is the red flag
• dig +short MX <domain>

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Domains are sometimes legitimately renewed after a lapse. Rule out: registration history shows continuity, or the maintainer changed address on the registry and confirms it publicly.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1586.002: Compromise Accounts: Email Accounts
• MITRE ATT&CK T1078: Valid Accounts
• PEP 541: Package Index Name Retention

Why it matters

This is the worm pattern: stolen tokens are used to republish everything the victim can publish, which turns one compromised developer into a whole family of poisoned packages.

How to verify manually

• npm search --searchlimit 100 "maintainer:<user>"
• for p in <list>; do npm view $p time.modified dist-tags.latest; done # recent modification clustering
• Check the same account's packages for an identical new file or scripts entry.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Maintainers of monorepos or package families release together (for example a framework's scoped packages). Rule out: the release is a coordinated version bump with a tag and changelog, not a new hook or file.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• MITRE ATT&CK T1528: Steal Application Access Token
• OWASP Top 10 CI/CD Security Risks (Dependency Chain Abuse, Poisoned Pipeline Execution, Insufficient Credential Hygiene)

Why it matters

Not a sign of attack. It marks single points of failure: one stolen credential or one burnt-out maintainer affects every dependent.

How to verify manually

• npm view <pkg> maintainers --json
• curl -s "https://api.npmjs.org/downloads/point/last-week/<pkg>"

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Most small, excellent libraries have one author. This is context for a risk register, not a finding. Mitigate with pinned versions and delayed adoption instead of treating it as suspicious.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• npm docs: configuring two-factor authentication
• OWASP Top 10 2021 A06: Vulnerable and Outdated Components

Why it matters

Building from an sdist executes setup.py with the installer's privileges before anything is imported. A custom install class is the Python equivalent of an npm postinstall hook.

How to verify manually

• curl -s "https://pypi.org/pypi/<pkg>/<version>/json" | jq -r ".urls[] | select(.packagetype==\"sdist\") | .url" # download the sdist, do not pip-install it
• tar -xzf <pkg>-<version>.tar.gz && grep -nE "cmdclass|subprocess|os\.system|urllib|requests|socket" <pkg>-<version>/setup.py

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

C-extension builds, code generation and Cython projects override build commands with local compiler calls. Rule out: the override only invokes compilers or generators on files inside the project and makes no network call.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• PEP 517: A build-system independent format for source trees
• MITRE ATT&CK T1059.004: Command and Scripting Interpreter: Unix Shell

Why it matters

import <package> is the one action every user performs. Code at module level runs for every importer, including test runs and CI, with no installer step to review.

How to verify manually

• unzip -p <wheel>.whl "<pkg>/__init__.py" | head -120
• python -X importtime -c "import <pkg>" in a sandbox with network logging, or inspect with strace -f -e trace=network,openat

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Packages register plugins, configure logging or perform lazy-import setup at import time. Rule out: nothing at module level touches the network, subprocess, credentials or files beyond reading its own data.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• MITRE ATT&CK T1059.004: Command and Scripting Interpreter: Unix Shell

Why it matters

Python processes .pth files at interpreter start-up, and lines starting with import are executed. The code therefore runs on every Python launch, not only when the package is imported, and survives importing nothing.

How to verify manually

• unzip -l <wheel>.whl | grep "\.pth$"
• unzip -p <wheel>.whl "<name>.pth"
• On a machine: find "$(python -c 'import site;print(site.getsitepackages()[0])')" -name "*.pth" -exec grep -lE "^import|exec|subprocess" {} +

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Editable installs and some namespace packages use .pth files, usually with plain directory paths. Rule out: every line is a plain path, or a documented, short import used by a well-known packaging tool.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• Python docs: site (.pth file handling)
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• MITRE ATT&CK T1059.004: Command and Scripting Interpreter: Unix Shell

Why it matters

Reviewers typically read the repository or the sdist, while installers prefer the wheel. Any code only in the wheel never went through the review path, and the mismatch is the signal.

How to verify manually

• unzip -l <wheel>.whl | awk "{print \$4}" | sort > wheel.txt; tar -tzf <pkg>-<version>.tar.gz | sed "s#^[^/]*/##" | sort > sdist.txt; diff wheel.txt sdist.txt
• Compare METADATA Requires-Dist between the wheel and the sdist PKG-INFO.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Wheels contain compiled extensions and exclude tests, docs and build files that sdists include, and metadata is regenerated by the build backend. Rule out: differences are compiled output, license/docs/tests, and dependency lists match.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• Python Packaging: binary distribution format
• PEP 517: A build-system independent format for source trees
• OWASP Top 10 2021 A08: Software and Data Integrity Failures
• MITRE ATT&CK T1195.002: Compromise Software Supply Chain

Why it matters

An sdist forces a build on install, which means project-controlled code runs at install. A non-standard build backend is code that executes during that build.

How to verify manually

• curl -s "https://pypi.org/pypi/<pkg>/<version>/json" | jq ".urls[] | {packagetype, filename}"
• tar -xzf <sdist> && cat <dir>/pyproject.toml | sed -n "/build-system/,/^$/p"
• pip download <pkg>==<version> --no-deps --only-binary=:all: -d dl # fetches a wheel if one exists, runs no build

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Small projects often publish only an sdist, and legitimate in-tree backends exist for large projects. Rule out: backend is a well-known one (setuptools, hatchling, flit-core, poetry-core, pdm-backend) and no code runs in setup.py or backend hooks beyond packaging.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• PEP 517: A build-system independent format for source trees
• pip docs: secure installs (hash-checking mode)
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

pip treats all configured indexes as equals. An attacker who publishes your internal name publicly with a higher version gets installed instead of your own package.

How to verify manually

• pip config list; grep -rn "extra-index-url" requirements*.txt pip.conf pyproject.toml
• pip index versions <internal-name> # which versions does PyPI offer for your internal name?
• Prefer --index-url pointing to a proxy that serves a single namespace, plus --require-hashes.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

The public package may genuinely be yours (open-sourced), or an unrelated project may share a generic name. Rule out: the public project is verifiably yours, or the name is reserved by you on PyPI.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

Seen in the wild

torchtriton (December 2022): a PyPI package took precedence over the PyTorch nightly dependency of the same name served from a separate index.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• pip docs: secure installs (hash-checking mode)
• OWASP Top 10 CI/CD Security Risks (Dependency Chain Abuse, Poisoned Pipeline Execution, Insufficient Credential Hygiene)

Why it matters

Looking for secrets by pattern is what a stealer does. Libraries operate on paths their caller gives them; they do not sweep the user's disk.

How to verify manually

• grep -rnE "homedir\(\)|readdirSync|walk\(|glob\(|os\.walk|Path\.home\(\)" package | grep -iE "env|pem|key|wallet|credential|token"
• strace -f -e trace=openat,getdents64 node install-script.js # in a throwaway VM with decoy secrets

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Linters, bundlers, file watchers and secret scanners walk directories by design. Rule out: they start from the project directory passed by the user, and nothing read leaves the machine.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1083: File and Directory Discovery
• MITRE ATT&CK T1005: Data from Local System
• MITRE ATT&CK T1552.001: Unsecured Credentials: Credentials In Files

Why it matters

Malware lists running processes to decide whether it is being watched and to avoid detection or find high-value targets.

How to verify manually

• grep -rniE "tasklist|wmic|ps -|/proc/|process_iter|processList" package
• Look for comparison against a list of tool names (wireshark, procmon, defender, crowdstrike, tcpdump).

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Process managers, port-killers and dev servers list processes to find their own children. Rule out: lookups are for the tool's own processes or a PID the caller passes.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1057: Process Discovery
• MITRE ATT&CK T1497: Virtualization/Sandbox Evasion
• MITRE ATT&CK T1562.001: Impair Defenses: Disable or Modify Tools

Why it matters

Replacing the destination address in a transaction the user believes they are signing steals funds without touching the user's keys. A browser-side hook in a widely used dependency reaches every site that bundles it.

How to verify manually

• grep -rniE "clipboard|pbpaste|xclip|GetClipboardData|window\.ethereum|XMLHttpRequest\.prototype|window\.fetch *=" package
• Search for address-shaped regexes: 0x[a-fA-F0-9]{40}, bc1, T[A-Za-z0-9]{33}, and hardcoded replacement address lists.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Copy-to-clipboard UI helpers use clipboard writes on an explicit click, and web3 libraries use window.ethereum by design. Rule out: clipboard access only happens inside a user-triggered handler, and a wallet library never rewrites addresses it did not generate.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

Seen in the wild

chalk, debug and related packages (September 2025): a phished maintainer account published releases containing browser code that swapped cryptocurrency addresses.

References

• MITRE ATT&CK T1115: Clipboard Data
• MITRE ATT&CK T1565.002: Data Manipulation: Transmitted Data Manipulation
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Turning off verification lets a network position intercept anything the package sends, and malware sets it so its own exfiltration works against hosts with self-signed or mismatched certificates.

How to verify manually

• grep -rnE "NODE_TLS_REJECT_UNAUTHORIZED|rejectUnauthorized *: *false|verify *= *False|_create_unverified_context" package

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Tests, local development and tools that target self-signed internal servers set it, usually behind a flag. Rule out: it is opt-in via an option or environment variable, documented, and not set at module load.

Recommended action

Allow with review. Fine to keep once a person has looked and the checks above came back clean.

References

• MITRE ATT&CK T1562.001: Impair Defenses: Disable or Modify Tools
• OWASP Top 10 2021 A08: Software and Data Integrity Failures

Why it matters

Package registries and security vendors detonate new packages in sandboxes. Malware that stays dormant there passes review and fires only on real machines.

How to verify manually

• grep -rniE "vmware|virtualbox|qemu|hypervisor|sandbox|os\.cpus\(\)\.length|os\.totalmem|os\.uptime|networkInterfaces|dmidecode" package
• Run the install in two environments (a plain VM and a realistic developer image) and compare network and file activity.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Telemetry libraries read OS, CPU and CI details for anonymous statistics, usually with documented opt-out. Rule out: data is limited to coarse fields, disclosed, and sent only to the vendor.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1497: Virtualization/Sandbox Evasion
• MITRE ATT&CK T1082: System Information Discovery
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Time bombs outlast the review window; geo or locale gates hit chosen victims and stay quiet everywhere else, including in the sandbox of an analyst in another country.

How to verify manually

• grep -rnE "new Date\(.{0,40}20[2-3][0-9]|setTimeout\([^,]+, *[0-9]{7,}|resolvedOptions\(\)\.(timeZone|locale)|process\.env\.(LANG|LC_ALL)|geoip|ipinfo|ip-api" package
• Change the system clock/timezone/locale in a VM and rerun to see whether behaviour changes.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Licence-expiry checks, localisation, scheduling libraries and analytics use dates and locales. Rule out: the branch changes presentation or language, not file, process or network behaviour.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1480: Execution Guardrails
• MITRE ATT&CK T1497: Virtualization/Sandbox Evasion
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Whatever the author's motive, a dependency that damages the systems it runs on has violated the trust the install granted. It is a supply-chain integrity event even when announced.

How to verify manually

• grep -rnE "unlinkSync|rmSync|rm -rf|writeFileSync" package | head # then check the surrounding condition
• Read the changelog and issues for the version; protestware is usually discussed within hours.
• npm view <pkg> deprecated # npm often deprecates affected versions

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Cleanup utilities delete files by design. Rule out: deletion targets a path the caller passes, never a fixed system or user path, and is not conditioned on locale or geography.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

Seen in the wild

colors and faker (January 2022): maintainer-added sabotage. node-ipc (March 2022): a release that overwrote files on machines geolocated to certain countries.

References

• MITRE ATT&CK T1485: Data Destruction
• MITRE ATT&CK T1480: Execution Guardrails
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Input capture records passwords, tokens and commands typed by the user. No ordinary library needs a system-wide keyboard hook.

How to verify manually

• grep -rniE "iohook|uiohook|pynput|keyboard\.(on|hook)|setRawMode|keypress|keydown" package

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

CLI prompt libraries (inquirer, readline wrappers), TUI frameworks, games and accessibility tools read keys on their own terminal or page. Rule out: input is read only on the program's own stdin or page and is not logged or transmitted.

Recommended action

Quarantine. Hold it out of builds until a person has verified it.

References

• MITRE ATT&CK T1056.001: Input Capture: Keylogging
• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools

Why it matters

Self-modification and cross-package writes are propagation mechanics. They turn one install into a foothold across the dependency tree or into new poisoned releases.

How to verify manually

• grep -rnE "node_modules|site-packages|writeFileSync\(.*__dirname|npm publish|twine upload" package
• Hash node_modules before and after the install in a throwaway VM and diff the results.

Inspect archives with tar and unzip. Do not run a package's code to check it; if you must detonate, use a disposable VM with no real credentials.

Common false positives, and how to rule them out

Patch-package style tools and postinstall patchers deliberately modify other packages on explicit instruction. Rule out: documented, applied to a named target, driven by files committed to your repo.

Recommended action

Block. Do not install; remove from manifests and lockfiles and start incident triage if it already ran.

References

• MITRE ATT&CK T1195.001: Compromise Software Dependencies and Development Tools
• MITRE ATT&CK T1528: Steal Application Access Token