Monday, September 28, 2026

Inside akca: evidence-first adaptive DAST scanning from a single Go binary

Inside akca: evidence-first adaptive DAST scanning from a single Go binary

akca is an open-source Go-based DAST scanner that models an application's attack surface before launching adaptive, evidence-producing checks for injection, authorization, and client-side flaws in authorized tests.

Toolakha-security/akca — evidence-oriented DAST web security scanner written in Go, currently at v0.2.4
CategoryDynamic Application Security Testing (DAST) / web vulnerability scanner
Primary UseDiscovering endpoints, hidden parameters, and API operations on authorized web applications, then running adaptive checks via profiles like -m sql, -m xss, -m auth, and -m passive with replayable evidence
Safe UseIntended solely for systems you own or have explicit written permission to test — engagement scopes, internal labs, and CI security pipelines; the README states this authorization requirement explicitly
Telemetry NoteGenerates substantial HTTP traffic against the target and fingerprints WAF behavior; blue teams will observe multi-vector crawler traffic, parameter probing, and OAST callback attempts, plus HTML/JSON/SARIF artifacts on the operator side

akca, hosted at akha-security/akca under an Apache-2.0 license, positions itself against a specific failure mode of commodity scanners: the crawl-then-spam pattern where a broad payload set is fired at every discovered endpoint. The README's thesis is that this approach creates unnecessary traffic, trips defensive tooling, and yields weak signals that demand heavy manual triage. Instead, akca spends its early pipeline stages learning the target — technology stack, parameters, authentication state, WAF behavior — and then selects tests contextually before committing active probes. It is written in Go 1.25+ and ships as a single command-line binary, which keeps deployment trivial for consultants moving between engagement environments.

Version v0.2.4 is honest about its maturity. The README explicitly disclaims feature parity with Acunetix, Invicti/Netsparker, or Burp Suite Professional, noting it is independently maintained by one developer. That candor matters when scoping a tool for client work: what you get is a transparent, source-available engine with roughly 181 stars and a CHANGELOG.md/FEATURES.md discipline, not a commercial support contract. The stated priority is a simple, useful, dependable scanner, with a GUI planned only once the engine stabilizes — a reasonable engineering sequencing for a solo project.

Installation follows standard Go practice. With a suitable toolchain, go install github.com/akha-security/akca/engine/cmd/akca@latest puts the binary on your PATH (the README walks through GOPATH/GOBIN configuration for Linux, macOS, and Windows). Prebuilt releases cover Linux amd64/arm64, macOS Intel and Apple Silicon, and Windows x64, each accompanied by a SHA256SUMS.txt for checksum verification — a supply-chain hygiene detail worth respecting before running any scanner against client infrastructure. Browser-backed checks additionally require Chrome, Chromium, or Edge on the host.

The architecture is a staged pipeline, and the README describes it clearly enough to reason about its internals. Stage one fingerprints technologies, server behavior, WAF signals, and TLS posture, then calibrates request pacing. Stage two assembles the attack surface by combining HTTP crawling, a persistent headless-browser session, JavaScript and AST-assisted endpoint analysis (including lazy-loaded chunks), API definitions, path fuzzing, hidden parameter discovery, and 403-bypass observation. Stages three and four model test candidates and plan adaptive probes, allocating work across endpoint, method, parameter, and module combinations rather than spraying every payload everywhere. The final two stages verify signals — baseline comparisons, negative controls, replay, identity checks, OAST callback correlation — and export findings with Burp-style HTTP transactions, payloads, confidence, and proof status.

This emphasis on verification and evidence is the tool's distinguishing trait. A promising signal is replayed against baselines before being promoted to a finding, and every result carries the request, response, payload, classification, confidence, and proof-policy context needed for independent investigation. Equally notable is the coverage honesty: skipped, failed, budget-limited, or unfinished targets are recorded as incomplete coverage rather than silently treated as clean. Anyone who has watched a scanner declare a half-timed-out scan 'no vulnerabilities found' will recognize how much report quality depends on that single design decision.

Test selection happens through profiles passed with -m: sql covers SQL and NoSQL injection; xss handles reflected, DOM, stored-candidate, and blind XSS; rce spans command injection, SSTI, and deserialization; api targets BOLA/IDOR, BFLA, mass assignment, and token checks; and further profiles cover graphql, ssrf, auth, passive, and fuzz families. full enables everything and is the default. Note the README's caveat that passive still sends requests for discovery and inspection — the label describes the checking mode, not network silence, which is relevant when briefing a client about expected traffic volumes.

API-heavy engagements are well served by the import layer, which accepts OpenAPI/Swagger, RAML, Postman, HAR, GraphQL, WSDL, protobuf, and AsyncAPI inputs, including ZIP bundles. Authenticated testing is handled through a session cookie via -c or an Authorization header via -H, though the README acknowledges that some authorization checks need multiple identities or state configuration beyond a single session. A -p flag routes traffic through a proxy such as a local listener on 127.0.0.1:8080, so you can watch every probe in an intercepting proxy during a lab run — genuinely useful for validating what the adaptive engine actually sends.

The capability list is broad for a solo project: beyond the injection staples it includes XXE, LFI and path traversal, CRLF injection, React Server Components RCE checks, PDF-generation injection, LLM prompt-injection testing, JWT and OAuth/OIDC flow analysis, HTTP request smuggling (CL.TE and TE.CL), cache poisoning and CPDoS, WebSocket security, CORS misconfiguration, prototype pollution, and multi-tenant isolation checks. The README sensibly tempers this with a disclaimer: a listed capability runs only when the discovered surface, profile, safety policy, and verification prerequisites align, and no listed family guarantees detection of every vulnerability variant.

Operator resilience is addressed in the traffic management layer. The engine learns WAF behavior, applies target-aware encoding and pacing, and can pause and recover from rate limiting or host-level blocking within configured scan and time limits — for the target's benefit as much as the scanner's. The stated goal is deliberately not to exhaust the application but to find real weaknesses with a defensible request budget, which aligns with responsible-testing norms on fragile production-adjacent staging environments.

Reporting supports interactive HTML, JSON, Markdown, CSV, and SARIF output via -f and -o, the SARIF option making CI integration into code-scanning pipelines straightforward. OAST callbacks are collected over DNS, HTTP, and SMTP and correlated with the originating probe, giving blind-injection findings a reproducible proof chain rather than a heuristic guess. For an authorized workflow, the combination of replayable transactions and reproduction guidance means findings can survive review by a skeptical engineering team.

The framing throughout is authorization-first: the usage section instructs operators to use akca only on systems they own or have permission to test, with https://example.com standing in for an authorized target. From a defensive perspective, its traffic profile is observable — multi-vector crawling, parameter probing, and OAST callbacks will show up in WAF and SIEM telemetry — making it equally useful as a purple-team instrument for validating detection coverage. As a v0.x project from a single maintainer it warrants lab validation before engagement use, but the architecture, evidence discipline, and honest coverage accounting make akca a scanner worth tracking.

Official project repository for akha-security/akca.
Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Share articleFacebookXLinkedIn

Continue exploring

Browse all articles →

0 comentários:

Post a Comment

Note: Only a member of this blog may post a comment.