Development methodologies, DevSecOps and maturity models

How an organization builds software shapes where and how security can be applied. A defense contractor building flight software under a fixed contract works very differently from Ridgeline's teams, which release small changes to production many times a day. Security practices that suit one will fail in the other. The CISSP outline expects you to recognize the main development methodologies, understand how security fits each, and know the maturity models and frameworks that organizations use to assess and improve their secure development practices.

CMPUT-301 Lesson 2 covers software process models from an engineering point of view, and Lesson 11 of that course covers continuous integration, delivery and DevOps in practice. This lesson takes the security manager's view: what each model implies for controls, evidence and governance.

Waterfall and its variants

The waterfall model moves through phases in sequence: requirements, design, implementation, verification and maintenance, with each phase completed and approved before the next begins. Its strengths for security are predictability and documentation. Requirements are fixed early, design reviews and formal sign-offs are natural, and auditors find abundant evidence. Its weaknesses are rigidity and late feedback. Security problems discovered in testing may require rework of designs approved months earlier, and changing threats are hard to absorb once requirements are frozen.

The V-model pairs each development phase with a corresponding testing phase: requirements with acceptance testing, system design with system testing, detailed design with integration testing and coding with unit testing. It makes explicit that every requirement, including every security requirement, needs a matching verification activity. The spiral model, introduced by Barry Boehm, repeats cycles of planning, risk analysis, engineering and evaluation, and puts risk analysis at the center of each loop. That makes it a natural home for security risk assessment, and it is often cited as the forerunner of iterative development. Other historic approaches that may appear on the exam include rapid application development (RAD), which emphasizes fast prototyping with user feedback, and the cleanroom method, which aims to prevent defects through formal specification and statistical testing rather than removing them through debugging.

Agile methods

Agile methods, crystallized in the Agile Manifesto of 2001, deliver working software in short iterations, welcome changing requirements and value collaboration over comprehensive documentation. Scrum organizes work in sprints, usually two weeks long, with a product owner who prioritizes a backlog, a development team and a Scrum Master who removes impediments. Kanban visualizes work on a board and limits work in progress rather than using fixed iterations. Extreme Programming (XP) contributed practices such as pair programming, test-driven development and continuous integration.

Agile creates both opportunities and risks for security. The opportunities are frequent feedback, small changes that are easier to review, and the ability to respond quickly to new threats. The risks are that security work is squeezed out of sprints in favor of visible features, that documentation needed for compliance is neglected, and that no one owns architecture-level security across many small teams. Security fits agile when it is expressed in agile terms: security requirements as backlog items or acceptance criteria, security criteria in the definition of done, lightweight threat modeling in sprint planning, security champions in each team and automated checks that run on every change.

DevOps and DevSecOps

DevOps joins development and operations into a single flow, supported by automation, shared responsibility and fast feedback. Code moves through continuous integration (every change is merged frequently and built and tested automatically) and continuous delivery or deployment (every change that passes the pipeline is ready to release, or is released automatically). Infrastructure is defined as code, environments are created on demand, and teams own their services in production. High-performing DevOps organizations release many times a day with low change failure rates, as the research popularized by the DORA program has shown.

DevSecOps adds security as an equal, automated participant in that flow. Instead of a separate security phase, security checks run inside the pipeline: secrets scanning and static analysis when code is committed, software composition analysis when dependencies change, infrastructure-as-code scanning before environments are created, dynamic tests against staging environments, container image scanning before deployment, and runtime monitoring afterwards. The security team's role shifts from performing reviews to building and tuning these automated guardrails, coaching teams and handling the exceptions that automation cannot decide.

Automation brings speed and consistency, but it does not remove the need for judgment. Tools generate false positives that waste developer time and false negatives that create false confidence. Business logic flaws, authorization errors and design weaknesses are poorly detected by automated scanners. A DevSecOps program therefore combines automated checks for the common, well-defined problems with human threat modeling and review for the subtle ones, and it measures both.

Change management in development

Change management, introduced in CISSP-116 for operations and in ITIL-140 for service management, applies equally to software. Every change to production code should be traceable from a request or story, through review and testing, to an approved release, and it should be possible to roll back. In DevOps environments, much of this control is automated: branch protection rules require peer review before merging, the pipeline records who changed what and which tests passed, and deployment tools keep previous versions available for rollback. Auditors increasingly accept such automated evidence in place of manual change tickets, provided the controls cannot be bypassed and exceptions are recorded. Separation of duties is preserved by ensuring that no single person can write, approve and deploy a change alone.

