Supply Chain Package Acquisition - smart-commit-host-agent
This rule watches for someone running a command that explicitly installs, fetches, or executes a specific npm package named smart-commit-host-agent, including obfuscated or typosquatted spellings of it. The package was flagged based on suspicious metadata, not because anyone has confirmed it does anything malicious.
How the attack works
An attacker (or an unsuspecting developer) runs a command line that names the package directly — through npm install, a one-shot runner like npx or pnpx, a direct registry/tarball fetch, or by executing it from within a node_modules path. The rule matches on that literal command text, including separator tricks or near-miss spellings meant to evade a simple name match. It does not try to detect what the package does once installed, such as network calls or code execution — those behaviors are not observable with this detection method. It also will not catch the package being pulled in silently as a transitive dependency during a routine lockfile restore.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7c1e4a92-4b3d-4f8e-9a26-5d0f1b8c73ae
- Severity
- Medium
Why it matters
If the package turns out to be malicious, an organization could get compromised developer or CI tooling and unknown code execution in that environment. Right now this rule only confirms whether the package is being acquired at all — it does not confirm compromise.
What you can do
- →Treat any hit as a trigger for manual review: check who ran the command and why, and inspect the package contents before allowing it to run further.
- →Block or require approval for installs of this package name (and obvious variants) at the registry or CI level while its status is unclear.
- →Review dependency lockfiles for any existing reference to this package name, since transitive installs won't trigger this detection.
- →Report confirmed sightings back to your security team to help build evidence on whether this package is actually being pulled into your environment.
Known benign look-alikes
- A developer or platform engineer deliberately installing the package after review, or an internal fork published under a colliding name.
- CI or build automation that pins and explicitly names the package in an install step (a lockfile-only restore via "npm ci" will not match).
- Security researchers or triage analysts reproducing this very report in a sandbox - inspection verbs (ls/view/why/audit), removal verbs, --dry-run and the common scanner binaries are filtered, but a live fetch in a sandbox will still report.
- Documentation, changelog or advisory authoring that shells out with the package name; the common redirect-into-.md/.txt and editor invocations are filtered.
- An unrelated package whose name normalises to the same token under the separator-insensitive match (accepted cost of typosquat coverage).