Simpro Knowledge Base

Secure Development Lifecycle

Secure Development Lifecycle visual map

Purpose

The Secure Development Lifecycle, or SDL, is the practice of building security into every stage of software delivery.

The old model says: build the feature, test it, then ask security to inspect it. The modern model says: understand risk early, design secure defaults, automate checks, and verify continuously.

Secure SDLC Stages

Stage Security Practice
Idea/discovery Identify sensitive data, compliance needs, abuse cases, and business risk
Requirements Add security and privacy requirements alongside functional requirements
Design Threat model important flows and choose controls
Implementation Follow secure coding standards and use approved libraries
Review Review code, dependencies, secrets, IaC, auth, logging, and error handling
Testing Run SAST, SCA, secrets scanning, DAST/API tests, and manual abuse-case testing
Release Verify configuration, deployment permissions, TLS, monitoring, and rollback
Operations Patch, monitor, respond to incidents, and review vulnerabilities
Learning Feed incidents, audits, and near-misses back into standards and training

Security Requirements

Security requirements should be explicit. Examples:

  • Only authorized users can access customer records.
  • Administrative actions must be logged.
  • Tokens must expire and be revocable.
  • Passwords must never be stored in plain text.
  • Sensitive fields must not appear in logs.
  • File uploads must be scanned and size-limited.
  • APIs must enforce rate limits.
  • Backups must be encrypted.
  • Critical systems must have monitored health and alerts.

Definition Of Ready

Before starting sensitive work, ask:

  • What data is involved?
  • Who should access it?
  • What are the abuse cases?
  • What third-party services are involved?
  • What secrets or certificates are needed?
  • What logs/metrics/alerts are required?
  • What security tests should be added?

Definition Of Done

For security-relevant features:

  • Access control is implemented and tested.
  • Input validation is present at trust boundaries.
  • Sensitive data is protected in transit and at rest.
  • Secrets are not in code, config files, logs, or tickets.
  • Dependencies are scanned.
  • Error messages do not leak internals.
  • Audit logs exist for important actions.
  • Threat model assumptions are captured.
  • Release configuration is reviewed.

Secure Coding Baselines

Developers should routinely check:

  • Broken access control.
  • Injection risks.
  • Cryptographic failures.
  • Insecure design.
  • Security misconfiguration.
  • Vulnerable dependencies.
  • Authentication/session weaknesses.
  • Insecure deserialization or unsafe parsing.
  • Missing security logging and monitoring.
  • Server-side request forgery.

These map closely to OWASP Top 10 categories.

Secure Design Habits

  • Make the secure path the default path.
  • Deny by default.
  • Use least privilege.
  • Validate input at boundaries.
  • Encode output in the right context.
  • Avoid custom crypto.
  • Keep secrets out of source control.
  • Log security-relevant events.
  • Fail safely.
  • Design for patching and recovery.

Security In Agile/Kanban

Security work should be visible in normal planning:

  • Security acceptance criteria.
  • Abuse stories.
  • Threat-model tasks.
  • Security test tasks.
  • Vulnerability remediation work.
  • Security debt items.
  • Incident follow-up actions.

Security debt is still debt. It also charges emotional interest during audits and incidents.

Team Reference Guide

Guidelines For Teams

  • Add security requirements to stories where risk exists.
  • Include security in design reviews and PR reviews.
  • Automate repeatable checks in CI/CD.
  • Track vulnerabilities as normal work with owner and due date.
  • Convert repeated issues into standards, templates, or tests.

Reflection Questions

  • Which current feature should have had a threat model earlier?
  • What security check happens too late today?
  • What secure default can the platform provide for every team?
  • What vulnerability pattern keeps repeating?

Further Study

  • NIST SSDF SP 800-218: https://csrc.nist.gov/pubs/sp/800/218/final
  • Microsoft SDL: https://www.microsoft.com/en-us/securityengineering/sdl/
  • OWASP SAMM: https://owasp.org/www-project-samm/
  • OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
  • OWASP Secure Coding Practices Checklist: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/