Domain 8 - Software Development Security

About this note

This is the expanded reference version of my original CISSP exam notes. The bullet-point original is preserved in Domain 8 - Software Development Security (Original-Stichpunkte) for comparison. Written for readers with several years of hands-on security and networking experience.

Programming Concepts

The abstraction ladder, from silicon upward:

• Machine code — the raw binary the CPU executes; the only language hardware actually speaks.
• Assembler language — human-readable mnemonics (ADD, SUB, JMP) mapping nearly 1:1 to machine instructions; what reverse engineers read when analyzing malware without source.
• Source code — the program as written in a higher-level language; the artifact that code reviews, SAST, and repositories deal in.
• Compiled languages — a compiler translates the higher-level source into machine code once, ahead of execution; what ships is the binary, not the source.
• Interpreted languages — the translation happens every time the code runs; what ships is the source (or something close to it), executed by an interpreter.
• Bytecode — the middle path: source compiles to an intermediate representation executed by a virtual machine (JVM, CLR). Portable across platforms, and decompilable enough that “the source isn’t shipped” offers little secrecy.

The security relevance of the ladder: it determines what an attacker (or auditor) can see and modify. Compiled binaries require reverse engineering; interpreted code is readable as delivered; bytecode sits in between. And regardless of level, the trust question is the same — what runs must match what was reviewed, which is what code signing and supply-chain controls exist for.

Top-down programming starts with the big picture and decomposes into ever-smaller functions — historically the home of procedural programming. Bottom-up programming builds small, self-contained components first and composes them into complex systems — the natural habit of OOP. In practice every real project mixes both; the exam just wants the association.

Software Development Methods

Waterfall

Strictly linear phases — requirements, design, implementation, testing, deployment — with no stepping back: each phase completes before the next begins. Its virtue is predictability and documentation; its vice is that requirements are frozen at the start, when everyone knows the least. Security implication: in waterfall, security requirements must be complete up front, because there’s no structural opportunity to add them later.

Sashimi

Waterfall with overlapping phases — design begins before requirements fully close, testing overlaps implementation. Named after the overlapping fish slices; it trades waterfall’s clean gates for earlier feedback.

Agile

Self-organizing, cross-functional teams with adaptive planning: short iterations, working software over comprehensive documentation, requirements allowed to evolve. The security challenge is cadence — a security review process built for one release per year meets a team shipping every two weeks. The answer is embedding security into the iteration (security acceptance criteria, automated testing in the pipeline) rather than gating around it.

Scrum

The dominant agile framework: small teams with three roles — the product owner (owns the backlog and priorities — and is therefore where security requirements must land to get built), the development team, and the Scrum Master (process facilitator, impediment remover). Work happens in fixed-length sprints from a prioritized backlog.

Spiral Model

Iterative development organized around risk: each loop of the spiral passes through planning, risk analysis, engineering, and evaluation. Its distinguishing feature — explicit risk analysis every cycle — makes it the methodology answer whenever an exam question emphasizes risk-driven development of large, expensive systems.

RAD — Rapid Application Development

Left empty in the original; the fill: RAD prioritizes speed through prototyping and iterative user feedback over up-front planning — build a working prototype fast, refine it with the users, converge on the product. Strong where requirements are fuzzy and user interaction is central; risky where scalability and rigor matter, because the prototype has a habit of becoming production.

Prototyping

Also empty in the original: building deliberately incomplete models of the system to test concepts, requirements, and interfaces before committing to full development. Two flavors worth distinguishing: throwaway prototypes (built to learn, then discarded) and evolutionary prototypes (refined into the product). The security caution applies to the second: prototypes are built without security rigor by design, and evolutionary ones carry that debt into production unless it’s consciously paid off.

SDLC — Software Development Life Cycle

