CISSP - Software Development Security (10% of the exam) - Section 8.1

Understand and integrate security in the Software Development Life Cycle (SDLC), including development methodologies, maturity models, operation and maintenance, and change management.

Integrate security across the SDLC by embedding security gates into Agile, DevSecOps, and other development methodologies and by applying maturity models to measure and improve the security programme over time. Recognise where in the lifecycle security requirements, design reviews, code analysis, and operational change management each deliver maximum risk reduction.

SDLCAgileDevSecOpsmaturity modelschange management

Practice question for this objective

Free sampleSoftware Development Securityhard

A CISO is comparing BSIMM with the OWASP Software Assurance Maturity Model (SAMM) before recommending one to the board as the basis for a software security improvement programme. Which statement BEST describes the difference in how the two models are constructed?

ABSIMM measures application runtime behaviour during penetration tests, while SAMM measures static code quality through automated tooling.
BBSIMM is a descriptive model derived from observed activities across participating firms, whereas SAMM is a prescriptive framework that defines target practices and maturity levels. Correct
CBoth models are prescriptive, but BSIMM is aligned to ISO 27034 while SAMM is aligned to NIST SP 800-53.
DSAMM is a closed proprietary benchmark sold to member firms, whereas BSIMM is released openly under a Creative Commons licence.

Distinguish descriptive software security maturity models from prescriptive ones when recommending a programme baseline. Whether a maturity model is descriptive or prescriptive changes how the organisation uses it. Descriptive models like BSIMM give a benchmark against observed industry practice and answer the question what are peers actually doing. Prescriptive models like SAMM define target activities and levels, answering the question what should we be doing. Confusing the two leads to misuse of scores as targets or vice versa.

Why A is wrong: Neither model is a testing tool. Both describe organisational software security programmes rather than runtime or static analysis findings. A candidate who confuses maturity models with assessment tools picks this.

Why B is correct: BSIMM is explicitly an observational instrument: its content is a measurement of what real firms actually do, summarised into a software security framework. SAMM, by contrast, prescribes business functions, security practices, and maturity levels an organisation should aim for. This is the textbook distinction.

Why C is wrong: BSIMM is descriptive, not prescriptive, and neither model is formally aligned to those standards in the way described. The framework attributions in this option are invented and a candidate should reject them.

Why D is wrong: This reverses the openness story: SAMM is the openly published OWASP model, and BSIMM publishes its report openly while drawing data from participating firms. Candidates relying on vague impressions of vendor backing pick this.

See more CISSP practice questions, answers explained.

Exam traps in Software Development Security

Answers that look right on this material and are not. Each one is a distractor from a different question in the CISSP bank for this domain.

Require that all emergency patches go through a normal change advisory board with no fast-track path.
Why it is wrong: Forcing every emergency patch through a normal CAB cycle creates pressure to bypass the process and does not address the underlying gap, which is the absence of an auditable link between approvals and deployed code.
Mandate that every squad immediately upgrade the vulnerable logging component to a patched version and report completion within the week.
Why it is wrong: Patching the known issue is necessary but tactical; it remediates the current finding without preventing the next vulnerable library from entering the codebase, so it does not address the systemic gap the audit exposed.
Branch protection rules that require peer code review and signed commits before a merge to the release branch is permitted.
Why it is wrong: Peer review and signed commits are strong controls over what enters the codebase, but they sit before the deployment step. A reviewed commit can still bypass production controls if the deployment pipeline itself is not gated, so this is necessary but not the most direct answer to the auditor's question.

Examworthy is not affiliated with or endorsed by ISC2. Original, blueprint-aligned practice material only.