Secure SDLC Guide: Security Requirements, Threat Modeling, and Secure Coding [2026]

Security bolted on after development is architecture debt. A login system that processes authentication but lacks brute-force protection cannot be retrofitted with proper rate limiting and lockout logic without rearchitecting the authentication flow. A file upload feature that processes uploaded content without validating file types cannot be made safe by adding an external scanner — the unsafe processing has already happened. Security requirements that are missing from the design phase become production vulnerabilities that cost orders of magnitude more to fix than they would have cost to prevent.

Secure SDLC (Secure Software Development Lifecycle) integrates security into every phase of software development: requirements gathering, design, implementation, testing, deployment, and maintenance. This is not a checklist to complete once before launch — it is a practice that runs continuously through every development cycle.

This guide covers the full Secure SDLC: security requirements definition, threat modeling methodologies, secure coding standards and SAST integration, dynamic security testing, deployment security controls, and maintenance practices. By the end, you will have a framework for building security requirements into your development process rather than inspecting for security failures at the end.

The Cost Case for Secure SDLC

The cost differential between early and late vulnerability discovery is not theoretical — it is a well-documented empirical pattern.

A vulnerability discovered during design takes hours to address: update the architecture decision, document the control. During implementation, it takes a day: change the code, test the change. During testing, it takes days: identify the root cause, fix the code, retest. In production, it takes weeks: incident response, forensic analysis, remediation, redeployment, and potentially regulatory notification and penalties.

The IBM System Sciences Institute research that is frequently cited places the production-to-design ratio at approximately 100:1. Organizations that have implemented Secure SDLC programs consistently report:

• 40-60% reduction in production security incidents
• Significant reduction in penetration test findings year-over-year
• Faster compliance certification (fewer remediation cycles)

The counter-argument — that Secure SDLC slows development — confuses friction with rigor. Well-implemented Secure SDLC speeds development by preventing the rework cycles that come from discovering security flaws late.

Phase 1: Security Requirements

Security requirements answer the question: "What must this system prevent?" Functional requirements answer "What must this system do?" Both are necessary.

Eliciting security requirements starts from the system's threat landscape:

• What data does this system process? Personal data, financial records, health information, intellectual property?
• Who are the potential attackers? Opportunistic bots, targeted competitors, insider threats, nation-state actors?
• What is the impact of a breach? Data loss, service disruption, regulatory penalty, reputational damage?
• What are the applicable regulatory requirements? GDPR, PCI-DSS, HIPAA, SOC 2?

Security requirements should be specific, testable, and assigned to components. Not "the system must be secure" — but:

• "User authentication must implement account lockout after 5 failed attempts within 15 minutes"
• "All API responses must not include server version information in headers"
• "All PII must be encrypted at rest using AES-256"
• "Password hashes must use bcrypt with minimum cost factor 12"
• "Session tokens must expire after 30 minutes of inactivity"

Each of these requirements can be verified: write a test that checks account lockout behavior, write a test that checks response headers, write a configuration check that verifies encryption settings.

Regulatory mapping: identify which data assets are in scope for which frameworks. A healthcare application processing protected health information (PHI) must meet HIPAA Security Rule requirements. An application processing payment card data must meet PCI-DSS. Mapping requirements to regulatory obligations ensures that compliance work happens during design, not as a retrofitting exercise before an audit.

Phase 2: Threat Modeling

Threat modeling is the systematic practice of identifying how a system can be attacked. It produces a structured analysis of potential attack vectors and the controls needed to address them.

STRIDE Methodology

STRIDE (developed at Microsoft) categorizes threats into six types applied to each component:

S — Spoofing: can an attacker impersonate another user or system? Mitigation: strong authentication, signed tokens, certificate pinning.

T — Tampering: can an attacker modify data in transit or at rest? Mitigation: message signing, integrity checks, audit logging.

R — Repudiation: can a user deny having performed an action? Mitigation: non-repudiation logging, digital signatures.

I — Information Disclosure: can an attacker read data they should not have access to? Mitigation: encryption, access controls, minimal response data.

D — Denial of Service: can an attacker prevent legitimate users from accessing the service? Mitigation: rate limiting, resource quotas, DDoS protection.

E — Elevation of Privilege: can an attacker gain higher-level permissions than they should have? Mitigation: principle of least privilege, authorization checks, privilege separation.

Applying STRIDE to each component produces a structured list of threats, their likelihood and impact, and the controls required. This analysis drives security requirements that would otherwise not be elicited.

Data Flow Diagrams (DFDs)

Threat modeling starts with a data flow diagram that shows:

• External entities (users, third-party services, IoT devices)
• Processes (application components, microservices)
• Data stores (databases, caches, file systems)
• Data flows between them
• Trust boundaries (lines across which privilege levels change)

Trust boundaries are where most attacks occur. A request that crosses from the public internet into an application server, or from an application server into a database, crosses a trust boundary. These crossing points should have explicit security controls.

PASTA: Process for Attack Simulation and Threat Analysis

PASTA provides a more comprehensive seven-stage analysis than STRIDE, incorporating business risk, technical architecture, attacker profiles, and attack pattern matching against the CAPEC (Common Attack Pattern Enumeration and Classification) database. Use PASTA for complex systems with high-value assets where a thorough analysis is warranted. STRIDE is more appropriate for feature-level analysis in Agile sprints.

Threat Modeling in Agile

In Agile development, threat modeling does not require a dedicated two-week sprint — it can run as a two-hour session per significant feature. For each user story that introduces a new data flow, a new authentication requirement, or a new external integration:

