Capstone: a secure development program for an organization, with Domain 8 exam strategy

This final lesson brings the course together. We design a secure development program for Ridgeline Payments, decide how to measure whether it works, and plan its first eighteen months. Then we turn to the exam: how Domain 8 questions are framed, the traps they set, and how a manager's perspective helps choose the best answer. As throughout the course, this is independent study material, not produced or endorsed by ISC2, and every question is original.

Where Ridgeline stands

Earlier lessons revealed Ridgeline's strengths and gaps. It has a modern delivery pipeline with automated builds, branch protection and peer review (Lessons 3 and 4). Its build and deployment practices scored highest in the SAMM self-assessment, while threat assessment and architecture assessment scored lowest (Lesson 3). Its SAST rollout generated too much noise (Lesson 9). A staging environment held real customer data (Lesson 4), a penetration test found an insecure direct object reference exposing other merchants' refunds (Lesson 7), bank account numbers were readable by many services (Lesson 8), and developers had begun using consumer AI tools with company code (Lesson 11). The bank partner wants evidence of a mature program within eighteen months, and the company may expand into the EU market, where the Cyber Resilience Act would apply.

Program structure

A secure development program needs the same governance elements as any security program: a policy approved by senior management, standards that make the policy concrete, defined roles, resources, a plan, metrics and regular reporting. For Ridgeline the program charter assigns accountability as follows. The chief technology officer owns the program jointly with the chief information security officer; product owners own the security risk of their products; the application security team sets standards, provides tooling and training, performs expert reviews and reports metrics; security champions lead day-to-day practice in each team; and the platform team owns the security of the pipeline and environments.

Measuring effectiveness

The CISSP objective on assessing the effectiveness of software security includes auditing and logging of changes and risk analysis and mitigation, and in practice it depends on good metrics. Metrics should answer management's questions: Are we finding problems early? Are we fixing them fast enough? Is the risk going down? Are the controls actually operating? A small, stable set of metrics, reported consistently over time, is more useful than a large dashboard nobody reads. Metrics fall into three groups.

from datetime import date
from statistics import mean, median
# Remediation performance and escape rate for one quarter (synthetic findings)
DEADLINE = {'critical': 7, 'high': 30, 'medium': 90}
findings = [  # severity, found where, opened, closed (None = still open at 2026-09-30)
    ('critical', 'production',  date(2026, 7, 3),  date(2026, 7, 6)),
    ('critical', 'pre-release', date(2026, 8, 14), date(2026, 8, 25)),
    ('high',     'pre-release', date(2026, 7, 1),  date(2026, 7, 20)),
    ('high',     'production',  date(2026, 7, 9),  date(2026, 8, 28)),
    ('high',     'pre-release', date(2026, 8, 2),  date(2026, 8, 19)),
    ('high',     'pre-release', date(2026, 9, 1),  None),
    ('medium',   'pre-release', date(2026, 7, 15), date(2026, 9, 2)),
    ('medium',   'production',  date(2026, 6, 20), None),
    ('medium',   'pre-release', date(2026, 8, 5),  date(2026, 8, 30)),
    ('medium',   'pre-release', date(2026, 9, 10), date(2026, 9, 22)),
]
end = date(2026, 9, 30)
for sev in DEADLINE:
    rows = [f for f in findings if f[0] == sev]
    closed = [(c - o).days for s, w, o, c in rows if c]
    on_time = sum(1 for s, w, o, c in rows if ((c or end) - o).days <= DEADLINE[sev] and c)
    overdue_open = sum(1 for s, w, o, c in rows if not c and (end - o).days > DEADLINE[sev])
    print(f'{sev:8s} n={len(rows)}  mean {mean(closed):5.1f} d  median {median(closed):4.1f} d  '
          f'on time {on_time}/{len(rows)}  open past deadline {overdue_open}')
prod = sum(1 for f in findings if f[1] == 'production')
print(f'Escape rate: {prod}/{len(findings)} = {prod / len(findings):.0%} of findings were first found in production')

critical n=2  mean   7.0 d  median  7.0 d  on time 1/2  open past deadline 0
high     n=4  mean  28.7 d  median 19.0 d  on time 2/4  open past deadline 0
medium   n=4  mean  28.7 d  median 25.0 d  on time 3/4  open past deadline 1
Escape rate: 3/10 = 30% of findings were first found in production

The numbers tell a story management can act on. Critical findings are fixed quickly, though one took longer than the seven-day target; one high finding found in production took 50 days, far beyond its deadline; and a medium production finding is still open after more than three months. The escape rate of 30 % shows that too many problems are first found after release, which is consistent with the weak design-phase practices identified earlier. Means and medians are both reported because a few long-running items can make the mean misleading.

Change auditing is also part of assessing effectiveness. The pipeline and repository logs described in Lesson 4 should be reviewed to confirm that controls cannot be bypassed: sample production changes each quarter and verify that each has a linked work item, an independent approval, passing checks and a deployment record; investigate any change that reached production outside the pipeline. Findings from these audits feed back into the risk register, where residual risks are analysed and either mitigated or formally accepted by their owners.

An eighteen-month roadmap

For Ridgeline in Calgary, the roadmap also maps to Canadian expectations: privacy safeguards under PIPEDA and, for Quebec merchants, Law 25; the bank partner's obligations under OSFI Guidelines B-10 and B-13, which flow down to Ridgeline as a third party; and readiness for supply chain requirements under the Critical Cyber Systems Protection Act if Ridgeline's partners are designated operators once regulations are made.

Domain 8 on the exam

Domain 8 carries about 10 % of the weight in the April 2024 outline. Its questions rarely ask you to read code. They test whether you understand where security fits in development, what each technique does and does not do, and what a responsible manager would choose. The following patterns recur.

Watch for distractors that are technically true but not the best managerial choice. An answer that adds a web application firewall may reduce risk, but fixing the code is usually better. An answer that requires the security team to review every change may sound rigorous, but it does not scale and removes ownership from developers. An answer that bans a tool or practice outright is rarely best when a governed alternative exists. When two answers seem right, prefer the one that addresses root cause, is earliest in the life cycle, assigns accountability correctly and leaves evidence. And as in every domain, human safety and legal obligations come first.

Finally, connect Domain 8 with the rest of the CISSP. Secure design principles come from Domain 3; identity and session controls from Domain 5; testing programs from Domain 6; change and vulnerability management from Domain 7; and governance, risk, supply chain and legal requirements from Domain 1. Exam scenarios often cross these boundaries, and a candidate who sees software security as part of the whole security program will choose better answers.