OpenAnt is an open source LLM-based harness from knostic that finds verified security flaws in code you own through a two-stage detect-then-attack pipeline, aimed at defenders and maintainers.
| Tool | knostic/OpenAnt — open source LLM-based vulnerability discovery and remediation harness with adversarial verification |
| Category | AI-assisted static analysis and dynamic verification (sast + LLM pipeline) |
| Primary Use | Scanning repositories you own or maintain with openant scan --verify to surface verified, low-false-positive vulnerabilities before attackers do |
| Safe Use | For authorized security assessments, open source maintainers hardening their own projects, and defensive research in lab environments |
| Telemetry Note | Writes local artifacts under ~/.openant/projects/<org>/<repo>/scans/ per commit and stores API keys in ~/.config/openant/config.json with 0600 permissions; exits with code 1 when findings exist, which CI pipelines can observe |
OpenAnt, released by knostic under the Apache-2.0 license, is positioned as the first open source LLM-based vulnerability discovery and remediation product — or, as the README now calls it, a harness. Its core thesis is refreshingly blunt: Stage 1 detects, Stage 2 attacks, and what survives the adversarial verification is real. That framing matters because the industry's loudest complaint about LLM-assisted sast is false-positive noise, and OpenAnt's architecture is explicitly designed around minimizing both false positives and false negatives by making the model prove its findings rather than merely assert them. The project stems from research by Nahum Korda and Gadi Evron, documented in an arXiv paper titled OpenAnt: LLM-Powered Vulnerability Discovery Through Code Decomposition, Adversarial Verification, and Dynamic Testing, and the README is candid that it began as a research project with many capabilities shipping as beta.
The maintainer's rationale for open-sourcing is worth reading closely. With the explosion of AI-discovered vulnerabilities, the hope is that open source maintainers can run OpenAnt against their own repositories — or submit them for free scanning via Knostic's program — to stay ahead of attackers. The README explicitly disclaims any ambition to compete with Aardvark from OpenAI (now Codex Security) or Claude Code Security from Anthropic, noting that Knostic's commercial focus is protecting agents and coding assistants from supply-chain risks like MCP servers, extensions, and skills. That separation of concerns is analytically interesting: the tool exists to give the defensive side the same class of LLM-driven discovery capability that offensive researchers have been assembling in private harnesses.
Language coverage is broad but tiered. Go, Python, and C/C++ are listed as fully supported, while JavaScript/TypeScript, PHP, Ruby, Zig, Swift, and Rust all sit in beta. The repo metadata shows the primary language as Python, which matches the README's statement that parsing, enhancement, analysis, and reporting code runs on Python 3.11+, while the CLI itself is a Go binary. This is a hybrid architecture: a compiled openant CLI orchestrating a Python runtime beneath it. The CLI resolves its interpreter via the OPENANT_PYTHON env var first, then a managed venv at ~/.openant/venv/ auto-created on first use, then python3 or python on PATH, and it exits with a helpful error if nothing yields 3.11+. If you upgrade Python, you delete ~/.openant/venv/ and rerun any command to rebuild it.
Local setup is a standard Go build. Running cd apps/openant-cli && make build compiles the binary to apps/openant-cli/bin/openant, which you can symlink onto your path with ln -sf. Note the Go 1.25+ requirement for the build. From there, openant setup llm launches an interactive wizard that walks you through naming a config, picking a provider per pipeline phase, and entering API keys — and importantly, it probes each unique provider+model pair with a 1-token request before committing anything to ~/.config/openant/config.json. That pre-save probe is a thoughtful touch that catches mistyped keys or unavailable models before you burn tokens on a full scan.
The seven-phase pipeline is the architectural heart of the tool: app_context, llm_reach, enhance, analyze, verify, dynamic_test, and report. Each phase routes through a configurable (provider, model) pair, and the wizard defaults encode a deliberate cost/capability split — stronger reasoning models like Claude Opus for detection, verification, and reachability review, and lighter models for context gathering, reporting, and test generation. The enhance and verify phases run an agentic tool-use loop, which means every provider adapter must support tool calling; the README warns that very small local models via Ollama may not handle those phases reliably.
Provider support is genuinely heterogeneous. Shipped adapters include anthropic, openai, google, bedrock, openrouter, and ollama. The bedrock adapter pulls credentials from the standard AWS chain (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, ~/.aws profiles, AWS_REGION) rather than an API key, and uses inference profile model IDs. openrouter acts as a single-key gateway to many vendors. ollama gives you fully local inference at zero cost — the tool reports $0 cost for local runs, which is a meaningful option for teams with data-residency constraints or no cloud LLM budget. The README also notes that provider API keys are separate from consumer subscriptions like Claude Pro or ChatGPT, a practical gotcha that trips up first-time users. Custom base_url values are accepted for OpenAI- and Anthropic-compatible proxies such as vLLM or internal gateways.
Extending the adapter layer is documented with unusual precision: one Python file implementing the LLMAdapter Protocol, a factory for the contract-test harness, and a registry entry is enough to run a new adapter from a hand-authored config. Wiring it into the wizard requires a few Go touch-points in apps/openant-cli/cmd/setup.go — the supported-provider list, a probe case, and per-phase default-model maps — after which 12 contract tests run automatically against your adapter. This is a well-designed seam for anyone who needs to point the tool at a private, self-hosted inference endpoint, and the fact that the contract-test harness exists at all says something about the project's engineering discipline.
Working with a project follows a clear lifecycle. openant init <repo-url> -l go clones and registers a project (the -l language flag is required; use go or python), with --commit <sha> to pin a specific revision or a local path with --name <org/repo> for in-place analysis. Each project gets a workspace under ~/.openant/projects/<org>/<repo>/ containing project.json and a per-commit scans/ directory. The pipeline steps — parse, enhance, analyze, verify, build-output, report -f summary — each consume the previous step's output, or you can run the whole thing with openant scan --verify.
The exit-code contract deserves a paragraph of its own because it is the kind of operational detail that saves CI pipelines from subtle breakage. openant scan exits 0 for a clean scan, exits 1 when it finds vulnerabilities — which the README stresses is the tool working, not failing — and exits 2 only when the scan itself errored, with details available in the errors field of the JSON envelope on stdout. Generic CI steps that treat any non-zero exit as failure will misclassify a healthy findings run, so the README shows gating on rc greater than 1 instead of parsing stdout. Anyone wiring this into CI should internalize that contract before the first scheduled run.
From a defensive-observability standpoint, OpenAnt leaves a clean, auditable footprint: all state lives in ~/.config/openant/ (with 0600 permissions on the config holding your API keys) and ~/.openant/, and every scan produces per-commit output artifacts that can be diffed over time. For defenders and authorized assessors, the interesting question is not just what OpenAnt finds in your code, but what it would find in your code before an attacker's harness does — and with 785 stars, Apache licensing, and free scanning offered for open source projects, the barrier to answering that question is about as low as it gets.
knostic/OpenAnt.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.