MAL-HOOK Install, Build, and Git-Hook Execution Surfaces

Code that runs automatically on clone, install or build executes before any application code is invoked. This rule surfaces those execution points outside the npm package.json lifecycle (covered by other detectors), so you can read what a just-cloned repository will do before running it.

What Vulkro detects

Each rule needs an execution surface that carries a risky token: a remote fetch, a pipe into an interpreter, an eval, a base64 decode.

• MAL-HOOK-001 (High or Medium): a git hook under .git/hooks/ that is not a .sample template, or a husky hook under .husky/. A remote fetch piped into a shell is High; any other risky token is Medium.
• MAL-HOOK-002 (High): a Makefile recipe that pipes a remote fetch into a shell.
• MAL-HOOK-003 (High or Medium): a setup.py or pyproject.toml build step that shells out with a risky token, or fetches a URL and evaluates it. setup.py runs at pip install time.
• MAL-HOOK-004 (Medium): a Cargo build.rs that shells out with a risky token or fetches over the network. A plain Command::new("cmake") stays quiet.

Comments are blanked before matching, so a docblock warning against curl ... | bash does not score. The rule never certifies code safe.

How to fix

• Confirm the fetch target and executed content are ones you control.
• Replace pipe-to-shell installs with a pinned, checksum-verified artifact.
• Move anything that need not run at install time into an explicit command.

References

• OWASP A08:2021

See also: Confidence model.

---

This page is generated by vulkro rules export <out-dir> from Vulkro's built-in detector catalogue. Edits made by hand are overwritten on the next regeneration.