Authenticated DAST finds the real bugs, and that is why it is hard to automate

There are two very different activities that both get called DAST, and conflating them produces most of the confusion about whether dynamic scanning is worth doing.

Unauthenticated scanning points a tool at a URL and checks what any stranger could reach. Authenticated scanning logs in, holds a session, and exercises the application as a user.

The second is where the findings are. It is also substantially harder to run, and that gap, not any deficiency in the idea, is why so many pipelines end up running the first and concluding DAST does not find much.

What the unauthenticated scan is for#

It is not useless. It answers a specific, worthwhile question: what is exposed to someone with no credentials at all?

• A debug endpoint or admin panel reachable from the internet.
• /.git/ served as static files, a directory listing, a stack trace on error.
• Default credentials on an embedded component.
• A version banner matching a known CVE.
• Anything that appeared since the last check, which a point-in-time review structurally cannot catch.

That list is short, cheap to check, and full of things that start real incidents. It is a perimeter check, and perimeter checks are worth running continuously precisely because they are cheap.

What it is not is a measure of your application's security. Quoting a clean unauthenticated result as though it covered the application is where the misleading happens, and it is usually unintentional, because the report does not say which surface it saw.

What authenticated scanning costs#

Everything that makes it valuable also makes it awkward to automate:

• Credentials have to exist and be managed. A test account, in a secret store, rotated, scoped so the scan cannot do anything irreversible.
• The session has to be maintained. Login flows, tokens that expire mid-scan, CSRF tokens, multi-step or MFA-protected authentication. This is where most attempts fail.
• Destructive actions have to be excluded. A scanner exercising authenticated endpoints will find the delete button. Ask anyone who has run one against a shared staging environment.
• APIs need a specification. There is no HTML to crawl, so coverage comes from an OpenAPI document telling the scanner which routes, methods and content types exist. Without it, an API scan sees almost nothing.

None of this is exotic. ZAP and Burp have supported all of it for years, and teams run it successfully every day. It is setup, and setup is what does not survive being bolted onto a pipeline as an afterthought.

What Draugr's dast covers#

The perimeter by default, on every release. Draugr's dast control runs Nuclei against the URL a component declares, checked continuously, as part of the same descriptor and the same verdict as everything else it looks at.

That is the half worth automating into a gate, and it is the half most teams do not run at all, because standing up a scan per service is a job nobody has time for. Declaring a host in a Saga is one line, and the check comes with the pipeline you already have.

Both of the costs above are declarations rather than infrastructure. A host carries an auth: block naming the environment variable that holds a token. There is no field for the credential itself, because a descriptor is committed, and the scan runs as a user. Point it at an openapi.yaml and it exercises the routes the API declares instead of crawling for them.

What that does not buy you is the session handling described earlier. A bearer token is not a login flow, and an API with a short-lived session still needs the machinery this post is about. The descriptor covers the cases where a credential is a header, which is most APIs and few browser applications.

A spec-driven scan is read-only unless you say otherwise. A specification lists DELETE too, and a scanner handed one will use it, so operations whose method you have not named are removed before the scanner sees the document, and the scan targets the endpoint your descriptor declared rather than the one the specification names.

Draugr never turns dast on for you. Even when discovery finds a host, it stays off, because this control sends probing traffic at a live service and enabling that on the strength of a descriptor mentioning a URL is not a decision a tool should make on somebody's behalf.

The comparison worth drawing instead#

The useful axis is not scanner versus pentester but breadth against depth, on a schedule.

A perimeter scan is cheap enough to run on every release, so it catches the thing that changed. An authenticated scan costs setup and is worth running on a slower cadence against an environment you control. A pentest understands what your application is for. That user 41 should not read user 42's invoices, and no scanner ever will, because the logic being violated exists only in your requirements.

Three tools, three cadences, three questions. The mistake is expecting any one of them to answer another's.

The DAST guide covers what dynamic scanners check and how they differ, and HTTP security headers covers the passive half of the same surface.