# Software Development Security

> Chapter 13 of the Courseiva ISC2-CISSP curriculum — https://courseiva.com/learn/isc2-cissp/software-development-security

**Official objective:** 7.1 — Understand and integrate security in the software development lifecycle

## Introduction

Without integrating security into every phase of software creation, organisations expose themselves to data breaches that can cost millions in regulatory fines, destroy customer trust, and force costly emergency rewrites. This chapter explains how to bake security into the process from the very first requirement, rather than bolting it on after a disaster. It is the core of CISSP Domain 7—and one of the most heavily tested concepts in the exam.

## The 200-Unit Housing Estate Fire Safety Analogy

In a 200-unit housing estate, 47 fire alarms were installed only after residents had moved in, tripling the retrofit cost to £2.1 million and leaving homes unprotected for six months. The original builders treated fire safety as an afterthought—a final inspection checkbox. This is exactly how organisations used to develop software: build everything first, then hang a few security alarms (a penetration test) on the finished system before launch.

In modern construction, fire safety is woven into the blueprint. Architects plan evacuation routes, specify fire-resistant materials, and position sprinklers before the foundation is poured. Each phase—from ground-breaking to interior finishing—includes inspections that verify the fire safety plan. Similarly, software development security embeds protective measures at every phase of the Software Development Life Cycle (SDLC): planning threat models, writing secure code, testing applications while they run, and monitoring them after release. When security is part of the blueprint, you avoid the panic of retrofitting defences into a system that already has residents—or customers—living in it.

## Core explanation

Software Development Security is the practice of embedding safeguards throughout the entire lifecycle of a software application, from the initial idea to ongoing maintenance. The central concept is that security cannot be a final step; it must be a continuous thread woven through planning, design, coding, testing, deployment, and operations. This approach is often called 'shifting left', because you move security activities as early as possible on a timeline that conventionally reads left to right.

The Software Development Life Cycle (SDLC) is the structured process organisations follow to build software. A typical SDLC consists of these phases:

- Planning: stakeholders decide what the software should do and roughly how it will be built.
- Requirements: the team writes precise, detailed descriptions of every function and constraint.
- Design: architects create blueprints for the software’s structure, components, and data flows.
- Development: programmers write the actual source code.
- Testing: the software is checked for bugs, performance issues, and security flaws.
- Deployment: the finished software is released to users, on premises or in the cloud.
- Maintenance: the team fixes bugs, adds features, and responds to incidents over the software’s lifetime.

Historically, security was inserted late in testing or just before deployment, often as a one-off penetration test. This reactive model proved disastrous. Fixing a security design flaw after coding is complete can cost 30 to 60 times more than addressing it during requirements. Moreover, a single missed vulnerability can lead to a breach right after launch.

Integrating security means applying specific activities at each SDLC phase. During planning, the team defines high-level security objectives—for example, “customer payment data must be encrypted at rest and in transit.” During requirements, analysts write misuse cases (how an attacker might abuse a feature) alongside normal use cases. In the design phase, architects perform threat modelling, a structured exercise that identifies potential threats (spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege—the STRIDE model), assesses their likelihood, and plans countermeasures.

In development, security shifts to the code itself. Developers follow secure coding standards that prevent common mistakes like SQL injection or cross-site scripting. They use static application security testing (SAST) tools, which analyse source code without executing it, much like a spellchecker that finds dangerous patterns. Peer code reviews add another human layer of scrutiny.

During testing, the focus moves to dynamic application security testing (DAST), which probes the running application from the outside, simulating how an attacker would interact with it. Teams also conduct penetration testing, where ethical hackers actively try to break in. Any found flaws are ranked and fixed.

Deployment is not the end. Operations teams configure the production environment securely—locking down ports, enabling logging, and applying least-privilege access controls. They set up continuous monitoring to detect anomalies and potential intrusions. In maintenance, a formal vulnerability management process kicks in: the team tracks new threats, applies patches, and revisits threat models whenever features change.

This entire workflow is increasingly automated through DevSecOps, a cultural and technical movement that makes security a shared responsibility across development, security, and operations. In a DevSecOps pipeline, every code change triggers automated SAST scans, DAST scans in staging environments, and compliance checks before the change reaches production. Security becomes a fast, invisible safety net rather than a gatekeeper who stops everything for a manual review.

Two critical concepts underpin this approach. Secure by design means that systems are built from the ground up to be resistant to attack, not merely fixed after the fact. Security by default means that the system’s factory settings are protective—for example, enabling encryption without requiring an administrator to opt in.

