CCNA Secure Software Testing Questions

Option C is correct because the ease of exploitability and the existence of public exploits (e.g., weaponized PoCs in Exploit-DB or Metasploit modules) directly raise the real-world risk of a DAST finding, making it a primary prioritization factor. Option D is correct because the sensitivity of the data handled by the vulnerable endpoint (e.g., PII, credentials, or PCI data) determines the potential business impact if the finding is exploited, which is essential for risk-based triage. Option E is correct because the CVSS base score provides a standardized, vendor-neutral severity metric (combining exploitability and impact sub-scores) that is widely used to rank DAST findings objectively.

Option A does not belong because the time of day a scan ran has no bearing on the vulnerability's severity or exploitability. Option B does not belong because lines of code is a static code metric, not a DAST finding attribute, and does not indicate exploitability or impact.

Option A is correct because secure API authentication must prevent username/account enumeration: error responses for invalid usernames and invalid passwords should be indistinguishable (same generic message and status code, e.g., 401 with a generic body), so validating that error messages do not disclose account existence is a core security test. Option B is correct because insecure token storage is a common authentication weakness: tests should verify that tokens (JWT, OAuth 2.0 access/refresh tokens, session IDs) are not stored in insecure locations such as localStorage, unencrypted files, or logs, and are protected in transit and at rest. Option C is correct because token lifecycle controls are essential: tests must confirm that tokens expire after their defined lifetime (e.g., JWT 'exp' claim), that refresh tokens can be revoked, and that revoked or expired tokens are rejected by the API.

Option D is not a secure authentication test element; automating the password recovery workflow is a functional/process automation concern, not a security validation of authentication mechanisms. Option E is not a security test element; measuring API response speed is a performance test and does not validate authentication security properties.

Option B (PDF) is correct because PDF is a standard, widely used format for delivering polished security testing reports, preserving layout, tables, and charts for stakeholders and clients. Option E (JSON) is correct because JSON is a common machine-readable format used to export structured findings from scanners and testing tools, enabling automation, parsing, and integration with other systems. Option A (PNG) is an image format, suitable for screenshots or diagrams but not a typical full report output format.

Option C (MP3) is an audio format and is irrelevant to security report deliverables. Option D (BIOS) is firmware, not a report format at all.

Option C is correct because fuzz testing deliberately sends malformed, unexpected, and potentially destructive inputs, so the fuzzing environment must be isolated from production data to prevent corruption, data leakage, or service disruption. Option E is correct because monitoring application logs for crash signals, exceptions, stack traces, and error codes is essential to detect the faults fuzzing is designed to uncover and to reproduce and triage them. Option A is wrong because disabling logging removes the very evidence needed to identify crashes and exceptions, undermining the purpose of fuzzing.

Option B is wrong because manual input does not scale and defeats the automation that makes fuzzing effective at generating large volumes of varied test cases. Option D is wrong because using a production environment risks real data and availability, whereas fuzzing should run in an isolated, non-production environment.

Option B is correct because integrating SAST into early SDLC stages (e.g., IDE plugins or pre-commit hooks) gives developers immediate feedback on secure coding patterns while code is being written, enabling them to fix issues before they propagate. Option C is correct because SAST analyzes source code statically without executing it, allowing vulnerabilities such as SQL injection, XSS, or hardcoded credentials to be identified early in development when remediation is cheapest and least disruptive. Option A is incorrect because SAST does not reduce developer education; it typically requires security training so developers can interpret findings and apply secure coding practices.

Option D is incorrect because SAST tools inherently produce false positives due to limitations in static analysis, and no tool eliminates all of them. Option E is incorrect because SAST is not penetration testing; pen testing involves dynamic exploitation of running applications, whereas SAST is a static code review technique and does not automate pen testing.

Option A is correct because the password recovery/reset workflow is a classic authentication bypass vector: testers must check for predictable or leaked reset tokens, token reuse, missing expiry, host-header injection in reset links, and whether the reset endpoint verifies the user's identity before allowing a password change. Option C is correct because manipulating session cookies (e.g., tampering with session IDs, forging JWTs, altering role/identity claims, or replaying stolen cookies) directly tests whether the application properly validates session state and can be tricked into granting authenticated access without valid credentials. Option E is correct because brute forcing account credentials tests authentication strength controls such as account lockout thresholds, rate limiting, CAPTCHA enforcement, and password complexity, all of which are core to assessing whether authentication can be bypassed through weak credential policies.

Options B and D are incorrect because changing the CSS file or the application's color scheme are purely cosmetic presentation changes that have no bearing on authentication logic, session handling, or access control.

Option B is correct because IAST instruments the running application and observes execution paths, so code that is never reached during testing (unreachable or dormant code paths) cannot be exercised and therefore its vulnerabilities go undetected. Option E is correct because IAST agents hook into runtime execution and add instrumentation overhead, which can degrade application performance and throughput, making performance impact a well-known implementation challenge. Option A is not a defining IAST challenge since IAST relies on runtime instrumentation rather than requiring full source code access, unlike SAST.

Option C is incorrect because IAST typically still produces false positives, so a 'lack of false positives' is not a challenge. Option D is incorrect because IAST agents are deployed on the application server or runtime environment, not on client machines.