TechclickCISSP Prep
☰

CISSP Domain 8 · 10% of the exam

Software Development Security

Building security into software from requirements to retirement: SDLC models, secure coding, application and API attacks, databases, third-party code and AI-assisted development.

Practise Domain 8Domain 8 cheat sheet

Key concepts

Rule cards

SDLCRequirements → Design → Code → Test → Deploy → Maintain → Dispose. A secure product = security in EVERY phase. Cheapest fix = requirements/design. Threat modelling in design.
Certification & accreditationCertification = technical evaluation of controls → Accreditation = management formally accepts the risk (authority to operate). Testing done → accreditation next.
MaturityCMMI: 1 Initial (chaotic) → 2 Managed → 3 Defined → 4 Quantitatively managed → 5 Optimizing · OWASP SAMM = prescriptive · BSIMM = descriptive.
OWASP fixesSQLi → parameterised queries · XSS → output encoding + CSP · CSRF → anti-CSRF tokens + SameSite · IDOR/broken access → server-side authorisation · insecure deserialisation → sign/validate objects · session hijack → new session ID, Secure/HttpOnly cookies.
DatabasesACID = Atomicity (all or nothing), Consistency, Isolation, Durability · aggregation / inference = the problem → polyinstantiation, views, cell suppression = fixes.
Supply chainCode signing = publisher authenticity + integrity · software escrow = source code if the vendor fails · SBOM + SCA = know your components · acquired software → independent assurance + contract terms.
AI-assisted codingTreat AI output as untrusted: code review, SAST/SCA, approved package registry (hallucinated package names = slopsquatting), no secrets in prompts.
EnvironmentsSeparate dev / test / production · developers do not deploy their own code to production · version control + peer review · change control for releases.

Development models — hard words made simple

TermSimple meaningExample / analogyExam hook
WaterfallPhases one after another; no going backBuilding a house floor by floorRigid, sequential
V-modelEach development phase has a matching test phaseRequirements ↔ acceptance test“matching test phase”
SpiralRepeating loops with risk analysis every loopPrototype → risk check → improve“risk analysis each iteration”
AgileBuild in small pieces, adapt to feedbackA feature every 2 weeksFlexible, customer feedback
Scrum / sprintAgile framework; a sprint is a 1–4 week time-box“This sprint we build login”Short iteration
Backlog / user storyPrioritised to-do list / feature from the user’s view“As a user I want to reset my password”—
RAD / prototypingQuick working models for fast feedbackMock-up appSpeed over documentation
DevOps / DevSecOpsDev + Ops with automation; DevSecOps adds security to the pipelineSecurity scan on every buildSecurity automated in CI/CD
CI/CDContinuous integration / delivery: automatic build-test-deployPush → auto-tested → deployedThe pipeline
PolyinstantiationTwo versions of a record at different classification levelsLow users see a cover storyStops inference
Aggregation / inferenceCombining harmless data reveals secrets / deducing secrets from cluesTroop food orders reveal troop countProblem; fix = polyinstantiation
TOCTOUTime-of-check vs time-of-use race conditionFile swapped between check and useRace condition
DeadlockTwo processes waiting on each other foreverTwo cars blocking a narrow laneConcurrency, not DoS

Read the full Domain 8 cheat sheet →

10 free Domain 8 practice questions

Try each question before opening the answer. The full bank has many more Domain 8 questions with filters and progress tracking.

Question 1 · FIRST

A development team discovers that an API key was accidentally committed to a public Git repository. What should they do FIRST?

  1. Investigate which developer made the mistake
  2. Add a pre-commit secret scanning hook for all developers
  3. Delete the commit from the repository history
  4. Revoke and rotate the exposed API key
Show answer & explanation

Answer: D — Revoke and rotate the exposed API key

Once public, the secret must be assumed compromised; revoking it stops misuse immediately. Cleaning history, adding scanners and reviewing the cause are important follow-ups but do not stop an attacker who already copied the key.

Question 2 · NEXT

Security testing of a new HR system is complete and the residual risks have been documented by the certifier. What should happen NEXT before go-live?

  1. Management formally accepts the residual risk and authorises operation
  2. The system is deployed because testing has finished
  3. Developers start the next release to fix low-priority findings
  4. The certifier repeats all tests to confirm the results
Show answer & explanation

Answer: A — Management formally accepts the residual risk and authorises operation

Certification (technical evaluation) is followed by accreditation: an authorising official accepts the residual risk and grants authority to operate. Deploying without that decision skips governance.

Question 3 · LEAST

At which point in the SDLC is fixing a security design flaw LEAST expensive?

  1. After deployment to production
  2. During system testing
  3. During user acceptance testing
  4. During requirements and design
Show answer & explanation

Answer: D — During requirements and design

The cost of fixing defects rises sharply in later phases. Addressing flaws in requirements and design avoids rework of code, tests and deployed systems.

