Vulkro Inspect - malicious-code capability surface
Vulkro Inspect reads just-cloned first-party source for malice planted by the repository's own author. It answers one question: what can this code do on my machine if I run it, and which lines should I read first?
What Vulkro detects
Each MAL-* rule emits an evidence signal starting with mal-. The vulkro inspect view and the inspect_repo MCP tool group these into behaviour buckets: trojan source, shell or backdoor shapes, credential access, credential exfiltration, install hooks, obfuscation, environment-gated execution, self-propagation, wallet access, remote code load, persistence, committed binaries, dependency integrity, and prompt injection aimed at an AI coding agent. Any new mal- signal lands in an Other bucket rather than disappearing.
Inspect never certifies code safe. There is no clean, pass or approved state, no reassuring zero-count message, and no machine-actionable proceed verb. Every report carries this disclosure verbatim: This is a static scan of code that has not run, over source an author may have crafted to evade it: it surfaces behaviors for a human to review and can never certify the code free of malicious behavior.
Several rules score two tokens found within a few lines of each other in the same file. That is co-location, not data flow: both capabilities are present and adjacent, not proven connected. Comments are blanked before matching, so a security note in prose does not score as code.
How to fix
- Treat each hit as a prompt to read that line, not a verdict.
- Decide whether the behaviour has a legitimate reason to exist in this repository.
- Do not run install scripts or build steps until you have.
References
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.