knostic/OpenAnt: Open-Source LLM Scanner for Verified Vulnerability Discovery

knostic/OpenAnt: Open-Source LLM Scanner for Verified Vulnerability Discovery

Security teams and open-source maintainers face a persistent challenge: traditional static analysis tools drown engineers in false positives, while missing real vulnerabilities that attackers eventually exploit. The gap between "something looks suspicious" and "this is actually exploitable" wastes hours of triage time and leaves critical flaws undiscovered. knostic/OpenAnt addresses this directly with a two-stage pipeline that uses large language models to first detect potential issues, then actively attack them to verify which ones are genuine.

Developed by Knostic and released under Apache 2.0, OpenAnt represents a pragmatic approach to AI-assisted security testing. With 680 GitHub stars and 103 forks, it's gaining traction among defenders who need verified findings rather than noisy alerts. This article covers what OpenAnt does, how it works, and how to run it on your own code.

What is knostic/OpenAnt?

OpenAnt is an open-source LLM-based vulnerability discovery product maintained by Knostic, a company focused on protecting AI agents and coding assistants. Unlike Knostic's commercial offerings, OpenAnt is explicitly not a competitor to OpenAI's Aardvark (now Codex Security) or Anthropic's Claude Code Security. Instead, it's positioned as a community resource for defenders and open-source maintainers.

The project's architecture reflects its research origins. The core pipeline—parsing, enhancement, analysis, verification, and reporting—is implemented in Python^{↗ Bright Coding Blog} 3.11+, while the CLI is built in Go 1.25+. This polyglot design separates the heavy LLM orchestration work (Python) from the fast, portable command interface (Go). The tool currently supports Go and Python as production-ready languages, with JavaScript^{↗ Bright Coding Blog}/TypeScript, C/C++, PHP^{↗ Bright Coding Blog}, and Ruby in beta.

OpenAnt's distinguishing characteristic is its two-stage verification philosophy: Stage 1 detects potential vulnerabilities using LLM reasoning, and Stage 2 actively attacks those candidates to confirm exploitability. What survives this process is reported as a verified finding. This approach directly targets the false positive problem that plagues conventional security scanners.

The project is explicitly described as having started as a research project, with some features still in beta. Knostic offers free scanning for open-source projects via a submission form, and the codebase welcomes community contributions.

Key Features

Two-Stage Verification Pipeline OpenAnt's core innovation is its detect-then-attack methodology. The analyze phase identifies candidate vulnerabilities, and the verify phase attempts to confirm them through dynamic testing. This structural separation means findings that reach the final report have survived active validation, not just pattern matching.

Multi-Provider LLM Support The tool ships with adapters for Anthropic, OpenAI, and Google (Gemini), with each provider configurable per pipeline phase. The default openant-default config uses Claude Opus 4.6 for detection and verification phases, Claude Sonnet 4 for other phases—reflecting a cost-performance optimization where stronger reasoning models handle critical security decisions.

Configurable Phase-Specific Models Advanced users can assign different (provider, model) pairs to each of seven pipeline phases: app_context, llm_reach, enhance, analyze, verify, dynamic_test, and report. This granularity lets teams optimize for their budget and latency constraints.

Extensible Adapter Layer Adding a new LLM provider requires implementing a Python LLMAdapter Protocol, a factory for contract tests, and registry entries. To also appear in the interactive setup wizard, contributors add Go touch-points for probe support. Twelve contract tests validate new adapters automatically.

Project-Centric Workflow OpenAnt initializes projects with openant init, creating persistent workspaces under ~/.openant/projects/<org>/<repo>/. This design supports iterative analysis and multi-project workflows through openant project switch and -p flags.

Managed Python Environment The Go CLI automatically creates a managed venv at ~/.openant/venv/ on first use, eliminating manual Python dependency management for most users.

Use Cases

Open-Source Maintainer Proactive Scanning OpenAnt's stated purpose is helping "open source maintainers stay ahead of attackers." Maintainers can run it against their own repositories before releases, or submit repos to Knostic's free scanning service. The verified-findings approach reduces the noise that makes continuous security monitoring impractical for volunteer-run projects.

