CISSP Software Development Security: 120 practice questions
7-day money-back guarantee — full refund within 7 days of purchase if you've completed under 20% of the questions. See pricing →
Certifications Tools Flashcards Career Paths Exam Guides Blog Pricing For Teams About
Try 20 questions free →

CISSP Software Development Security: 120 practice questions

CISSP 120 questions 12 shown free

12 of the 120 Software Development Security questions in the Certsqill CISSP bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CISSP? Take the free 5-min readiness check →

1. Apply context-appropriate output encoding before HTML: Select TWO controls that address the demonstrated risks

Medium
An international nonprofit's portal builds a search query and displays the search term. Exhibit: the query concatenates user input into SQL; the browser renders returned text inside an HTML paragraph; the team can add exactly two controls. Select TWO controls that address the demonstrated risks.

Select two. More than one option is correct — every correct one is ticked below.

  1. Escape database input before concatenating it into SQL.
    Escaping alone is fragile and does not provide the primary separation between SQL code and data.
  2. Apply context-appropriate output encoding before HTML rendering. ✓
    HTML-context output encoding treats returned input as data, preventing executable markup from becoming active browser content.
  3. Validate search input against a permitted character set only.
    Allowlisting can constrain inputs, but it does not replace parameterization or context-specific output encoding.
  4. Use parameterized queries for database operations. ✓
    Parameterized queries separate SQL instructions from supplied values, preventing input from altering query structure.
  5. Deploy a web application firewall in front of the portal.
    A WAF may provide defense in depth, but it does not correct unsafe query construction or rendering.
The trap
Input validation is not universal protection for either demonstrated vulnerability. Escaping is not the primary SQL injection defense. A perimeter filter cannot replace secure application construction.

Parameterized queries address SQL injection; context-specific encoding addresses the HTML output risk.

2. 13 weighted defects per million lines: Using risk-weighted escaped defects per million lines, which result is

Medium
A telecommunications provider records four escaped defects: two low-risk defects, one medium-risk defect, and one high-risk defect. Their assigned weights are 1, 3, and 8 respectively. The release contained 1,000,000 lines of code. Using risk-weighted escaped defects per million lines, which result is correct?
  1. 0.13 weighted defects per million lines.
    The denominator is already one million lines, so the weighted total of 13 is not divided by another 100.
  2. 13 weighted defects per million lines. ✓
    The weighted total is 2×1 + 1×3 + 1×8 = 13; with 1,000,000 lines, the rate is 13 weighted defects per million lines.
  3. 14 weighted defects per million lines.
    The weighted total is 13, not 14: two low-risk defects contribute 2, one medium contributes 3, and one high contributes 8.
  4. 4 defects per million lines.
    This is the raw defect count and ignores the assigned risk weights.
The trap
Uses the unweighted count. Introduces an extra normalization factor absent from the measure. Miscomputes the weighted numerator.

The weighted total is 13, and the one-million-line denominator yields 13 weighted defects per million lines.

3. Run SCA against dependency manifests and lockfiles: Which TWO controls satisfy those explicit requirements?

Medium
A professional services firm permits only two automated controls in its pipeline. Management requires one control to inspect code without executing the application and another to identify vulnerable third-party packages from dependency data. Which TWO controls satisfy those explicit requirements? Select TWO.

Select two. More than one option is correct — every correct one is ticked below.

  1. Run SCA against dependency manifests and lockfiles. ✓
    SCA identifies third-party components and known vulnerabilities, matching the dependency-focused requirement.
  2. Run SAST on source or compiled code. ✓
    SAST examines source or compiled code without executing the target application, matching the first requirement.
  3. Require signed release artifacts before deployment.
    Signing supports publisher and integrity verification, but does not inspect code or identify package vulnerabilities.
  4. Run DAST against a deployed test instance.
    DAST tests running behavior, so it does not satisfy the requirement for nonexecuting code inspection.
  5. Generate an SBOM without analyzing package vulnerabilities.
    An SBOM inventories components, but inventory alone does not identify or remediate known vulnerabilities.
The trap
Dynamic testing executes the application under test. Integrity evidence is not static analysis or dependency analysis. Component inventory alone does not provide vulnerability identification.

SAST supplies nonexecuting code analysis, while SCA identifies vulnerable third-party components.

4. Obtain contractual right-to-audit verification access: Which TWO controls most directly address these demonstr

Easy
A food distributor is evaluating a COTS warehouse package. The supplier's questionnaire claims secure development, but the contract has no patch-notification obligation, no vulnerability monitoring commitment, and no agreed verification access. Which TWO controls most directly address these demonstrated due-diligence gaps? Select TWO.