In summary, Software Development Security is not a single tool or phase. It is a mindset and a set of practices that treat security as an inherent quality attribute—like reliability or performance—that must be designed, built, tested, and maintained continuously.

## Real-world context

Imagine a mid-sized financial company building a mobile banking application. The project kicks off with a cross-functional team: business analysts, developers, security engineers, and operational staff. On day one, the security engineer facilitates a threat modelling workshop using the STRIDE framework. Together, they draw data flow diagrams of how the app will authenticate users, retrieve account balances, and transfer funds. They identify threats: an attacker might try to spoof a legitimate user’s session, tamper with transaction amounts in transit, or perform a denial-of-service attack against the login endpoint.

These threats are translated into security requirements. The requirement “All API responses containing personally identifiable information must be encrypted with TLS 1.3” goes into the same backlog as functional user stories. This ensures developers know exactly what protection to build from the start.

During design, the architects choose a microservices architecture with each service running in an isolated container. They specify that all inter-service communication must be mutually authenticated using certificates. A secure design review meeting with a senior security architect catches a flaw: one service was planning to accept unencrypted HTTP for internal health checks. That is rejected; even internal traffic stays encrypted.

In development, every programmer uses an integrated development environment (IDE) pre-loaded with SAST plug-ins. When a developer writes a database query that concatenates user input directly into the SQL string, the SAST tool highlights it in real time as a potential SQL injection. The developer rewrites the query using parameterised statements. Code is then committed to a central repository, where a continuous integration (CI) server automatically runs a full SAST scan and a software composition analysis (SCA) that checks third-party libraries for known vulnerabilities. A critical vulnerability in an open-source logging library is flagged; the team updates it before it ever reaches a test environment.

When a build passes all static checks, it is deployed to a staging environment. Here, automated DAST scanners fire thousands of attack payloads at the running application—cross-site scripting, path traversal, brute-force login attempts. Meanwhile, an external penetration testing firm has been engaged to simulate a real-world attack. Their report finds a misconfigured cloud storage bucket that exposes temporary files; the operations team fixes it immediately.

Before go-live, the security engineer reviews the final deployment configuration. Web application firewalls are tuned, logging is enabled in Microsoft Entra ID and the cloud platform’s monitoring service, and an incident response runbook is tested.

Three weeks after launch, the cloud monitoring system detects 500 failed login attempts from a single IP address. The on-call engineer blocks the IP and investigates. No breach occurs because the alerting was configured and tested from the start. Security never stopped; it simply shifted from building to operating.

## Exam focus

CISSP exam questions on Software Development Security are notorious for testing your ability to distinguish where different security activities belong in the lifecycle. They will not ask for definitions; they will present a scenario and expect you to recognise that “a static code analysis scan should have been done before the code was merged into the main branch” or “the missing activity was a threat model during the design phase.”

Specific question types that appear:
- Phase placement questions: “During which phase of the SDLC should secure coding standards first be applied?” You must answer “development”, not “testing” or “design”.
- Tool vs. function: They will describe a tool that “reviews source code for potential vulnerabilities without executing the program” and ask you to identify it as static application security testing (SAST). The trap is selecting dynamic application security testing (DAST) or penetration testing.
- Cost-of-fix curve: A common correct answer is that shifting security left reduces the cost and impact of fixing defects. This principle is the foundation of many questions.
- DevSecOps culture: Questions will describe a team where security checks are automated in the continuous integration pipeline and ask what concept this illustrates. The answer is DevSecOps, not simply “automated testing”.
- Threat modelling techniques: You may be asked to recognise STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) or other frameworks like DREAD and PASTA. Know that STRIDE categorises threats, while DREAD quantifies risk.
- Roles and responsibilities: “Who is ultimately responsible for the security of an application under development?” The correct mindset is that everyone shares responsibility, but the security officer or team provides governance.

Common traps set by the exam writers:
- Confusing static and dynamic testing. SAST is inside-out (white-box, looking at source); DAST is outside-in (black-box, testing a running system).
- Thinking that a penetration test at the end of a project is sufficient. CISSP constantly rewards the “integrate early and often” pattern.
- Forgetting that security requirements must be defined in the requirements phase, not invented during coding.
- Assuming that cloud platforms like Azure (now featuring Microsoft Entra ID for identity) automatically handle all application-level security. You must still secure your code and configurations; the shared responsibility model applies.
- Misunderstanding that bug fixes are not the same as security patching; they are driven by vulnerability management, not just problem tickets.

