DAST, SAST or IAST: which testing does your app need first?
Describe your application and get the testing types it needs, in order, with open-source and commercial examples. Then build the DAST scope: targets, login, exclusions, rate limits and test window, ready to copy.
Your application
B2B SaaS: JavaScript / TypeScript; Single-page app, REST API; Basic CI.
Your testing order
Highest value for this app first. Tool names are examples that do the job, listed alphabetically, not a ranking.
- 1
Software composition analysis (SCA)
Start nowWhen: Every pull request + nightly
- • Most of the code you ship is open-source packages; SCA is quick to switch on and finds known CVEs in them.
Open source: Dependabot, OSV-Scanner, OWASP Dependency-Check, Trivy
Commercial: Black Duck, Mend, Snyk Open Source, Sonatype
Finds and misses
Finds: Known CVEs in dependencies, outdated or abandoned packages, licence conflicts.
Misses: Flaws in your own code; zero-days in packages; whether the vulnerable function is even called (unless the tool does reachability).Source: PCI Security Standards Council, NIST - 2
Secret scanning
Start nowWhen: Pre-commit + every pull request
- • A leaked key is exploitable in minutes and needs no vulnerability; a pre-commit hook costs almost nothing.
Open source: Gitleaks, TruffleHog
Commercial: GitGuardian, GitHub secret scanning (private repos need GitHub Secret Protection)
Finds and misses
Finds: Hard-coded credentials, private keys, cloud keys in config and git history.
Misses: Secrets that live only in runtime config or a CI variable that leaks through logs.Source: NIST - 3
Static application security testing (SAST)
Start nowWhen: Every pull request (fast rules) + main branch (full)
- • You own the source, so SAST finds flaws at the line where they are written, before deploy, which is the cheapest place to fix them.
- • Tune it: start with high-confidence rules on new code only, or teams learn to ignore it.
Open source: Bandit (Python), Brakeman (Rails), CodeQL (no cost for public repos), gosec (Go), Semgrep Community Edition, SonarQube Community Build, SpotBugs + Find Security Bugs (Java)
Commercial: Checkmarx, GitHub Code Security (CodeQL on private repos), OpenText Fortify, Semgrep AppSec Platform, Snyk Code, Veracode
Finds and misses
Finds: Injection sinks, unsafe deserialisation, weak crypto calls, path traversal, with the exact file and line.
Misses: Runtime and configuration issues, authentication and business-logic flaws, anything in code it cannot parse.Source: OWASP, NIST, PCI Security Standards Council - 4
API-focused DAST and fuzzing
Start nowWhen: In CI against an ephemeral or staging API
- • APIs are invisible to a crawler; feed the scanner your OpenAPI or GraphQL schema so every endpoint is tested.
- • Give it two test users with different permissions: broken object-level authorisation is the top OWASP API risk and needs two identities to find.
Open source: Schemathesis, ZAP API scan (OpenAPI, GraphQL, SOAP)
Commercial: 42Crunch, Burp Suite DAST, StackHawk
- 5
Dynamic application security testing (DAST)
Start nowWhen: Baseline each release + full authenticated scan weekly
- • You expose web pages; DAST tests what an attacker actually reaches, including server and header configuration SAST cannot see.
- • Most of the app sits behind login: configure authenticated scanning (a test account and session handling) or the scan only sees the login page.
Open source: Nuclei (template-based), ZAP by Checkmarx (Apache 2.0)
Commercial: Burp Suite DAST (PortSwigger), Invicti, Rapid7 InsightAppSec, StackHawk
Finds and misses
Finds: Injection that is reachable, missing security headers, cookie flags, TLS and server misconfiguration, some XSS and access issues.
Misses: Code paths it does not reach (pages behind login it cannot keep a session for, multi-step flows), the root-cause line of code, most logic flaws.Source: OWASP, ZAP, PCI Security Standards Council - 6
Manual penetration test
NextWhen: Yearly + before major launches
- • Tools miss authorisation and business-logic flaws; a person testing between two tenants or roles finds them.
- • SOC 2 and ISO 27001 do not mandate a pen test by name, but auditors and enterprise customers routinely ask for a recent one.
Open source: Burp Suite Community, ZAP and Nuclei are common tester tools
Commercial: Independent testing firms; PCI requires qualified internal or external testers
Finds and misses
Finds: Broken access control between users and tenants, workflow abuse, payment and pricing logic, chained low findings.
Misses: Breadth: it is a snapshot of one version in a time-boxed window.Source: PCI Security Standards Council, OWASP - 7
Interactive application security testing (IAST)
LaterWhen: Continuous in QA/staging
- • Worth adding once SAST and DAST are tuned: it confirms which findings are reachable, cutting triage time.
- • Only as good as your test suite: it sees only what the tests exercise.
Open source: Few mature open-source options; check your language
Commercial: Black Duck Seeker, Contrast Assess, Datadog Code Security (IAST), HCL AppScan
Finds and misses
Finds: Reachable vulnerabilities with the line of code and the request that triggered them; fewer false positives than SAST alone.
Misses: Anything your tests do not exercise; languages the agent does not support. Adds runtime overhead, so it belongs in test environments.Source: OWASP - 8
Infrastructure-as-code scanning
LaterWhen: Pull requests that touch infrastructure
- • Only worth it once infrastructure is defined in code (Terraform, CloudFormation, Helm).
Open source: Checkov, KICS, Trivy (config scanning)
Commercial: Prisma Cloud (Palo Alto Networks), Snyk IaC, Wiz Code
Finds and misses
Finds: Public buckets, open security groups, privileged containers, missing encryption.
Misses: Drift made by hand in the console after deploy (that is posture management).Source: NIST
Not needed for this app: Mobile (No mobile app selected.)
Testing plan
Preview
APPLICATION SECURITY TESTING PLAN App: JavaScript / TypeScript; Single-page app, REST API; Basic CI 1. [Start now] Software composition analysis (SCA) When: Every pull request + nightly - Most of the code you ship is open-source packages; SCA is quick to switch on and finds known CVEs in them. Open-source examples: Dependabot, OSV-Scanner, OWASP Dependency-Check, Trivy Commercial examples: Black Duck, Mend, Snyk Open Source, Sonatype 2. [Start now] Secret scanning When: Pre-commit + every pull request - A leaked key is exploitable in minutes and needs no vulnerability; a pre-commit hook costs almost nothing. Open-source examples: Gitleaks, TruffleHog Commercial examples: GitGuardian, GitHub secret scanning (private repos need GitHub Secret Protection) 3. [Start now] Static application security testing (SAST) When: Every pull request (fast rules) + main branch (full) - You own the source, so SAST finds flaws at the line where they are written, before deploy, which is the cheapest place to fix them. - Tune it: start with high-confidence rules on new code only, or teams learn to ignore it. Open-source examples: Bandit (Python), Brakeman (Rails), CodeQL (no cost for public repos), gosec (Go), Semgrep Community Edition, SonarQube Community Build, SpotBugs + Find Security Bugs (Java) Commercial examples: Checkmarx, GitHub Code Security (CodeQL on private repos), OpenText Fortify, Semgrep AppSec Platform, Snyk Code, Veracode 4. [Start now] API-focused DAST and fuzzing When: In CI against an ephemeral or staging API - APIs are invisible to a crawler; feed the scanner your OpenAPI or GraphQL schema so every endpoint is tested. - Give it two test users with different permissions: broken object-level authorisation is the top OWASP API risk and needs two identities to find. Open-source examples: Schemathesis, ZAP API scan (OpenAPI, GraphQL, SOAP) Commercial examples: 42Crunch, Burp Suite DAST, StackHawk 5. [Start now] Dynamic application security testing (DAST) When: Baseline each release + full authenticated scan weekly - You expose web pages; DAST tests what an attacker actually reaches, including server and header configuration SAST cannot see. - Most of the app sits behind login: configure authenticated scanning (a test account and session handling) or the scan only sees the login page. Open-source examples: Nuclei (template-based), ZAP by Checkmarx (Apache 2.0) Commercial examples: Burp Suite DAST (PortSwigger), Invicti, Rapid7 InsightAppSec, StackHawk 6. [Next] Manual penetration test When: Yearly + before major launches - Tools miss authorisation and business-logic flaws; a person testing between two tenants or roles finds them. - SOC 2 and ISO 27001 do not mandate a pen test by name, but auditors and enterprise customers routinely ask for a recent one. Open-source examples: Burp Suite Community, ZAP and Nuclei are common tester tools Commercial examples: Independent testing firms; PCI requires qualified internal or external testers 7. [Later] Interactive application security testing (IAST) When: Continuous in QA/staging - Worth adding once SAST and DAST are tuned: it confirms which findings are reachable, cutting triage time. - Only as good as your test suite: it sees only what the tests exercise. Open-source examples: Few mature open-source options; check your language Commercial examples: Black Duck Seeker, Contrast Assess, Datadog Code Security (IAST), HCL AppScan 8. [Later] Infrastructure-as-code scanning When: Pull requests that touch infrastructure - Only worth it once infrastructure is defined in code (Terraform, CloudFormation, Helm). Open-source examples: Checkov, KICS, Trivy (config scanning) Commercial examples: Prisma Cloud (Palo Alto Networks), Snyk IaC, Wiz Code Not needed for this app: Mobile Tool names are examples that do this job, listed alphabetically, not a ranking.
DAST scope and rules of engagement
Preview
DAST SCOPE AND RULES OF ENGAGEMENT: Customer portal Prepared with PlayCISO AppSec Testing Chooser. Review and approve before any scan runs. 1. OWNER AND APPROVAL Scope owner: AppSec lead, appsec@example.com Approved by (system owner): ____________ Date: ________ 2. ENVIRONMENT Stable staging 3. IN-SCOPE TARGETS - https://staging.example.com/ - https://api.staging.example.com/v1/ API definition (import into the scanner): https://api.staging.example.com/openapi.json Anything not listed is out of scope, including other subdomains. 4. AUTHENTICATION Method: OAuth 2.0 / OIDC Test identities: 2 test users: user-a (standard role), user-b (admin role), separate tenants Use a scripted login or pre-issued token; do not point the scanner at the production identity provider. MFA: use a test account with an MFA exemption limited to the scanner IP, or a TOTP seed held by the scan owner. Logged-in indicator for the scanner: (text or header only present when signed in) Use two users with different roles/tenants to test object-level authorisation. 5. EXCLUSIONS (DO NOT SCAN) - /logout - /account/delete - /billing/charge - /api/v1/admin/purge - Third-party domains (payment provider, CDN, analytics) - Any endpoint that sends real email, SMS, payments or deletes data 6. RATE LIMITS AND SAFETY Max 10 requests/second, max 5 concurrent threads; stop on a sustained 5xx error rate. Scan mode: Safe active (Attack payloads, no destructive or DoS checks). Disable denial-of-service, buffer-overflow and brute-force checks unless explicitly approved. Seed test data before the scan; expect junk records in forms and restore from snapshot after. Kill switch: scope owner can stop the scan at any time; on-call contact below. 7. TEST WINDOW AND NOTIFICATION Window: Tue-Thu 22:00-02:00 local, outside release freezes Notification: On-call SRE and SOC notified 24h before; scanner source IP allow-listed in WAF for the window only Scanner source IP(s): ____________ (allow-list only for the window, remove after) 8. OUTPUT AND HANDLING Report findings with request/response evidence, severity and affected URL. Results contain session tokens and data samples: store with restricted access, delete raw traffic after triage. Retest fixed findings before closing them. 9. WHERE THIS FITS IN THE TESTING PROGRAMME - Start now: Software composition analysis (SCA) (Every pull request + nightly) - Start now: Secret scanning (Pre-commit + every pull request) - Start now: Static application security testing (SAST) (Every pull request (fast rules) + main branch (full)) - Start now: API-focused DAST and fuzzing (In CI against an ephemeral or staging API) - Start now: Dynamic application security testing (DAST) (Baseline each release + full authenticated scan weekly) - Next: Manual penetration test (Yearly + before major launches) - Later: Interactive application security testing (IAST) (Continuous in QA/staging) - Later: Infrastructure-as-code scanning (Pull requests that touch infrastructure)
Loading…
DAST scope builder
Fill in what the scanner may touch. The scope document updates as you type.
TL;DRThe short answer
5 points
- SAST reads your source code without running it; DAST attacks the running app from outside with no source; IAST watches from inside the running app while tests exercise it. They find different bugs, so mature programmes use more than one.
- For most teams that own their code, the cheapest first steps are dependency scanning (SCA), secret scanning and SAST on pull requests, then DAST against staging.
- APIs need API-aware DAST fed from the OpenAPI or GraphQL schema, with two test users so authorisation flaws show up.
- No scanner finds business-logic or cross-tenant access flaws reliably; a manual penetration test still has a place, and PCI DSS 11.4 requires one.
- A DAST scan without a written scope (targets, auth, exclusions, rate limits, window) is how test scans delete data or page the on-call team.
Every testing type: what it finds and what it misses
For a longer explainer of dynamic testing, read What is DAST?
How the order is decided
Each testing type gets a priority from your inputs: whether you own the source (SAST, secrets and SCA need it), what the app exposes (web pages favour DAST, APIs need schema-driven API testing, a mobile binary needs mobile testing), how mature your pipeline is (IaC scanning and IAST pay off in mature pipelines with test environments), and what compliance applies (PCI DSS raises the weight of code review and penetration testing). The rules are PlayCISO's judgement built on the OWASP, NIST and PCI sources below, not a benchmark.
Tool names are factual examples of products that do each job, listed alphabetically. We do not rank vendors; trial two against your own app before buying.
Frequently asked questions
What is the difference between SAST and DAST?
SAST (static application security testing) analyses source or compiled code without running it, so it runs early and points to the exact line, but it cannot see runtime or configuration problems. DAST (dynamic application security testing) tests the running application from the outside, like an attacker, without source access, so it finds what is actually reachable and misconfigured but cannot tell you which line caused it and misses code it never reaches.
Is DAST or SAST better?
Neither replaces the other. If you own the source, SAST on every pull request catches flaws when they are cheapest to fix. DAST then checks the deployed app, including server, header and TLS configuration that SAST cannot see. If you buy the product and have no source, DAST is the main test you can run yourself.
What is IAST and when is it worth it?
IAST (interactive application security testing) places an agent inside the running application and reports vulnerabilities as functional tests or a DAST scan exercise the code, with the line and the request that triggered them. It is worth adding once you have a test environment and a good automated test suite, because it only sees code the tests reach.
Does PCI DSS require DAST?
PCI DSS v4.0.1 does not name DAST. Requirement 6.2.3 requires bespoke software to be reviewed before release, 6.2.4 lists attack classes to prevent, and 6.4 covers public-facing web applications (from 31 March 2025, an automated technical solution that detects and prevents web attacks). Requirement 11.4 requires penetration testing that includes the application layer. DAST is a common way to evidence part of this, but it does not replace the ASV scan in 11.3.2 or the 11.4 penetration tests.
Is OWASP ZAP still open source?
Yes. In September 2024 ZAP joined Checkmarx and is now called ZAP by Checkmarx; the ZAP project says it stays under the ZAP Core Team, remains open source and stays licensed under Apache v2.
What should a DAST scope include?
The in-scope URLs and API definitions, the environment, how the scanner logs in and with which test users, exclusions (logout, delete, payment and email-sending endpoints, third-party domains), a request-rate limit, the scan mode (passive, safe or full active), the test window, who is notified, and how results are handled. The builder on this page writes that document for you.
Sources
- OWASP: Vulnerability Scanning Tools / DAST (community page, read 31 Oct 2026). Dynamic scanners test a running application from the outside, without source code; they find runtime and configuration issues but cannot see code paths they do not reach.
- OWASP: Source Code Analysis Tools (community page, read 31 Oct 2026). SAST tools analyse source or compiled code without running it, can run early in development, and point to the exact file and line, but produce false positives and cannot find runtime or configuration issues.
- ZAP: ZAP has joined forces with Checkmarx (24 Sep 2024). ZAP is now "ZAP by Checkmarx"; it stays under the control of the ZAP Core Team, open source, and licensed under Apache v2.
- NIST: SP 800-218, Secure Software Development Framework (SSDF) v1.1 (Feb 2022). Practice PW.7 is reviewing and/or analysing human-readable code for vulnerabilities; PW.8 is testing executable code to identify vulnerabilities. Both are expected of a secure development process.
- PCI Security Standards Council: PCI DSS v4.0.1 (Jun 2024). Req. 6.2.3: review bespoke and custom software before release. 6.2.4: engineering techniques to prevent common software attacks. 6.3.2: inventory of bespoke software and third-party components. 6.4.1/6.4.2: protect public-facing web apps (from 31 Mar 2025, an automated technical solution that detects and prevents web attacks is required). 11.3.1/11.3.2: internal and external (ASV) vulnerability scans every three months. 11.4: internal and external penetration tests at least every 12 months and after significant change, covering the application layer.
- OWASP: Application Security Verification Standard (ASVS) (read 31 Oct 2026). A list of verification requirements for web applications and APIs, organised by level, usable as the test basis for code review, DAST and penetration tests.
- OWASP: Mobile Application Security (MASVS and MASTG) (read 31 Oct 2026). The mobile verification standard (MASVS) and testing guide (MASTG): mobile apps need static and dynamic testing of the app binary itself, not only of the backend API.
- OWASP: API Security Top 10 (2023) (2023). Broken object level authorisation is the top API risk; it is a logic flaw that generic scanners rarely find without authenticated, multi-user test accounts.
Educational guidance. Only scan systems you own or have written permission to test.
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.