The phase framework for the whole life of software: Investigation → Analysis → Design → Build → Test → Implement → Maintenance and Support — with the domain’s central message attached: security can (and must) be built into each step. Requirements in Investigation/Analysis, threat modeling in Design (Domain 3’s STRIDE), secure coding in Build, security testing in Test (Domain 6’s whole arsenal), hardening in Implementation, and patching in Maintenance. The economics are the argument: a flaw caught in design costs a meeting; the same flaw in production costs an incident. “Shift left” is the modern slogan for what this bullet list already says.

Projects, Programs, Portfolios

The management hierarchy: a project has a finite start and end and creates a unique product; a program is a collection of related projects managed together for benefits no single project delivers alone; a portfolio is the collection of projects and programs aligned to strategic objectives — the level where Domain 1’s governance decides what gets funded at all. An IPT (Integrated Product Team) is the multidisciplinary group collectively responsible for delivering a defined product — the org form that puts security in the room from day one instead of at the sign-off gate.

Source Code Escrow and Repositories

Source code escrow — a third party holds the vendor’s source, released to the customer under contractually defined triggers (vendor bankruptcy, abandoned support). The continuity control for the “what if our critical vendor disappears” scenario from Domain 7’s supply-chain thinking — with the practical caveat that escrowed source without build documentation and environment is an archive, not a capability; good escrow agreements include verified builds.

Source code repositories — version control as a security control: complete change history (who changed what, when — Domain 5’s accountability applied to code), enforceable review gates before merge, and signed commits binding changes to identities. The repo is also a crown-jewel target: it holds the intellectual property and, too often, accidentally committed secrets.

API Security

The checklist from the original, expanded into what each item means for an API specifically: authentication (every endpoint, no anonymous “internal” APIs — they never stay internal), access control (per-object authorization, because IDOR/BOLA is the dominant real-world API flaw: authenticated user A reading object B by incrementing an ID), input validation (schema-validate everything; the API contract is the whitelist), output encoding/escaping (context-appropriate, so stored data can’t execute downstream), cryptography (TLS everywhere, correctly configured — Domain 3’s implementation-over-algorithm lesson), and error handling and logging (errors that don’t leak internals; logs that feed Domain 7’s detection).

Configuration Management Guidelines

NIST SP 800-128 — security-focused configuration management — provides the vocabulary: the Configuration Management Plan (CMP) defines the process; the Change Control Board (CCB) approves changes (Domain 7’s change management, formalized as a body); configuration item identification determines what is under management at all; configuration change control governs how items change; and configuration monitoring verifies reality still matches the approved baseline — drift detection, the control that catches both sloppy admins and intruders modifying systems outside process.

DevOps

A software development and delivery process emphasizing communication and collaboration between product management, development, and operations — dissolving the wall over which software was traditionally thrown. The security extension the exam era hinted at and practice completed: DevSecOps — security as the third partner, with controls automated into the pipeline (SAST, dependency scanning, IaC checks, signed artifacts) so that velocity and security stop being a trade-off. The cultural point matters more than the tooling: in DevOps, whoever builds it runs it — and securing it becomes part of running it.

Databases

DBMS

The database management system (the original’s “DRMS” was a typo): the software layer through which users and applications interact with the data — and therefore the enforcement point for everything below: integrity rules, access control, auditing. Nobody should touch the tables except through the DBMS’s controlled interfaces; direct file access bypasses every rule the DBMS enforces.

Database Integrity

The four integrity types — this is Domain 3’s integrity goal (Biba, Clark-Wilson) implemented in relational machinery:

• Referential integrity — every foreign key matches an existing primary key: no orphaned references, no order rows pointing at deleted customers.
• Semantic integrity — every attribute value is consistent with its data type and domain rules: no text in date columns, no negative quantities where the domain forbids them.
• Entity integrity — every row has a unique, non-null primary key: every record is individually identifiable.
• User-defined integrity — the business rules beyond the structural three: custom constraints and triggers (“discount may not exceed 20% without approval flag”) — Clark-Wilson’s well-formed transactions expressed as database constraints.

