CISSP Software Development Security: Secure SDLC, APIs, and Coding

Introduction

CISSP software development security integrates secure SDLC practices, application testing, supply chain assurance, and secure coding. This lesson covers Domain 8, Software Development Security (10% of the exam, ISC2 exam outline effective 15 April 2024), tasks 8.1 to 8.5: 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. It is the last content lesson of the course; practice exams support further review.

Software vulnerabilities can expose an organization through an unvalidated input, an exposed API, an outdated library, a leaked secret in a repository. The CISSP expects you to think like a manager and architect: place security activities at every stage, choose the right testing technique for the situation, manage third-party code, and measure whether the program works. You do not need to write code, but you must recognize insecure patterns.

Learning objectives

After this lesson you can:

1. Compare development methodologies (waterfall, agile, DevOps, DevSecOps) and the maturity models CMMI, BSIMM, and OWASP SAMM.
2. Place security activities in each SDLC phase, including requirements, threat modeling, design review, and secure disposal.
3. Secure the development ecosystem: repositories, CI/CD pipelines, secrets, IDEs, runtimes, libraries, and configuration management.
4. Choose among SAST, DAST, IAST, SCA, fuzzing, and manual code review, and interpret their results.
5. Assess the security of acquired software: COTS, open source, managed applications, cloud services, and software bills of materials.
6. Apply secure coding guidelines, including input validation, output encoding, parameterized queries, error handling, and API security.
7. Recognize common source-code vulnerabilities and the OWASP Top 10:2025 categories.

1. Security in the SDLC

1.1 Methodologies

Shift left means finding and fixing defects earlier, when they are cheaper. A flaw found in design costs far less than the same flaw found in production.

1.2 Security activities by phase

The NIST Secure Software Development Framework (SSDF, SP 800-218) groups practices into four sets: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. It is a useful structure for answering "what should the program include?". Version 1.1 remains the final publication in the consulted NIST listing; Version 1.2 (SP 800-218 Rev. 1) is listed as a draft, so do not present it as a final replacement.

1.3 Maturity models

• CMMI (Capability Maturity Model Integration): the familiar maturity progression is Initial (1), Managed (2), Defined (3), Quantitatively Managed (4), and Optimizing (5); current CMMI guidance also describes Incomplete (0). Organizational maturity levels differ from capability levels for individual practice areas.
• BSIMM (Building Security In Maturity Model): descriptive; it observes what real organizations actually do and lets you compare against peers.
• OWASP SAMM (Software Assurance Maturity Model): prescriptive; it provides a framework to assess and improve across governance, design, implementation, verification, and operations.
• ISO/IEC 27034 addresses application security processes; ISO/IEC 12207 covers software life cycle processes.

Exam hook: BSIMM = what others are doing (descriptive); SAMM = what you should do (prescriptive).

An integrated product team brings product owners, developers, operations, security, privacy, and other stakeholders together to resolve requirements and risks throughout delivery. Security decisions need accountable owners and acceptance criteria.

1.4 Operational and change aspects

• Software configuration management (SCM) tracks versions, branches, and builds. Use version control with branch protection, signed commits, and required reviews.
• Change control connects releases to incident response, patching, and controlled change: approvals, testing, deployment verification, and recovery planning.
• Separation of environments: development, test, staging, and production are distinct; production data must not be used in test without masking.
• Separation of duties: developers do not deploy directly to production without independent approval.
• Release management and configuration baselines make builds repeatable and auditable.

1.5 Worked example: adding security to an agile team

Scenario. A fintech's agile team ships every two weeks. Last quarter a broken access control bug reached production and exposed customers' statements. Management asks the security architect to reduce this class of defect without slowing releases.

Step by step.