Security Team Triage Augmentation For organizations with existing SAST tools, OpenAnt serves as a second-stage filter. Run it against high-priority codebases to verify whether flagged issues are actually exploitable, focusing human review time on confirmed problems rather than theoretical ones.

Research and Vulnerability Disclosure Knostic notes the tool is "in the vulnerability disclosure process for its findings." Security researchers can use OpenAnt to systematically discover and verify flaws before coordinated disclosure, with the attack verification providing reproducible proof-of-concept evidence.

LLM Security Pipeline Validation Teams building AI-powered coding assistants or agents can use OpenAnt to test whether their generated code contains exploitable patterns. This aligns with Knostic's commercial focus on agent security, even though OpenAnt itself is a general-purpose scanner.

Local Pre-Commit Security Checks Developers can integrate openant scan --verify into pre-commit hooks or CI pipelines for languages with stable support (Go, Python), catching verified vulnerabilities before code reaches production.

Installation & Setup

Build the CLI

OpenAnt requires Go 1.25 or later. Clone the repository and build from source:

cd apps/openant-cli && make build

This compiles the Go source and outputs the binary to apps/openant-cli/bin/openant.

Add to PATH

Symlink the binary for global access. Run this from the repository root:

ln -sf "$(pwd)/apps/openant-cli/bin/openant" /usr/local/bin/openant

The $(pwd) resolves to the absolute path of the current directory, so executing from the repo root is essential.

Configure LLM Access

Interactive wizard (recommended):

openant setup llm

This prompts for a config name, provider selection per phase (anthropic, openai, or google), and API keys. The wizard validates each provider+model pair with a 1-token request before writing ~/.config/openant/config.json.

Quick path for Anthropic-only setups:

openant set-api-key sk-ant-...
openant scan /path/to/repo

This uses the built-in openant-default config—Claude Opus 4.6 for detection phases, Sonnet 4 for others—without creating a config file.

Python Runtime

The CLI locates Python 3.11+ in this priority:

1. OPENANT_PYTHON environment variable (pin specific interpreter)
2. Managed venv at ~/.openant/venv/ (auto-created)
3. python3 / python on PATH

If none qualify, the CLI exits with an error pointing to python.org downloads. Rebuild stale venvs by deleting ~/.openant/venv/ and rerunning any openant command.

Real Code Examples

Example 1: Initialize and Scan a Remote Repository

# Initialize a remote Go repository
openant init https://github.com/example/project -l go

# Run full pipeline with verification
openant scan --verify

The init command clones the repository, creates a project workspace, and sets it as active. The -l go flag is required and must match a supported language. The scan --verify flag runs the complete pipeline including the attack-based verification stage—omitting it skips verification.

Example 2: Hand-Authored Multi-Provider Configuration

{
  "$schema_version": 2,
  "default_llm": "my-llm",
  "llm_providers": {
    "anthropic": {"type": "anthropic", "api_key": "sk-ant-..."},
    "openai":    {"type": "openai",    "api_key": "sk-proj-..."},
    "google":    {"type": "google",    "api_key": "AIza..."}
  },
  "llm_configs": {
    "my-llm": {
      "app_context":  {"provider": "openai",    "model": "gpt-4o-mini"},
      "llm_reach":    {"provider": "anthropic", "model": "claude-opus-4-6"},
      "enhance":      {"provider": "openai",    "model": "gpt-4o-mini"},
      "analyze":      {"provider": "anthropic", "model": "claude-opus-4-6"},
      "verify":       {"provider": "anthropic", "model": "claude-opus-4-6"},
      "dynamic_test": {"provider": "google",    "model": "gemini-2.0-flash"},
      "report":       {"provider": "google",    "model": "gemini-2.0-flash"}
    }
  }
}

This configuration demonstrates cost optimization: lightweight models (gpt-4o-mini, gemini-2.0-flash) handle context generation, enhancement, and reporting, while premium reasoning models (claude-opus-4-6) execute security-critical detection and verification. The base_url field supports OpenAI-compatible proxies for each provider.