The surrounding quality attributes from the original — stability, performance, re-usability, maintainability — are the general software qualities a database design is judged by alongside integrity.

Normalization

The stepwise removal of redundancy — the three classic forms, paraphrased as in the original:

1. First normal form — divide the base data into tables; assign primary keys (atomic values, no repeating groups).
2. Second normal form — move data that is only partially dependent on the primary key into its own table.
3. Third normal form — remove data that is not dependent on the primary key at all (no transitive dependencies).

The payoffs, as listed: better organization, reduced redundancy, data consistency, flexible design, and a better handle on security — the last one being the underrated point: when each fact lives in exactly one place, access control and classification can be applied precisely (Domain 2’s labeling, at table granularity) instead of chasing copies. Practical footnote: warehouses deliberately denormalize for read performance — a conscious trade, not an accident.

Database Query Languages

The SQL sublanguages: DDL (Data Definition Language) shapes the structure — CREATE, ALTER, DROP; DML (Data Manipulation Language) works the data — SELECT, INSERT, UPDATE, DELETE. The security relevance of the split: least privilege maps onto it directly — application accounts need DML, almost never DDL; an app account that can DROP TABLE is an incident waiting for an injection to happen. (The third sibling, DCL — GRANT/REVOKE — is the permission machinery itself.)

Coupling and Cohesion

The module-quality pair: coupling is the interdependence between modules; cohesion is how much the elements inside a module belong together. The design goal: low coupling, high cohesion — modules that each do one thing well and depend on each other minimally. The security translation: low coupling means containable failure — a compromised or buggy module with few dependents has a small blast radius. High coupling is how one library’s flaw becomes everyone’s incident.

ORB — Object Request Broker

Middleware that lets program calls travel from one computer to another across a network as if they were local object calls. The named generation — COM, DCOM, CORBA, .NET Remoting — is legacy technology now (today’s equivalents are REST/gRPC APIs and message queues), but the security lesson transfers unchanged: distributed calls need authentication, authorization, and encryption per call, and every remoting interface is attack surface — DCOM’s CVE history made the point emphatically.

OOAD — Object-Oriented Analysis and Design

The iterative discipline: iteration after iteration, the analysis models (OOA) and design models (OOD) are refined and evolve continuously, driven by risk and business value — note that even the definition puts risk among the driving factors.

• OOA (Analysis) — understand the problem in object terms: find the objects, organize them, describe how they interact, define their behavior and their internals. The output is a model of what the system must do.
• OOD (Design) — how we accomplish what the OOA found: mapping the analysis model onto concrete classes, interfaces, and patterns.
• OOM (Modeling) — the umbrella producing abstract and accessible definitions of both — in practice: UML diagrams as the shared language between analysis and design.

The security hook: OOA/OOD is exactly where threat modeling belongs — the object interactions being modeled are the data flows a STRIDE analysis walks. Designing the objects and threat-modeling them in the same iteration is shift-left with no extra ceremony.

OWASP Top 10

Version note

This list matches the OWASP Top 10 2017 Release Candidate 1 — recognizable by A7 (Insufficient Attack Protection/Detection) and A10 (Underprotected APIs), which were replaced in the final 2017 edition (that final list lives in Domain 3). The categories below are evergreen regardless of numbering.

