Legacy Haven University

Unpatched application flaws reach production when teams scan too late, scan only one layer, or treat a green build as a secure build. CompTIA Security+ (SY0-701) treats that failure as a vulnerability-management problem: you identify weaknesses in code at rest and in the running application, then you confirm, prioritize, and fix them before attackers reuse them.

Industry vendors brand those two identification methods as SAST and DAST. The official SY0-701 objectives do not use those acronyms. Version 5.0 of the exam objectives names the same work as static code analysis / static analysis and dynamic analysis, and it places a third method beside them: package monitoring. Learn the industry labels. Answer the exam with CompTIA’s words.

This article maps both testing methods onto the SY0-701 domains, shows how each method actually inspects an application, and places them inside the software development lifecycle (SDLC) that Domain 5 lists as a governance policy. Use it with the broader domain map in The Ultimate Guide to CompTIA Security+ (SY0-701) in 2026.

Where SY0-701 Puts Pipeline Testing

Three objectives carry this topic. They do not overlap by accident.

Objective 4.1 asks you to apply application-security techniques to computing resources. The official list is short and specific: input validation, secure cookies, static code analysis, code signing, and sandboxing. Static code analysis sits here as a control you run, not as a theory you define.

Objective 4.3 asks you to explain vulnerability-management activities. Under identification methods, CompTIA groups application security as:

• Static analysis
• Dynamic analysis
• Package monitoring

Those three sit next to vulnerability scans, threat feeds, penetration testing, responsible disclosure / bug bounty programs, and system or process audits. After identification, the same objective requires analysis: confirm the finding, separate false positives from false negatives, prioritize, and score with CVSS and CVE context.

Objective 5.1 lists the software development lifecycle (SDLC) as an information-security policy, beside change management. The exam does not name CI/CD, DevOps, or DevSecOps in the published objectives. Treat the pipeline as the operational form of the SDLC policy: code enters, tests run, a build ships, and change control records the release.

Objective 2.3 supplies the defects these tests hunt. Application vulnerabilities on the official list include memory injection, buffer overflow, race conditions (time-of-check / time-of-use), and malicious update. Web-based items include Structured Query Language injection (SQLi) and cross-site scripting (XSS). A pipeline that never inspects code or runtime behavior lets those classes travel from a commit into production.

CompTIA’s own hardware and software list for SY0-701 preparation includes “static and dynamic analysis tools.” The exam can expect you to choose the right class of tool for a scenario. It does not require a vendor name.

Static Analysis: Inspect Code Without Running It

Static analysis examines source code, bytecode, or binaries at rest. The application does not execute. NIST describes the job of source-code security analyzers in that same frame: examine source code at rest and report weaknesses that can lead to vulnerabilities. Industry practice calls this method static application security testing (SAST). CompTIA calls it static code analysis when you apply it (4.1) and static analysis when you use it to identify vulnerabilities (4.3).

Under the hood, a static analyzer does not “read the program like a developer.” It builds a model of the code, then matches that model against rules.

1. The tool parses the repository or the compiled artifact.
2. It constructs an intermediate representation: an abstract syntax tree, a control-flow graph, and often a data-flow graph.
3. Rule packs walk those graphs. A rule asks questions such as: does unsanitized user input reach a SQL statement? Does a copy run past the declared buffer length? Does a check on a file happen on one line and the use of that file happen later with no lock?
4. The tool emits findings with file, line, rule ID, and severity.

That design explains both the power and the noise. Because the analyzer sees the internals, it can flag a buffer overflow, a TOC/TOU race, or an injection sink before anyone starts the application. Because it does not execute the program, it cannot see a misconfigured TLS listener, a broken session cookie flag, or an authentication bypass that only appears after three live requests. It also cannot prove that a flagged path is reachable. That gap produces false positives—alerts that look like defects but never fire in a real run. Objective 4.3 expects you to confirm findings instead of treating every alert as a vulnerability.

Place static analysis early. Developers run it in the editor or on every pull request. A pipeline job can fail the build when a high-severity rule hits newly introduced code. That timing matches 4.1: you apply static code analysis as a technique on the computing resource that holds the source, not after users already exercise the product.

Static analysis does not replace the other 4.1 techniques. Input validation still stops tainted data at the boundary. Code signing still proves the binary you ship is the binary you built. Sandboxing still contains a process that slips past the scanner. The scanner finds the defect in the text. The other controls still have to hold the line at runtime.

Dynamic Analysis: Attack the Running Application

Dynamic analysis inspects the application while it runs. CompTIA lists it only under 4.3 identification methods, not under the 4.1 application-security technique list. That placement is deliberate. Dynamic analysis is how you discover what the live system actually does, not how you rewrite a source file.

Industry practice calls the automated form dynamic application security testing (DAST). A DAST tool takes a black-box stance: it does not need the source. It sends crafted requests to exposed interfaces—web routes, APIs, forms—and it reads the responses. IBM describes the same outside-in pattern: the tester examines the application in its runtime environment and simulates malicious traffic rather than reading the repository.