1. Draw the data flow for the feature
2. Apply STRIDE to the new components and trust boundaries
3. Add security requirements to the story's acceptance criteria for any threats identified
4. Track remaining threats as security debt if they require architectural changes

This produces security requirements just-in-time, embedded in the development workflow rather than treated as separate work.

Phase 3: Secure Coding Standards

Security requirements and threat models produce specifications. Secure coding standards define how developers implement those specifications correctly.

Input validation: validate all input at the trust boundary. Do not validate only in the UI and rely on that validation having occurred in the backend. Every piece of data that enters the system should be validated for type, format, range, and allowed characters before use.

Validation must be on the allowlist principle (accept only what is explicitly permitted) rather than the denylist principle (reject only what is explicitly forbidden). A denylist cannot anticipate every malicious input; an allowlist rejects everything unexpected.

Output encoding: encode data when rendering it in output contexts. Data displayed in HTML must be HTML-encoded (to prevent XSS). Data used in SQL queries must use parameterized queries (to prevent SQL injection). Data written to a filesystem path must have path traversal characters removed. Data placed in shell commands must use safe APIs that separate commands from arguments.

Authentication and session management:

• Passwords hashed with bcrypt, Argon2id, or scrypt (never MD5, SHA-1, or plain SHA-256)
• Session tokens generated with a cryptographically secure random number generator, minimum 128 bits of entropy
• Session tokens invalidated immediately on logout
• Account lockout after repeated failed authentication attempts
• MFA available (required for administrative access)

Cryptography:

• Use proven libraries (OpenSSL, libsodium, Bouncy Castle) — do not implement cryptographic primitives
• AES-256-GCM for symmetric encryption
• RSA-4096 or ECDSA-P256 for asymmetric operations
• PBKDF2/bcrypt/Argon2 for password hashing — never reversible encryption
• TLS 1.2 minimum, TLS 1.3 preferred; disable TLS 1.0 and 1.1

Error handling: error messages exposed to users must not reveal system internals (database queries, stack traces, server version information). Log detailed error information internally with correlation IDs. Return a reference ID to users so they can report issues without the error response leaking exploitable information.

Dependency management: maintain an inventory of all dependencies. Keep them updated. Integrate dependency vulnerability scanning into CI/CD. Establish a patching SLA: critical CVEs patched within 48 hours, high within 7 days, medium within 30 days.

Phase 4: Security Testing

Security testing validates that the implementation meets the security requirements defined in Phase 1.

SAST integration: run SAST tools (SonarQube, Semgrep, CodeQL) automatically on every commit. New critical findings block merge. For security requirements defined in Phase 1, write custom rules that verify the implementation — for example, a Semgrep rule that detects use of SHA-1 for password hashing.

DAST integration: deploy DAST tools (OWASP ZAP, Burp Suite Enterprise) against staging environments after deployment. Run baseline scans on every deployment; run full scans before releases.

Threat model validation: each threat identified in the threat model should have a corresponding test that verifies the control is effective. A threat of "brute-force against the login endpoint" produces a test that verifies the account lockout fires after the specified number of failed attempts.

Penetration testing: automated tools catch known vulnerability patterns; manual penetration testers find logic flaws, chained vulnerabilities, and attack paths that automated tools cannot reason about. Schedule penetration tests annually and before significant releases. Integrate pentest findings into the threat model for future features in the same system.

Phase 5: Secure Deployment

Security does not end at the application boundary. The deployment configuration is part of the attack surface.

Hardening checklist before every production deployment:

• Remove debug interfaces and development configurations
• Verify that error pages do not expose stack traces or server information
• Check security headers (Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options)
• Verify CORS policy is as restrictive as functional requirements allow
• Confirm all secrets are injected at runtime from a secrets manager (never baked into artifacts)
• Verify rate limiting is active on authentication and sensitive endpoints

Infrastructure as Code scanning: Checkov, TFSec, or KICS should run against all IaC before deployment, catching misconfigurations (world-accessible storage buckets, security groups open to all traffic, unencrypted volumes) before they reach the cloud.

Deployment verification: after deployment, run automated checks that verify security configurations are in place — security headers present, debug mode disabled, expected rate limiting behavior active.

Phase 6: Maintenance

Security is not a state — it is a continuous practice. Vulnerabilities are discovered in deployed software continuously, through application vulnerability research, CVE disclosures in dependencies, and changes in the threat landscape.

Patch management: monitor NVD (National Vulnerability Database) and GitHub Security Advisories for vulnerabilities in components you use. Automated dependency scanning tools (Dependabot, Snyk) generate pull requests for vulnerable packages — the patch is ready, it just needs review and merge.

Security monitoring: production systems need security event logging and alerting. Authentication failures (especially volume spikes that indicate brute force), privilege escalation events, access to sensitive resources, and anomalous API call patterns should all generate alerts. SIEM tools (Splunk, Elastic SIEM, Microsoft Sentinel) aggregate and correlate these events.

Incident response planning: before a security incident happens, define who is responsible for what: who coordinates the response, who does forensic analysis, who handles external communications, who makes the call to take a service offline. Teams that practice incident response tabletop exercises respond faster and more effectively when real incidents occur.

Regular security reviews: annual penetration tests, quarterly dependency audits, and continuous SAST/DAST scanning form the baseline. For high-value systems, consider bug bounty programs that engage the broader security research community.

A Secure SDLC program does not eliminate vulnerabilities — it systematically reduces their frequency and catches the ones that are introduced before they reach production. The benchmark for maturity is not "zero vulnerabilities found in production" but "most vulnerabilities are found before reaching production." Organizations that reach that state have fundamentally changed their relationship with software security risk.