Secure Development Lifecycle (SDL): Building Security into the Development Process

Why security cannot be bolted on after the fact

Most security vulnerabilities in software are not caused by sophisticated attacks but by avoidable development mistakes: missing input validation, insecure default configurations, hardcoded credentials, missing authentication on API endpoints, or outdated libraries with known vulnerabilities.

Finding and fixing these mistakes after the fact is laborious and expensive. Studies show that the cost of remediating a security vulnerability increases exponentially the later it is discovered in the development process. A vulnerability addressed during the design phase costs a fraction of what a fix after the production release costs, when patches must be developed, tested, distributed, and deployed at customer sites.

A Secure Development Lifecycle (SDL) inverts the logic: instead of checking security at the end, it is built into the process from the start. Each development phase includes security activities that ensure vulnerabilities are detected and prevented early.

The phases of a Secure Development Lifecycle

An SDL consists of security activities mapped to the standard development phases. The model originated with Microsoft, which introduced the SDL in the early 2000s following its "Trustworthy Computing" initiative. It has since been adapted and evolved many times.

Phase 1: Requirements

In the requirements phase, security requirements are defined alongside functional requirements. This sounds obvious but is surprisingly often forgotten. Functional requirements describe what the software should do ("The user can log in with email and password"). Security requirements describe how the software protects itself against misuse ("Passwords are hashed with bcrypt, brute force attempts are blocked after 5 failed attempts for 15 minutes, sessions expire after 30 minutes of inactivity").

Typical security requirements include authentication and authorization (who is allowed to do what?), data encryption (in transit and at rest), input validation (what inputs are permitted?), logging and monitoring (what is recorded?), data protection and DSGVO (GDPR) compliance (what personal data is processed?), and compliance requirements (industry-specific regulations, NIS2, ISO 27001).

Practical tip: Create a checklist of standard security requirements that is reviewed for every project. This costs 30 minutes per project and prevents basic security aspects from being overlooked.

Phase 2: Design

In the design phase, the software architecture is created. This is where the most important security activity of the entire SDL takes place: Threat Modeling.

Threat Modeling

Threat Modeling is a structured process in which you analyze your application's architecture and systematically search for potential threats. The result is a list of threats and countermeasures that feed into the design.

The best-known threat modeling framework is STRIDE (from Microsoft), which defines six categories of threats:

• Spoofing (identity impersonation): Can someone pose as a different user or system?
• Tampering (data manipulation): Can someone alter data they should not be able to change?
• Repudiation (deniability): Can someone perform an action and later deny it?
• Information Disclosure: Can confidential data reach unauthorized parties?
• Denial of Service: Can someone impair system availability?
• Elevation of Privilege: Can someone gain higher privileges than intended?

For each component and data flow in your architecture, you walk through the STRIDE categories and ask: is this threat relevant here? If so, what countermeasure do we implement?

Practical tip: You do not need to threat-model every function. Focus on the critical areas: authentication, authorization, data flows involving personal data, interfaces to external systems, and areas where users provide input.

Secure architecture patterns

The design should incorporate established security patterns. Defense in Depth means not trusting a single security measure but layering multiple defenses. If the firewall fails, input validation protects. If input validation is bypassed, the database permission structure protects. Least Privilege means equipping components and users with the minimum necessary permissions. Fail Secure means the system defaults to a safe state on failure, not an open one. Secure Defaults means the default configuration is secure, and the user must actively disable security measures rather than enable them.

Phase 3: Implementation

In the implementation phase, code is written. Security activities here aim to prevent common programming errors.

Secure Coding Guidelines

Create Secure Coding Guidelines for the programming languages and frameworks used by your team. These guidelines describe how to avoid common vulnerability classes.

For web applications, the most important topics are input validation (every input is treated as potentially malicious and validated), SQL injection prevention (exclusively parameterized queries, never string concatenation), cross-site scripting prevention (output encoding, Content Security Policy), authentication (secure password storage, session management, MFA integration), authorization (server-side validation on every request, not just in the frontend), and error handling (no stack traces or internal details in user-facing error messages).

Use the OWASP Cheat Sheet Series as a foundation -- the OWASP Top 10 provide a good starting point. They deliver concrete, language-specific guidance for all common vulnerability classes.

