(ISC)² CBK Objectives
The 5 official learning areas of Domain 8. Click an objective for detail.
8.1 Integrate security into the SDLC
Security must be built in as an emerging property at every SDLC phase (shift-left), never added later. This means choosing a fitting methodology, applying threat modeling, and managing change management and configuration control.
Key points
- The best security is designed into the system, not added later; what matters is not that a formal SDLC exists but that the whole process involves security.
- Compare methodologies: waterfall (clear phases), V-shaped (verification/validation), iterative, spiral (PDCA), Agile, RAD, MPM, DevOps and DevSecOps.
- DevSecOps merges waterfall's phased review with DevOps to build in security and resilience at each turn of the cycle.
- Threat modeling (notably data-centric) identifies boundaries between system, subsystems and environment; its steps are identification, categorization and analysis (not mitigation).
- Change management and configuration control protect specifications, designs and source code from tampering in the pipeline.
8.2 Controls in development ecosystems
The software environment encompasses all elements, activities, people and systems affecting a software's creation and use. Controls must apply across it: IDEs, software libraries, CI/CD, source code management and secure automation.
Key points
- IDEs provide design, coding, compilation, testing and integration; software libraries (vendor, third-party, in-house, open-source) must be vetted.
- CI/CD automates communication and coordination: continuous integration frequently tests code in a repository, continuous delivery pushes it to production.
- Code reuse and refactoring reduce errors by reusing units already proven correct and safe.
- Encapsulation, code protection and data protection isolate software units from one another (code hiding, data hiding).
- Maturity models and software (quality) assurance frame continuous improvement of security and quality.
8.3 Assess software security effectiveness
The primary goal of assessment is to appraise and improve security measures by detecting vulnerabilities early in the cycle. Several complementary techniques exist: static, dynamic, interactive analysis and runtime protection.
Key points
- SAST (static analysis) examines source code without executing it to find type, bounds and unreachable-code errors - ideal when integrated into the SDLC.
- DAST executes the system to drive it to reveal vulnerabilities; IAST combines SAST and DAST to pinpoint the source.
- RASP embeds security agents in the application that detect and block violations at runtime.
- Regression testing checks that changes have not degraded other functions or introduced unauthorized behaviors; IV&V brings an objective third-party view.
- Four risk assessment types: certification and accreditation, risk management frameworks, CMMs, and software assurance.
8.4 Assess the impact of acquired software
Acquired software (COTS, open-source, libraries, managed services) introduces its own risks. Four phases shape acquisition through third parties, and each type calls for tailored assurance and security controls.
Key points
- Four acquisition phases: planning, contracting, monitoring/acceptance/deployment, and ongoing use and support.
- COTS are finished products not meant for modification, extensible via scripts, macros and parameters - their source code stays opaque.
- Open-source software exposes its source code for inspection and often allows modification and refactoring, but requires software composition analysis of dependencies.
- Citizen programmers and ungoverned code reuse escape quality, CM and security control, creating hard-to-manage risk.
- Acceptance is a formal handover (test, analysis, assessment); certification and accreditation validate posture before operation.
8.5 Define and apply secure coding standards
Since vulnerabilities are self-induced, the organization can mandate secure coding guidelines by policy. Combined with defensive programming and mastery of databases, the web and malware, they strongly reduce exploitable flaws.
Key points
- Input validation and defensive programming block dangerous inputs, preventing buffer overflow, SQL injection and arbitrary code execution.
- Strong data typing and blocked/allowed lists harden code; APIs must be explicitly protected.
- Database security: the ACID test (isolation makes transactions invisible to others), against aggregation, inference, query and bypass attacks via polyinstantiation and view-based access controls.
- Mobile code and the web (XML, REST, API) often travel as readable source code and concentrate self-inflicted vulnerabilities.
- Know the malware landscape (virus, worm, ransomware, APT, living off the land) and software-defined security (SDS) built on zero trust architecture.
Key concepts
SDLC models
Build & Fix, Waterfall (sequential phases), V-Model (mirrored V&V), Prototyping, Incremental, Spiral (risk assessed each iteration via PDCA), RAD, Agile. The SDLC ends at implementation; the SLC (Systems Life Cycle) also covers operation and retirement.
Secure SDLC & shift-left
Security must be designed in from the start, never bolted on later: fixing a flaw grows more expensive downstream (1x at design, exponential in production). Shift-left means moving security activities leftward on the timeline.
Threat modelling & STRIDE
Identify, categorise and analyse threats and missing safeguards by mapping system boundaries (threat surface). STRIDE (Microsoft) = Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation of privilege. Other models: PASTA, LINDDUN, Trike.
Maturity models (SW-CMM, SAMM, BSIMM)
SW-CMM (SEI, 1991): 5 levels from chaotic to optimised. OWASP SAMM: open framework of 4 functions (governance, construction, verification, operation), each practice on 3 levels. BSIMM: a descriptive model based on observing real-world programmes.
Development ecosystems
IDEs, code libraries, IPT/IPPD (cross-disciplinary teams), CI/CD (automation between steps), DevOps (Dev + Ops + QA continuously) and DevSecOps (security integrated at every step). Mobile code (JS, JAR, applets) expands the threat surface on both client and server.
SAST / DAST / IAST / RASP
SAST = static analysis of source code (no execution). DAST = dynamic test of the running application. IAST = combines SAST+DAST with behavioural analysis to pinpoint the flaw. RASP = embedded agent detecting and blocking attacks at runtime.
Software assurance & Certification/Accreditation
Software (Quality) Assurance = verify the software does what it should, nothing else, free of known flaws. Certification = the comprehensive technical analysis. Accreditation = a designated authority's (DAA) formal decision to operate at an acceptable risk level.
Acquired software: COTS, open-source, cloud
COTS = a finished product not user-modifiable (extensible via scripts/macros/config). Open-source, cloud services and third-party code introduce inherited risk: the EULA shield is eroding under growing liability. Assess assurance before integrating.
Software supply chain: SBOM & SCA
SBOM (Software Bill of Materials) = inventory of a product's components and dependencies. SCA (Software Composition Analysis) = analysing those dependencies for vulnerabilities and licences. Key against supply-chain attacks (cf. Apache Struts).
Object-oriented concepts
Object = data + methods encapsulated. Encapsulation = data/code hiding. Inheritance = a subclass inherits its parent class's characteristics. Polymorphism = an object takes many forms based on use, limiting ripple effects.
Buffer overflow & input validation
Buffer overflow = oversized input reaching memory outside the allocated buffer. Defence: input validation, strong data typing and type-safe languages. 'Garbage in, garbage out': unchecked input can cause arbitrary code execution.
DB threats: aggregation, inference, polyinstantiation
Aggregation = combine non-sensitive data that becomes sensitive en masse. Inference = deduce sensitive data from visible pieces. Polyinstantiation = defence: same key, different values per classification level. View-based access controls.
ACID & database models
ACID = Atomicity, Consistency, Isolation, Durability; guarantees transaction integrity (all-or-nothing). Models: hierarchical, network, relational (DBMS, DDL/DML), object-oriented (OO). Access via ODBC (risk: plaintext credentials) or REST APIs.
OWASP Top 10 (2021)
Broken Access Control (#1), Cryptographic Failures, Injection (SQLi, XSS), Insecure Design, Security Misconfiguration, Vulnerable & Outdated Components, Identification/Auth Failures, Software & Data Integrity Failures, Logging/Monitoring Failures, SSRF.
Secure coding & API security
Secure coding guidelines (CERT, OWASP), defensive programming, controlled code reuse and trusted libraries. REST APIs: token/session-key authentication, validation, TLS encryption; see the OWASP REST Security Cheat Sheet.
Malware taxonomy
Virus (needs user action, Fred Cohen 1984), worm (self-propagating), trojan/RAT, ransomware, logic bomb, spyware/adware, botnet, trapdoor/backdoor. Living off the land = abusing legitimate tools. Most exploit mobile code via social engineering.
Software-Defined Security & Zero Trust
SDS (Software-Defined Security) drives security through software/policy, automated and adaptable to the infrastructure. Zero Trust Architecture (ZTA) - never trust, always verify - is a prerequisite for and driver of SDS solutions.
Coupling and cohesion
Two design-quality metrics: aim for low coupling (weak dependency between modules) and high cohesion (each module has a single responsibility). The hallmark of maintainable, securable code.
Software escrow
Source code held by a trusted third party, released to the customer under contractual conditions (vendor bankruptcy, end of support). A supply-chain continuity control for bespoke software.
SOAP vs REST
SOAP: strict XML protocol with WS-Security (message-level security), stateful. REST: lightweight HTTP/JSON style, stateless, secured by TLS. Two API families to know.
Frameworks & standards
| Framework | Role |
|---|---|
| SW-CMM / CMMI | Software maturity model (SEI); 5 levels from chaotic to optimised. |
| OWASP SAMM | Software Assurance Maturity Model: 4 functions, practices on 3 levels. |
| BSIMM | Building Security In Maturity Model: descriptive, observation-based model. |
| OWASP Top 10 | List of the top 10 web application security risks (testing reference). |
| NIST SP 800-154 | Guide to data-centric system threat modelling. |
| CERT Secure Coding | Secure coding standards (SEI/CERT) per language. |
| STRIDE | Microsoft threat model: 6 attack categories. |
| CORBA / ORB | Object interoperability standards across machines via an Object Request Broker. |
| OWASP ASVS | Application Security Verification Standard: application verification requirements. |
Acronyms
| Acronym | Meaning |
|---|---|
| SDLC | Software Development Life Cycle (ends at implementation) |
| SLC | Systems Life Cycle (also covers operation and retirement) |
| SAST | Static Application Security Testing |
| DAST | Dynamic Application Security Testing |
| IAST | Interactive Application Security Testing |
| RASP | Runtime Application Security Protection |
| CI/CD | Continuous Integration / Continuous Delivery |
| CMMI | Capability Maturity Model Integration |
| SAMM | Software Assurance Maturity Model (OWASP) |
| BSIMM | Building Security In Maturity Model |
| COTS | Commercial Off-The-Shelf |
| SBOM | Software Bill of Materials |
| SCA | Software Composition Analysis |
| ACID | Atomicity, Consistency, Isolation, Durability |
| DBMS | Database Management System |
| ORB | Object Request Broker |
| CORBA | Common Object Request Broker Architecture |
| TOCTOU | Time Of Check to Time Of Use |
| TCB | Trusted Computing Base |
| OWASP | Open Worldwide Application Security Project |
| REST | Representational State Transfer |
| ODBC | Open Database Connectivity |
| XSS | Cross-Site Scripting |
| CSRF | Cross-Site Request Forgery |
| SQLi | SQL Injection |
| IPT/IPPD | Integrated Product Team / Integrated Product & Process Development |
| KDD | Knowledge Discovery in Databases |