Garnet Guard / Roadmap

Roadmap

Garnet Guard is in alpha. This is what comes next, by version. Versions and seasons are targets, not promises; the detail, with an issue for each planned check, is in the tool's ROADMAP.md. Every check listed here is open source under Apache-2.0, like the ones that ship today.

Version	When	What it adds
0.2 alpha	Out now	The GitHub Action, rules for PyPI and npm releases, policy files, SARIF
0.3 beta	Winter 2026–27	Checks before install, hooks for coding agents, npm lockfiles, two rules
1.0 stable	Spring 2027	Fixed interfaces, a VS Code extension, the remaining gap checks, fuzzing
2.x	Summer–fall 2027	Release history, more signals, plugins, more CI
3.x	2028	More ecosystems, checks built into package managers, an open dataset

0.2: alpha, out now

0.2.0, the first full release, came out on October 31, 2026. It has every rule built so far; each has a page under Rules, and the rules not built yet say planned. The GitHub Action is a preview. What Garnet can't see yet is on Limits.

0.3: beta, winter 2026–27

• Checks before install. garnet pip install … and garnet uv add, sync and lock work out what would change without installing it, run Garnet's checks on that, and install only if nothing blocks (spec §10.3). garnet npm install follows.
• Hooks for coding agents. A pre-install hook for Claude Code and Codex runs the same checks when an agent adds a package, and stops the install when the verdict is block (spec §10.4).
• npm lockfiles. The Action reads package-lock.json, Yarn and pnpm lockfiles, so it checks npm updates in a pull request the way it checks PyPI ones.
• Two planned rules. GRN-C006 reports a file in a wheel with no counterpart in the source archive (#60). GRN-C005 reports obfuscated code and sensitive calls looked up by a name built at run time (#54).
• New numbers. The everyday-update test on Results is run again with the 0.3 rules and published with a rate for each rule.

1.0: stable, spring 2027

• Fixed interfaces. From 1.0, Garnet follows semantic versioning: the CLI and its exit codes, rule IDs, the policy format (version = 1), the JSON report and the Action's inputs and outputs change only in a major release (spec §12).
• A VS Code extension. Garnet's findings in the editor, on the lockfile line that pins the new version, with the rule page linked. It runs the CLI's check in the background when a lockfile changes, holds no rules of its own, runs only in workspaces you trust and sends nothing anywhere. It comes after 0.3, around February to March 2027, free on the VS Code Marketplace and Open VSX (spec §10.5). Until then, garnet check --format sarif shows the same findings on the same lines in Microsoft's SARIF Viewer extension (how).
• The remaining gap checks. Between 0.3 and 1.0, checks for the gaps on Limits that have one planned:
  • a sensitive call made under another name (#91);
  • a hook installed at import (#55);
  • a release published from a different branch, tag or trigger than the trusted one (#56), or by a release workflow that changed in between (#57);
  • a git tag made after the upload or on a commit outside the default branch (#61), and trust checks on releases skipped in between (#62);
  • a first look at the code of a newly added dependency (#58);
  • a payload in a model or data file that a loader runs (#59);
  • a scheduled check of a deployed environment, for updates that never reach a lockfile (#63).
• Fuzzing. Every parser is fuzzed for at least an hour of CPU time per release, with no crash, hang or limit bypass (spec §13). An outside security review of the archive and network code and the Action follows if a grant or a volunteer makes it possible.
• Wrong flags first. A report that a flag was wrong is fixed before a new rule is added.

2.x: summer–fall 2027

• Release history. A baseline from each package's recent releases, not only the last one, so a one-off change after 40 consistent releases stands out and a project that always varies doesn't (#64).
• Changed inputs to calls a package already makes. A new host, URL or command passed to a sensitive call the trusted release also made (#65). This is the clearest gap on Limits.
• More signals. Files in the source archive that aren't in the tagged git tree, beyond the Python files GRN-C007 already compares, and changed maintainers or organization roles where the registry shows them.
• Plugins and shared policy. A stable plugin API for third-party checks and ecosystems, and a policy file that can extend another, so a team keeps one policy across its repositories.
• More CI. Recipes for GitLab CI, Buildkite and pre-commit, and a container image.

3.x: 2028

• More ecosystems, in order of how much provenance data they publish: crates.io, RubyGems, Maven Central, then Go modules.
• More source hosts for the tag and source checks: GitLab and Codeberg.
• Checks in the package managers. A proposed trust policy for uv and pip, modelled on pnpm's trustPolicy, with Garnet's test data as evidence, and the rules offered to registries as warnings at publish time. A rule that a package manager takes on natively comes out of Garnet.
• An open dataset of the release history Garnet's tests collect, for researchers.
• Governance. At least two maintainers from different organizations.

Not planned

A malware feed of Garnet's own, running or sandboxing packages, and closed-source detection of any kind. Garnet reads each release as files and never runs it.

To suggest something or follow the work, see the issues.