Code reviews with a security focus

Code reviews are one of the most effective quality assurance measures, including for security. Supplement your code review checklist with security aspects. On every review, check whether inputs are validated, whether database queries are parameterized, whether authentication and authorization are correctly implemented, whether error handling does not expose sensitive information, whether no credentials or secrets are in the code, and whether external libraries are current and free from known vulnerabilities.

Phase 4: Verification (Testing)

In the testing phase, automated and manual security tests are performed.

Static Application Security Testing (SAST)

SAST tools analyze source code without executing it. They search for known vulnerability patterns such as SQL injection, XSS, buffer overflows, or insecure cryptography. SAST is ideally integrated into the CI/CD pipeline and runs on every commit or pull request.

Common SAST tools include SonarQube (open source, multi-language, good dashboard), Semgrep (open source, rule-based, lightweight, well-suited for CI/CD), Checkmarx (enterprise, very comprehensive, high price), and CodeQL (by GitHub, free for open source projects, very capable).

Practical tip: Start with SonarQube or Semgrep. Both are open source, easy to set up, and deliver useful results without weeks of configuration. Initially enable only high-priority rules to keep the false-positive rate low.

Dynamic Application Security Testing (DAST)

DAST tools test the running application from the outside, as an attacker would. They send manipulated requests and analyze responses for vulnerabilities. DAST finds vulnerabilities that SAST cannot detect, such as missing HTTP security headers, insecure web server configurations, or authentication issues.

Common DAST tools include OWASP ZAP (open source, the de facto standard for automated web application scanning), Burp Suite (professional version is paid, very capable, preferred by penetration testers), and Nuclei (open source, template-based, very fast and flexible).

Penetration Testing

For critical applications, manual penetration testing by external specialists is recommended. Automated tools find many but not all vulnerabilities. An experienced tester also recognizes logical vulnerabilities (e.g., "User A can view User B's orders by changing the order ID in the URL") that automated tools cannot find.

Penetration tests should be performed at least annually and after significant changes for business-critical applications. In ISMS Lite, the entire SDL policy with checkpoints, scan results, and approvals can be documented and evidenced for audits.

Phase 5: Release and deployment

Before release, verify that all security requirements have been met and all identified vulnerabilities have been remediated or consciously accepted.

Secure CI/CD pipeline

The CI/CD pipeline itself must be secured. A compromised pipeline is a perfect attack vector because it has direct access to the production system.

Security measures for the pipeline include access control (who may modify pipeline configurations?), secrets management (no credentials in pipeline configurations; use vault integration instead), signed commits (only verified code is deployed), container image scanning (if you use containers: scan images for vulnerabilities before deployment), and infrastructure-as-code scanning (check Terraform, CloudFormation for misconfigurations).

Release checklist

Create a release checklist that is reviewed before every production deployment. The checklist includes items such as: SAST scan with no critical or high findings? DAST scan with no critical findings? Dependency scan with no known vulnerabilities in critical libraries? Security review for new features completed? Documentation updated (especially API documentation)? Rollback plan in place?

Phase 6: Maintenance and operations

After release, security work does not end. In the operations phase, the focus is on promptly remediating newly discovered vulnerabilities and continuously monitoring security posture.

Vulnerability Management: Establish a process to detect and promptly patch new vulnerabilities in your dependencies (libraries, frameworks, operating system). Dependency scanning tools like Dependabot, Renovate, or Snyk help with this.

Incident Response: Define how security incidents are handled. Who is notified when a vulnerability is found in production? How quickly must a patch be deployed? Who communicates with affected customers?

Monitoring: Monitor your application for suspicious activity. Unusual login patterns, elevated error rates, unexpected API calls can indicate an attack.

SDL for SMEs: starting pragmatically

A full SDL following Microsoft's model is not realistic for a small development team of 5 to 10 developers. You need a pragmatic approach that covers the most important security measures without grinding the development process to a halt.

Minimal SDL in three steps

Step 1: Introduce automation (weeks 1-2). Integrate a SAST scanner (SonarQube or Semgrep) and a dependency scanner (Dependabot or Renovate) into your CI/CD pipeline. This is a one-time effort of a few hours and delivers results on every commit from then on.

