CISSP Software Development Security: 59 practice questions

12 of the 59 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. Design phase; threat modeling during design identifies: At which SDLC phase should threat modeling be performe

1. Deployment phase; threat modeling here hardens the production environment and verifies configuration just before the application actually goes live to real users

   Deployment-phase security work is hardening, configuration review, and go-live verification — not initial threat modeling. By deployment the architecture and code are fixed, so modeling then only surfaces issues needing emergency patches or rollback.
2. Testing phase; threat modeling against the fully built application uncovers the real, exploitable vulnerabilities that only become visible once the running code is exercised

   Modeling in the Testing phase means all design and implementation decisions are already locked in. Though still useful, late modeling surfaces issues that demand expensive rework — it is most effective during Design while the architecture remains flexible.
3. Design phase; threat modeling during design identifies architectural security issues before code is written, when changes are least expensive ✓

   Threat modeling in the Design phase identifies architectural vulnerabilities — missing authentication boundaries, trust zone misalignments, insecure data flows — before they are built into the system. Changes at design time cost far less than rework after implementation. The 'Rule of Ten' states that fixing a bug in design costs 10x less than fixing it in testing, and 100x less than fixing it in production.
4. Maintenance phase; threat modeling performed on a yearly cadence as part of routine security review keeps the deployed system aligned with newly emerging threats over time

   Annual reviews during Maintenance do reassess threats against a deployed system, but threat modeling's primary value is in the Design phase before implementation. Maintenance-phase modeling is supplementary, not the primary opportunity.

Threat modeling during Design phase identifies architectural security flaws before code is written — design changes are far cheaper than post-implementation rework.

2. Parameterized queries: Which mitigation most directly addresses the root cause of this vulnerability?

1. Input validation using a strict blocklist that rejects single quotes, semicolons, and SQL keywords before the username is concatenated into the executed query string

   This is a blocklist approach that can be bypassed with alternative injection techniques (double quotes, comment sequences, encoded characters). It treats symptoms, not the root cause. Parameterized queries fix the architectural flaw — mixing code and data — rather than trying to filter specific attack characters.
2. Running the entire web application under a least-privilege database account so a successful injection is confined to the narrow permissions granted to that service account

   Least privilege is a defense-in-depth measure that limits the blast radius of a successful SQL injection (e.g., prevents DROP TABLE if the account lacks DDL rights). However, it does not prevent injection from succeeding — the attacker can still read data within the account's permissions. Parameterized queries prevent injection; least privilege only limits impact.
3. Encrypting the database connection with TLS so queries and their parameters travel over a confidential, tamper-resistant network channel to the database server

   TLS encrypts data in transit between the application and database server. It has no effect on SQL injection — the malicious query is assembled at the application layer, before any database communication. Encrypting the channel does not prevent injection of malicious query syntax.
4. Parameterized queries (prepared statements); the query structure is defined separately from user data, so user input is always treated as data, never as SQL syntax ✓

   Parameterized queries separate SQL code from data values. The database compiles the query template first, then substitutes data values — user input cannot alter the query structure. Example: `query = "SELECT * FROM users WHERE username = ?"` with the username value passed as a parameter. The single quotes in the attacker's input become literal data, not SQL syntax.

Parameterized queries fix SQL injection at the root cause by separating query structure from data — user input can never alter SQL syntax when parameterized.

3. Cross-Site Request Forgery: Which vulnerability is exploited, and what is the primary mitigation?

1. Cross-Site Request Forgery (CSRF); mitigation is CSRF tokens — server-generated unique values included in forms, verified with each state-changing request ✓

   CSRF exploits the browser's automatic inclusion of cookies in cross-origin requests. The malicious site crafts a request the browser sends with the victim's legitimate session cookies. CSRF tokens mitigate this: the server embeds a secret, random value in each form; the malicious site cannot read this value (same-origin policy) and cannot include it in its forged request.
2. Clickjacking; mitigation is X-Frame-Options headers plus frame-busting scripts that stop the banking page from being rendered inside a hostile iframe

   Clickjacking tricks users into clicking invisible UI elements by framing a legitimate site over a malicious page. The scenario describes automatic POST submission using existing session cookies — that is CSRF. X-Frame-Options prevents framing attacks, not cross-origin request forgery.