Key definitions to memorise:
- SAST: analyses source code, bytecode, or binaries without execution (static).
- DAST: tests an application in its running state, often without access to source code (dynamic).
- Threat modelling: a procedure for identifying and prioritising potential threats and countermeasures.
- DevSecOps: the integration of security practices and automated tooling into the DevOps pipeline, ensuring security is a shared responsibility.
- Secure by design: the philosophy that software should be architected to be secure from its inception.
- Shift left: moving security activities earlier in the SDLC timeline.

## Step by step

1. **Define Security Requirements Early** — During the planning and requirements phases, collaborate with business and security stakeholders to list specific security needs, such as encryption standards, authentication mechanisms, and regulatory compliance obligations. This ensures security becomes a measurable acceptance criterion, not an opinion.
2. **Perform Threat Modelling** — In the design phase, use a structured framework like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to visualise how an attacker might abuse the system. This process yields a prioritised list of countermeasures and informs architectural decisions.
3. **Apply Secure Coding Practices** — During development, programmers adhere to secure coding guidelines—such as input validation, output encoding, and parameterised queries—to prevent common vulnerabilities. Integrate SAST tools into the developer’s environment to catch flaws as code is written, and enforce peer code reviews.
4. **Conduct Multi-Layer Security Testing** — In the testing phase, combine DAST scans that attack the running application, software composition analysis that checks third-party components, and manual penetration testing. Every finding is tracked and remediated according to a risk-based severity ranking.
5. **Deploy Securely and Monitor Continuously** — Before going live, harden configurations, enable comprehensive logging, and integrate with identity systems like Microsoft Entra ID. After deployment, continuous monitoring and a practised incident response plan ensure that anomalies are detected and contained quickly, transforming security into an operational function.

## Comparisons

### SAST (Static Analysis) vs DAST (Dynamic Analysis)

**SAST (Static Analysis):**
- Analyses source code or binaries without executing the program
- Performed early in development, often inside the IDE
- Discovers coding errors like SQL injection in the actual code logic

**DAST (Dynamic Analysis):**
- Tests a live, running application by sending crafted inputs
- Performed later, once a working build is available in a test environment
- Discovers runtime issues like authentication bypasses or exposed endpoints

### Shift Left Security vs Traditional Final Pen Test

**Shift Left Security:**
- Security activities start at requirements and design stage
- Minimises rework because flaws are caught when changes are cheap
- Involves the whole team throughout the SDLC

**Traditional Final Pen Test:**
- Security check happens just before deployment as a one-off event
- Fixes are expensive and can delay release if critical flaws are found
- Often performed by an external team without developer involvement

### DevSecOps vs DevOps without Security Focus

**DevSecOps:**
- Automated security scans (SAST, DAST, SCA) are part of the CI/CD pipeline
- Security is a shared responsibility from code commit to production monitoring
- Failed security checks block the pipeline, enforcing a quality gate

**DevOps without Security Focus:**
- Pipeline focuses on speed and functional testing, potentially bypassing security
- Security is often a separate, slower process outside the delivery workflow
- Vulnerabilities may reach production because checks are not automated

### Threat Modelling (e.g., STRIDE) vs Code Review

**Threat Modelling (e.g., STRIDE):**
- Occurs during design, before coding starts
- Identifies architectural weaknesses and potential attack paths
- Uses structured frameworks to categorise threats systematically

**Code Review:**
- Happens during or after coding
- Finds implementation bugs like off-by-one errors or insecure function calls
- Relies on human reviewers or static analysis tools line by line

## Diagram

_The SDLC phases with integrated security activities that shift left across the lifecycle._

```mermaid
flowchart TD
    A[Planning: Security Requirements] --> B[Design: Threat Modelling]
    B --> C[Development: Secure Coding & SAST]
    C --> D[Testing: DAST & Pen Testing]
    D --> E[Deployment: Secure Config & Monitoring]
    E --> F[Maintenance: Patch & Incident Response]
    F --> A
```

## Common misconceptions

