GitHub's 2024 Open Source Survey found that 73% of respondents already use AI coding assistants in their day-to-day work, and GitHub's own Octoverse data has tracked AI-assisted code climbing toward roughly half of all new commits on the platform, with the share running even higher in some languages. That shift changes more than typing speed — it changes how fast an application's attack surface moves. A team that once shipped a new endpoint every few days can now have a coding agent scaffold a dozen CRUD routes, an auth middleware, and a webhook handler in an afternoon. The short version of DAST meaning, for anyone new to the term: it's testing a running application from the outside, the way an attacker would, rather than reading its source code. Traditional dynamic application security testing (DAST) was designed for a slower world: a crawler maps a site, a scan runs overnight or once per release, and a security team reviews results before the next sprint. That cadence assumes the application underneath barely changes between scans. When AI-assisted development compresses months of scaffolding into days, DAST built on periodic crawls and static scope lists starts missing exactly the endpoints it should be testing. This post looks at what the data says about AI-generated code's security posture, why the attack surface problem is structural and not just a volume problem, and what has to change in how dynamic testing discovers and prioritizes what to scan.
Is AI-generated code actually less secure?
Yes, and the effect has been measured directly, not just assumed. A peer-reviewed Stanford study, "Do Users Write More Insecure Code with AI Assistants?" by Perry, Srivastava, Kumar, and Boneh, found that participants who used an AI coding assistant wrote significantly less secure code than a control group — notably weaker on SQL injection defenses and string encryption — while simultaneously rating their own code as more secure than the control group did. That combination is the dangerous part: not just more bugs, but less awareness that the bugs exist. A separate academic study of GitHub Copilot, evaluating it against 89 security-relevant coding scenarios spanning MITRE's CWE Top 25 weakness classes, found that roughly 40% of the generated snippets contained potentially exploitable vulnerabilities. Neither study says AI tools are unusable — they say the code they produce needs the same or greater scrutiny as human-written code, at a moment when teams are inclined to give it less.
Does AI-assisted development change the size of the attack surface, or its shape?
Both, but the shape change is the harder problem for testing programs. AI coding agents are exceptionally good at scaffolding: generating a REST resource, its CRUD handlers, a matching database migration, and a route registration in one pass. That means the number of live endpoints, internal APIs, and microservices per developer-hour goes up, and each new route is a fresh opportunity to forget an authorization check. This is precisely the failure mode OWASP's own data already flags as dominant, independent of AI: Broken Access Control has held the #1 spot in the OWASP Top 10 since the 2021 edition and remains there in the current OWASP Top 10:2025, where it logged roughly 1.8 million CWE occurrences across the contributed dataset — the highest of any category, and a category present in 100% of the applications tested for it. Faster scaffolding doesn't introduce a new vulnerability class — it increases the rate at which the most common one already out there gets reproduced across a growing set of routes that nobody has manually reviewed for missing auth.
Why do crawler-based DAST assumptions break down here?
Classic DAST tooling works by crawling a target to build a map of pages and endpoints, then attacking what it finds. That model has two built-in assumptions that AI-assisted development violates. First, it assumes the map is roughly stable between scans — but a coding agent can add or rename a batch of routes in a single pull request, so a crawl from last week's scan window can miss this week's endpoints entirely, especially ones with no inbound links for a crawler to discover, like internal APIs or webhook receivers. Second, it assumes scope configuration — the allow-listed hosts and paths a scanner is permitted to test — stays current, but AI-accelerated projects spin up new subdomains, staging environments, and service-to-service APIs faster than security teams typically get around to registering them in scanner configuration. The result is a scan that faithfully tests an application that no longer matches what's actually deployed.
Does faster release cadence make periodic scanning obsolete?
Not obsolete, but insufficient on its own. Nightly or pre-release DAST scans were built around release cycles measured in days or weeks. Teams using AI pair-programming tools routinely merge and deploy multiple times a day, so a scan that only runs once every 24 hours can sit behind several rounds of unscanned change by the time it executes, and a scan gated only to "pre-release" can miss anything deployed via a hotfix or a feature-flag flip outside the normal pipeline. This doesn't mean DAST needs to run continuously against every commit — that's rarely practical for active scanning with rate limits and safety controls in place — but it does mean scan triggers need to track deployment events and scope changes, not a calendar, and findings need to correlate back to the specific code change that introduced them so a fast-moving team can fix the right commit instead of re-triaging the whole application. Where DAST sits in the SDLC has to shift accordingly: DAST in the SDLC used to mean a gate right before release, but with AI-assisted teams shipping multiple times a day, that gate needs to trigger off deployment events themselves, including the internal and service-to-service DAST API endpoints that never show up in a traditional site crawl.
Is this an industry-wide shift, or just a Safeguard framing?
It's industry-wide. The DAST definition itself hasn't changed — testing a running application from the outside — but every established vendor is under the same pressure to rethink scope discovery and scan cadence. Checkmarx DAST and Snyk DAST have both expanded their dynamic testing capabilities in recent years specifically to keep pace with faster release cycles, and analyst coverage (Gartner DAST research, in particular) has increasingly flagged continuous scope discovery as a differentiator rather than a nice-to-have. The direction Gartner and DAST vendors broadly are moving — event-driven scanning tied to deployments rather than a fixed nightly window — is the same shift this post argues for; the open question for any buyer is how deep that capability actually goes versus how much is repositioning of the same nightly-crawl architecture.
How Safeguard Helps
Safeguard's DAST solution is built as authorized, defensive testing from the ground up, which matters more, not less, as AI-assisted teams ship faster: every target must be verified through DNS TXT, file upload, meta tag, or email-domain proof before any active check runs, every outbound request is checked against an allow-listed host/path scope, and detection uses non-destructive, benign-marker techniques under configurable rate limits and safety modes (passive, safe_active, authenticated_safe_active, with a gated lab_aggressive mode for owned, isolated targets only). Because SAST, DAST, and SCA findings share one unified model with correlation keys, a DAST-confirmed issue on a newly scaffolded endpoint links back to the exact source-code sink that produced it — so when an AI-assisted commit adds ten new routes, a security team isn't left guessing which one is actually reachable and exploitable versus which one just showed up in a crawl. Every finding stays tenant- and org-scoped end to end, so the growing surface area from AI-assisted development doesn't turn into growing noise for the humans who still have to sign off on it.