3. Session hijacking; mitigation is HTTPS with Secure and HttpOnly cookies so an attacker cannot capture and replay the victim's active session token

   Session hijacking involves stealing a session token to impersonate a user. CSRF does not steal tokens — it exploits the browser automatically sending cookies with cross-origin requests. The attacker never needs the token; they only need the victim to load a page that triggers the request.
4. Cross-Site Scripting (XSS); mitigation is Content Security Policy (CSP) combined with output encoding to stop injected scripts from running in the victim's browser

   XSS injects malicious scripts into pages viewed by victims. The scenario describes a cross-origin request the browser sends with the victim's cookies, with no script injected into the banking site — that is CSRF, not XSS. CSP and output encoding mitigate XSS, not CSRF.

CSRF forges requests using the victim's active session cookies; CSRF tokens mitigate this by requiring a secret value that the malicious site cannot read due to the same-origin policy.

4. Security checks are automated and integrated throughout: Which change most accurately describes the key shift

1. The development team runs every security tool by hand during peer code review, treating each merge request as the one checkpoint where vulnerabilities are expected to be caught before any release

   Manual checks in peer review are valuable but insufficient for DevSecOps. The defining shift is AUTOMATION — security tools run automatically in the CI/CD pipeline on every commit without requiring manual developer action. Human review complements, but does not replace, automated pipeline security.
2. Security checks are automated and integrated throughout the CI/CD pipeline (SAST on commit, dependency scanning, DAST on staging) rather than performed as a separate gate before release ✓

   DevSecOps shifts security left by embedding automated security checks at each pipeline stage: SAST runs on every commit, software composition analysis (SCA) checks dependencies, container scanning runs on image builds, DAST runs against staging deployments. This provides continuous feedback rather than a late-stage gate that creates bottlenecks.
3. The security team is removed from the development process entirely, and developers become solely responsible for finding and fixing every security defect before shipping

   DevSecOps integrates security expertise INTO development teams and processes — it does not eliminate the security function. Security engineers become enablers (building automated tooling, providing guidance) rather than gatekeepers. It is shared responsibility, not exclusive developer responsibility.
4. Security testing is deferred until after deployment to production, so controls get validated against live traffic and real adversaries instead of synthetic pre-release test cases run earlier

   Testing in production is a DevOps practice (chaos engineering, feature flags), but security testing only in production is risky and incomplete. DevSecOps specifically moves security testing earlier (shift left) in the pipeline to catch issues before production deployment, not after.

DevSecOps embeds automated security checks throughout CI/CD (SAST, SCA, DAST) rather than performing security as a separate pre-release gate — shifting security left into every commit.

5. TOCTOU race condition: Which vulnerability is described, and what is the primary mitigation approach?

1. TOCTOU (Time of Check to Time of Use) race condition; mitigation includes atomic operations that combine the check and use, or using file handles/descriptors rather than file paths to prevent file substitution ✓

   TOCTOU exploits the window between checking a condition and acting on it. The attacker races to change the resource between TOC and TOU. Mitigation: atomic operations (check + use happen atomically with no intervening window), use file descriptors (open the file, check permissions on the descriptor, then read — the descriptor follows the original file, not a replacement symlink).
2. Buffer overflow; the file read operation exceeded its allocated buffer

   Buffer overflow involves writing more data than a buffer can hold. The scenario describes timing-based substitution of a file between permission check and access — this is a race condition, not a memory corruption vulnerability.
3. SQL injection; the file path is constructed from user input without sanitization

   SQL injection involves malicious SQL syntax in database queries. The scenario involves file system race conditions with symlink substitution — this is a TOCTOU race condition, not SQL injection.
4. Directory traversal; the attacker used '../' sequences to access parent directories

   Directory traversal uses path manipulation (../../../etc/passwd) to access files outside the intended directory. TOCTOU involves timing: the file path is valid at TOC but is replaced before TOU. The attack vector is temporal (timing), not path-based.

TOCTOU race condition exploits the window between checking a condition and using the result — mitigation uses atomic operations or file descriptors that cannot be redirected after opening.