- **Misconception:** A penetration test just before launch is sufficient to secure an application. **Reality:** Penetration testing finds only a snapshot of runtime vulnerabilities and cannot fix design flaws introduced months earlier. Security must be integrated into every SDLC phase. (Many organisations still treat security as a final checkbox. The exam explicitly tests the principle that early integration reduces risk and cost.)
- **Misconception:** Static analysis and dynamic analysis are basically the same thing. **Reality:** Static analysis reads code without running it (like proofreading a contract); dynamic analysis interacts with a live application (like a physiotherapist testing your reflexes). (The names sound similar and both find vulnerabilities, but the timing, access, and types of flaws they detect are drastically different.)
- **Misconception:** Only security engineers are responsible for security during development. **Reality:** Security is everyone’s responsibility. Developers must write secure code, testers must build security test cases, and operations must harden the production environment. (Old silo-ed models put security on a separate team. CISSP emphasises a shared-responsibility culture, especially in DevSecOps environments.)
- **Misconception:** Adding security steps always slows down software delivery. **Reality:** When integrated early and automated through DevSecOps, security can shorten delivery times by preventing costly late-stage rework and emergency patches. (Misconception stems from traditional waterfall projects where security only appeared at the end. Modern tooling makes security fast and frictionless.)
- **Misconception:** Using a cloud platform like Azure means the cloud provider secures my application code. **Reality:** Cloud providers operate under a shared responsibility model. They secure the underlying infrastructure, but you are responsible for securing your code, configurations, and data—including identity protection with services like Microsoft Entra ID. (Beginners often misinterpret cloud security boundaries and ignore application-level controls, assuming the provider handles everything.)

## Key takeaways

- Security must be integrated into every phase of the Software Development Life Cycle, not added as a final test.
- Shifting left—moving security activities earlier in the timeline—dramatically reduces the cost and impact of fixing vulnerabilities.
- Static Application Security Testing (SAST) analyses source code without execution, while Dynamic Application Security Testing (DAST) tests a running application.
- Threat modelling (e.g., STRIDE) identifies and prioritises potential threats during the design phase, before any code is written.
- DevSecOps automates security checks within the continuous integration and delivery pipeline, making security a shared and transparent process.
- Secure coding standards, input validation, and proper error handling are frontline defences against common attacks like injection and cross-site scripting.
- The shared responsibility model means even in the cloud, you must secure your application, data, and identities using tools such as Microsoft Entra ID for access management.

## FAQ

**What exactly is the difference between SAST and DAST?**

SAST (Static Application Security Testing) inspects source code or binaries without running the program, like a proofreader checking grammar. DAST (Dynamic Application Security Testing) attacks the application while it is running, like a car tester driving the vehicle to find handling issues.

**Why can’t I just run a penetration test before the release date?**

A penetration test uncovers only the vulnerabilities that exist at that specific runtime moment. It cannot fix deep design flaws, and fixing any issues at the last minute is far more expensive and risky than addressing them early in the design or coding stages.

**What is DevSecOps and how does it differ from DevOps?**

DevOps brings development and operations together to speed up delivery. DevSecOps adds security into this partnership, automating security checks so that every code change is scanned for vulnerabilities, compliance, and misconfigurations before it reaches production.

**What does 'shift left' mean in software security?**

Shift left is the practice of moving security activities to the earliest possible point in the development timeline. For example, performing threat modelling during design instead of waiting until testing, which reduces cost and prevents flaws from becoming baked into the system.

**Who is responsible for security during the software development lifecycle?**

Everyone—business analysts, developers, testers, operations staff, and security engineers—shares responsibility. Security teams provide expertise and governance, but each role contributes by following secure practices and raising concerns.

**How does threat modelling actually work in a real project?**

The cross-functional team draws data flow diagrams showing how data moves between components. They then apply a framework like STRIDE to ask 'what could go wrong?' for each flow. The output is a list of threats and the countermeasures that must be built into the design.

## Check your understanding

1. **A development team wants to reduce the cost of fixing security flaws. At which phase of the SDLC should they first integrate threat modelling?**

   Answer: During the design phase, because shifting security left identifies architectural threats before they are implemented in code, significantly lowering remediation cost.

2. **What type of security testing reviews source code without executing the program?**

   Answer: Static Application Security Testing (SAST). It finds vulnerabilities like SQL injection by inspecting the code’s logic, syntax, and data flows.

3. **During a project, automated security checks run on every code commit and block the pipeline if a high-severity issue is found. What cultural and technical approach does this illustrate?**

   Answer: DevSecOps, which integrates security automation directly into the continuous integration and delivery pipeline, making security a shared and continuous process.

4. **Which framework uses the categories Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege to identify threats?**

   Answer: The STRIDE threat modelling framework. Each letter corresponds to a category of threat that should be analysed during the design phase.

5. **A financial application is being migrated to the cloud. The security manager says the cloud provider is now solely responsible for all security. Is this correct?**

   Answer: No. Cloud services operate under a shared responsibility model. The provider secures the physical infrastructure, but the organisation must secure its own application code, data, and access controls, including using identity services like Microsoft Entra ID.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/isc2-cissp/software-development-security