Image: GitHub
Why it mattersMost teams only find a poisoned dependency after it is in production. A SARIF scanner catches it in a pull request instead.
Most code a company runs is not its own. One poisoned package can walk into production. A mutable GitHub Action can do the same. The known cases of this are no longer rare. The README names xz-utils, tj-actions/changed-files and event-stream. It also points at a steady stream of npm and PyPI malware. ZTrust is a new open-source scanner. The author publishes as Spectrmachina. ZTrust reads a project's lockfiles, source and workflows. It writes SARIF for the GitHub Security tab. It ties into a separate bounty protocol. The protocol pays people in shielded Zcash for finding the things the scanner cannot see.
The repository was created on 22 October. It shows 154 stars at the time of this item. It is licensed MIT. The code is written in Python 3.11 to 3.13. The project is on Trendshift's community source list in the latest sweep.
What the scanner reads
The ZTrust README lists five scanners. Secrets covers tokens for GitHub, GitLab, npm, PyPI, AWS, Stripe, Slack, Google, OpenAI, Anthropic and Zcash. It also covers committed environment files and high-entropy credentials. Typosquat compares the dependency list against npm, PyPI and crates.io. It flags look-alike names such as reqeusts, crossenv and l0dash. Integrity flags missing lockfile hashes. It also flags HTTP sources, unpinned requirements and install scripts. CI reads GitHub Actions workflows. It looks for unpinned actions. It looks for pull_request_target script-injection patterns. It looks for overly broad token permissions. The vulnerability scanner reads OSV.dev for known CVEs. It also reads the OpenSSF known-malware feed. Supported lockfile ecosystems include Python, JavaScript, Go modules and Cargo.lock.
Outputs are a terminal report, JSON, and SARIF 2.1.0 with security-severity set. GitHub's code-scanning Security tab reads SARIF directly. The release includes a pinned GitHub Action. The action asks for security-events write permission. A scan then runs on every push and pull request.
The bounty protocol
The second half of the project is what the README calls a bounty protocol. A maintainer funds a pool. The maintainer sends Zcash to a Unified Address. A viewing key is optional. If published, anyone can audit the balance without seeing who got paid. A researcher first commits a salted SHA-256 of their report. The ZTrust API timestamps the commitment. The researcher later reveals the full report. The earliest commitment wins any duplicate. Accepted findings are paid out through Zcash to a shielded address. The payout carries an encrypted memo. The toolkit includes address validation, Unified Address support and payment URIs.
What is missing from the picture
ZTrust is five days old. The bounty API is new code. The Zcash pool has no public history behind it. The README describes the economic model as the point of the project. It is not a measured outcome. A team adopting the scanner today gets the SARIF output. The track record of findings paid out is not yet there.
Source
- Repository, scanner rules and bounty protocol: Spectrmachina/Ztrust on GitHub.
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.