Select two. More than one option is correct — every correct one is ticked below.

  1. Accept the completed supplier questionnaire as sufficient evidence.
    A questionnaire is self-reported and does not independently verify security within the distributor's scope.
  2. Obtain contractual right-to-audit verification access. ✓
    A right to audit enables agreed verification beyond relying solely on supplier self-reporting.
  3. Add vulnerability notification and patching obligations. ✓
    Defined notification and patching requirements create measurable supplier responsibilities for vulnerability response.
  4. Require a general nondisclosure agreement before purchase.
    An NDA protects confidentiality commitments but does not establish patching, monitoring, or verification controls.
  5. Transfer all security accountability to the supplier contractually.
    Contracts can assign obligations, but the distributor retains oversight and accountability for its role.
The trap
Self-reported answers do not establish independent assurance. Confidentiality terms do not address demonstrated assurance gaps. Contractual transfer does not eliminate customer accountability.

Patch obligations and audit rights directly address missing supplier response commitments and independent verification.

5. Add testable security acceptance criteria to backlog: Which approach best satisfies the stated constraint?

Medium
A hospital consortium uses two-week agile sprints. The product owner says security work must remain visible in the backlog, while developers want security considered only during final acceptance. Which approach best satisfies the stated constraint?
  1. Create a separate security backlog outside product planning.
    A separate backlog can disconnect security requirements from features and sprint acceptance decisions.
  2. Add testable security acceptance criteria to backlog stories. ✓
    Backlog acceptance criteria keep security visible and make completion testable within each story.
  3. Schedule one security review after the release.
    A final review delays security integration and conflicts with maintaining visible sprint-level requirements.
  4. Rely on developers' informal security judgments.
    Informal judgment lacks explicit, testable requirements and weakens consistent acceptance decisions.
The trap
Separation reduces integration with delivery planning. Late review conflicts with integrated development. Unrecorded expectations are difficult to verify consistently.

Testable security acceptance criteria integrate explicit requirements into normal agile backlog work.

6. Authorized notes still require context-specific output: What residual limitation remains?

Medium
A logistics operator now verifies authorization server-side for every shipment object and requested action. A security review finds that authorized shipment notes are inserted into an HTML page without context-specific encoding. What residual limitation remains?
  1. Client-side validation should replace server-side authorization.
    Client-side validation is bypassable and cannot replace server-side authorization or context-appropriate output encoding.
  2. The server must stop checking object permissions.
    Removing server-side authorization would discard an effective control unrelated to the rendering vulnerability.
  3. Authorized notes still require context-specific output encoding. ✓
    Authorized data can still contain markup interpreted by the browser, so context-appropriate encoding or safe APIs remains necessary.
  4. Authorization guarantees that shipment notes contain no executable markup.
    Authorization determines whether access is permitted; it does not guarantee that authorized content is safe for browser interpretation.
The trap
Treats separate controls as alternatives. Confuses input checks with authorization and output safety. Confuses access control with content safety.

Authorization controls access, but context-specific encoding is still required for rendered note content.

7. Remediate the defect: Which corrective action is most appropriate?

Hard
A municipal water operator's independent security acceptance test finds that a release exposes unauthorized maintenance records. The development lead proposes correcting the code and self-certifying the same release for production. Which corrective action is most appropriate?
  1. Remediate the defect, then obtain independent acceptance retesting before production release. ✓
    Remediation followed by independent retesting verifies that the unauthorized-access failure is resolved before production acceptance.
  2. Replace the test with a code-signing check.
    Code signing verifies signer and artifact integrity under trusted validation, not authorization behavior.
  3. Deploy while tracking the unresolved exposure as technical debt and reviewing it during the next release cycle.
    The demonstrated unauthorized disclosure remains unresolved and lacks an authorized risk disposition.
  4. Ask the developer to rerun the failed test.
    Developer retesting does not provide independent acceptance evidence after the failure.
The trap
Self-retesting does not restore independent acceptance. Artifact integrity does not validate access-control behavior. Technical-debt labeling does not resolve a material security failure.

Remediate the defect and obtain independent retesting before production acceptance.

8. Restrict the build credential to compilation and artifact: Select TWO.

Medium
A government records office requires its build service to compile code and publish artifacts to an artifact repository. It must not modify source repositories or deploy to production. The current build credential can perform all three actions. Select TWO changes that best enforce least privilege. Select TWO.

Select two. More than one option is correct — every correct one is ticked below.

  1. Monitor the broad credential without changing its permissions.
    Monitoring improves detection, but the excessive permissions remain available for misuse or compromise.
  2. Restrict the build credential to compilation and artifact publication only. ✓
    Removing source-modification and production-deployment permissions enforces least privilege for the build service.
  3. Give developers the same production deployment credential.
    Sharing deployment authority expands access and weakens accountability.
  4. Use separate identities for build and production deployment. ✓
    Separate identities prevent build credentials from inheriting production deployment authority and support separation of duties.
  5. Use the unrestricted credential to sign published artifacts.
    Signing can support integrity and provenance, but does not reduce the credential's excessive operational permissions.
