Secure SDLC and Security Code Review

Secure SDLC: Building Security In, Not Bolting It On

The traditional approach to application security treats it as a final gate before release — a penetration test or security review that happens after development is complete. This approach is expensive, slow, and ineffective. Fixing a security flaw found in production costs 100x more than fixing it during design. The Secure Software Development Lifecycle (Secure SDLC) integrates security activities into every phase of development, from requirements to deployment.

The Cost of Late-Stage Security

These ratios, originally from IBM Systems Sciences Institute, have been validated repeatedly. A design flaw (e.g., missing authorization on object references) is a conversation during design, a code change during implementation, a test case during testing, and an emergency patch with potential data breach in production.

Phases of a Secure SDLC

1. Requirements

• Define security requirements alongside functional requirements
• Identify regulatory and compliance requirements (PCI-DSS, HIPAA, GDPR)
• Define data classification (public, internal, confidential, restricted)
• Establish security acceptance criteria for user stories

2. Design

• Threat modeling: identify attack surfaces, trust boundaries, and potential threats
• Security architecture review: authentication, authorization, data flow, encryption
• Select security controls based on identified threats
• Document security assumptions and trust boundaries

3. Implementation

• Secure coding standards and guidelines
• Static Application Security Testing (SAST) in the IDE and CI/CD
• Dependency scanning for known vulnerabilities
• Security-focused code review

4. Testing

• Dynamic Application Security Testing (DAST)
• Penetration testing for high-risk applications
• Security regression testing
• Fuzz testing for input validation

5. Deployment

• Infrastructure security scanning (container images, cloud configuration)
• Web Application Firewall (WAF) configuration
• Security monitoring and alerting setup
• Incident response plan

6. Operations

• Continuous monitoring and logging
• Vulnerability management and patching
• Incident response and forensics
• Periodic penetration testing and red team exercises

Threat Modeling

Threat modeling is the systematic process of identifying and mitigating security threats before code is written. The most common framework is STRIDE, developed by Microsoft:

Threat modeling process:

1. Diagram the system: Data flow diagrams showing components, data stores, and trust boundaries
2. Identify threats: Apply STRIDE to each element and trust boundary
3. Rate threats: Use DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) to prioritize
4. Mitigate: Design controls for each high-priority threat
5. Validate: Verify that mitigations are implemented correctly

Security Testing Layers and Code Review Practices

No single security testing method catches all vulnerabilities. SAST, DAST, and manual code review each cover different layers, and a mature security program uses all three.

Static Application Security Testing (SAST)

SAST tools analyze source code, bytecode, or binary code without executing the application. They identify patterns associated with vulnerabilities:

• SQL injection (string concatenation in queries)
• Hardcoded credentials
• Weak cryptography (MD5, DES, short key lengths)
• Path traversal (unsanitized file paths)
• Command injection (unsanitized input to exec, system)

Advantages:

• Catches vulnerabilities early (in IDE or CI/CD)
• Provides exact line numbers and code context
• Scales to large codebases
• Can enforce coding standards

Limitations:

• High false-positive rate (especially for data flow analysis)
• Cannot detect runtime vulnerabilities (authentication bypass, business logic flaws)
• Language-specific (each tool supports specific languages)
• Cannot analyze configuration or infrastructure

Tools: SonarQube, Semgrep, Checkmarx, Bandit (Python), ESLint security plugins

# Semgrep — lightweight SAST with custom rules
semgrep --config=auto --config=custom-rules/ src/

# Bandit — Python-specific SAST
bandit -r ./src -f json -o bandit-report.json

Dynamic Application Security Testing (DAST)

DAST tools test a running application from the outside, simulating attacker behavior:

• Fuzzing input fields with malicious payloads
• Testing for injection vulnerabilities (SQL, XSS, command)
• Analyzing authentication and session management
• Checking security headers and configurations
• Testing access control by attempting unauthorized actions

Advantages:

• Tests the actual running application (including configuration)
• Detects runtime vulnerabilities that SAST cannot
• Language-agnostic (tests the HTTP interface)
• Finds business logic flaws through workflow testing

Limitations:

• Cannot identify exact code locations (only the vulnerable endpoint)
• Requires a running application
• May miss vulnerabilities in unlinked or hidden endpoints
• Can be slow for large applications

Tools: OWASP ZAP, Burp Suite Professional, Acunetix, Nikto

# OWASP ZAP — automated DAST scan
zap-baseline.py -t https://example.com -r zap-report.html

Penetration Testing

Penetration testing is a manual, human-driven assessment that simulates a real attacker:

• Combines automated tools with manual exploitation
• Tests business logic flaws that automated tools miss
• Validates the effectiveness of security controls
• Provides a realistic assessment of risk

When to use:

• Before major releases
• After significant architecture changes
• For high-risk applications (financial, healthcare)
• Periodically (annually or semi-annually)

Security Code Review

Security code review is the manual examination of code changes for security flaws. It is the most effective way to catch business logic vulnerabilities and design flaws that automated tools miss.

What to look for in code review:

1. Authentication: Are credentials verified on every request? Is the session token validated?
2. Authorization: Is the user authorized for this specific action on this specific object?
3. Input validation: Is all user input validated at the trust boundary?
4. Output encoding: Is data encoded for the correct output context?
5. Cryptography: Are strong algorithms used? Are keys managed securely?
6. Error handling: Do error messages leak sensitive information?
7. Logging: Are security-relevant events logged? Are secrets redacted?

Scaling code review with security champions:

A security champion is a developer within a product team who has additional security training and serves as the first line of security review. Security champions:

• Review code for security flaws before it reaches the central security team
• Advocate for secure coding practices within their team
• Escalate complex security issues to the central security team
• Scale security review beyond what a central team can handle alone

Practice: Threat Model a Feature

Threat model a new feature: a file upload service that allows users to upload profile pictures. The images are stored in cloud storage and served via a CDN. Use STRIDE to identify threats.