Security in the software development life cycle

Almost every organization now writes software, even if it does not think of itself as a software company. A bank builds mobile apps, a hospital configures and extends an electronic health record, a retailer runs an online store, and a manufacturer programs the controllers on its production line. Much of that code is assembled from open source components, generated by tools, or bought from vendors and then customized. Each of those routes creates security risk, and each is governed by decisions that managers make long before an attacker ever finds a flaw. Domain 8 of the CISSP outline, Software Development Security, is about making those decisions well.

Domain 8 carries about 10 % of the exam weight under the outline ISC2 introduced on 15 April 2024. ISC2's exam refresh page still listed that outline as current when we checked in October 2026, so confirm the outline on isc2.org before you book. This course is independent study material: it is not produced, endorsed or reviewed by ISC2, and every question in it is original. As in the other CISSP courses, the point of view is that of a security manager or senior practitioner. You are not expected to be a programmer, but you are expected to understand how software is built, where security belongs in that process, what good secure development looks like, how to judge the security of software you buy, and how to measure whether a development program is working.

The domain has five objectives in the official outline: understand and integrate security in the software development life cycle; identify and apply security controls in software development ecosystems; assess the effectiveness of software security; assess the security impact of acquired software; and define and apply secure coding guidelines and standards. This course follows those objectives across twelve lessons. Several neighbouring topics are taught elsewhere and only referenced here: threat modelling as a general risk technique (CISSP-110 Lesson 12 and CISSP-112 Lesson 1), cryptography (CISSP-112), identity and authentication (CISSP-114), security testing programs and vulnerability scoring with CVSS, EPSS and KEV (CISSP-115), and incident response and change management in operations (CISSP-116). For hands-on software engineering, CMPUT-301 covers process models and DevOps, CMPUT-331 covers secure software from a computing science view, and CMPUT-404 covers web application security in code.

Throughout the course we follow Ridgeline Payments, an invented company of about 400 people headquartered in Calgary. Ridgeline builds a payments platform used by small businesses: a web dashboard, mobile apps, a public API for partners and a set of back-office services that move money through Canadian and US banking networks. It has about 90 developers in twelve product teams, a platform team that runs its cloud environment and continuous delivery pipeline, and a security team of eight, two of whom specialize in application security. Ridgeline is growing quickly, has just signed its first large bank partner, and has been asked by that partner to show evidence of a mature secure development program.

What the software development life cycle is

A software development life cycle (SDLC) is the set of phases through which software moves from an idea to retirement. Different organizations name and order the phases differently, and agile and DevOps teams repeat them in short cycles rather than once, but the underlying activities are always present. Someone decides what the software must do, someone designs it, someone writes and builds it, someone tests it, someone releases and operates it, and eventually someone retires it. Security has a job to do in every one of those activities, and the central idea of Domain 8 is that security is most effective and least expensive when it is built into each phase rather than inspected at the end.

The final column matters to a manager. An auditor, a customer or a regulator rarely asks whether developers care about security; they ask what evidence shows that security activities actually happened. A program that performs threat modelling but keeps no record of it cannot demonstrate due care. Ridgeline's bank partner, for example, has asked for exactly this kind of evidence: proof that security requirements are defined, that designs are reviewed, that code is scanned and reviewed, and that releases pass a defined gate.

Why early is cheaper: shifting left

Fixing a defect costs more the later it is found. A missing security requirement noticed during a design workshop costs a conversation; the same gap found after release may cost an emergency patch, an incident investigation, customer notifications and lost trust. The industry calls the practice of moving security activities earlier in the life cycle shifting left, because the early phases sit on the left of the usual diagram. You will often see precise multipliers quoted, such as a defect costing 30 or 100 times more to fix in production than in design. Those figures come from old and much-debated studies and should not be treated as laws of nature, but the direction of the effect is well established and is the reason every modern secure development framework emphasizes early activities.

Shifting left does not mean abandoning later controls. Some problems can only be found in a running system, such as a misconfigured server or an access control flaw that appears only when components interact. Mature programs therefore shift left and also shield right: they keep testing, monitoring and responding to vulnerabilities in production. The aim is defence in depth across the life cycle, with each phase catching what earlier phases missed.

Security requirements

Software can only be as secure as its requirements demand. Functional requirements describe what the system does; security requirements describe the protections it must provide and the behaviour it must refuse. Good security requirements are specific and testable. 'The application must be secure' is not a requirement. 'Every API request that reads or changes a merchant's data must be authorized against the merchant identifier in the caller's token, and requests for another merchant's data must be refused and logged' is a requirement a developer can build and a tester can verify.

Security requirements come from several sources. Regulations and contracts impose some, such as payment card industry rules for card data, privacy law for personal information, and the bank partner's own security schedule for Ridgeline. Organizational policies and standards impose others, such as approved cryptography or logging rules. Data classification drives many: data classed as restricted needs encryption, stricter access control and shorter retention. Threat modelling, covered in Lesson 2, identifies further requirements specific to the design. Industry catalogues help teams avoid starting from a blank page; the OWASP Application Security Verification Standard (ASVS), whose version 5.0 was released in 2025, is a widely used list of verifiable application security requirements organized into levels of rigour.

