Study guide
8.2 SAST, DAST, IAST, SCA, IaC, and Mobile Scans
CompTIA PenTest+ PT0-003
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current PT0-003 Exam Facts 1.2 Format, PBQs, Scoring, and Retake Policy 1.3 Recertification, CEUs, and Career Fit
2 Pre-Engagement Planning
2.1 Scope, Rules of Engagement, and Agreements 2.2 Target Selection and Assessment Types 2.3 Shared Responsibility, Legal Authorization, and Ethics
3 Collaboration, Frameworks, and Threat Modeling
3.1 Collaboration, Escalation, and Stakeholder Communication 3.2 Testing Frameworks and Methodologies 3.3 Threat Modeling: STRIDE, DREAD, and OCTAVE
4 Reporting and Remediation
4.1 Penetration Test Report Components 4.2 Findings Analysis and Remediation Recommendations
5 Information Gathering
5.1 Active vs Passive Reconnaissance 5.2 OSINT Sources and Techniques 5.3 DNS, Certificate Transparency, and Search Engine Enumeration 5.4 Network Recon, Protocol Scanning, Sniffing, and Banner Grabbing
6 Enumeration Techniques
6.1 OS Fingerprinting, Service Discovery, and Host Discovery 6.2 DNS, Directory, Share, and Account Enumeration 6.3 Secrets, Permissions, and Wireless Enumeration 6.4 WAF Enumeration, Web Crawling, and Attack Path Mapping
7 Recon Scripting and Tools
7.1 Modifying Bash, Python, and PowerShell for Recon 7.2 Recon and Enumeration Tools
8 Vulnerability Scan Types
8.1 Network, Host, Authenticated, and Wireless Scans 8.2 SAST, DAST, IAST, SCA, IaC, and Mobile Scans 8.3 Container, Secrets, and ICS Vulnerability Assessment 8.4 Core Vulnerability Scanners (Nessus, OpenVAS, Nikto)
9 Scan Analysis and Physical Security
9.1 Specialized Discovery Tools 9.2 Validating Scan, Recon, and Enumeration Results 9.3 Public Exploit Selection and Scripted Validation 9.4 Physical Security Concepts for PenTests
10 Attack Prioritization and Preparation
10.1 Target Prioritization: CVSS, CVE, CWE, and EPSS 10.2 Exploit Selection, Customization, and Attack Documentation
11 Network Attacks
11.1 On-Path, VLAN Hopping, Relay, and Multihomed Hosts 11.2 Default Credentials, Misconfigured Services, Packet Crafting, and Certificate Services
12 Authentication Attacks
12.1 Pass-the-Hash, Pass-the-Ticket, Pass-the-Token, and Kerberos Attacks 12.2 Password Attacks, MFA Fatigue, LDAP Injection, OIDC, and SAML
13 Host-Based Attacks
13.1 Privilege Escalation and Credential Dumping 13.2 Process Injection, Security Bypass, and Host Attack Tools
14 Web Application Attacks
14.1 SQL, Command, XSS, and SSTI Injection 14.2 CSRF, SSRF, Deserialization, IDOR, and Directory Traversal 14.3 LFI/RFI, Web Shells, API Abuse, JWT, and Session Hijacking
15 Cloud Attacks
15.1 IAM Misconfiguration, Metadata Service, and Exposed Storage 15.2 Container Escape, Supply Chain, and Cloud Attack Tools
16 Wireless and Social Engineering
16.1 Wireless Attacks and Tools 16.2 Phishing, Spearphishing, Whaling, Vishing, and Smishing 16.3 Physical Social Engineering and SE Tools
17 Specialized Systems
17.1 Mobile Attacks and AI Prompt/Model Attacks 17.2 OT/ICS, NFC, RFID, and Bluetooth Attacks
18 Attack Scripting and BAS
18.1 PowerShell, Python, and Bash Attack Automation 18.2 Breach and Attack Simulation (Caldera, Infection Monkey, Atomic Red Team)
19 Persistence
19.1 Scheduled Tasks, Services, Accounts, and Shells 19.2 C2, Backdoors, Rootkits, and Security-Control Tampering
20 Lateral Movement
20.1 Pivoting, Relays, and Additional Credential Capture 20.2 Remote Services: SMB, RDP, WinRM, WMI, SSH, and Others 20.3 Lateral Movement Tools and LOLbins
21 Exfiltration and Cleanup
21.1 Staging and Exfiltration 21.2 Cleanup, Restoration, and Artifact Preservation
8.2 SAST, DAST, IAST, SCA, IaC, and Mobile Scans
Key Takeaways Explain This Topic AI
SAST is static analysis of source code and of infrastructure-as-code templates; it does not require the application to be running.
DAST tests the running application from the outside, typically over HTTP, and finds issues that appear only at runtime.
IAST instruments a test or QA runtime so findings include request traces and code locations without treating production like a crawl target.
SCA matches third-party libraries and lockfiles to known CVEs; it is not a review of first-party source logic.
Mobile scans assess application packages such as APK or IPA for insecure storage, hardcoded secrets, and exported components; matching the type matters more than naming a mobile GUI.
Last updated: August 2026
CompTIA groups application scans under 3.1 as a separate family from network and host scans. The exam is heavy on matching : the stem describes what you were allowed to inspect, and you name the scan type. Learn the job of each acronym. Do not treat them as synonyms for "run a web scanner."
The official list is dynamic application security testing (DAST) , interactive application security testing (IAST) , software composition analysis (SCA) , static application security testing (SAST) including infrastructure as code (IaC) and source code analysis , and mobile scans.
SAST: source and IaC, not a live site
SAST inspects source code without executing the application . The analyzer reads languages the team wrote — Java, C#, Python, JavaScript, Go — and flags patterns such as string-built SQL, command concatenation, hardcoded secrets, and insecure cryptography APIs. Findings exist even if nobody has deployed the build. Dead code can still light up, which is a known SAST noise problem; the type is still SAST.
CompTIA explicitly parks IaC and source code analysis under SAST. IaC means templates that become infrastructure: Terraform, AWS CloudFormation, Azure Resource Manager, Kubernetes manifests, Helm charts, and similar. A SAST/IaC pass is the right answer when the tester is asked to review templates before deploy for an open security group, a public storage bucket, a privileged container, or a missing encryption flag. That is not DAST. Nothing is listening yet.
Exam trap: calling a Terraform review "a network scan" because the template mentions VPCs, or calling it SCA because HashiCorp is a third party. SCA is about application dependencies , not about who published the IaC tool.
DAST: the running application from the outside
DAST tests a running application, usually by sending HTTP and HTTPS requests the way a black-box tester or crawler would. You need a live URL — staging, QA, or an in-scope production window. Findings such as reflected cross-site scripting, directory listing, verbose 500 pages, and unauthenticated API routes appear because the app actually executed.
DAST may still use application credentials (a test user) to reach authenticated routes. That does not turn DAST into SAST, and it does not make it a Windows missing-KB scan. The object under test is the running app, not the source tree and not the guest OS patch list. If the stem says "crawl the staging URL" or "find XSS in the live form," pick DAST.
DAST cannot see a vulnerability that never executes. A dangerous helper function that no route calls can be a SAST hit and a DAST miss. Conversely, a misconfigured reverse proxy in front of the app is a DAST-visible issue that source analysis of the repo may never mention.
IAST: instrumented runtime in test
IAST sits between SAST and DAST. An agent or instrumentation inside the application runtime — a Java agent, a .NET profiler, a language hook — watches the app while a test suite or QA traffic runs . When a request hits a sink (SQL, OS command, LDAP), IAST can report the dataflow and the code location.
IAST belongs in test or QA , not as a reason to plant an agent in production without change control. Exam trap: calling IAST "just DAST with better reports" or "just SAST because it names a file." If the stem emphasizes an instrumented runtime during automated tests , and production was not crawled, the type is IAST.
SCA: third-party libraries and dependency CVEs
SCA inventories what you imported , not what you wrote. It reads lockfiles and manifests — package-lock.json , pom.xml , requirements.txt , go.sum , NuGet packages — and matches component names and versions to published CVEs and, often, license risk. The classic 3.1 item is a logging or serialization library with a known CVE while first-party source has no SQL concatenation at all.
SCA does not prove the vulnerable function is reachable. It proves the dependency is present . Reachability is a later analysis problem (objective 3.2). Exam trap: calling a pom.xml CVE SAST because the file is text, or calling it DAST because the app is in production. Presence of a third-party CVE in a dependency graph is SCA even if nobody has started the server.
Mobile scans
A mobile scan targets a packaged mobile application — typically an Android APK or iOS IPA — and sometimes the matching mobile API. Testers look for insecure local storage, backup flags, exported activities or intent filters, certificate pinning gaps, and hardcoded keys in the package. Runtime tests on an authorized device or emulator can add traffic and storage findings, but 3.1 still wants you to recognize mobile as its own scan type rather than calling every HTTP check DAST.
Mobile Security Framework (MobSF) is a common lab name for this work. On PT0-003 it belongs with later specialized and Domain 4.9 tooling; do not treat MobSF as the definition of the scan type. The exam match is "package or mobile app assessment," not a product logo.
Matching table (memorize the columns)
- Type What you inspect Is the app executing? Typical 3.1 finding
- SAST (source) First-party source No SQL built from unsanitized input in a .java file
SAST (IaC) Terraform, manifests, CloudFormation No (nothing deployed yet) Open security group or privileged pod in a template
DAST Running HTTP(S) application Yes, from outside Reflected XSS on the staging URL
IAST Instrumented QA or test runtime Yes, from inside during tests SQLi with code location while the test suite runs
SCA Third-party libraries and lockfiles Not required CVE in a logging dependency in pom.xml
Mobile APK, IPA, or mobile API in scope Package analysis, sometimes a device Hardcoded key or backup-enabled flag in the package
Work a single product through the table. A payments API has Java source (SAST), Terraform for its load balancer (SAST/IaC), a pom.xml with a vulnerable parser (SCA), a staging URL (DAST), a QA agent that traces the login test (IAST), and an Android companion app (mobile). Those are six 3.1 answers, not one "app scan." Pick the type that matches the artifact in the stem.