6. Stored XSS; mitigations include output encoding: Which XSS type is this, and what are the correct mitigations?

1. Reflected XSS; the primary mitigation is enforcing HTTPS on every page request so that the injected review payload is delivered over an encrypted channel and therefore cannot execute in other users' browsers

   Reflected XSS is non-persistent — the script echoes back in a single response to an attacker-crafted URL. The scenario describes stored XSS that persists in the database and affects all visitors. HTTPS encrypts the connection but does not prevent execution; the malicious script is served over HTTPS and still runs.
2. DOM-based XSS; the primary mitigation is server-side input validation of the review field so the malicious payload is sanitized at submission time before any client-side script is ever able to process it

   DOM-based XSS manipulates the browser's DOM via client-side JavaScript and may not involve server-side processing. The scenario involves a server-stored payload served to many users, which is stored XSS. DOM-based mitigation centers on safe client-side DOM APIs, not server-side input validation.
3. Stored XSS; the primary mitigation is instructing every end user to disable JavaScript in their browser so that any persisted review payload is rendered completely inert whenever the product page loads

   Disabling JavaScript would prevent XSS but also break essentially all modern web application functionality, and it cannot be enforced on end users. Output encoding and CSP allow legitimate JavaScript while preventing XSS execution — practical mitigations, unlike disabling JavaScript entirely.
4. Stored (Persistent) XSS; mitigations include output encoding of user-generated content when rendered in HTML, Content Security Policy (CSP) to restrict script execution, and input validation when storing ✓

   Stored XSS: malicious script is saved to the database and served to all subsequent visitors — it 'persists.' Output encoding (HTML entity encoding) when rendering user content ensures the browser displays the script as text rather than executing it. CSP restricts which scripts are allowed to execute. Input validation reduces malicious content stored.

Stored (Persistent) XSS saves malicious scripts to the database, executing for all subsequent visitors; output encoding when rendering HTML and CSP are the primary mitigations.

7. BSIMM: Which framework is specifically designed for measurement and industry benchmarking of software security

1. BSIMM (Building Security In Maturity Model) ✓

   BSIMM is a measurement framework based on observing real software security initiatives at hundreds of organizations. It describes what organizations ARE doing (not prescriptive about what they SHOULD do), enabling benchmarking against peer organizations and industries. It measures current state against an observed industry baseline.
2. Microsoft Security Development Lifecycle (SDL)

   Microsoft SDL is a prescriptive methodology for integrating security activities into the software development process (threat modeling, security design review, security testing requirements). It is a development methodology, not a measurement and benchmarking framework.
3. NIST Cybersecurity Framework (CSF)

   NIST CSF is an enterprise-level cybersecurity framework covering Identify, Protect, Detect, Respond, and Recover functions. It addresses overall organizational cybersecurity, not specifically software development security maturity measurement and benchmarking.
4. OWASP SAMM (Software Assurance Maturity Model)

   OWASP SAMM is a prescriptive framework that defines what an organization SHOULD do to improve software security maturity. It provides a roadmap for improvement but is not specifically designed for peer benchmarking against observed industry data — it defines ideal maturity levels, not observed industry baselines.

BSIMM measures and benchmarks software security practices by observing what organizations actually do — enabling peer comparison. OWASP SAMM prescribes what to do; BSIMM measures what is done.

8. Dynamic testing: Which assessment approaches can the organization use to evaluate the application's security p

1. Requiring the vendor to hand over full application source code before any security assessment can begin, on the view that no meaningful evaluation of a COTS product is possible without static analysis of the code

   While source code access enables SAST, requiring it as a prerequisite is often commercially unacceptable for COTS vendors and would eliminate access to most enterprise commercial software. Organizations must assess security with the access they have, which may be limited to the binary or running application.
2. Dynamic testing (black-box penetration testing), vendor security questionnaires/attestations (SOC 2 Type II, penetration test reports), and dependency analysis using the vendor's Software Bill of Materials (SBOM) ✓

   Without source code access, security assessment options include: black-box dynamic testing (test the running application for vulnerabilities), vendor questionnaires and third-party attestations (SOC 2 reports, penetration test summaries), and SBOM review (identify known-vulnerable components in the software supply chain). These provide meaningful security assurance without source access.
