Describe the secure development lifecycle, including threat modelling, secure coding practices, security testing and ongoing monitoring

What this dot point is asking

NESA wants you to describe security as an integrated part of the whole software development lifecycle, not a checkbox at the end. You need to name the stages, the activities at each stage, and the tools or techniques used.

The answer

The secure development lifecycle (SDLC) integrates security into every phase of software development. Industry frameworks (Microsoft SDL, OWASP SAMM, NIST SSDF) describe slightly different stages, but the structure is broadly:

1. Requirements and design

• Threat modelling: identify what could go wrong using a framework like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege).
• Security requirements: write each threat-mitigation as a testable requirement.
• Reference architectures: use patterns known to be secure (HTTPS everywhere, parameterised queries, MFA, RBAC) rather than reinventing.

2. Implementation

• Secure coding standards: OWASP cheat sheets, CERT guides, language-specific guidance.
• Code review: every change peer-reviewed before merge. Reviewers look for security issues alongside correctness and style.
• Static Application Security Testing (SAST): automated code scanners (Semgrep, SonarQube, GitHub Advanced Security) catch common vulnerabilities and bad patterns.
• Secret scanning: detect API keys or passwords committed to source control.
• Dependency management: lock files, dependency scanners (Dependabot, Snyk), pin versions.

3. Testing

• Unit and integration tests for security-relevant logic (authentication, authorisation, validation).
• Dynamic Application Security Testing (DAST): OWASP ZAP, Burp Suite probe the running app.
• Penetration testing: ethical hackers attempt real attacks. Done by external firms before major releases.
• Fuzz testing: feed random or malformed inputs to find crashes and edge cases.

4. Deployment

• Hardened configuration: minimal services, secure defaults, secret management (AWS Secrets Manager, HashiCorp Vault).
• Infrastructure as code (IaC): reproducible builds, scanned for misconfigurations.
• Signed artefacts: verify integrity of binaries and container images at deploy time.

5. Operation and monitoring

• Centralised logging: capture authentication events, errors, anomalous access.
• Security monitoring: a Security Information and Event Management (SIEM) system aggregates logs and runs detection rules.
• Alerting and incident response: defined playbooks for common incidents (credential leak, suspected breach).
• Patch management: automate dependency updates, apply OS and runtime patches promptly.
• Periodic retesting: rerun the design and test stages against the live system.

Continuous, not linear

In modern practice security activities run continuously, not as a one-off audit at the end. Each pull request triggers SAST scans, dependency scans and code review. Each deploy triggers configuration checks. Each production day generates security logs that feed monitoring.

# Example: a GitHub Actions security stage
# .github/workflows/security.yml
"""
name: Security
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: SAST
        uses: github/codeql-action/analyze@v3
      - name: Dependency scan
        run: pip install pip-audit && pip-audit
      - name: Secret scan
        uses: gitleaks/gitleaks-action@v2
"""