Question 4 · NOT

Which of the following is NOT an effective defence against SQL injection?

  1. Validating input against an allow-list of expected values
  2. Hiding database error messages from users as the only control
  3. Applying least privilege to the application's database account
  4. Using parameterised queries or prepared statements
Show answer & explanation

Answer: B — Hiding database error messages from users as the only control

Parameterised queries are the primary fix; least privilege and allow-list validation reduce impact and attack surface. Suppressing error messages only makes exploitation harder to see (blind SQLi still works).

Question 5 · BEST

A security team must test a third-party web application for vulnerabilities while it runs in a staging environment. The vendor will not provide source code. Which method BEST fits?

  1. Software composition analysis
  2. Static application security testing
  3. Runtime application self-protection
  4. Dynamic application security testing
Show answer & explanation

Answer: D — Dynamic application security testing

TEST + running + no source code = DAST (black box). SAST needs code; RASP PROTECTS, it doesn't test; SCA needs the dependency list or code.

Question 6 · PRIMARY

A bank's security team wants every application to publish a Software Bill of Materials (SBOM). What is the PRIMARY security benefit of doing so?

  1. It prevents developers from adding open-source libraries without manager approval
  2. It replaces the need for static and dynamic security testing during development
  3. It proves to regulators that the application has no exploitable vulnerabilities in production
  4. It lets the bank quickly identify which applications contain a newly disclosed vulnerable component
Show answer & explanation

Answer: D — It lets the bank quickly identify which applications contain a newly disclosed vulnerable component

An SBOM is an inventory of components. Its main value is rapid impact analysis when a component vulnerability is disclosed. It does not prove absence of vulnerabilities, does not replace testing, and does not by itself enforce approval workflows.

Question 7 · MOST

A software developer needs to prevent SQL Injection vulnerabilities in a Java application processing database queries. Which coding practice is MOST effective?

  1. Filter SQL query strings by replacing single quote characters with double quotes
  2. Use Parameterized Queries (Prepared Statements) with strict input validation
  3. Concatenate user input strings directly into dynamic SQL query strings
  4. Encrypt the database connection password stored in application source code
Show answer & explanation

Answer: B — Use Parameterized Queries (Prepared Statements) with strict input validation

Option B is correct because Parameterized Queries separate SQL code from user data, ensuring the database driver treats input strictly as literal parameters rather than executable SQL code. Option C is incorrect because string concatenation is the primary cause of SQL injection. Option A is wrong because character replacement filtering is easily bypassed by attackers using alternative encoding techniques. Option D is incorrect because password encryption does not prevent SQL syntax injection.

Question 8

A DevSecOps team is integrating security into the early design phase of a new web application. Which process identifies potential threats, attack vectors, and mitigations before code is written?

  1. Threat Modeling (e.g., using STRIDE framework)
  2. Compiling application binaries with debug flags enabled
  3. Penetration testing against live production servers
  4. Post-incident root cause analysis
Show answer & explanation

Answer: A — Threat Modeling (e.g., using STRIDE framework)

Option A is correct because Threat Modeling analyzes system architecture during design to identify threats (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) early in the SDLC. Option C is incorrect because penetration testing occurs late in the lifecycle after deployment. Option D is wrong because root cause analysis occurs after a security incident. Option B is incorrect because debug flags increase vulnerability exposure in binaries.

Question 9 · FIRST

A retail company is starting a new mobile payments app. The product owner wants developers to begin coding next week to meet a launch date. As the security architect, what should you ensure happens FIRST?

  1. Security and privacy requirements are defined and approved alongside functional requirements
  2. A static analysis tool is integrated into the build pipeline before any code is merged
  3. Developers complete secure coding training on the OWASP Top 10 before writing code
  4. An external penetration test is booked for two weeks before the planned launch
Show answer & explanation

Answer: A — Security and privacy requirements are defined and approved alongside functional requirements

Security starts in the requirements phase: without defined security requirements there is nothing to design, test or verify against. SAST, training and pentests are all valuable but come later and depend on knowing what 'secure' means for this app.

Question 10 · NEXT

During a sprint review, a tester confirms that a newly reported SQL injection flaw has been fixed in the login module. What should the team do NEXT before releasing?

  1. Close the ticket and release the build because the specific flaw is verified as fixed
  2. Run regression tests to confirm the fix did not break existing functionality
  3. Update the secure coding standard to prohibit dynamic SQL in all future projects
  4. Schedule a full external penetration test of the entire application before release
Show answer & explanation

Answer: B — Run regression tests to confirm the fix did not break existing functionality

After a change is verified, regression testing confirms nothing else broke. Releasing immediately skips that check, a full pentest is disproportionate for one fix, and updating standards is a lessons-learned activity rather than the next release step.

Ready for the full bank?

2,000+ explained questions, timed mocks and a CAT simulator that behaves like the real exam.

Practise freeSee plans