Secure SDLC Implementation Guide: Security at Every Phase of Development

Security requirements define what the software must do (and must not do) from a security perspective. Without them, developers build features without knowing the security constraints.

Security requirements sources:

• Regulatory and compliance: PCI DSS, HIPAA, GDPR, SOC 2 -- each mandates specific technical controls (encryption, access logging, data retention)
• Organizational security policy: Approved algorithms, prohibited functions (no MD5, no SHA-1, no eval())
• Business risk: What happens if this feature is compromised? Data breach, financial fraud, service disruption?
• User trust model: Who uses this feature? Internal employees vs. anonymous public users have different threat models

Application risk classification:

Classify each application to determine the intensity of security controls required:

Security user stories:

Capture security requirements as user stories in your backlog:

• "As the security team, we need all authentication events logged with user ID, IP, timestamp, and outcome so that we can detect and investigate anomalous access."
• "As a user, my session token must expire after 30 minutes of inactivity so that my account cannot be accessed from an unattended device."
• "As the compliance team, all credit card data must be encrypted with AES-256 at rest using a KMS-managed key so that stolen database files cannot expose PAN."

Security user stories prevent security requirements from being treated as optional -- they are tracked in the same backlog as features and must be accepted by the same definition of done.

Threat modeling identifies how an attacker might abuse your design before a line of code is written. In an agile environment, it should happen at two levels: a high-level model at project kickoff and lightweight feature-level modeling per sprint.

Threat modeling at project kickoff (STRIDE):

STRIDE is the most widely used enterprise threat modeling framework. For each data flow in your architecture diagram, ask:

Tools for threat modeling:

• OWASP Threat Dragon: Free, web-based, produces DFDs with threats annotated
• Microsoft Threat Modeling Tool: Free, Windows-based, STRIDE-focused with automated threat suggestions
• IriusRisk: Commercial, integrates with Jira, generates requirements automatically from architecture diagrams
• Threagile: Open-source, YAML-based, generates threat models as code (ideal for DevSecOps pipelines)

Lightweight sprint-level threat modeling:

For each new significant feature in a sprint, run a 30-minute threat model session:

1. Draw a simple data flow diagram (5-10 minutes)
2. Walk through each data flow and ask "what is the worst thing an attacker can do here?" (15 minutes)
3. Create security user stories for each finding (10 minutes)

This catches design-level issues before implementation and typically takes less time than the code review that would find the same issues later.

Secure coding standards define the implementation-level rules developers must follow. The most effective standards are language-specific, integrated into the IDE, and enforced automatically in CI.

Security-relevant coding rules by category:

Input validation and output encoding:

• Validate all input against an allowlist (not a denylist)
• Parameterize all database queries -- never concatenate user input into SQL
• Encode all output in the correct context (HTML encoding, JavaScript encoding, URL encoding)
• Validate file uploads: type, size, filename, content

Authentication and session management:

• Use established libraries for authentication -- never implement custom auth
• Store passwords with Argon2id (preferred), bcrypt (acceptable), or scrypt -- never with MD5, SHA-1, or unsalted SHA-256
• Generate session tokens with cryptographically secure random number generators (CSPRNG)
• Invalidate sessions on logout and privilege change

Cryptography:

• Use AES-256-GCM for symmetric encryption -- never implement custom ciphers
• Use the platform TLS implementation for transport security -- never roll your own
• Never hard-code secrets, keys, or passwords in source code
• Use secure key storage (KMS, Vault) -- never store keys in application config files

Error handling:

• Return generic error messages to users; log detailed errors server-side with correlation IDs
• Never expose stack traces, database errors, or internal paths to users

IDE and pre-commit security:

Enforce security rules before code is committed:

# Semgrep pre-commit hook (catches security anti-patterns at save time)
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/returntocorp/semgrep
    rev: 'v1.70.0'
    hooks:
      - id: semgrep
        args: ['--config', 'p/security-audit', '--config', 'p/owasp-top-ten', '--error']

# Install and run
pip install pre-commit
pre-commit install
pre-commit run --all-files

Automated security testing in CI/CD provides continuous feedback without requiring manual security reviews for every pull request.

SAST (Static Application Security Testing):

SAST analyzes source code for security vulnerabilities without executing it. Best integrated at the pull request stage to catch issues before merge.

GitHub Actions SAST pipeline (Semgrep + CodeQL):

name: Security Scan
on: [pull_request]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/owasp-top-ten
            p/secrets
          auditOn: push
  codeql:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript, python
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

SCA (Software Composition Analysis):

SCA identifies vulnerable open-source dependencies. Run on every dependency update and in CI.

# Trivy for dependency scanning
trivy fs --scanners vuln --severity HIGH,CRITICAL .

# Snyk for developer-friendly output with remediation suggestions
snyk test --severity-threshold=high

# OWASP Dependency-Check (free, supports Java, .NET, Node, Python)
dependency-check.sh --project "MyApp" --scan ./

DAST (Dynamic Application Security Testing):

DAST tests the running application from the outside, finding runtime vulnerabilities that SAST misses (authentication bypass, session management, business logic flaws).

Integrate DAST in a staging environment as part of the deployment pipeline:

# OWASP ZAP baseline scan against staging
docker run -v $(pwd):/zap/wrk/:rw   ghcr.io/zaproxy/zaproxy:stable zap-baseline.py   -t https://staging.yourapp.com   -r zap-report.html   -x zap-report.xml   -I  # ignore warnings, only fail on errors

# ZAP full scan (more thorough, slower)
docker run ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py   -t https://staging.yourapp.com   -r full-scan-report.html

Security gate thresholds:

Automated tooling catches common vulnerability classes but misses business logic flaws, complex authentication bypasses, and chained attack scenarios. Manual security testing fills this gap.

Security testing types by SDLC phase:

Penetration testing cadence by application tier:

Pre-pentest checklist:

Before engaging an external pentest firm:

• SAST and SCA findings are triaged and critical/high issues remediated or risk-accepted
• Staging environment matches production architecture (same auth flows, same services)
• Test accounts are provisioned at each privilege level (unauthenticated, regular user, admin)
• Scope document defines in-scope URLs, endpoints, IP ranges, and out-of-scope systems
• Rules of engagement define testing hours and contact procedures

Tracking findings through remediation:

All security findings (from any tool or manual test) should enter a unified tracking system (Jira, DefectDojo, or ThreadFix) with:

• Severity and CVSS score
• SLA for remediation by severity tier (Critical: 24h, High: 7d, Medium: 30d, Low: 90d)
• Owner (the development team responsible for the component)
• Risk acceptance workflow for findings that cannot be remediated within SLA

SSDLC programs need metrics to demonstrate progress and identify gaps.

OWASP SAMM (Software Assurance Maturity Model):

SAMM provides a framework for measuring SSDLC maturity across 5 business functions and 15 security practices, each scored 0-3:

Run a SAMM assessment annually. Target progression: Level 1 (baseline controls) in Year 1; Level 2 (structured program) in Year 2-3; Level 3 (optimized, measured) for organizations with dedicated AppSec teams.

Key metrics for SSDLC reporting: