> ## Documentation Index > Fetch the complete documentation index at: https://docs.neo.projectdiscovery.io/llms.txt > Use this file to discover all available pages before exploring further. # DAST: Dynamic Application Testing Traditional DAST tools crawl a running application and fuzz every endpoint against a library of known vulnerability signatures. That catches the vulnerability classes with a recognizable payload: injection, XSS, common misconfigurations. It doesn't catch the flaws that only show up when an attacker understands what the application is supposed to do, because there's no reasoning behind the fuzzing, just pattern matching against a signature list. And running one commercially still means a separate product to license and keep configured. ## How Neo Solves This 1. **Crawls and tests for full coverage.** Neo maps the application, discovers endpoints, forms, and parameters, and runs the same vulnerability classes a traditional DAST scanner covers: injection, XSS, authentication and session issues, misconfigurations, and more. 2. **Reasons about business logic, not just signatures.** This is the differentiator a signature-based scanner can't offer. Because Neo understands what the application is trying to do, it tests whether that logic can be manipulated: workflow steps skipped or replayed out of order, values (price, quantity, discount) tampered with in ways a fuzzer wouldn't think to try, access checks that hold at the endpoint level but fail once you follow a multi-step flow. 3. **Starts from what SAST already knows.** When Neo has also read the source, dynamic testing isn't black-box. It already has the endpoints, auth flows, and data model a [SAST](/use-cases/sast) pass mapped, so it can go straight at the parts of the application worth testing instead of rediscovering them from the outside. 4. **Runs on a schedule.** [Schedule](/concepts/scheduling) a DAST run tied to your deploy cadence, so every push to production gets tested automatically. 5. **Organized by application, with your team.** Set up a [project](/platform/projects) per application, and every dynamic testing run inside it builds on what previous runs already found instead of starting over. [Invite teammates](/platform/projects#managing-members) to the project, and [attach the credentials](/platform/settings/secrets#ownership-and-sharing) that application needs so everyone's tasks can authenticate too, not just the person who added them. Findings from every run land in the project's [Issues](/platform/issues) tab, so the whole team works off the same list of what's open on that target. 6. **Or hand it to autopilot.** Put the project on [autopilot](/platform/projects#project-autopilot) instead of a fixed schedule, and Neo decides what to re-test as the application changes, with no prompt required. ## What This Looks Like in Practice You point Neo at a staging environment: ``` Run a dynamic test of https://staging.yourapp.com. Focus on the checkout flow. ``` A signature-based scanner would fuzz the checkout endpoints for injection and call it done. Neo does that too, but it also works through the checkout flow the way a user would: it finds that submitting a negative quantity during a return causes the system to issue a refund larger than the original payment. No signature flags that. It's only visible once something understands what "checkout" is supposed to do. ## What You Get * **Full coverage of the standard DAST class.** Injection, XSS, auth and session issues, and the rest, tested and validated automatically. * **Business logic flaws caught.** Unique to Neo's reasoning layer, not available from a signature-based scanner. * **Sharper testing when paired with SAST.** Code-aware context from a [SAST](/use-cases/sast) pass tells Neo where to look first instead of discovering the application from scratch. * **Continuous testing.** Scheduled runs tied to your release cycle, or autopilot deciding what to retest as the application evolves. * **A shared home per application.** [Projects](/platform/projects) keep every run, finding, and invited teammate's work on that target in one place instead of scattered across one-off tasks. * **Shared credentials, not just shared findings.** Attach the application's secrets to the project once, and every teammate's tasks in it can authenticate, instead of each person configuring their own. * **The same evidence standard as a manual pentest.** Every finding ships with a working exploit and reproduction steps, not a raw scanner alert. ## Setup To run a dynamic test: 1. Add your target environment in **Settings → Secrets**. 2. Connect the application's repository in **Settings → Applications → [GitHub](/integrations/github)** for code-aware testing (optional, and pairs with [SAST](/use-cases/sast)). 3. Start a new conversation and tell Neo what to test, or create a [project](/platform/projects) for the application, [invite your team](/platform/projects#managing-members), [attach the secrets](/platform/settings/secrets#ownership-and-sharing) they'll need, and either set up a [schedule](/concepts/scheduling) or turn on [autopilot](/platform/projects#project-autopilot) to run it continuously. The complementary half: reads the source directly instead of testing from the outside. A full pentest engagement that combines dynamic testing with manual-style chaining and depth. Organize dynamic testing per application, invite teammates, share credentials, and turn on autopilot.