Free CISSP Software Development Security practice test questions
8 questions from this domain with answers and explanations - different from the samples on the main (ISC)² CISSP page. Sign up free to practice the full set.
-
What is the security benefit of input validation in applications?
- AIt helps prevent injection and other attacks by rejecting malicious inputCorrect
- BIt encrypts stored records so the database remains protected at rest
- CIt authenticates the user before the request reaches the application
- DIt load-balances incoming requests across the available application servers
✓ Correct answer: AInput validation enforces that data entering an application matches expected type, format, length, and range before it is processed, so malformed or malicious input, such as SQL injection payloads or script tags, is rejected at the boundary rather than reaching interpreters or the database. It is a preventive application-layer control distinct from authentication, encryption, and load balancing, which protect identity, confidentiality, and availability but do not inspect the content of a request.
Why the other options are wrong- BEncryption at rest protects storage; it does not vet the content of incoming input.
- CAuthentication verifies identity, whereas validation checks the data supplied in a request.
- DLoad balancing distributes traffic and has nothing to do with sanitizing input.
-
Which condition describes a TOCTOU (time-of-check to time-of-use) race vulnerability?
- AData is written beyond the bounds of an allocated fixed-size memory buffer, corrupting adjacent memory
- BA session cookie is transmitted over the network without the Secure flag set, allowing plaintext exposure
- CUntrusted user input is concatenated directly into a SQL statement that the database then executes
- DA resource's state changes between when it is validated and when it is used, allowing an attacker to substitute itCorrect
✓ Correct answer: DA TOCTOU flaw is a race condition: a program checks a resource's state (for example, that a file path is safe and owned by the user) and then acts on it as a separate step. If an attacker changes the resource in the gap between the check and the use - such as swapping a file for a symlink to a privileged target - the program operates on something different from what it validated. Atomic operations or holding a lock across check-and-use closes the window.
Why the other options are wrong- AWriting past a buffer's bounds is a buffer overflow, not a check-to-use race condition.
- BA missing Secure flag is a cookie transport weakness, unrelated to TOCTOU timing.
- CConcatenating input into SQL is injection, not a race between check and use.
-
A C program copies user-supplied data into a fixed-size stack buffer using strcpy without bounds checking, allowing an attacker to overwrite the saved return address. Which compiler/runtime defense is SPECIFICALLY designed to detect this corruption before the function returns?
- AStack canaries (stack-smashing protection)Correct
- BHTTP Strict Transport Security (HSTS)
- CContent Security Policy (CSP)
- DCross-Origin Resource Sharing (CORS)
✓ Correct answer: AA stack canary is a known sentinel value the compiler inserts between local buffers and the saved return address; the function epilogue verifies the canary before returning and aborts if it changed, catching the classic stack-based buffer overflow. This is a memory-safety defense aimed precisely at the described overwrite. The other options are web/transport controls unrelated to native stack corruption.
Why the other options are wrong- BHSTS forces browsers to use HTTPS and has nothing to do with native memory corruption on the stack.
- CCSP restricts which content/scripts a browser will load to mitigate XSS, not stack buffer overflows.
- DCORS governs cross-origin browser requests; it is irrelevant to detecting a corrupted return address in compiled code.
-
A company acquires another firm's web application and must determine its security posture, but no source code is available and the vendor is gone. Which assessment technique is MOST appropriate to evaluate the compiled, deployed application's resilience to attack?
- APenetration testing combined with dynamic and fuzz testing against the running applicationCorrect
- BStatic source-code analysis run against the application's original code repository
- CManual peer code review of the application's pull requests before merge
- DUnit test coverage measurement across the application's internal functions
✓ Correct answer: AWhen only the deployed, compiled application is accessible, black-box techniques such as penetration testing, DAST, and fuzzing exercise the live system to reveal exploitable weaknesses without needing source. These approaches simulate real attacker behavior and identify runtime, configuration, and input-handling flaws. They are the practical choice for assessing acquired software whose code is unavailable.
Why the other options are wrong- BStatic source analysis needs the source code, which is unavailable, so it cannot assess the compiled deployed application.
- CPeer code review also requires access to the source, which the acquired application no longer provides.
- DUnit test coverage measures the codebase's tests, but with no source available it cannot evaluate the compiled app.
-
An API issues signed JSON Web Tokens (JWTs) to clients. A reviewer warns that accepting the token's own 'alg' header value to choose verification could let an attacker switch the algorithm to 'none' and forge tokens. Which control best prevents this?
- APin the server to a specific expected signing algorithm and reject 'none' or unexpected algorithmsCorrect
- BExtend the JWT expiration window so that a single issued token can be reused for much longer
- CStore the JWT in a browser cookie without setting the HttpOnly or Secure flags
- DApply an additional layer of Base64 encoding to the token before it is transmitted
✓ Correct answer: AThe classic JWT attack abuses servers that trust the token's 'alg' header to pick verification, allowing an attacker to set it to 'none' or swap RS256 for HS256. Pinning the accepted algorithm server-side and validating against an allowlist neutralizes this, since the server no longer lets the attacker dictate how the signature is checked. Tokens claiming 'none' or an unexpected algorithm are rejected outright.
Why the other options are wrong- BA longer expiration merely lengthens token reuse and does not stop an attacker from switching the algorithm to none.
- CCookie flags affect exposure to theft, not whether the server trusts an attacker-chosen alg header.
- DExtra Base64 encoding changes only the token's representation and provides no defense against algorithm substitution.
-
A development organization is integrating security into an Agile/DevSecOps workflow. Which TWO practices BEST embed security continuously without becoming a one-time, end-of-cycle gate? (Choose TWO)
- AAutomate SAST and dependency (SCA) scanning to run on every pull request in the pipelineCorrect
- BDefine security acceptance criteria and abuse cases within user stories during backlog groomingCorrect
- CDefer all security testing to a single manual review just before the production release
- DRemove automated tests from the pipeline to keep build times short
✓ Correct answer: A, BDevSecOps integrates security throughout the lifecycle: automated SAST and software composition analysis on each pull request give developers fast, continuous feedback, while building security acceptance criteria and abuse cases into user stories ensures requirements address threats from the start. These shift-left, automated practices avoid a brittle end-of-cycle gate. The incorrect options concentrate or eliminate security work, defeating continuous assurance.
Why the other options are wrong- CA single pre-release manual gate is exactly the late, bottlenecked approach DevSecOps seeks to replace, finding defects expensively and late.
- DRemoving automated tests sacrifices continuous quality and security feedback for marginal speed gains.
-
A security leader wants the development organization to catch design-level flaws as early as possible rather than discovering them in penetration testing late in the project. At which SDLC phase does formal threat modeling deliver the GREATEST return by shaping the system before code is written?
- ARequirements and design phaseCorrect
- BImplementation (coding) phase
- CTesting and verification phase
- DOperations and maintenance phase
✓ Correct answer: ASecurity is cheapest to add early. Threat modeling at design time identifies trust boundaries, attack surface, and abuse cases so the architecture can be changed on paper, where remediation costs least, rather than after the flaw is embedded in code and deployed.
Why the other options are wrong- BCoding is where design decisions are implemented; modeling threats only here misses architectural flaws that should have been removed earlier.
- CTesting confirms whether controls work but happens after the design is fixed, so it catches flaws far later and more expensively.
- DOperations is the latest and costliest place to discover a design flaw, requiring rework of fielded software.
-
A vendor instruments the running application with agents so that during functional tests it can observe data flow inside the code and pinpoint vulnerable lines with low false positives, combining strengths of static and dynamic analysis. Which testing approach is this?
- AIAST (interactive application security testing), agent-based during test runsCorrect
- BDAST only, observing external black-box behavior of the running app
- CSAST only, analyzing source code before the application ever runs
- DPenetration testing, an external manual assessment of the live system
✓ Correct answer: AInteractive application security testing instruments the application with agents while it runs, so it observes both the underlying code and live data flow as functional or automated tests exercise the application. That inside view lets IAST pinpoint the exact vulnerable line with far fewer false positives than DAST, which only sees external behavior, or SAST, which never sees runtime execution at all.
Why the other options are wrong- BDAST observes only external, black-box behavior and cannot see internal code-level data flow during execution.
- CSAST analyzes code statically before it runs and cannot observe live runtime data flow.
- DPenetration testing is a manual or tool-assisted external assessment, not instrumented internal data-flow analysis.
How Software Development Security is tested
This domain holds 132 of the 1,117 questions in the CISSP bank, about 12%. The mix is 106 single-answer multiple choice and 26 multiple-response, so it is worth practising the formats as well as the content.
Once you have a few attempts recorded, CertGrid scores every domain separately and points you at the weakest one, so you can drill Software Development Security on its own rather than re-running full-length mocks.
Other CISSP exam domains
- Security and Risk Management172 questions
- Asset Security109 questions
- Security Architecture and Engineering141 questions
- Communication and Network Security138 questions
- Identity and Access Management138 questions
- Security Assessment and Testing130 questions
- Security Operations157 questions
- All CISSP practice questions1,117 total
- Software Development Security study notesKey concepts
- Security practice examsAll Security
CISSP Software Development Security FAQ
How many CISSP practice questions are there on Software Development Security?
CertGrid has 132 CISSP practice questions mapped to Software Development Security, which is about 12% of the 1,117-question CISSP bank. Every one carries a full explanation covering why the right answer is right and why each wrong option is wrong.
Can I practice only the Software Development Security domain?
Yes. Inside CertGrid you can run a focused drill on a single exam objective rather than the whole bank, and the app picks your weakest domain automatically once you have attempts to measure. The button on this page starts a Software Development Security drill directly.
How is Software Development Security tested on the CISSP exam?
In this bank the domain is made up of 106 single-answer multiple choice and 26 multiple-response questions, and it accounts for roughly 12% of the practice pool. Mapping follows the current published exam objectives; CertGrid is an independent practice platform and these are not official exam questions.
What CertGrid is (and is not)
CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.
Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by ISC2. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.