Step 2: Adapt the code review process (weeks 3-4). Supplement your code review checklist with the most important security aspects. Train the team on the OWASP Top 10. Establish the rule: no merge without code review, and every reviewer also checks for security.

Step 3: Threat modeling for critical features (ongoing). For new critical features (authentication, payment processing, API interfaces), conduct a brief threat modeling session. 30 to 60 minutes per feature is sufficient when using the STRIDE framework as a guide.

These three steps cover the majority of security risks and are implementable within one month.

SDL maturity levels

You can expand your SDL incrementally. Level 1 (Basic) includes automated scans (SAST, Dependency Scanning), code reviews, and Secure Coding Guidelines. Level 2 (Advanced) adds threat modeling for critical features, DAST scans before releases, and a release checklist with security aspects. Level 3 (Mature) adds penetration tests, formal threat modeling for all new features, security champions in the development team, and a bug bounty program.

For most mid-market companies, Level 2 is a realistic and sufficient goal.

Security Champions: embedding security in the team

A Security Champion is a developer on the team who is particularly interested in security topics and serves as the point of contact for security questions. They are not a full-time security expert but a developer who, in addition to their regular tasks, builds and shares security knowledge.

The duties of a Security Champion include participating in threat modeling sessions, conducting code reviews with a security focus, evaluating findings from automated scans, sharing security knowledge with the team (e.g., brief presentations on current vulnerabilities), and representing the team in cross-functional security committees.

The Security Champion model works particularly well in organizations with multiple development teams. Instead of having a central security team perform all reviews (bottleneck), you distribute security responsibility to the teams. This scales better and brings security knowledge to where the code is written.

Common mistakes when introducing an SDL

Too much at once: Attempting to introduce all SDL phases simultaneously overwhelms the team and generates resistance. Start with automated measures (SAST, Dependency Scanning) that require no additional manual effort, and expand incrementally.

Security as a blocker: If every security scan blocks the build for hours or every security requirement delays the release by weeks, the team will view the SDL as an obstacle and find ways around it. Security measures must integrate into the development flow, not work against it.

Tools only, no culture: Tools find vulnerabilities but do not fix them. If nobody processes the findings or learns from the mistakes, the best SAST scanner delivers no value. Invest at least as much in training and culture as in tooling.

Lacking management support: An SDL requires time and resources. If management only prioritizes features and considers security secondary, the SDL will fail. Secure executive commitment before introducing the SDL. NIS2 requirements and personal liability of executive management are often convincing arguments.

SDL and regulatory requirements

NIS2

NIS2 Article 21 paragraph 2(e) requires "security measures in the acquisition, development, and maintenance of network and information systems, including vulnerability handling and disclosure." A documented SDL is the evidence that you meet this requirement.

ISO 27001

Annex A, Control A.8.25 (Secure development lifecycle), explicitly requires that rules for the secure development of software and systems are established and applied. Control A.8.26 (Application security requirements) requires that security requirements are identified, specified, and approved.

OWASP SAMM

If you want to measure and systematically improve your SDL maturity, the OWASP Software Assurance Maturity Model (SAMM) is a good framework. SAMM defines maturity levels for various security practices and helps you set priorities.

Tools and resources

OWASP Cheat Sheet Series: Concrete, language-specific guidance for secure development. Freely available at cheatsheetseries.owasp.org.

OWASP ASVS (Application Security Verification Standard): A framework with security requirements at three levels that you can use as a checklist for your application.

Microsoft SDL Practices: Microsoft's official SDL documentation, which describes individual practices in detail. Good as a reference, even if you do not implement the full Microsoft SDL.

NIST SSDF (Secure Software Development Framework): A NIST framework describing practices for secure software development. Less detailed than Microsoft's SDL but good as an overarching framework.

Related articles

• OWASP Top 10 for Developers: Avoiding the Most Common Vulnerabilities
• Container Security: Securing Docker and Kubernetes for SMEs
• API Security: Authentication, Rate Limiting, and Input Validation
• Secrets Management: Securely Managing Passwords, API Keys, and Certificates
• Dependency Scanning: Finding Vulnerabilities in Third-Party Libraries