The trap
Shared credentials increase privilege and reduce attribution. Logging does not remove unnecessary authority. Signing does not remediate excessive build authority.

Restrict build permissions and separate build identity from production deployment authority.

9. The component requires risk assessment and remediation: What inference is justified by this evidence?

Medium
A remote clinical service maintains an SBOM for every release. A listed open-source component has a published vulnerability, no available vendor patch, and is used by the application. What inference is justified by this evidence?
  1. The application is definitely exploitable in production.
    Component vulnerability and usage warrant assessment, but the evidence alone does not prove exploitability.
  2. The component requires risk assessment and remediation planning. ✓
    The SBOM identifies exposure, while the vulnerability and usage justify assessing treatment or replacement.
  3. The SBOM has automatically remediated the vulnerability.
    An SBOM inventories components but does not change vulnerable code or remediate identified weaknesses.
  4. The component is safe because its publisher is known.
    Publisher identity does not establish absence of vulnerabilities in the supplied component.
The trap
Inventory is not remediation. Known publisher status is not vulnerability assurance. The evidence does not establish exploitability.

The SBOM establishes component presence; vulnerability evidence supports risk assessment and remediation planning, not certainty of exploitation.

10. The threat model needs reassessment for the new boundary: What limitation remains?

Easy
An industrial manufacturer approved a threat model for an internal production scheduler. During implementation, the design adds an external partner data feed and a new trust boundary. The original model remains unchanged, and code review finds no defect in existing controls. What limitation remains?
  1. Signing the scheduler artifact resolves the modeling gap.
    Signing verifies artifact integrity and signer trust, but does not analyze changed threats or boundaries.
  2. The threat model needs reassessment for the new boundary. ✓
    A changed trust boundary and external flow can introduce threats absent from the approved original model.
  3. The team must remove every external data feed.
    The evidence requires updated analysis, not automatic removal of a potentially justified integration.
  4. Code review proves the original threat model remains sufficient.
    Code review cannot establish that newly introduced data flows and trust boundaries were modeled adequately.
The trap
Risk analysis does not mandate eliminating every integration. Integrity verification cannot replace threat modeling. Implementation review does not replace threat-model reassessment.

New trust boundaries and external flows require threat-model reassessment despite clean code review results.

11. Targeted static and dynamic memory-safety results: Which evidence is most appropriate?

Medium
A pharmaceutical laboratory is reviewing an application that handles compound records. The authorization authority requires evidence that memory bounds and object lifetimes are safely handled before production approval. Which evidence is most appropriate?
  1. A code-signing certificate for the binary
    Code signing verifies publisher and artifact integrity, not safe memory bounds or object lifetimes.
  2. A general vulnerability scan reporting no detected high-severity findings
    A generic scan may miss memory defects and does not establish coverage of boundary and lifetime conditions.
  3. A spreadsheet listing developers who reviewed memory-related functions
    Reviewer names show participation but do not demonstrate safe runtime behavior or adequate technical coverage.
  4. Targeted static and dynamic memory-safety results for boundary and lifetime cases ✓
    Static and dynamic evidence directly evaluates memory handling across relevant code paths and runtime conditions.
The trap
Confuses authenticity with memory safety. Treats review participation as proof of secure behavior. Assumes broad severity results prove a specific property.

Use targeted static and dynamic evidence addressing memory boundaries and object lifetimes.

12. Require the missing security scenarios to be tested: What should the reviewer decide?

Easy
A media production company policy permits release exceptions only when required security tests are complete or formally waived by the security authority. A team reports 98 percent unit-test coverage, but authorization failures and unsafe file handling were not tested. What should the reviewer decide?
  1. Approve because coverage exceeds the usual threshold.
    Aggregate coverage does not demonstrate that required security scenarios were tested.
  2. Record the omitted scenarios as technical debt and authorize release under normal procedures.
    Technical-debt tracking does not satisfy the explicit release condition.
  3. Approve because repeatable unit tests provide stronger release evidence than specialized security testing for authorization and file handling.
    Repeatability does not compensate for omitted tests of the stated security behaviors.
  4. Require the missing security scenarios to be tested or obtain a documented waiver from the security authority before approving release. ✓
    The policy requires completion of the relevant security tests or a formal waiver before release.
The trap
Equates a coverage percentage with security-test completeness. Reclassifies an unmet requirement instead of resolving or formally waiving it. Confuses test consistency with relevant security coverage.

Require the missing security tests or a formal waiver.

108 more Software Development Security questions

The remaining 108 questions in this domain are part of the full CISSP bank — 1200 questions, every option explained. Start with the free five-minute check and see your score per domain.

Test your CISSP readiness — free

Other CISSP domains

Part of the Certsqill CISSP question bank · Software Development Security · Every answer, right and wrong, comes with its own explanation.