Unpinned or Latest Dependency Installation
Package installers can be told to grab whatever the newest version of a library is, instead of a specific, known version. If the software registry serving that package is later compromised, the next install silently pulls in malicious code.
How the attack works
An install command runs against a package registry (npm, pip, or similar) without specifying an exact version number, or with an explicit request for 'latest'. The installer fetches whatever the registry currently serves under that name. If an attacker has compromised the registry, hijacked the package name, or pushed a malicious update to a legitimate package, the unpinned install brings that malicious code straight into the environment. This is one step of a supply chain attack — the compromise itself has to happen upstream first.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- d7f1c645-8e5a-4f2d-d7f6-1e4a9f6d5b38
- Severity
- Medium
Why it matters
An organization can end up running attacker-controlled code inside its build systems, CI/CD pipelines, or production environment, with no version record showing exactly what was installed or when the change happened.
What you can do
- →Pin dependencies to exact versions and commit lockfiles (package-lock.json, poetry.lock, Pipfile.lock, etc.) to source control.
- →Review CI/CD and deployment scripts for install commands that omit version numbers or explicitly use 'latest'.
- →Use a private package mirror or registry proxy so you control what versions are actually served internally.
- →Set up automated dependency update workflows (e.g. Dependabot) so version bumps go through review instead of happening silently at install time.
Known benign look-alikes
- Legitimate development environments where exact pinning is deferred
- Package update automation scripts