PRIVATE BETA · AUTHORIZED TESTING ONLY
See the vulnerability. See the line that caused it.
Eonycs correlates source-code analysis with live attack verification to produce evidenced findings, transparent coverage, and the exact location developers need to remediate.
Reflected XSS via search parameter
Source evidence
Runtime evidence
GET /search?q=<eonycs-canary-7f3> HTTP/1.1
200 OK — canary reflected unescaped in the response body
app/views.py:42 Coverage: 47 of 52 endpoints testedThe problem
Security signals that never meet
Most teams run two kinds of tools and get two halves of the truth. Validation and triage happen by hand, in between.
External scanners see behavior
Black-box tools observe responses from the outside, but they cannot tell you which line of code produced them.
Static tools see code
Source analysis flags suspicious patterns, but cannot prove they are reachable or exploitable in the running application.
Teams pay for the gap
Security engineers spend cycles validating results and hunting for the responsible code instead of driving remediation.
The Eonycs correlation engine
Three signals. One corroborated finding.
Eonycs runs whitebox analysis, repository reconnaissance, and blackbox verification as coordinated signals — and only reports what the evidence supports.
Whitebox analysis
Traces dangerous sinks back to the input handlers that feed them, inside your own source code.
Repository recon
Maps every discovered route to its exact source-code location, so evidence always has an address.
Blackbox verification
Sends real HTTP requests against the live application and, where needed, verifies behavior in a real browser.
Correlated finding
Observed runtime behavior tied to the responsible file and line — such as app/views.py:42 — with evidence from both sides of the correlation.
app/views.py:42Sample finding
Evidence a developer can act on
Every confirmed finding ships with its severity, reproduction summary, evidence sources, and the exact code location to fix.
Reflected XSS via search parameter
- Severity
- high
- Estimated CVSS
- 6.1
- Endpoint
GET /search- Confirmation status
- TRUE
- Responsible location
app/views.py:42
Honest coverage
“Not tested” is always on the page
Every report opens with run completeness. Untested surface is shown next to what was verified — never silently omitted.
Hover a segment or select a tile for the breakdown
Three findings can mean very different things
A complete run
3 verified findings after all 52 endpoints were exercised means the remaining surface was tested and ruled out by evidence.
A run stopped after two minutes
The same 3 findings with 41 endpoints untouched is a weaker statement. Eonycs reports the completeness of the run alongside the findings, so you always know which one you are reading.
Live product demo
Your whole security posture, one workspace
Explore the exact dashboard your team gets — verified findings, coverage trends, runs and authorized targets — with fictional demo data. No account needed.
46
Verified findings
14
Runs completed
86%
Avg. coverage
Severity distribution
Coverage trend
- highTRUEReflected XSS via search parameterapp/views.py:42
- criticalTRUESQL injection in account exportapp/exports.py:18
- mediumTRUEOpen redirect on login return URLapp/auth.py:64
How it works
From authorized scope to actionable evidence
Five deliberate steps. Nothing runs before authorization and scope are recorded.
Select a step to see what happens inside it
Safety and control
Built to demonstrate, not to exploit
Eonycs is designed for authorized testing of your own systems, with mechanical guardrails at every layer.
Authorized targets only
A run cannot start until scope and authorization are recorded in the audit trail.
Host lock
Verification traffic is pinned to the authorized host set.
Cross-host redirect protection
Redirects that leave the authorized scope are followed by nothing.
Mechanical payload guardrails
Canary tokens and non-destructive probes prove impact without touching real data.
Demonstrate, do not exploit
Findings are confirmed with the minimum interaction needed — never data extraction.
Audit trail
Scope, authorization, budgets, and every verification step are recorded.
Verdict honesty
TRUE, FALSE, NaD, and ERROR have separate meanings. A tool failure is never a security verdict.
BYOK
Bring your own supported LLM provider key. Planned for private beta.
Private pilot
Join the private pilot
Eonycs is in private beta with a small number of design partners. Annual plans and support levels will be introduced after private-pilot validation — pilot participants help shape them.
Request a pilotFAQ
Frequently asked questions
Straight answers, including when a capability is planned rather than available.
How is this different from DAST?
DAST observes the application from the outside. Eonycs combines that outside view with whitebox source analysis and repository reconnaissance, so a confirmed finding connects runtime evidence to the exact file and line that caused it — for example app/views.py:42.
Does Eonycs exploit customer data?
No. Eonycs demonstrates vulnerabilities with mechanical canary tokens and non-destructive probes. It never reads, extracts, or modifies real customer data to prove a finding.
What source-code access is required?
Full correlation requires read-only access to the application's repository. Configurations with reduced source visibility are being explored for the private beta, with correspondingly reduced code-level correlation.
What happens when a test is inconclusive?
It is reported as NaD — could not be determined — and listed explicitly in the coverage section. Eonycs never describes “not tested” or “inconclusive” as “not vulnerable.”
Can Eonycs test authenticated applications?
Yes. You provide credentials for the authorized scope, and session handling stays within the recorded scope rules for the run.
Where is customer data processed?
During the private beta, processing locations and sub-processors are documented in the pilot agreement. Bring-your-own-key support for supported LLM providers is planned for the private beta.