Which Practice Protects Against Malformed Input Destabilization?
A development team is launching a new public-facing web product. The Chief Information Security Officer has asked that the product be protected from attackers who use malformed or invalid inputs to destabilize the system. Which of the following practices should the development team implement?
Community Votes
100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The scenario specifically targets runtime behavior and system stability when processing malformed inputs, making dynamic fuzz testing the direct solution over static code review methods.
This question evaluates understanding of application security testing techniques designed to handle unexpected or malformed inputs. The community consensus strongly supports fuzzing as the correct method for identifying system destabilization caused by invalid data.
Many candidates incorrectly choose Static Code Analysis (C) because it identifies input validation flaws like SQL injection or XSS during development, but the question emphasizes protecting a live system from destabilization via malformed inputs, which requires dynamic runtime testing rather than pre-execution code review.
Community Discussion (7 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Core Concept: Fuzz Testing vs. Static Analysis
The scenario describes a requirement to protect a public-facing application from attackers leveraging malformed or invalid inputs to cause system instability or crashes. The most effective practice for this specific goal is fuzzing (Option A). Fuzzing is an automated software testing technique that feeds random, unexpected, or invalid data into a program's interfaces to observe how it responds. By monitoring for crashes, memory leaks, assertion failures, or logic errors, fuzzing directly simulates real-world exploitation attempts targeting input validation weaknesses.Why Static Code Analysis is a Common Trap
Option C (Static Code Analysis or SAST) examines source code without executing it to find vulnerabilities like SQL injection, cross-site scripting (XSS), or buffer overflows. While highly valuable for enforcing proper input validation early in the SDLC, it cannot guarantee that the running application will handle all edge cases dynamically. As noted by community members advocating for SAST, it identifies coding flaws, but the question explicitly focuses on runtime destabilization from invalid inputs, which dynamic fuzzing targets more directly.Evaluating Other Options
Option B (Continuous Deployment) accelerates software delivery through automated pipelines but does not inherently provide security testing against malformed inputs. Option D (Manual Peer Review) relies on human inspection, which is prone to oversight and lacks the systematic, high-volume data generation required to uncover obscure input-handling bugs.Community Consensus & Exam Context
The SY0-701 exam frequently distinguishes between pre-runtime validation techniques (SAST, code reviews) and runtime/dynamic testing techniques (fuzzing, penetration testing). When keywords like "destabilize," "crash," "malformed inputs," or "unexpected data" appear, CompTIA expects you to select fuzzing as the primary defensive testing mechanism.Official Reference
- OWASP Testing Guide v4 - Fuzzing: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering_and_Reconnaissance/04-Fuzzing_Web_Applications
- NIST SP 800-115 - Technical Guide to Information Security Testing and Assessment: https://csrc.nist.gov/publications/detail/sp/800-115/final
- MITRE CWE-20: Improper Input Validation: https://cwe.mitre.org/data/definitions/20.html
Exam Strategy
Focus on keyword mapping: "malformed/invalid inputs causing crashes/instability" points directly to Fuzzing, while "reviewing source code for vulnerabilities" indicates SAST. Always match the testing phase (dynamic/runtime vs. static/pre-runtime) to the scenario's explicit outcome requirement before selecting your answer.
Related Analysis
Practice All SY0-701 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SY0-701 Practice Test →