1. Requirements: add a security acceptance criterion to every story that touches data ("a user can only read their own records") and write an abuse case ("customer A tries to read customer B's statement by changing the identifier").
2. Design: a lightweight threat model (STRIDE) at sprint planning for features that change trust boundaries; authorization is enforced server-side in one shared component.
3. Build: peer review checklist with an authorization item; SAST and secrets scanning in the pull request pipeline.
4. Test: automated authorization tests for each role; DAST against staging; periodic manual penetration test.
5. Release/operate: pipeline gates fail on high-severity findings; monitoring alerts on unusual access patterns; track defect escape rate as a metric.

Why this works: it moves detection earlier and makes the control repeatable. Why not a final security review before each release? It becomes a bottleneck, finds issues late, and cannot keep pace with two-week sprints. Why not rely only on a yearly penetration test? The interval is too long relative to the release cadence.

2. Security controls in the development ecosystem

2.1 Repositories and pipelines

• Source code repositories (Git platforms) need strong authentication (MFA, SSO), least privilege, branch protection, mandatory reviews, audit logs, and secret scanning. Source code is intellectual property and reveals attack paths.
• CI/CD pipelines are high-value targets: they hold credentials and produce what runs in production. Harden runners, restrict who can modify pipeline definitions, use short-lived credentials (OIDC federation) instead of long-lived tokens, isolate build agents, pin dependency versions, and sign build artifacts and verify associated provenance (for example SLSA-style attestations). Verify the signer, expected build identity, source, and policy: a signature alone does not prove that the software or build was trustworthy.
• Secrets management: never hard-code credentials, API keys, or private keys in code. Public certificates are not normally secrets. Use a vault or cloud secrets manager, rotate regularly, and scan history if a secret was committed (rotating is mandatory because deleting a commit does not remove it from copies).
• Infrastructure as code is code: review it, scan it for misconfiguration, and manage state files securely.
• Artifact repositories store binaries and containers; scan them, control who can publish, and use private registries with allowlisted base images.

2.2 Tools, IDEs, languages, and runtimes