3. Accepting the vendor's written security claims without any independent verification, on the basis that established COTS software is generally secure and has already been vetted thoroughly by the vendor's many other customers

   Vendor claims without independent verification are insufficient for due diligence when processing sensitive data. COTS and widely used components have well-documented vulnerabilities — SolarWinds, Log4j, and many other incidents show this. Independent verification is required, not blind acceptance.
4. Treating static analysis of the application's source code as the only reliable assessment method, and postponing the whole evaluation until the vendor can eventually be persuaded to release the code for review

   The scenario explicitly states the vendor refuses to provide source code, and SAST requires source access. Without source, other methods (DAST, vendor attestations, SBOM review) must substitute. SAST is valuable but is not the only reliable method, and deferring the assessment leaves the risk unmanaged.

Without source code access, assess COTS software through black-box dynamic testing, vendor security attestations (SOC 2, pen test reports), and SBOM analysis for known-vulnerable components.

9. Peer review catches logic errors: From a security perspective, what is the primary benefit and what limitation

1. Peer review primarily surfaces performance and maintainability defects, so security evaluation ought to stay a completely separate activity handled only by a dedicated security team using its own specialist tooling

   Peer review can and should include security review. Security-focused code review checklists guide reviewers to examine authentication, authorization, input handling, and cryptographic usage. Security is not a separate concern isolated from functional code quality.
2. Peer review delivers exactly the same coverage as SAST tools by having a human inspect every line for injection sinks and unsafe patterns, which makes running automated static analysis in the pipeline largely redundant work

   Peer review and SAST are complementary, not redundant. SAST automatically and consistently checks every line for known patterns (SQL injection, buffer-overflow sinks, injection paths). Humans are better at logic flaws; SAST is better at consistent, comprehensive pattern detection. Neither replaces the other.
3. Peer review catches logic errors, insecure coding patterns, and business logic flaws that automated tools miss; however, reviewers may have knowledge gaps in security and can develop review fatigue, reducing effectiveness ✓

   Human peer review excels at identifying logic flaws, business logic vulnerabilities, and contextual security issues that automated tools cannot understand. Limitations: developers may lack security expertise, review fatigue from high PR volume reduces thoroughness, developers may approve familiar-looking code without scrutinizing security implications.
4. Peer review removes the need for penetration testing, since reviewers examining each individual commit will reliably identify every exploitable vulnerability well before the code is ever promoted to production

   Peer review operates at the code level — it cannot assess runtime configuration issues, deployment misconfigurations, or vulnerability chaining across system boundaries. Penetration testing in staging or production finds a different class of issues than code review does.

Peer review catches logic flaws and business logic vulnerabilities that automated tools miss, but requires security knowledge and is susceptible to review fatigue — it complements rather than replaces automated tools.

10. Insecure deserialization: Which vulnerability is exploited, and what is the MOST effective mitigation?

1. Server-Side Request Forgery (SSRF); the most effective mitigation is to block the server from opening any outbound connection to internal network addresses and cloud metadata endpoints, since those internal calls are what an attacker abuses to reach protected back-end services

   SSRF tricks the server into making requests to internal services. While insecure deserialization can sometimes lead to SSRF as a secondary effect, the vulnerability here is insecure deserialization — the demonstrated remote code execution requires exploiting the object-reconstruction mechanism, not outbound request forgery.
2. XML External Entity (XXE) injection; the most effective mitigation is to disable DTD processing and external entity resolution in every parser that handles the incoming client data, so a crafted entity cannot read files or reach internal services

   XXE exploits XML parsers that process external entity references. The scenario describes serialized Java object deserialization, not XML parsing, so disabling DTD processing does not apply. XXE is a distinct vulnerability class, even though it also appears in the OWASP Top 10.
3. Buffer overflow; the most effective mitigation is strict input length validation on the received payload combined with a non-executable stack, so the oversized serialized data cannot overrun the memory buffer and let the attacker execute injected code

   Buffer overflow involves writing past buffer boundaries in memory. Insecure deserialization exploits the object-reconstruction process — malicious objects trigger code through gadget chains during deserialization itself, not through a memory overrun. Input length validation does not prevent deserialization exploitation.
