From Requirements to Runtime: An End-to-End Secure SDLC & DevSecOps Playbook

1. Security Requirement Elicitation

Purpose

Security requirements are the foundation. Without explicit requirements, security becomes an afterthought, leading to expensive retrofitting and unmitigated threats.

Inputs

• Business context (criticality, deployment environment, user personas)
• Regulatory and contractual obligations (GDPR, HIPAA, customer SLAs)
• Known threat intelligence for your domain

Activities

1. Conduct stakeholder interviews (product, engineering, compliance, customers)
2. Use security requirement frameworks: OWASP ASVS, NIST SP 800-53 controls, IEC-62443 SL levels
3. Document functional security requirements (authentication, authorization, encryption) and non-functional (performance under attack, audit logging)
4. Prioritize using MoSCoW (Must/Should/Could/Won't)

Outputs

SR-001: [MUST] All user authentication shall use multi-factor authentication (MFA) for privileged accounts.
SR-002: [MUST] System shall encrypt data at rest using AES-256 and in transit using TLS 1.3+.
SR-003: [SHOULD] API rate limiting shall prevent > 100 requests/min per client to mitigate DoS.
SR-004: [MUST] All security events (auth failures, privilege escalations) shall be logged immutably.

What Good Looks Like

• Requirements are testable: "User session timeout = 15 minutes" not "sessions should be short"
• Each requirement is traceable to a regulation or threat (e.g., SR-001 → NIST AC-2)
• Requirements drive test cases, threat model, and architecture decisions

Tooling

Jira/Azure DevOps (requirements backlog), Confluence/Notion (documentation), OWASP ASVS checklist

Metrics

• Leading: % of features with documented security requirements before design
• Lagging: # of security bugs found in production that trace back to missing requirements

2. Defining Security Objectives

Purpose

Security objectives translate business goals into measurable security outcomes. They align stakeholders and set target security postures.

Inputs

Business strategy, risk appetite, compliance mandates, previous incident history

Activities

1. Define CIA triad priorities (Confidentiality, Integrity, Availability) for your product
2. Set quantitative targets: "Zero high-severity vulnerabilities in production," "99.9% uptime under attack"
3. Document acceptable risk: "We accept informational-severity findings if remediation cost > business impact"

Outputs

Product: Industrial Edge Monitoring System

Primary Objective: Protect operational integrity and safety—system failures must not cause equipment damage or safety incidents.

CIA Priorities:
1. Integrity (Critical): Sensor data tampering could cause incorrect safety shutdowns
2. Availability (High): Downtime impacts production schedules
3. Confidentiality (Medium): Proprietary process data exposure is a business risk

Target Security Posture:
- IEC-62443 Security Level 2 (SL2) by Q2 2026
- Zero critical/high CVEs in production releases
- Mean Time to Patch (MTTP) < 7 days for exploited vulnerabilities
- 100% of privileged access logged and auditable

3. Threat & Risk Analysis

Purpose

Threat modeling systematically identifies attack vectors before code is written. It's the most cost-effective security activity—fixing design flaws early is 10x cheaper than fixing them post-deployment.

Inputs

Architecture diagrams, data flow diagrams (DFDs), security requirements, known threat intel

Activities

1. Use STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)
2. Identify trust boundaries (e.g., internet → DMZ → internal network)
3. For each data flow crossing a trust boundary, enumerate threats
4. Rank threats using DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) or CVSS
5. Define mitigations: eliminate, mitigate, transfer (insurance), or accept

Outputs

Component: API Gateway

Trust Boundary: Internet → API Gateway → Backend Services

Threat T-001: [Spoofing] Attacker impersonates legitimate API client
  Category: STRIDE-S | Risk: HIGH | CVSS: 8.5
  Mitigation: Implement OAuth 2.0 + client certificates (mTLS)
  Owner: Backend Team | Due: Sprint 12

Threat T-002: [DoS] Attacker floods API with requests
  Category: STRIDE-D | Risk: MEDIUM | CVSS: 6.0
  Mitigation: Rate limiting (100 req/min), IP blocklist, WAF
  Owner: DevOps Team | Due: Sprint 11

Threat T-003: [Information Disclosure] API error messages leak stack traces
  Category: STRIDE-I | Risk: LOW | CVSS: 3.2
  Mitigation: Generic error messages, detailed logs server-side only
  Owner: Dev Team | Due: Sprint 10

What Good Looks Like

• Threat models are living documents, updated with every architecture change
• Each threat maps to a mitigation (control), which maps to a test case
• Teams threat-model collaboratively (dev, security, ops) in 1-2 hour workshops

Tooling

Microsoft Threat Modeling Tool, OWASP Threat Dragon, IriusRisk, Draw.io (for DFDs)

4. Devising Security Strategy

Purpose

Transform threat analysis into a coherent roadmap: which controls to implement when, what resources are needed, how to measure progress.

Activities

1. Prioritize mitigations by risk score and feasibility
2. Define security milestones (e.g., "Achieve 80% SAST coverage by Q2")
3. Allocate budget and resources (security tooling, training, headcount)
4. Create a security roadmap synced with product roadmap

Outputs

Security strategy document, 12-month security roadmap, quarterly OKRs

5. Secure Architecture & Design

Purpose

Implement defense-in-depth: layers of controls so that a single failure doesn't compromise the system. Document key decisions for future maintainers.

Key Principles

• Least Privilege: Components/users get minimum necessary permissions
• Fail Securely: Errors default to deny access, not grant it
• Defense in Depth: Multiple overlapping controls (WAF + input validation + parameterized queries)
• Zero Trust: Never trust, always verify—even internal network traffic

Outputs

Title: Use mutual TLS (mTLS) for service-to-service authentication
Status: Accepted
Context: Microservices communicate over internal network. Threat model identified service impersonation risk (T-045).
Decision: Implement mTLS using service mesh (Istio/Linkerd). Each service gets X.509 cert, rotated every 24h.
Consequences: (+) Stronger auth, encrypted internal traffic. (-) Cert management overhead, debugging complexity.
Alternatives Considered: Shared secrets (rejected: hard to rotate), JWT tokens (rejected: doesn't encrypt traffic)
Traceability: Mitigates T-045, implements SR-023

Tooling

Architecture as Code (Terraform/Pulumi), service mesh (Istio), ADR tools (adr-tools CLI)

6. Secure Supplier & Component Selection

Purpose

Third-party libraries and suppliers introduce supply chain risk. Assess security posture before adoption.

Activities

1. Maintain an approved component list (libraries, frameworks, SaaS vendors)
2. Evaluate new components: CVE history, maintainer responsiveness, last update date
3. Use Software Composition Analysis (SCA) to track dependencies
4. Verify provenance: check signatures, use private artifact registries

Outputs

SBOM (Software Bill of Materials), component security assessment scorecard