Open-Source AppSec Agents for Code Security Audits

The short answer

If the question is simply “what open-source AppSec agent can audit code?”, there is no single honest winner. The category currently spans at least four different products: agent frameworks that reason over source, portable playbooks that shape an existing coding agent, autonomous pentest runtimes that execute proofs, and deterministic SAST engines that feed them signals.

SecHelix sits between the first two categories and is growing an optional runtime: the portable Agent Skill works without an account or runner, while the V4 runtime adds a replayable reasoner DAG, budgets, coverage history and bounded evidence execution. Its defining rule is not “find more alerts”; it is that a material finding remains a claim until evidence and an independent refutation attempt support it.

What each project actually optimizes for

Source repositories: SecHelix · OWASP AppSec Agent · OWASP Secure Agent Playbook · SEC-AF · Strix · Vulnhuntr · Opengrep.

OWASP AppSec Agent: explicit jobs for the security lifecycle

OWASP AppSec Agent exposes specialized roles instead of one giant “review everything” prompt. Its current role catalog includes full-repository and PR reviewers, a PR adversary, a false-positive adversary, a threat modeler, a finding validator, a code fixer and a QA verifier. That separation is useful because discovery, skepticism, remediation and QA are different jobs.

SecHelix already separates hunter, independent verifier, remediator and patch verifier, but the OWASP project highlights two areas worth keeping explicit in SecHelix: a first-class threat-model artifact and a durable loop that learns from dismissed candidates without turning a past dismissal into a future blind spot.

OWASP Secure Agent Playbook: procedures and cross-standard traceability

The Secure Agent Playbook takes a different approach: structured OWASP-grounded procedures and a team lead that dispatches code, dependency, API, mobile and AI-security specialists. Findings link to CWE and OpenCRE-backed cross-standard references. Its AI-security material includes agent permissions, MCP servers, LLM risks, prompt injection and multi-agent threat modeling.

SecHelix already covers AI/MCP authority and evidence-to-control mapping, but two useful gaps remain visible from this comparison: the native/mobile lane must become a built, applicability-gated capability rather than a plan, and cross-standard references should be as navigable for a reader as they are machine-readable.

Opengrep and Vulnhuntr solve different halves of data-flow review

Opengrep is not an AI agent. That is precisely why it is valuable underneath one. A deterministic taint engine can cover broad language surfaces repeatedly while a reasoning layer decides whether the path represents attacker control, a failed boundary and concrete impact. SecHelix therefore treats SAST output as candidate evidence, never as a verdict.

Vulnhuntr is narrower and more research-oriented: it follows remote user input through Python call chains to look for a small set of exploitable vulnerability classes. The idea SecHelix should borrow is not its Python limitation; it is the discipline of starting from attacker-controlled input and following a concrete path instead of beginning from a scary sink and assuming reachability.

SEC-AF and Strix show why execution matters

SEC-AF makes orchestration visible: multiple reasoners, exploitability-oriented validation, structured traces and explicit execution cost. Strix goes further into active testing with a containerized pentest runtime and proof-of-concept validation. Those systems demonstrate something a prompt-only security skill cannot guarantee: who ran, what they were allowed to do, how long they took and what evidence they actually produced.

SecHelix V4 is intentionally adopting that execution discipline without adopting an unrestricted offensive sandbox. Its runner is optional, STATIC remains the default, budget exhaustion fails closed, network authority is deny-by-default, and runtime evidence cannot manufacture missing attacker control.

Where SecHelix is deliberately different

• Applicability has four honest outcomes — APPLICABLE, NOT_APPLICABLE, UNKNOWN and BLOCKED — so missing evidence is not rewritten as absence.
• Important candidates go to an independent verifier whose job is to refute the claim, not to make the original hunter sound more confident.
• Authorization and business logic are first-class surfaces: role/object/action matrices, tenant isolation, state machines, payments, retries, idempotency and race windows.
• AI/MCP review models agent → server → tool → permission → data authority instead of reducing AI security to prompt injection.
• A verified fix is expected to gain regression proof and a retest; the release gate fails closed when required evidence is unavailable.
• The V4 runner records DAG, context views, budget, replay and coverage history while remaining optional to the portable skill.

Start with the AppSec agent guide or try SecHelix in five minutes.

What the evidence allows us to claim

SecHelix currently has one uncontaminated blind label-only measurement on an authored 76-case suite: precision 0.950, detection recall 1.000 and false-positive rate 0.053. That run did not execute the full SecHelix workflow. Full-workflow performance and cross-tool comparison remain NOT_MEASURED.

Choose by the question you need answered

The strongest practical stack may combine categories: deterministic SAST for breadth, an AppSec agent for architectural/business-logic reasoning, and bounded runtime proof only where authority and environment permit it.