true, right now it's AST pattern matching with `pattern-inside`/`pattern-not-inside` for syntactic scoping. I changed the description. Intraprocedural dataflow is the next step (tracking in #10) and while trying to keep it close linter latency.

update: `NoPickle`/`NoYamlLoad` string-match the callee text, so `import pickle as p; p.loads(...)` and `from pickle import loads as d` slip past. Filed as #7 with a fix plan (intraprocedural alias table). Thanks!

thx for the tip, I'll measure and see if LoC time is stable accross different codebases. Mind if I cite it in the readme (anonymized)?

Sure thing, feel free. If you’d like more details, you send me an email at msplanchard (at gmail)

update: filed #9 to build a labeled corpus and publish per-rule numbers.

didn't measure that yet, but definitely thinking of adding it into scope soon

cool, will check it out thanks!

Appreciate it! cloudformation isn't in scope today but the perf approach (tree-sitter + parallel file walk + rule pre-filtering) transfers, so happy to check it out.

quick correction: built-in rules are compiled in, but foxguard also loads Semgrep-compatible YAML rules at runtime via --rules <path> (or .foxguard.yml). You can add or modify rules without touching the binary. The rust-coded rules are just the default pack for zero-config speed :D

I work as a cyber defense engineer in the SOC of one of the largest companies in my country. We've tried many SOAR platforms over the years and we've never figured out a good solution to simplify the lives of our less technical analysts while allowing our technical staff to quickly and easily iterate our platbooksa and tweak processes, sometimes using coding ai tools.

The problem is usually that they each have their own custom abstraction layer when defining actions / playbooks. Some are low-code (like swimline) so you gotta mess around with some UI bs when configuring a new use-case, and it doesn't even have proper Git versioning, while some have yaml for everything < this sounds cool until you actually have like 1000 playbooks that are a pain to deal with and not as good as full on code. Also those who support "custom-code" via python are usually sandboxing runners to an extent that most of the customization is barely possible...

I'm not even going to get into the costs that most platforms require when adding all these features, but in any case I've been building the perfect tool for myself, and I know a bunch of colleagues around here dreaming of a solution like this as well.. It's fully open-source, please contribute and try it out if it is also useful to you!

Appreciate yall, as much as I hate marketing, without some sort of feedback from more users, it would be difficult to iterate and know where to improve!

Thanks for reading this far :D have a nice day

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.