• A1 — Injection — untrusted input interpreted as commands, most often SQL or LDAP. Mitigation: input validation, data-type limitation, input length limits — and above all parameterized queries, which remove the interpretation problem instead of filtering around it. The original’s CGI note stands for the architectural idea: a mediating layer separating the untrusted user from the backend database, so raw input never reaches the interpreter.
• A2 — Broken Authentication and Session Management — sessions that live too long or never expire, and predictable session IDs. The fixes are mechanical: cryptographically random IDs, sensible timeouts, rotation on privilege change — Domain 5’s session discipline applied to web apps.
• A3 — XSS (Cross-Site Scripting) — attacker-injected client-side scripts executing in other users’ browsers. Prevention: input validation and data typing on the way in, and (the half the original omitted, and the more important one) context-aware output encoding on the way out. The simultaneous-logins-from-two-IPs detection note is a session-hijack tripwire — catching XSS’s favorite payoff, stolen sessions, after the fact.
• A4 — Broken Access Control — authorization enforced inconsistently or not at all; the fix in the original is the right one: centralize the access control mechanism — one enforcement point, uniformly applied, instead of per-endpoint ad-hoc checks that inevitably miss one. (In the final 2017 list and beyond, this category climbed to #1 — deservedly.)
• A5 — Security Misconfiguration — default settings left in place, misconfigured databases; findable with a vulnerability scanner (Domain 6), preventable with hardened baselines and configuration management (Domain 7).
• A6 — Sensitive Data Exposure — HTTP instead of HTTPS, unencrypted data at rest — Domain 2’s three-states discipline, violated in a web context. (Phishing rides alongside: exposed data feeds credential attacks.)
• A7 — Insufficient Detection and Response (RC1-specific) — not detecting that we’ve been compromised: applications that neither log security events nor resist active attack. The listed mitigations (patching, closing ports) are generic hygiene; the real answer is application-level logging feeding Domain 7’s SIEM. The theme survived into later lists as “Insufficient Logging & Monitoring.”
• A8 — CSRF (Cross-Site Request Forgery) — the browser’s automatic credential-sending turned against the user: a stolen or ambient session (cookies, including passwords saved in cookies) is exploited by a forged request from another site, often delivered by phishing. Anti-CSRF tokens and SameSite cookies are the modern fixes — effective enough that CSRF dropped off later Top-10 lists.
• A9 — Using Components with Known Vulnerabilities — the Windows XP example generalizes to every unpatched dependency: the modern supply-chain problem in embryo. Today’s answer: dependency scanning and SBOMs — you can’t patch what you don’t know you ship.
• A10 — Underprotected APIs (RC1-specific) — badly coded APIs, no TLS. The category was folded back into the others in the final list, then outgrew them: OWASP now maintains a dedicated API Security Top 10 — the API-security section above is its condensed ancestor.

Additional Attacks

• Buffer overflow — malformed input overrunning a buffer, corrupting adjacent memory: from crash (availability) to full code execution. The attack class Domain 3’s DEP and ASLR exist to blunt — and memory-safe languages increasingly remove at the root.
• Race conditions / TOCTOU — time-of-check to time-of-use: the state validated at check time changes before use time (the file you verified is swapped before you open it). The fix is making check-and-use atomic; the bug class thrives wherever privileged code touches attacker-influenced resources.
• Privilege escalation — leveraging a foothold into higher privilege, vertically (user → admin) or horizontally (user A → user B).
• Backdoors — hidden access paths around authentication: planted by attackers, left by developers (“maintenance hooks”), or shipped in the supply chain. Code review and integrity verification are the counters.
• Disclosure — the umbrella for unintended information leakage: verbose errors, debug endpoints, metadata — each small leak feeding the attacker’s recon.

Software Capability Maturity Model (SW-CMM)

The five-level maturity staircase — structurally the same ladder as Domain 1’s risk-management maturity model, applied to software development:

• Level 1 — Initial: success rides on competent people and informal processes; work is ad-hoc and chaotic, with no formal process. Heroics deliver — sometimes.
• Level 2 — Repeatable: project management and basic lifecycle processes exist; earlier successes can be repeated on similar projects.
• Level 3 — Defined: engineering processes are documented and standardized organization-wide — requirements management, project planning, quality assurance, configuration management, code reuse. Process belongs to the organization, not the individual project.
• Level 4 — Managed (Capable): quantitatively controlled — product and process are measured, and management steers by the numbers.
• Level 5 — Optimizing: continuous process improvement as the operating state, working hand in hand with the IDEAL model.

The security reading: secure development presupposes maturity — a Level 1 shop cannot meaningfully run an SDL, because there is no defined process to embed security into. Maturity level is therefore a fair proxy question when assessing a software vendor.

IDEAL

The improvement cycle paired with CMM — the acronym is the sequence:

1. Initiate — begin: establish sponsorship and goals for the improvement effort.
2. Diagnose — perform the assessment: where are we against where we want to be?
3. Establish — build the action plan with priorities and measurable targets.
4. Action — implement the improvements.
5. Leverage — reassess, learn, and feed the next cycle: continuous improvement.

Structurally it’s Plan-Do-Check-Act with an explicit sponsorship phase up front — the same lesson as Domain 7’s BCP development: without initiated leadership support, improvement programs starve.

Acceptance Testing

The final gate before software goes live — several flavors, distinguished by who accepts what:

• User acceptance testing (UAT) — does the software do what it was built for? — verified by the actual users against their real workflows, not by developers against the spec.
• Operational acceptance testing — can operations run it? Backups, monitoring, failover, runbooks — the same gate described in Domain 6.
• Contract acceptance testing — does the delivery meet the contractually agreed criteria? The formal basis for payment and for dispute.
• Compliance acceptance testing — does it meet the regulatory and policy requirements that apply (Domain 1’s legal landscape, verified before production)?
• Compatibility / production testing — does it behave correctly in the actual production environment, alongside the systems it must coexist with?

Security’s seat at this table: security acceptance criteria belong in UAT and compliance testing explicitly — defined at requirements time (the RTM from Domain 6 tracing them through), not discovered at go-live.

Buying Software from Other Companies

Acquired software deserves the same skepticism as built software — the due care / due diligence pair from Domain 1 applies verbatim: diligence is the research, care is acting on it, and “the vendor said it’s secure” satisfies neither.

The practical checklist for COTS (Commercial Off-The-Shelf) software: study reviews and independent assessments, check the roadmap (is the product alive? where is it going?), use a requirements traceability matrix to verify the product actually meets your requirements rather than approximately resembling them, ask for references on long or expensive implementations (talk to organizations who’ve lived with it), and check financial viability — a vendor’s bankruptcy is your unpatched dependency (and the scenario source-code escrow above exists for).

What the exam-era list only implies and current practice makes explicit: proper testing of acquired software includes security testing — vendor SOC 2 reports (Domain 6), penetration test attestations, SBOM review. Supply-chain security begins at procurement.

AI — Artificial Intelligence

Left empty in the original — understandable then, impossible now. The security view in brief, wearing the same two hats as every tool:

AI as attack surface: systems incorporating ML models inherit novel vulnerability classes — prompt injection (untrusted input steering model behavior: A1’s injection lesson in new clothes), training-data poisoning (integrity of the data supply chain), model extraction and inversion (confidentiality of the model and its training data), and adversarial inputs (crafted samples flipping classifications). The Domain 3 threat-modeling discipline applies unchanged; only the asset types are new.

AI in the SDLC: code generated by AI assistants is unreviewed third-party code until proven otherwise — the A9 lesson applies: review, scan, and test it like any dependency. Conversely, AI strengthens the defensive toolchain (triage, anomaly detection, code analysis at scale) — Domain 7’s behavioral detection, upgraded.

The governance frame arriving alongside: NIST’s AI Risk Management Framework and the EU AI Act extend Domain 1’s compliance landscape to AI systems — risk-based classification, documentation duties, accountability. The pattern of this entire study guide holds: new technology, same principles — classify the assets, model the threats, control the risks, verify continuously.

---

Erstellt: 2026-07-08 — ausformulierte Fassung der Original-Stichpunkte, siehe Domain 8 - Software Development Security (Original-Stichpunkte)