DAST

What it means

Dynamic Application Security Testing (DAST) tests an application while it runs. The OWASP DevSecOps Guideline calls it “Black-Box” testing: the tool sends requests, including malicious payloads, to a live deployment and reads what comes back. Without source access, it judges observed behavior rather than intent.

OWASP lists what DAST is helpful for detecting:

• Input or output validation. Injection attempts such as SQL injection or cross-site scripting travel through real requests.
• Authentication issues. Login and session behavior is observed as a client experiences it.
• Server configuration mistakes. Headers and exposed endpoints belong to the deployment, not to any repository file.

The same outside view sets the limits. The OWASP Developer Guide notes that dynamic testing cannot cover 100% of the application, so the tester must check how much of the attack surface the tool reached. ZAP’s guide adds that login-protected pages stay undiscovered during an automated scan unless authentication is configured, and that active scanning is a real attack requiring permission.

DAST vs SAST

SAST reads code; DAST exercises the deployed result.

Axis	DAST	SAST
What it inspects	The running application through its web front end	Source or compiled code, unexecuted
When it runs	Against a deployed instance, for example nightly	Before deployment
What it finds	Injection, authentication flaws, server misconfiguration	Insecure code patterns
What it needs	A reachable target, permission to attack it, login configuration	Access to the code and build

Neither replaces the other. A change that passes static analysis can still ship behind a misconfigured server, and a dynamic scan cannot say which line produced the response it observed.

Why it matters for AI-written code

OpenSSF’s guide for AI code assistant instructions states that “AI-generated code isn’t a shortcut around engineering processes such as code reviews, testing, static analysis, documentation, and version control discipline.” It tells developers to assume such code can have vulnerabilities, and several of its rules are runtime properties: security headers such as Content Security Policy in web responses, and frameworks’ built-in cookie protections.

A diff review cannot confirm those properties. An agent can generate a handler that reads correctly and still ship behind a proxy that strips the header, or a route exposed without the intended middleware. Only requests against the running application see the combined result of code, framework, and infrastructure.

How Enji Guard helps

Enji Guard keeps a project in the green zone through recurring audits and a continuous autofix cycle, so coding agents build on a healthier codebase. For a linked website, the active part of that loop is the Web pentest audit, listed in the catalog as “Run Web pentest”.

Its runbook states the scope: “It performs active testing for the exact consented target” and never creates or modifies repository files, issues, branches, PRs/MRs, deployments, or accounts. Two rules define that target:

• One exact target. The run resolves exactly one URL from the task’s Web pentest target block and never canonicalizes, redirects, discovers, or substitutes another. Consent for one linked website covers no other subdomain, tenant, or redirect destination.
• Owner consent first. Active-testing consent comes from someone who owns the target or holds written permission to test it; repository access implies nothing.

Confirmed findings feed the paired “Web pentest Autofix” improvement, which creates or reuses at most one issue, may open one bounded defensive PR/MR, and never merges it. A later deployment and a new Web pentest are required before the score changes.

The repository security audit is not DAST: it performs only safe read-only HTTP checks against linked origins and forbids login attempts, fuzzing, form posts, and payload injection. A Web pentest run with no confirmed vulnerability is not a guarantee that the application contains none.