foxguard is a Rust-based static analysis engine that bundles taint tracking, secrets detection, OSV dependency scanning, and post-quantum crypto audit for security teams reviewing code they are authorized to assess.
| Tool | 0sec-labs/foxguard — fast local security scanner for code, secrets, dependencies, and crypto risk, written in Rust |
| Category | Static application security testing (SAST) and multi-surface code scanning |
| Primary Use | Scanning codebases with foxguard ., triaging findings in the TUI, and exporting SARIF/CycloneDX results in CI pipelines and pre-commit hooks |
| Safe Use | Intended for developers and authorized security teams auditing their own codebases, internal repositories, and client-engagement targets with written permission |
| Telemetry Note | The CLI is local and offline-first; the hosted GitHub App emits structured event=foxguard.scan.completed logs with repository and PR correlation fields that blue teams can monitor for scan activity |
foxguard positions itself as a batteries-included local scanner that collapses several security review surfaces into a single fast binary: static code analysis, secrets detection, dependency vulnerability scanning via OSV, and a post-quantum cryptography audit mode. The project is written in Rust, MIT-licensed, sits at roughly 295 stars on GitHub, and is integrated into 0sec, the broader open cybersecurity harness from the same 0sec-labs organization. What makes it interesting compared to a typical linter is the breadth: 200+ built-in rules across 12 source languages, taint tracking for 14 languages, and cross-file analysis for Python, JavaScript, Go, Java, Ruby, PHP, C#, and Kotlin. That is an ambitious scope for a single tool, and the README spends considerable effort documenting how the pieces fit together.
The scanning core exposes distinct subcommands rather than forcing everything through one mode. foxguard . runs the full sweep, foxguard diff main . restricts findings to what a branch introduced relative to main, foxguard secrets . hunts for leaked credentials and keys, foxguard sca . checks dependencies against OSV advisories, and foxguard pqc . performs the post-quantum crypto audit. The diff mode is a pragmatic touch for CI workflows where reviewers care about new findings rather than drowning in pre-existing debt, and the post-quantum audit is a capability most SAST tools in this class simply do not ship.
Interoperability is clearly a design priority. foxguard implements a Semgrep/OpenGrep-compatible YAML bridge that the README claims loads roughly 98% of the public rule registry, with a published coverage report at docs/parity/registry-coverage.md. This means existing Semgrep rule investments are not stranded — teams can migrate gradually and keep custom YAML rules. On the output side, the tool emits terminal output, JSON, SARIF, CycloneDX 1.6 CBOM, and Semgrep-compatible JSON via --format semgrep-json, which covers the formats that GitHub code scanning, dependency-graph tooling, and most CI platforms ingest natively.
Installation is refreshingly multi-channel, which suggests the maintainers care about developer ergonomics across ecosystems. The zero-install path is npx foxguard ., and the same binary ships on PyPI as prebuilt wheels for Python 3.9+ across Linux glibc 2.28+ (x86_64/ARM64), macOS Intel and Apple Silicon, and Windows x86_64. There is also pipx install foxguard, a curl-driven standalone installer, cargo install foxguard for source builds, and published crates.io and npm packages. Alpine/musl users are directed to the standalone Linux binaries, and the Python packages deliberately provide no Python API — they are just delivery vehicles for the native CLI.
Supply-chain hygiene is documented better than most tools of this size. Standalone installers verify GitHub release binaries against checksums.txt, and releases publish GitHub artifact attestations that can be checked with gh attestation verify, with additional detail in docs/release-provenance.md. For a tool whose job is telling you whether your dependencies are trustworthy, it is reassuring that the project holds itself to the same standard — readers running this in CI should verify attestations on first adoption.
CI and editor integration is first-class rather than an afterthought. A GitHub Action exists at 0sec-labs/foxguard/action@v0.14.1 with path, severity, fail-on-findings, and upload-sarif inputs, plus a pre-commit hook pinned to rev: v0.14.1 for catching issues before they land. Beyond that, the README lists a hosted GitHub App, a VS Code extension, a Claude Code plugin, and an MCP server — the MCP integration in particular hints at the current direction of the ecosystem, letting AI coding assistants consume scan results as context during development rather than as a post-hoc gate.
The terminal review experience is where the README goes deepest. foxguard tui . launches an interactive triage interface with Scan, Diff, Secrets, and PQC modes selectable via arrow keys and Tab. The keybinding model is dense but coherent: j/k and arrows navigate, v expands details, 0–4 and c adjust severity and confidence thresholds, f cycles review-status filters, and i previews triage actions. Wide terminals render findings beside their detail pane with inline source-range highlighting; narrower ones fall back to a list view. Secrets findings deliberately show redacted snippets rather than loading raw source into the pane, which is a thoughtful defensive default for a tool that runs on developer workstations.
State handling in the TUI is unusually well-engineered for a scanner. Review marks persist automatically in per-user storage — $XDG_STATE_HOME/foxguard/tui on Linux, Application Support on macOS, %LOCALAPPAPPDATA% on Windows — scoped to the canonical project root and scan mode. Atomic writes and revision checks prevent two terminals from silently clobbering each other, and storage failures surface a visible UNSAVED marker with explicit retry (w), reload (r), and backup-and-reset (Shift+R) paths. Notably, the storage holds fingerprints and filter settings, never source code, which limits the blast radius if a developer's state directory is exposed. Editor integration respects $VISUAL then $EDITOR, falling back to nvim, vim, nano, or vi, and supported editors jump directly to the finding's line.
Baseline workflows deserve attention from anyone running repeated assessments. foxguard tui --baseline .foxguard/baseline.json . compares current results against a saved baseline and separates findings into introduced, recurring, and resolved categories. The README is honest about semantics: resolved means absent from the current scan output, not verified remediation, and meaningful comparison requires equivalent scope, rules, and thresholds. Exports from the TUI include the full current scan rather than only filtered rows, existing files require explicit y confirmation before overwrite, writes are atomic, and destination symlinks — including dangling ones — are rejected outright. These are the operational details that reveal a tool designed by people who have shipped scanners into real pipelines.
The auto-fix capability is scoped conservatively. foxguard --fix src/ applies supported taint fixes in place, with targets checked against the canonical scan directory so findings outside scope are skipped. Python command-injection fixes will add import subprocess when needed while preserving module docstrings and future imports, and the README explicitly advises reviewing generated changes before committing. Error handling is similarly deliberate: file-read, metadata, and directory-traversal failures in the native scanner exit with code 2 rather than emitting a misleadingly clean report or overwriting a baseline, and unsupported, binary, or oversized files remain skips with notices the reviewer should inspect when checking coverage.
For teams operating the hosted GitHub App, the README includes operational guidance that reads like it was written from production scars. The app writes newline-delimited JSON logs with event=foxguard.scan.completed and event=foxguard.scan.failed records carrying delivery, installation, repository, PR, commit, duration, and usage_scope fields, and the authors recommend keeping identifiers as log fields rather than metric labels to avoid cardinality explosions. FOXGUARD_INTERNAL_ACCOUNTS classifies installations as internal, external, or unknown, with the sensible caveat that external activity is not proof of a paying customer and scans are not people. The installation registry reconciles hourly against GitHub's App installation API, failed refreshes retain state, and operators are told to monitor foxguard.installations.reconcile_failed and size FOXGUARD_PR_WORKERS against scanner peak memory to avoid silent child-process OOM kills.
In the broader landscape, foxguard competes with Semgrep and OpenGrep on rules compatibility while adding integrated secrets scanning, OSV dependency checks, and a PQC audit under one roof, all in a fast local binary with no runtime dependency on a rule marketplace. For authorized security teams and developers doing shift-left review of their own code, the combination of diff mode, baseline triage, SARIF export, and a genuinely usable TUI makes it a credible daily driver rather than a novelty. The main caveats are that its coverage claims — like the 98% registry-parity figure — should be validated against your own rule corpus before migration, and that resolved findings in baseline mode still require human verification. As a defensive, developer-side tool, it fits cleanly into pre-commit, CI, and IDE workflows with no offensive capability at all.
0sec-labs/foxguard.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.