Domain 8 and thinking across the domains

The last domain of the CISSP common body of knowledge, Domain 8, Software Development Security, carries 10 % of the exam. It covers how security is built into software from the first requirement to retirement, how development environments are protected, how the security of software is assessed and how software acquired from others is evaluated. Many candidates who are not developers worry about this domain, but it is written for security professionals who work with developers, not for programmers. The second half of this lesson steps back from individual domains to look at the way of thinking the exam rewards across all eight, often called the manager's mindset, and at techniques for scenario questions that cut across domains.

Domain 8 at a glance

The 2024 outline asks candidates to understand and integrate security in the software development life cycle (SDLC); 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. Its central message is that security is cheapest and most effective when it is designed in from the beginning, rather than tested in or bolted on at the end.

Security in the software development life cycle

Every SDLC, whatever its methodology, moves through similar activities: gathering requirements, design, development, testing, deployment, operation and maintenance, and eventually retirement. Security activities belong in each. During requirements, define security and privacy requirements alongside functional ones. During design, perform threat modelling and design reviews. During development, follow secure coding standards and use static analysis. During testing, run dynamic testing, fuzzing and penetration tests. During deployment, harden configurations and control releases. During operation, monitor, patch and manage changes. At retirement, dispose of data securely.

Development methodologies differ in how they sequence this work. The waterfall model moves through phases in order, with formal sign-off between them; security reviews fit naturally at phase gates. Agile methods deliver small increments in short iterations; security must be built into each iteration, for example through security user stories, abuse cases and automated tests. DevOps combines development and operations with heavy automation and continuous delivery, and DevSecOps adds security to that pipeline through automated scanning, policy checks and infrastructure as code reviews. Other models, such as the spiral model, rapid application development and the integrated product team approach, appear in older study materials and are still examinable.

Maturity models help organizations measure and improve their development practices. The Capability Maturity Model Integration (CMMI) describes levels from initial (ad hoc) to optimizing. The OWASP Software Assurance Maturity Model (SAMM) and the Building Security In Maturity Model (BSIMM) focus specifically on software security practices. Change management, configuration management and code repositories with access controls protect the integrity of software as it moves from development to production.

Secure coding and common vulnerabilities

Secure coding guidelines translate principles into practical rules: validate all input, encode output, use parameterized queries, handle errors without revealing sensitive details, manage sessions securely, store secrets outside code, apply least privilege to application accounts and log security-relevant events. The OWASP Top 10, a regularly updated list of the most critical web application security risks, is a widely used reference; broken access control, cryptographic failures, injection and insecure design have all featured prominently in recent editions. Application programming interfaces (APIs) need the same care, with authentication, authorization, rate limiting and input validation on every endpoint.

Acquired software and the supply chain

Most organizations run far more software that they bought or downloaded than software they wrote. Domain 8 asks how to assess the security of commercial off-the-shelf software, open-source components, third-party custom software, managed services and cloud services. Approaches include reviewing vendors' security practices, requiring independent assessments, testing products before deployment, negotiating contractual security requirements and monitoring for vulnerabilities after purchase. A software bill of materials (SBOM), a machine-readable inventory of the components in a piece of software, helps organizations find out quickly whether they are affected when a vulnerability is announced in a widely used component.

In Canada, the Canadian Centre for Cyber Security publishes guidance on secure software development and supply chain risk, and Government of Canada departments apply supply chain integrity reviews to significant technology purchases. Canadian organizations often refer to international standards such as ISO/IEC 27034 for application security and to the NIST Secure Software Development Framework as good practice, even though it is not binding in Canada.

The manager's mindset

The CISSP is written for professionals who advise organizations, so many questions are best answered from the point of view of a security manager or trusted adviser rather than a technician. This is often summarized as 'think like a manager', although 'think like a risk adviser' might be more accurate. A few principles guide this mindset.

• Human safety comes first, always, ahead of data, systems and money.
• Security serves the business. Controls exist to support the organization's mission and objectives within its risk appetite.
• Senior management owns risk. Security professionals advise; executives decide and accept residual risk.
• Governance before technology. Policies, roles, processes and management support usually come before specific tools.
• Understand before acting. Identify assets, assess risk and gather facts before choosing controls or taking drastic action.
• Follow process. Use established incident, change and escalation processes rather than acting alone.
• Prefer root causes and lasting solutions over quick fixes, while still containing immediate harm.
• Balance cost and benefit. The best control is not the strongest one but the one that reduces risk appropriately at a justified cost.

Reading scenario questions

Many items describe a situation and ask what should be done FIRST, what is the BEST or MOST important action, or which option is LEAST appropriate. These qualifiers matter. Several options may be good actions; the question asks for priority. A reliable approach is to read the final question sentence first, identify the role you are being asked to play, note key facts and constraints in the scenario, eliminate options that are wrong or out of scope, and then compare the remaining options against the mindset principles above. If two options remain, ask which one comes earlier in the logical sequence or which one has the broader, longer-lasting effect.

How the domains connect

Although the exam outline divides the material into eight domains, real problems do not respect the boundaries. A ransomware incident involves risk management and business continuity (Domain 1), backups and data classification (Domain 2), architecture and segmentation (Domain 3), network defences (Domain 4), privileged access (Domain 5), testing of recovery plans (Domain 6), incident response and recovery (Domain 7) and software patching (Domain 8). Studying the domains as separate silos can leave you unprepared for questions that combine them. As you study each domain in later courses, keep asking how it links to the others; lesson 12 suggests ways to build this into your study plan through mixed practice.

Supporting development teams as a security professional

Security professionals who are not developers can still add a great deal of value to software projects. They can help define security requirements in plain language, run threat modelling workshops with architects and developers, choose and tune automated scanning tools so that developers are not flooded with false positives, and translate findings into business risk for product owners. They can also champion training, set up a security champions program in which a developer on each team takes on extra security responsibilities, and make sure that security exceptions are documented and approved at the right level. The goal is to make the secure path the easy path for developers, rather than acting as a gate that slows every release.

Measuring progress helps. Useful indicators include the share of applications with up-to-date threat models, the time taken to fix critical vulnerabilities, the proportion of builds that pass automated security checks and the number of security defects found in production compared with those found earlier. Trends matter more than single values: falling numbers of production defects and shorter fix times show that security is moving earlier in the life cycle, which is exactly what Domain 8 encourages.

Artificial intelligence and software security

The 2024 outline asks candidates to consider the security implications of artificial intelligence and machine learning across all domains, and Domain 8 is where many of those issues arise. Organizations now build software that uses machine learning models, integrate third-party AI services through APIs and use AI coding assistants in development. Each creates new risks: training data can be poisoned, models can be manipulated through crafted inputs such as prompt injection, sensitive data can leak through model outputs, and code suggested by an assistant may contain vulnerabilities or licensing problems. The core principles still apply. Treat AI components as part of the software supply chain, validate inputs and outputs, apply least privilege to what AI systems can access and do, test for misuse and review generated code as carefully as any other code.