8.2 SAST, DAST, IAST, SCA, IaC, and Mobile Scans

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)

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.