• Developer workstations are an entry point; apply endpoint protection, patching, and least privilege. IDE plugins and extensions are third-party code, so vet them.
• Memory-safe languages (such as Java, C#, Go, Rust, and Python) reduce memory-corruption risks in their safe execution models. Unsafe blocks, native extensions, foreign-function interfaces, and runtime defects can reintroduce those risks. Where native memory-unsafe code is necessary, combine bounds-aware APIs, static analysis, compiler protections such as stack canaries, and platform exploit mitigations such as ASLR and DEP/NX. These mitigations do not repair a buffer-overflow bug.
• Runtimes and frameworks should be supported versions with security updates. Frameworks provide secure defaults (output encoding, CSRF tokens, parameterized queries) that custom code often misses.
• Containers and serverless: minimal base images, no root, immutable images, scanning at build and runtime, and restricted function permissions.
• Software-defined security: security policies expressed as code and enforced automatically (policy as code, admission controllers, cloud security posture management). Benefits: consistency, speed, auditable history. Risk: a mistake in the code propagates at scale, so test and review policy code like any other code.

Apply the threat modeling and software supply chain principles to developer tools, dependencies, and build services as well as application features.

2.3 APIs

APIs expose business logic directly, so they need: strong authentication and authorization on every call (object-level and function-level), input validation and schema enforcement, rate limiting and quotas, TLS, minimal data in responses, versioning, an inventory of all endpoints (no shadow or zombie APIs), logging, and an API gateway for central policy. Typical flaws: broken object-level authorization (changing an ID returns another user's data), excessive data exposure, and missing rate limits.

2.4 Worked example: a leaked cloud key

Scenario. A developer commits a cloud access key to a public repository by mistake. An automated scanner alerts the security team 20 minutes later. The key belongs to a service account with broad storage permissions.

Solution.

1. Revoke and rotate the key immediately (containment). Removing the file from the latest commit is not enough because history and forks retain it.
2. Review cloud audit logs for use of the key during the exposure window, and treat any access as a possible incident (follow the incident process).
3. Reduce the service account's permissions to least privilege.
4. Add preventive controls: pre-commit hooks and server-side push protection for secrets, central secrets management, short-lived tokens through role federation, and developer awareness.

Why not only delete the commit? Copies and caches persist; the secret must be considered compromised. Why not wait for the weekly review? Automated scanning by attackers finds exposed keys within minutes.

3. Assessing software security effectiveness

3.1 Testing techniques

Use complementary security assessment and testing techniques, including SAST and DAST, because they expose different weaknesses; add SCA for dependencies and IAST where deep context is needed. Synthetic transactions and RASP (runtime application self-protection) support detection in production.

3.2 Assessing the effectiveness of the program

Look beyond the tool output:

• Metrics: vulnerability density, time to remediate by severity, defect escape rate (issues found in production versus earlier), percentage of builds with scans, coverage of threat models, training completion.
• Change audit logs: review who changed what and when, to detect unauthorized or unreviewed changes to code, pipeline definitions, and configurations.
• Risk analysis and mitigation tracking: record accepted risks, compensating controls, and exceptions with owners and expiry dates.
• Independent assessment: penetration tests, third-party code review, audits, and bug bounty programs.
• Compliance with coding standards: automated linters and policy checks with documented exceptions.

3.3 Worked example: choosing the right test

Scenario. A hospital buys a custom patient portal built by a vendor. The contract allows testing but delivers no source code. The hospital wants evidence that the application resists common web attacks before go-live in three weeks.

Solution.

1. DAST against a staging copy with test accounts for each role, checking authentication, session handling, and injection.
2. Penetration test by an independent firm to attempt chained attacks and verify authorization.
3. Contractual requirements: request the vendor's SAST/SCA results, a software bill of materials, and a vulnerability disclosure process.
4. Configuration review of TLS, headers, and cloud settings.

Why not SAST as the primary choice? The stated goal is runtime testing. Static tools need analyzable source, bytecode, or binaries and appropriate support; absence of source alone does not rule out every static technique. Why not rely on the vendor's assurance letter? It is not independent evidence. Why not skip testing because the vendor is reputable? Risk remains with the organization.

4. Acquired software and third-party risk

4.1 Types of acquired software

• COTS (commercial off-the-shelf) software: vendor controls the code; you control configuration, patching, and access.
• Open-source software (OSS): transparent but maintained by communities; risks include abandoned projects, malicious packages (typosquatting, dependency confusion, compromised maintainers), and unpatched transitive dependencies.
• Managed applications and SaaS/cloud services: the provider runs the platform; you manage identities, data, and configuration under the shared responsibility model.
• Outsourced/custom development: contract must state security requirements and testing rights.

4.2 Assessing and controlling the risk

1. Due diligence before purchase: security questionnaires, independent reports (SOC 2, ISO 27001), penetration test summaries, vulnerability history, support lifecycle.
2. Contract terms: security requirements, right to audit, breach notification time, patch timelines, source code escrow for critical software, indemnity, data location and deletion at exit.
3. Software bill of materials (SBOM): a machine-readable inventory of components (formats such as SPDX and CycloneDX) used to quickly answer "are we affected?" when a new vulnerability appears. Pair with trusted, current VEX statements describing whether and why a product is affected by a specified vulnerability. VEX is an assertion with scope and justification, not an independent guarantee of exploitability or safety.
4. Integrity verification: verify signatures and hashes of downloaded software, use trusted repositories, pin versions, and use internal mirrors.
5. Testing before deployment in a sandbox or staging, then hardening and secure configuration.
6. Ongoing management: patching, monitoring advisories, SCA scans, and exit plans if the vendor is acquired or stops support.
7. License compliance: open-source licenses (permissive such as MIT and Apache; copyleft such as GPL) carry obligations that legal must review.

Supply chain incidents (a poisoned build system or update channel) show why integrity of the build and delivery path matters; OWASP Top 10:2025 uses Software Supply Chain Failures (A03) to broaden the earlier focus on vulnerable and outdated components.

4.3 Worked example: a critical open-source library vulnerability

Scenario. A widely used logging library has a remote code execution vulnerability announced on a Friday. The company runs 40 applications; no one knows which use the library.

Solution.

1. Query the SBOM repository and SCA tool for the affected component and versions, including transitive dependencies.
2. Prioritize internet-facing applications; apply the vendor patch or upgrade; where not possible, use mitigations such as disabling the vulnerable feature and WAF/IPS rules.
3. Follow emergency change procedures, test, and redeploy; verify with a rescan.
4. Monitor logs for exploitation attempts; treat any confirmed exploitation as an incident.
5. Improve: require SBOMs, automate dependency updates, and track component inventory.

Why not wait for the monthly patch window? Active exploitation of an RCE on exposed systems is an emergency. Why not simply remove the library from the repository? Deployed applications and transitive uses would still be vulnerable.

5. Secure coding guidelines and standards

5.1 Core practices

Standards to know: OWASP Secure Coding Practices, OWASP ASVS (verification requirements), CERT secure coding standards, CWE (catalog of weakness types), and CWE Top 25.

5.2 Common vulnerabilities

5.3 OWASP Top 10:2025

The 2025 edition lists: A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, and A10 Mishandling of Exceptional Conditions. Compared with the previous edition, A03 broadens the component-risk category to software supply chain failures, while exceptional-condition handling is a new category, and server-side request forgery was folded into broken access control. Do not memorize the order for the exam; understand the categories and map each to controls.

5.4 Databases and data-driven flaws

Application security overlaps with database security: use parameterized queries, stored procedures that avoid unsafe dynamic SQL and run with least privilege, row- or column-level controls, encryption of sensitive fields, and avoid exposing database errors. Inference and aggregation attacks derive sensitive facts from combining non-sensitive data; controls include query restrictions, views, and polyinstantiation (multiple versions of a record at different classification levels).

5.5 Worked example: fixing an injection finding

Scenario. SAST flags a deliberately flawed login handler that concatenates the username into SELECT * FROM users WHERE name = ' plus the input plus '. It then grants a session whenever a row is returned, without verifying a password hash. The input ' OR '1'='1 makes the condition true for other rows. This example contains two defects: SQL injection and missing password verification.

Solution.

1. Use a fixed query such as SELECT id, password_hash FROM users WHERE name = :username, binding the supplied username through the database API. Bound values remain data; dynamic table names or sort directions require fixed allowlisted mappings, not ordinary value placeholders.
2. Validate input (length and allowed characters) as defense in depth, but do not rely on blacklisting quote characters.
3. Store salted password hashes using an appropriate adaptive algorithm, preferably Argon2id under current OWASP guidance. Verify the supplied password with the library’s verification API before issuing a session, handling missing accounts without revealing account existence. Hashing protects stored credentials; it does not repair injection or authorize login by itself.
4. Give the application database account only the rights it needs.
5. Add regression tests for malicious input, unknown accounts, valid credentials, and an existing account with the wrong password. Retain the relevant static-analysis checks.

Why not escape quotes manually? Custom escaping is error-prone and context-dependent. Why not rely on a WAF only? A WAF is a compensating control, not a fix of the code.

6. Pitfalls and exam tips

• Fix root causes in code; a WAF or IPS is a temporary compensating control (virtual patching).
• SAST = source, no execution, early; DAST = running app, black box; IAST = agent inside the running app; SCA = third-party components.
• Use bound parameters for SQL data values, safe rendering and context-aware encoding for XSS, and framework CSRF defenses for cookie-authenticated state changes. Each control must cover all relevant paths; none fixes unrelated authorization flaws.
• Validation happens on the server; client-side checks are for usability only.
• BSIMM describes; SAMM prescribes; CMMI measures process maturity.
• Rotating an exposed secret is required, even after deleting the commit.
• Test and approve changes; developers should not deploy their own code to production unreviewed.
• Accountability for third-party software risk stays with the buyer: use due diligence, contracts, SBOMs, and testing.

7. Mini case study: the payments API

Case. A retailer launches a mobile app backed by a new API. Three months later a researcher reports that changing the orderId in a request returns other customers' orders including addresses. The API has no rate limiting, logs show scraping of 80,000 orders over a week, and the SCA report lists an outdated JSON parsing library with a known vulnerability. The pipeline runs SAST only and secrets are stored in environment variables inside the repository's configuration files.

Commented solution.

1. Root vulnerability: broken object-level authorization (OWASP A01). Fix by checking server-side that the authenticated user owns the order on every request; add automated tests per role.
2. Detection gap: no rate limiting or monitoring. Add rate limiting, anomaly alerts on enumeration patterns, and API gateway logging (OWASP A09).
3. Testing gap: the existing SAST checks missed this authorization defect; static analysis does not prove runtime policy enforcement. Add DAST or IAST, authorization-focused tests, and a penetration test.
4. Supply chain: upgrade the vulnerable library, maintain an SBOM, and automate dependency updates (A03).
5. Secrets: move them to a secrets manager, rotate all exposed values, and add secret scanning.
6. Incident handling: the scraping is a data breach; invoke incident response, preserve logs, involve legal for notification duties, and run lessons learned.

Key terms

• SDLC / DevSecOps / shift left: life cycle / security integrated in DevOps / earlier security activity.
• SAST / DAST / IAST / SCA: static / dynamic / interactive testing / composition analysis.
• Fuzzing: feeding malformed inputs to find defects.
• SBOM / VEX: component inventory / exploitability statement.
• BSIMM / SAMM / CMMI: descriptive / prescriptive / process maturity models.
• SSDF: NIST Secure Software Development Framework (SP 800-218).
• Parameterized query: database call separating code from data.
• XSS / CSRF / SSRF: script injection into browsers / forged authenticated requests / forged server-side requests.
• TOCTOU: time-of-check to time-of-use race condition.
• Software-defined security: policies enforced as code.
• Source code escrow: third party holds code for use if the vendor fails.

Summary checklist

• I can place security activities in each SDLC phase and explain shift left.
• I can compare waterfall, agile, DevOps, and DevSecOps and name CMMI, BSIMM, SAMM, and SSDF.
• I can secure repositories, pipelines, secrets, runtimes, and APIs.
• I can choose between SAST, DAST, IAST, SCA, fuzzing, and penetration testing.
• I can assess COTS, open source, and SaaS risk using due diligence, contracts, and SBOMs.
• I can apply input validation, output encoding, parameterized queries, and safe error handling.
• I can recognize injection, XSS, CSRF, buffer overflow, race condition, SSRF, and deserialization flaws.
• I can map issues to OWASP Top 10:2025 categories and select controls.

Official sources

• ISC2 CISSP exam outline: https://www.isc2.org/certifications/cissp/cissp-certification-exam-outline (opens in a new tab)
• NIST SP 800-218, Secure Software Development Framework (SSDF) v1.1: https://csrc.nist.gov/pubs/sp/800/218/final (opens in a new tab)
• OWASP Top 10:2025: https://owasp.org/Top10/2025/ (opens in a new tab)
• NIST SSDF publication status: https://csrc.nist.gov/Projects/ssdf/publications (opens in a new tab)
• OWASP SQL injection prevention: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html (opens in a new tab)
• OWASP XSS prevention: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html (opens in a new tab)
• OWASP CSRF prevention: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html (opens in a new tab)
• OWASP password storage: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html (opens in a new tab)
• CMMI maturity and capability levels: https://cmmiinstitute.com/learning/appraisals/levels (opens in a new tab)
• OWASP Application Security Verification Standard: https://owasp.org/www-project-application-security-verification-standard/ (opens in a new tab)
• OWASP SAMM: https://owaspsamm.org/ (opens in a new tab)
• CISA, Secure by Design: https://www.cisa.gov/securebydesign (opens in a new tab)
• CWE Top 25: https://cwe.mitre.org/top25/ (opens in a new tab)