Notifications
Clear all
Topic starter
02/08/2026 12:27 pm
TL;DR: Cross-platform runtime gaps, build-system constraints, and Windows-specific file semantics can block local SAST delivery, according to Semgrep. The broader lesson is that developer-side security feedback only scales when tooling, packaging, and execution environments are treated as part of the governance problem, not just the scanner itself.
NHIMG editorial — based on content published by Semgrep: Windows support for Semgrep's local SAST tooling through JavaScript and WebAssembly
Questions worth separating out
Q: How should security teams validate developer security tools across operating systems?
A: They should test the tool in the exact environments developers use, including native Windows, macOS, Linux, and any sanctioned fallback such as WSL or containers.
Q: Why do developer security tools fail when they rely on Unix assumptions?
A: Unix assumptions often hide dependencies on process spawning, signals, path layouts, newline handling, and device files such as /dev/null.
Q: What do teams get wrong about local scanning versus CI scanning?
A: They often assume CI scanning is enough because it eventually catches issues.
Practitioner guidance
- Validate security tooling on every developer platform Run scanners and IDE extensions on the same operating systems your engineers use, then record where local execution depends on WSL, container wrappers, or other workarounds.
- Separate runtime adapters from security logic Design security tools so the core detection or policy engine is insulated from platform-specific I/O, process, and filesystem code.
- Test for silent failure, not only exceptions Check whether your tooling writes state, reads files, and suppresses output correctly when the operating system behaves differently from Unix defaults.
What's in the full article
Semgrep's full article covers the implementation detail this post intentionally leaves for the source:
- How the OCaml to JavaScript path was assembled with js_of_ocaml and Emscripten for Windows support
- Why Dune virtual modules let the team switch between native and JavaScript-friendly Lwt implementations
- The exact Windows newline, HOME, and NUL handling fixes that were needed for the language server
- The LLVM optimisation pass investigation that cut Wasm build times and made testing practical
👉 Read Semgrep's technical breakdown of Windows support for its local SAST tool →
Windows support for Semgrep on the command line: what changed for teams?
Explore further
02/08/2026 1:26 pm
Cross-platform delivery is now part of security control effectiveness. A scanner that cannot run locally on Windows cannot support the same developer feedback loop that it provides on Linux or macOS. That shifts the question from feature completeness to control reachability, which is a governance issue as much as a technical one. For security teams, the lesson is to measure whether controls are available at the point of development, not only in central pipelines.
A question worth separating out:
Q: How should teams decide whether platform support is good enough for security tooling?
A: They should measure whether the tool can run without special exceptions, whether it preserves state correctly, and whether it behaves consistently across file systems and shells. If a platform needs a workaround that most developers will not use, the control is not truly available. That is a governance problem, not just an engineering inconvenience.
👉 Read our full editorial: Windows support for Semgrep exposed the limits of local SAST portability
