Hello World! collaborator here. We're currently working on rule tuning, confidence scores, per-rule enable/disable, severity overrides, and threshold tuning for things like secret detection. Basically letting teams dial in what matters to them without just turning rules off.
One thing I think is underrated about the approach: rules run on tree-sitter ASTs, not regex, so they actually understand the structure of your code. We also have cross-file taint tracking (following data from source -> sink across function calls), which catches stuff that pattern matchers just can't. And it's still so incredibly fast.
Hey HN, I built foxguard because most security scanners use bloated python to use locally. Semgrep takes 10-30s on a medium repo. foxguard finishes in under a second on the same codebase (61x faster on the express codebase for example).
It's a Rust binary using tree-sitter for AST parsing and rayon for parallelism. 100+ built-in rules across JS/TS, Python, Go, Ruby, Java, PHP, Rust, C#, Swift. No JVM, no Python runtime, no network calls.
The idea:
if your security scanner is fast enough to run on every save (not just in CI), people might actually use it.
> npx foxguard .
to try it
Happy to answer questions about the tree-sitter approach, rule implementation, or the Semgrep compatibility layer.
One thing I think is underrated about the approach: rules run on tree-sitter ASTs, not regex, so they actually understand the structure of your code. We also have cross-file taint tracking (following data from source -> sink across function calls), which catches stuff that pattern matchers just can't. And it's still so incredibly fast.
reply