Example 3: Multi-Project Workflow

# List all projects with active marker
openant project list

# Switch context between projects
openant project switch org/repo-a
openant parse

# Or target directly without switching
openant parse -p org/repo-b

The project system maintains persistent state per repository, enabling parallel work across multiple codebases without re-initialization.

Advanced Usage & Best Practices

Model Selection Strategy The default phase-to-model mappings reflect Knostic's operational experience. For budget-conscious deployments, maintain strong models (claude-opus-4-6, o1, gemini-1.5-pro) for analyze and verify only; downgrade app_context, enhance, and report to cheaper alternatives. The dynamic_test phase's model choice affects execution speed more than accuracy.

Local and On-Prem Inference The adapter architecture supports custom base_url configurations for OpenAI-compatible and Anthropic-compatible proxies. For teams with [INTERNAL_LINK: self-hosted LLM infrastructure], this enables routing through internal gateways, vLLM deployments, or OpenRouter. Full Ollama and vLLM adapters are on the roadmap.

API Key Hygiene Config files at ~/.config/openant/config.json are created with 0600 permissions. Rotate keys regularly, and consider using environment-variable injection or secret managers rather than storing keys in plaintext configs for production CI usage.

Language Maturity Awareness Go and Python have stable support; beta languages (JavaScript/TypeScript, C/C++, PHP, Ruby) may produce less reliable parsing or analysis. Verify findings from beta language scans manually before acting on them.

Pipeline Step Debugging Run phases individually (parse, enhance, analyze, verify, build-output) when investigating unexpected results. Each step reads from and writes to the project's scans/ directory, enabling inspection of intermediate artifacts.

Comparison with Alternatives

OpenAnt's explicit non-competition stance with Aardvark and Claude Code Security is notable—it's positioned as a community alternative rather than an enterprise competitor. The trade-off is operational complexity: you manage LLM provider accounts, API costs, and model selection rather than using a bundled service. For teams prioritizing verified findings over scan speed, this trade-off is intentional.

FAQ

What LLM providers does OpenAnt support? Anthropic, OpenAI, and Google (Gemini) with full tool-calling support. Ollama, vLLM, Cohere, Mistral, Groq, Bedrock, and Azure OpenAI are on the roadmap.

Is there a hosted version? Knostic offers free scanning for open-source projects via form submission at knostic.ai/blog/oss-scan. A self-serve API for partners is a future possibility.

What does "beta" mean for supported languages? JavaScript/TypeScript, C/C++, PHP, and Ruby parsing and analysis may be less reliable than Go and Python. Findings should be manually verified.

How much does it cost to run? Token costs vary by provider, models selected per phase, and codebase size. Knostic details this in their technical blog post. No fixed pricing exists—it's pay-per-use through your LLM provider accounts.

Can I use consumer subscriptions (ChatGPT Plus, Claude Pro, Gemini Advanced)? No. These don't include API quota. You need separate API-tier keys from each provider's developer console.

Is OpenAnt safe to run on production code? The verify phase executes dynamic tests that may modify state. Only scan code you own or have explicit permission to test. The tool is intended for defensive purposes only.

How do I contribute a new LLM provider? Implement the Python LLMAdapter Protocol, add factory and registry entries, and optionally add Go wizard touch-points. See docs/features/llm-providers/HOW_TO_ADD_AN_ADAPTER.md.

Conclusion

knostic/OpenAnt occupies a specific niche in the security tooling landscape: open-source, LLM-powered vulnerability discovery with active verification. It's not a drop-in replacement for fast static analysis, nor does it compete with the integrated security offerings from major AI labs. Instead, it serves defenders and maintainers who need confidence that reported issues are real and exploitable.

The project is best suited for security-conscious teams with existing LLM provider accounts, open-source maintainers seeking free scanning, and researchers performing coordinated disclosure. Its beta status and research origins mean users should expect some rough edges, particularly in non-Go/Python languages.

If verified security findings with minimal false positives align with your workflow, explore the codebase, read the technical details on Knostic's blog, and consider contributing to the roadmap. Start at https://github.com/knostic/OpenAnt.