A typical dynamic scan follows this data flow:

1. The scanner crawls or is given a list of URLs and API endpoints.
2. It maps parameters, cookies, headers, and authentication flows.
3. It injects payloads: SQL fragments, script tags, path traversals, oversized fields, replayed tokens.
4. It compares responses. An error page that leaks a database message, a reflected script that comes back unencoded, or a session cookie missing the Secure flag becomes a finding.
5. It reports the request, the response evidence, and a suggested class of weakness.

Because the application is live, dynamic analysis catches defects static analysis never sees: server misconfiguration, broken access control that only appears after login, insecure cookie attributes, and injection that depends on a concrete runtime interpreter. Because the scanner lacks source context, it often cannot point to the exact function that built the response. Developers then reproduce the request and walk the code by hand.

Dynamic analysis also creates operational risk. A destructive payload against a live production database is not a test. Teams run these scans against staging or an isolated production clone, then treat remaining production checks as carefully scoped monitoring. CompTIA does not prescribe that staging pattern in the objectives. The constraint follows from the method itself: you are attacking a running system.

Objective 4.3 still applies after the scan. Confirm the finding. A scanner that reports XSS because it saw its own payload reflected has not proved the browser will execute it. A scanner that misses an authenticated admin route has produced a false negative. Prioritize what you confirm. CVSS and environmental impact decide order, not the tool’s default color code.

SAST vs DAST: The Distinction the Exam Tests

Use this comparison when a question gives you a symptom and asks which identification method fits.

Neither method owns the full 2.3 list. A buffer overflow in C source is a static-analysis target. An SQLi payload that only works after a live login is a dynamic-analysis target. A malicious update that arrives as a swapped dependency is neither: that is package monitoring.

Package Monitoring Completes CompTIA’s Trio

Objective 4.3 does not stop at static and dynamic analysis. It adds package monitoring as a peer identification method. Modern applications pull libraries, containers, and modules from external registries. A clean SAST report on first-party code does not inspect those packages. A DAST scan may never exercise a vulnerable function inside a locked dependency.

Package monitoring watches the inventory: names, versions, and known CVE records for those components. When a library you ship receives a new CVE, the monitor flags the build or the deployed artifact. That control maps directly to the 2.3 “malicious update” vulnerability class. Attackers do not need your source if they can poison a package you already trust.

A complete identification plan on the exam therefore has three legs, not two:

• Static analysis for first-party code at rest
• Dynamic analysis for the running application
• Package monitoring for the components you did not write

How the Methods Sit in the SDLC

Domain 5 treats the SDLC as policy. The pipeline is how that policy becomes a repeatable process.

Design and coding. Developers write input validation and avoid TOC/TOU patterns. Static analysis starts here. A rule that fires in the editor costs minutes. The same defect in production costs an incident.

Build and review. The pipeline runs static analysis against the branch and records the result in change management. Code signing prepares the artifact so operators can verify integrity later—another 4.1 technique, not a scanner feature.

Test and stage. A deployable build reaches a non-production environment. Dynamic analysis attacks that build. Sandboxing, also on the 4.1 list, can isolate the scanner or the application so a crash stays contained.

Release and operate. Package monitoring continues after release. A dependency that was clean on ship day can become a CVE next week. Vulnerability management then moves from identification into 4.3 analysis and remediation: confirm, prioritize, patch or mitigate, and validate that the fix holds.

A “secure pipeline” on SY0-701 is not a product name. It is this sequence under governance: the SDLC policy says when security work happens; 4.1 names the techniques you apply; 4.3 names how you find and judge the remaining defects.

Choosing the Method in an Exam Scenario

Read the stem for what the tester can see and whether the application is running.

• The team has the repository, the application is not running, and the question mentions source review or a pre-commit gate → static code analysis / static analysis.
• The team has a URL or API, no source, and the question describes crafted requests or a running web app → dynamic analysis.
• The finding is a known CVE in a third-party library version → package monitoring.
• The question asks you to apply a secure-coding control during development, not merely to discover a live bug → 4.1 items such as input validation, secure cookies, static code analysis, code signing, or sandboxing.
• The question then asks what you do with a noisy report → 4.3 analysis: confirm (false positive / false negative), prioritize, and use CVSS or organizational impact. Do not skip confirmation.

If a scenario offers only one test and claims the application is “fully assessed,” the answer is incomplete. CompTIA listed three application-security identification methods for a reason. Static analysis and dynamic analysis answer different questions. Package monitoring answers a third. The pipeline that ships software without all three leaves an official identification gap.

Study the five-domain map, then return to these identification methods until you can pick the correct one from a single sentence of evidence. The hub that organizes that map is The Ultimate Guide to CompTIA Security+ (SY0-701) in 2026.