Privacy requirements deserve separate attention. Canadian privacy law, including PIPEDA and Quebec's Law 25, expects organizations to limit collection to what is necessary, protect personal information with safeguards appropriate to its sensitivity, and, under Law 25, assess privacy impacts for new systems that handle personal information and apply the most privacy-protective settings by default. In practice, that means asking at the requirements stage which personal information the feature truly needs, how long it will be kept and who can see it. CISSP-110 and CISSP-111 cover the law in detail.

Abuse cases and misuse cases

Use cases and user stories describe how legitimate users achieve their goals. Abuse cases, sometimes called misuse cases, describe how someone might use the same features to cause harm. They are written from the point of view of a hostile actor, a careless insider or a confused customer. For each important feature, the team asks: who might want to misuse this, what would they try, and what must the system do to stop or detect it? The answers become security requirements and test cases.

Abuse cases work best when they are short and concrete and written collaboratively by developers, product owners and security staff. They should not become a catalogue of every conceivable attack. The test of a good abuse case is whether it changes what the team builds or tests.

Security gates and the definition of done

A security gate is a checkpoint at which defined security criteria must be met before work moves to the next phase. Traditional waterfall projects used formal phase gates: a design could not proceed to implementation until the security architecture review was signed off. Agile and DevOps teams move too quickly for heavyweight sign-offs on every change, so they build security criteria into the definition of done for each story and into automated checks in the delivery pipeline. A release might be blocked automatically if static analysis reports a new critical finding, if a dependency has a known exploited vulnerability, or if a required peer review is missing.

Gates must be designed carefully. A gate that blocks too much will be bypassed or quietly disabled by frustrated teams. A gate that blocks nothing gives false comfort. The usual approach is to block only on a small set of high-confidence, high-severity conditions, record everything else as findings with remediation deadlines, and provide a documented exception process through which an accountable business owner can accept a time-limited risk.

# Evaluate a release against Ridgeline's security gate policy (illustrative)
policy = {
    'max_new_critical': 0,       # new critical findings allowed
    'max_new_high': 2,           # new high findings allowed with tickets
    'kev_dependencies': 0,       # components with known exploited vulnerabilities
    'require_peer_review': True,
    'require_threat_model_for_new_service': True,
}
release = {
    'name': 'refunds-service 2.4.0',
    'new_critical': 0, 'new_high': 3, 'kev_dependencies': 0,
    'peer_reviewed': True, 'new_service': False, 'threat_model': False,
    'exceptions': {'new_high': 'RISK-118 accepted by product owner until 2026-11-30'},
}
reasons = []
if release['new_critical'] > policy['max_new_critical']:
    reasons.append('new critical findings')
if release['new_high'] > policy['max_new_high'] and 'new_high' not in release['exceptions']:
    reasons.append('too many new high findings')
if release['kev_dependencies'] > policy['kev_dependencies']:
    reasons.append('dependency with known exploited vulnerability')
if policy['require_peer_review'] and not release['peer_reviewed']:
    reasons.append('missing peer review')
if release['new_service'] and policy['require_threat_model_for_new_service'] and not release['threat_model']:
    reasons.append('new service without threat model')
print('Release:', release['name'])
for k, v in release['exceptions'].items():
    print('  exception on', k, '->', v)
print('Decision:', 'BLOCK (' + '; '.join(reasons) + ')' if reasons else 'PASS')

Release: refunds-service 2.4.0
  exception on new_high -> RISK-118 accepted by product owner until 2026-11-30
Decision: PASS

Look at what makes this gate defensible: the criteria are written down, the decision is reproducible, and the exception names an accountable owner and an expiry date. Those are the same governance properties that CISSP expects of any control, applied to software delivery.

Roles and responsibilities

Secure development is a shared responsibility, and confusion about who owns what is a common cause of failure. Senior management sets policy, funds the program and accepts residual risk. Product owners decide what is built and own the business risk of their products, including the decision to accept or fix security findings. Developers write secure code and fix the defects they introduce. Architects choose patterns and components. The security team defines standards, provides tools and training, performs expert reviews and testing, and reports on risk; it supports teams but should not become the only line of defence. Operations or platform teams run the pipeline and production environment.

Many organizations add security champions: developers in each product team who receive extra training, act as the first point of contact for security questions, help with threat modelling and reviews, and represent their team in a community of practice. Champions scale a small security team across many developers. Ridgeline, with eight security staff for 90 developers, relies heavily on this model: each of its twelve teams has one champion who spends about a tenth of their time on security work.

Retirement and the end of the life cycle

The last phase is often forgotten. Software that is no longer maintained still runs, still holds data and still exposes interfaces. Unmaintained applications are a frequent source of breaches because nobody patches them and nobody watches them. Retirement should be a planned activity with its own checklist: migrate or securely dispose of the data in line with retention rules, revoke service accounts, keys and certificates, remove DNS records and firewall rules, update the asset inventory, and archive the documentation needed for legal holds. The same thinking applies to components: a library that its maintainers have stopped supporting is effectively retired, and the software that depends on it inherits the risk. Lesson 10 returns to this in the context of the software supply chain.