Why We Built Eresus Guard: DAST With Less Noise and Real Authorization Testing

Disclosure: I am the founder of Eresus Security, and we build Eresus Guard. This is a product post, but it is about the problems the product is meant to solve rather than a feature list. What Guard is, and is not, is on the Eresus page.

The biggest problem in application security is usually not a lack of tools. There are plenty of scanners. The problem is that what they produce does not match what a team can act on. Across pentests and work with engineering teams, we kept running into three problems.

1. Fragmented tools, scattered results#

One tool for dynamic testing, another for source code, a third for dependencies, a fourth for secrets. Each has its own interface, its own data model, its own idea of "critical". The team ends up writing and maintaining integrations just to see findings in one place. Security work turns into spreadsheet merging.

Eresus Guard puts dynamic and static analysis in one platform with one data model. Knowing which layer a finding came from matters; not having to visit five screens matters more.

2. False-positive noise#

When a scanner reports two hundred findings and most are not exploitable, developers stop opening the next report. The real issue disappears into the noise. When a scanner wired into CI/CD breaks builds with false alarms, the usual outcome is that someone turns it off.

So we invested in validation: reproducible HTTP evidence for each finding, and out-of-band verification (OAST) for bugs you cannot see in the response. More on why below.

To be explicit: we do not promise zero false positives. Validation reduces noise; it does not remove human triage. Be skeptical of any security product that claims otherwise.

Blind bugs and OAST#

With blind command injection or SSRF, the application response shows nothing. The request succeeds and the page looks normal. The only evidence is the server making an outbound request to an address you control.

POST /api/import HTTP/1.1
Host: app.example.com
Content-Type: application/json
 
{"url": "https://abc123.oast.example/"}

The response may be 200 OK with an empty body. But if abc123.oast.example receives a DNS query or HTTP request from the target, you have proven the SSRF without reading the response. That is far stronger than "the response was slow, maybe it is vulnerable". (The request above is a generic illustration of the concept, not product output.)

3. Modern APIs and authentication#

Today's applications are not static pages. They are single-page frontends over dozens of APIs, with authorization context changing on every request. Catching IDOR and BOLA (broken object-level authorization) takes more than scanning as one user. You have to compare the same request across two users' contexts:

User A (account 1001):  GET /api/orders/9001  -> 200, A's order
User B (account 1002):  GET /api/orders/9001  -> 200, A's order   <-- vulnerable
User B (account 1002):  GET /api/orders/9001  -> 403               <-- expected

A scanner can only see this if it holds both sessions at once and compares responses. We designed Eresus Guard for multi-session authenticated testing in pre-production environments.

What we are, and are not#

We try to stay away from "AI solves everything" claims. Eresus Guard is a security engineering product built on deterministic scan rules and bounded, verifiable automation.

Honest limits:

• It is not a WAF; it tests for vulnerabilities, it does not block traffic.
• It is commercial and closed source; there is no offline (air-gapped) license mode.
• It does not replace human review.
• A license covers the software platform only. Manual penetration testing, red team work, and consulting are separate services from Eresus Security under their own agreements.

The full product description, who it is for and who it is not for, is on the Eresus page. Product site: guard.eresussec.com.