Operations and maintenance are part of the development life cycle. Once software is live, the team must handle vulnerability reports, apply patches to its own code and dependencies, respond to incidents and keep configuration under control. Software that is released but not maintained decays: new vulnerabilities are discovered in its components, cryptographic choices become obsolete and the people who understood it move on.

Integrated product teams and the IPT idea

The CISSP outline also mentions integrated product teams (IPT), a term from systems engineering for cross-functional teams that bring together all disciplines needed to deliver a product, including engineering, testing, operations, security, procurement and the customer. The idea anticipates DevOps: security is a member of the team from the start rather than a reviewer at the end. In exam scenarios, a recommendation to involve security staff in project teams from inception is almost always better than one that adds a review at the end.

Maturity models and frameworks

Maturity models describe a progression from ad hoc to optimized practice and let organizations assess where they stand and plan improvement. The Capability Maturity Model Integration (CMMI), originally from Carnegie Mellon's Software Engineering Institute and now maintained by the ISACA-owned CMMI Institute, uses five levels: initial, managed, defined, quantitatively managed and optimizing. On the exam, remember the order and the idea that higher levels mean processes that are documented, measured and continuously improved.

OWASP SAMM is prescriptive: it says what an organization should do at each level for each practice, which makes it convenient for building a roadmap. BSIMM is descriptive: it reports what many real organizations actually do, which makes it convenient for benchmarking. The NIST Secure Software Development Framework (SSDF) is outcome-based and deliberately technology-neutral. Version 1.1, published in February 2022 as SP 800-218, organizes practices into four groups: prepare the organization (PO), protect the software (PS), produce well-secured software (PW) and respond to vulnerabilities (RV). NIST released a draft of version 1.2 (SP 800-218 Rev. 1) for public comment in December 2025, adding practices such as PO.6; check NIST's site for its final status, which we could not confirm in October 2026. NIST also finalized SP 800-218A in 2024, a community profile that adds practices for developing generative AI and dual-use foundation models.

# OWASP SAMM-style self-assessment: current vs target scores (0-3) by business function
current = {
    'Governance':     {'Strategy and metrics': 1.0, 'Policy and compliance': 1.5, 'Education and guidance': 1.0},
    'Design':         {'Threat assessment': 0.5, 'Security requirements': 1.0, 'Security architecture': 1.5},
    'Implementation': {'Secure build': 2.0, 'Secure deployment': 2.0, 'Defect management': 1.0},
    'Verification':   {'Architecture assessment': 0.5, 'Requirements-driven testing': 1.0, 'Security testing': 1.5},
    'Operations':     {'Incident management': 1.5, 'Environment management': 2.0, 'Operational management': 1.5},
}
target = 2.0   # bank partner expectation for every practice within 18 months
print(f"{'Function':15s} {'avg':>4s}  largest gap")
gaps = []
for func, practices in current.items():
    avg = sum(practices.values()) / len(practices)
    worst = min(practices, key=practices.get)
    print(f'{func:15s} {avg:4.2f}  {worst} ({practices[worst]:.1f})')
    gaps += [(target - s, func, p) for p, s in practices.items() if s < target]
print(f'Practices below target: {len(gaps)} of 15')
print('Three largest gaps:')
for g, func, p in sorted(gaps, reverse=True)[:3]:
    print(f'  {p} ({func}): {g:.1f} levels')

Function         avg  largest gap
Governance      1.17  Strategy and metrics (1.0)
Design          1.00  Threat assessment (0.5)
Implementation  1.67  Defect management (1.0)
Verification    1.00  Architecture assessment (0.5)
Operations      1.67  Incident management (1.5)
Practices below target: 12 of 15
Three largest gaps:
  Architecture assessment (Verification): 1.5 levels
  Threat assessment (Design): 1.5 levels
  Requirements-driven testing (Verification): 1.0 levels

The assessment shows a familiar pattern for a fast-growing company: strong automation in build and deployment, weak design-phase practices. Ridgeline builds and ships well but rarely models threats or reviews architecture. The roadmap that follows should therefore prioritize threat assessment and architecture assessment, which also address the bank partner's specific request for design evidence.

Maturity scores are means, not ends. An organization can reach high scores by producing documents while its software remains vulnerable. Assessments should be backed by evidence and paired with outcome measures such as the number of serious vulnerabilities found in production and how quickly they are fixed.