Secure Development Lifecycle

The Secure Development Lifecycle (SDL) is a process that integrates security practices into every phase of software development — from requirements gathering to deployment and maintenance. Rather than treating security as an afterthought or a final review gate, the SDL embeds security thinking throughout the entire development process.

---

Why a Secure Development Lifecycle?

The cost of fixing security vulnerabilities increases exponentially the later they are discovered:

Phase Discovered	Relative Cost to Fix
Requirements/Design	1x
Development/Coding	5x
Testing/QA	10x
Production	30x–100x

Finding and fixing a vulnerability during design is far cheaper than responding to a breach in production. The SDL aims to shift security left — addressing it as early as possible.

---

SDL Phases

Phase 1: Security Requirements

Define security requirements alongside functional requirements:

Activity	Description
Identify sensitive data	What data does the application handle? How must it be protected?
Define access control requirements	Who can access what? What roles and permissions are needed?
Regulatory compliance	What regulations apply (GDPR, PCI DSS, HIPAA, etc.)?
Security user stories	Write stories from an attacker's perspective (abuse cases)
Baseline security standards	Define minimum security requirements (authentication, encryption, logging)

Example security user stories:

As a malicious user, I want to access other users' data by manipulating API parameters,
so that I can steal personal information.

Acceptance criteria:
- All API endpoints enforce authorisation checks
- Users cannot access resources belonging to other users
- Access control failures are logged and monitored

---

Phase 2: Threat Modelling

Threat modelling is the process of identifying threats, attack vectors, and security controls during the design phase.

STRIDE Model

STRIDE categorises threats into six types:

Threat	Description	Example
S — Spoofing	Pretending to be someone else	Using stolen credentials to log in
T — Tampering	Modifying data or code	Altering a price in a hidden form field
R — Repudiation	Denying an action occurred	Claiming a transaction was never made
I — Information Disclosure	Exposing data to unauthorised parties	Error messages revealing database structure
D — Denial of Service	Making the system unavailable	Flooding the API with requests
E — Elevation of Privilege	Gaining higher access than permitted	Exploiting a bug to become an admin

Threat Modelling Process

1. Define the scope (what are we modelling?)
2. Create a Data Flow Diagram (DFD)
3. Identify threats using STRIDE for each DFD element
4. Rate each threat (likelihood × impact)
5. Define mitigations for each threat
6. Validate mitigations are implemented

Data Flow Diagram Elements

Element	Symbol	Example
External entity	Rectangle	User, third-party API
Process	Circle	Web server, API handler
Data store	Parallel lines	Database, file system
Data flow	Arrow	HTTP request, database query
Trust boundary	Dashed line	Internet/DMZ, DMZ/internal network

---

Phase 3: Secure Design

Apply security design patterns and principles:

Principle	Application
Defence in depth	Layer multiple security controls; do not rely on a single mechanism
Least privilege	Grant minimum necessary permissions to users, processes, and services
Separation of duties	No single user should have end-to-end control of a critical process
Secure defaults	Ship with the most secure configuration by default
Fail securely	When errors occur, deny access rather than grant it
Don't trust user input	Validate and sanitise all input from external sources
Minimise attack surface	Remove unnecessary features, endpoints, and services

Architecture Review Checklist

Area	Questions
Authentication	How are users authenticated? Is MFA supported?
Authorisation	How are permissions enforced? Is there role-based access control?
Data protection	How is sensitive data encrypted in transit and at rest?
Input handling	How are all forms of user input validated and sanitised?
Error handling	Do error messages leak sensitive information?
Logging	What security events are logged? Where are logs stored?
Third-party components	What external libraries and services are used? How are they secured?

---

Phase 4: Secure Coding

Follow secure coding practices during implementation:

Secure Coding Guidelines