4. Insecure deserialization; the most effective mitigation is to not accept serialized objects from untrusted sources — replace with safe data formats (JSON, XML) with schema validation, or implement strict deserialization allowlists limiting which classes can be deserialized ✓

   Insecure deserialization occurs when applications deserialize data from untrusted sources without validation. During deserialization, Java gadget chains can trigger code execution through the class loading mechanism. The most effective mitigation is architectural: avoid deserializing untrusted data. If deserialization is unavoidable, use class allowlists (only permit safe, expected classes) and run deserialization in sandboxed environments.

Insecure deserialization allows RCE through gadget chains during object reconstruction; primary mitigation is avoiding deserialization of untrusted data, using safe formats (JSON) instead.

11. Shift security left by defining security requirements: Which change to the development process would MOST effe

1. Shift security left by defining security requirements during the requirements phase, conducting threat modeling during design, and integrating SAST into the CI/CD pipeline for every code commit ✓

   Shifting security left introduces security at the earliest possible stages — when defects are cheapest to fix. IBM Secure Engineering found that defects found in requirements cost 10x less to fix than those found post-release. Threat modeling during design and SAST during coding prevent vulnerabilities from reaching the test phase.
2. Add a dedicated security code review sprint at the end of each development cycle, giving security specialists a focused window to inspect the finished code before it is promoted toward the release branch

   End-of-cycle security reviews are still relatively late — though better than just pre-release pentesting, this approach doesn't integrate security into the daily development workflow or address architectural issues that require design-phase intervention.
3. Replace the final penetration test with a considerably more thorough one that probes deeper and uncovers a larger share of the application's vulnerabilities before the release goes out

   A more thorough pentest is still a late-stage activity — it may find more vulnerabilities but they are still expensive to fix. This does not address the root cause: security requirements and design flaws are introduced early but not caught until late.
4. Hire additional security engineers to expand the final penetration testing team, increasing throughput so more of the codebase can be exercised during the pre-release testing window

   Adding pentesters at the end of the cycle increases testing capacity but does not shift security activities earlier. The cost and impact of late-stage vulnerability discovery remains unchanged — more pentesters find the same late-stage vulnerabilities.

Shift-left security — introducing requirements, threat modeling, and automated scanning early in the SDLC — is exponentially cheaper than finding vulnerabilities at release time.

12. Parameterized queries that separate SQL code from data: Which is the MOST effective primary defense against SQ

1. Restricting the database account to read-only permissions so a SQL injection attack cannot modify or delete any of the underlying stored data

   Least-privilege database accounts limit SQL injection impact but do not prevent exploitation — read-only SQL injection can still exfiltrate the entire database. This is a valuable complementary control, not a primary defense against SQL injection itself.
2. Parameterized queries (prepared statements) that separate SQL code from data, preventing user input from being interpreted as SQL commands ✓

   Parameterized queries structurally prevent SQL injection by ensuring user input is always treated as data, never as SQL code. The query structure is fixed and cannot be modified by input content — this eliminates the vulnerability at the code level.
3. Input sanitization that escapes special characters such as quotes and semicolons before values are concatenated into the query

   Input sanitization/escaping is a weaker defense — different database engines require different escaping rules, escaping can be bypassed with encoding tricks (Unicode normalization, hex encoding), and developers often implement it inconsistently. Parameterized queries are always preferred.
4. Deploying a WAF with SQL injection detection signatures in front of the application to inspect and block incoming requests that match known attack patterns

   WAF rules can block known SQL injection patterns but can be bypassed with obfuscation, encoding, and novel payloads. WAF is a defense-in-depth layer, not a substitute for secure code — parameterized queries eliminate the vulnerability; WAF only reduces exploitation probability.

Parameterized queries eliminate SQL injection by structurally separating SQL code from data — the query structure cannot be modified by user input, eliminating the vulnerability at its root.

Other CISSP domains

• Security and Risk Management — 89 questions →
• Security Architecture and Engineering — 87 questions →
• Communication and Network Security — 63 questions →
• Identity and Access Management (IAM) — 63 questions →
• Security Operations — 48 questions →
• All 497 CISSP questions →