SSDLC

What is SSDLC

The Secure Software Development Lifecycle (SSDLC) is a systematic process that integrates security practices into every phase of software development, including planning, design, implementation, testing, release, and operations. Its goal is to proactively identify and mitigate security risks, ensuring that security is considered from the outset and maintained throughout the software’s lifecycle.

• Framework that details development steps
• Well-structured sequence of stages
• Rapid development of high-quality software

OSI Model and Developer Security Layers

The OSI model provides a clear framework for placing security controls. Developer impact is strongest at Layers 7–5, with awareness required for Layers 4–3.

Developer‑centric implementation

Layer 7 — Application (primary focus)

• Authentication: secure login, MFA, password hashing, secure reset flows
• Authorization: RBAC, least privilege, robust permission checks, audit logs
• Input validation: sanitize and validate, secure file upload handling
• API security: authentication, rate limiting, schema/request validation
• Business logic security: prevent privilege escalation and logic abuse

Layer 6 — Presentation (data security)

• Encryption: sensitive data at rest and in transit
• SSL/TLS: hardened protocol/cipher suites, cert management
• Data handling: safe JSON/XML parsing; correct character encoding
• Compression safety: avoid insecure compression where applicable

Layer 5 — Session (connection management)

• Session lifecycle: secure creation, validation, timeout, cleanup
• Token security: JWT or similar, rotation/refresh, revocation, storage
• Connection security: secure establishment and termination

Cross‑layer awareness

• Layer 4 — Transport: enforce HTTPS, secure ports, secure connection pooling, load balancer security
• Layer 3 — Network: segmentation, firewall allow‑lists, IP restrictions, VPN integration

Our security toolchain and platform

AWS SecOps (platform baseline)

We operate on AWS with a SecOps baseline. Beyond the controls below, AWS services provide continuous guardrails:

• Security Hub, GuardDuty, Inspector for findings aggregation and threat detection
• AWS WAF and Shield for L7 protection; WAF used also for DAST validation scenarios
• CloudTrail, CloudWatch, and Config for auditing, monitoring, and drift detection
• IAM Access Analyzer, least‑privilege IAM, SCPs, and service‑to‑service roles
• ECR image scanning, EKS/ECS best practices, KMS for encryption keys, Secrets Manager/SSM Parameter Store for secrets

SAST and SCA

• Biome rules: static analysis and formatting with security‑oriented rules enabled
• Snyk: SAST for code issues and SCA for third‑party dependency vulnerabilities and license compliance

DAST

• OWASP ZAP Attack Proxy: automated dynamic scans against deployed environments
• AWS WAF testing: validate WAF rules/rate limits/bot control against real traffic patterns

Browser‑side protections (security headers)

• Content‑Security‑Policy (CSP): default‑src 'self'; granular script/style/img/connect/frame policies
• Anti‑clickjacking: X-Frame-Options: DENY or CSP frame-ancestors 'none'
• HSTS: Strict-Transport-Security with preload and includeSubDomains
• X‑Content‑Type‑Options: nosniff; Referrer‑Policy; Permissions‑Policy; Cross‑Origin policies (COEP/COOP/CORP) as applicable

Minimal example (NGINX):

add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" always;
add_header X-Frame-Options "DENY" always; # or rely on CSP frame-ancestors
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;
add_header Permissions-Policy "geolocation=(), microphone=()" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

SSDLC implementation strategy

Phase 1 — Foundation hardening

1. Security headers: CSP, anti‑clickjacking, HSTS, and complementary headers implemented by default
2. Authentication and authorization: MFA, secure password hashing, brute‑force protection, robust RBAC and audit logging
3. Input validation and sanitization: server‑side validation, output encoding, safe file uploads

Phase 2 — Secure development practices

1. Secure code reviews: automated checks + focused manual reviews for critical paths
2. Dependency management: SCA with Snyk; regular updates; vulnerability gating in CI
3. Secure dev environment: collaborator access controls, protected branches, monitored CI/CD

Phase 3 — Continuous security integration

1. Automated security testing: Biome and Snyk in CI; DAST with ZAP; dependency and container scanning
2. Runtime protection: WAF policies, anomaly detection, rate limiting, secure logging
3. Threat monitoring: integrate Security Hub/GuardDuty/Inspector; continuous posture visibility

Phase 4 — Advanced controls

1. Secrets management: KMS + Secrets Manager/Parameter Store; short‑lived credentials
2. Encryption: TLS everywhere; database/storage encryption; key rotation procedures
3. Error handling and logging: avoid sensitive data leakage; structured logs with correlation IDs

Security testing across layers

Application layer

• Authentication: secure login/logout, password reset, MFA flows
• Authorization: RBAC checks, vertical/horizontal escalation prevention
• Input validation: validation/sanitization, XSS output encoding
• Business logic: abuse case and negative path testing

Presentation layer

• TLS configuration and certificate hygiene
• Data format and encoding handling correctness

Session layer

• Session fixation/hijacking protections, timeout and storage validation
• Token generation/validation/rotation/revocation

Tooling in CI/CD

• SAST/SCA: Biome + Snyk
• DAST: OWASP ZAP; plus AWS WAF rule validation against staging/prod

OWASP Top 10 focus

SQL Injection

• Parameterized queries/ORM safe APIs; least‑privilege DB users; server‑side validation; DAST coverage

Cross‑Site Scripting (XSS)

• Output encoding, CSP, input sanitization, avoid unsafe DOM sinks; disable HTTP TRACE

Cross‑Site Request Forgery (CSRF)

• Anti‑CSRF tokens, SameSite cookies, origin/referer validation for state‑changing requests

OWASP Top 10 (2021) overview

OWASP is a software security foundation. Its Top 10 is the reference list of the most critical web application risks, built through industry data, surveys, analysis, draft review, and consensus.

The 2021 risks

1. Broken Access Control — unauthorized actions due to weak permission checks
2. Cryptographic Failures — weak/incorrect crypto leading to data exposure
3. Injection — untrusted input executed as commands/queries
4. Insecure Design — missing controls and flawed security design
5. Security Misconfiguration — insecure defaults, verbose errors, open services
6. Vulnerable and Outdated Components — known‑vulnerable libs and runtimes
7. Identification & Authentication Failures — weak auth flows and session mgmt
8. Software & Data Integrity Failures — unverified updates/builds, supply‑chain
9. Security Logging & Monitoring Failures — missing logs/alerts for incidents
10. Server‑Side Request Forgery (SSRF) — backend makes unintended outbound calls

How the list is produced

• Plan schedule and call for data; survey industry

• Analyze collected data and submissions

• Draft categories; review with the community

• Reach consensus and publish

• OWASP Top Ten — Official

• OWASP ZAP: 6 steps for DAST (Jit)

• OWASP Cheat Sheet Series

• OWASP ASVS

• OWASP Proactive Controls

• OWASP ZAP Project

• OWASP Dependency-Check

• OWASP SAMM

OWASP Top 1–3: prevention highlights

A01 — Broken Access Control

• Enforce RBAC/ABAC with least privilege; deny by default
• Server‑side checks for every action; no hidden client‑only controls
• Test vertical and horizontal privilege escalation; add audit logs

A02 — Cryptographic Failures

• Use modern TLS; disable legacy protocols; enforce HTTPS everywhere
• Encrypt sensitive data at rest and in transit; manage keys securely (KMS)
• Strong algorithms/modes; rotate keys; avoid home‑grown crypto

A03 — Injection

• Parameterized queries and safe ORM APIs; no string concatenation
• Validate and encode input/output for context; avoid unsafe sinks
• Use allow‑lists; centralized query builders; strong database least privilege

OWASP Top 4–6: prevention highlights

A04 — Insecure Design

• Do threat modeling; choose proven security patterns and controls early
• Define abuse cases and non‑functional security requirements

A05 — Security Misconfiguration

• Harden defaults; disable verbose errors and unused features
• Automate configuration via code; scan infra and containers regularly

A06 — Vulnerable & Outdated Components

• Maintain SBOM; enable SCA in CI; automate updates with policy gates
• Remove unused dependencies; verify signatures/provenance

OWASP Top 7–10: prevention highlights

A07 — Identification & Authentication Failures

• MFA; strong password policies; secure session management
• Avoid custom auth; use vetted providers; protect against credential stuffing

A08 — Software & Data Integrity Failures

• Protect CI/CD; signed artifacts; verify checksums/signatures
• Enforce branch protection and code reviews; restrict build permissions

A09 — Security Logging & Monitoring Failures

• Centralized, structured logs with correlation IDs; retain and protect logs
• Alerting on auth/critical flows; regular testing of detection rules

A10 — SSRF

• Default‑deny egress; allow‑list destinations; block link‑local/metadata IPs
• Normalize and validate URLs; use network segmentation and WAF where applicable

Developer responsibilities

Code‑level security

• Follow secure coding guidelines, use vetted libraries, regular security reviews
• Maintain dependency hygiene; fix supply‑chain alerts promptly

Configuration security

• Secure application configs and environment variables
• Structured, privacy‑aware logging and monitoring; secure deployment procedures

Integration security

• Secure API design (authn/z, quotas, schema validation)
• Hardened DB and external service connections; mTLS where required

Embedding SSDLC practices turns security into a proactive capability and keeps risk, velocity, and reliability in balance across the portfolio.

Security code practices

Security code practices integrate concrete guardrails into everyday development. They are part of the development process, target the application layer, and are cost‑effective when applied early. They help mitigate vulnerabilities and align Dev + SecOps.

HTTP security headers

Enforce CSP, anti‑clickjacking, HSTS, Referrer‑Policy, Permissions‑Policy, and nosniff across environments.

CORS policies

Restrict origins, methods, headers, and credentials. Default‑deny; allow only what the app actually needs.

Credentials & SCM hygiene

Block secrets in git, sign commits, protect branches, enforce MFA/SSO, and rotate tokens.

Secrets management (Vault/KMS)

Keep secrets out of code and CI logs. Use short‑lived creds with least privilege and audit trails.

General practices

• Follow a secure SDLC and coding standards (e.g., OWASP ASVS, language‑specific guides)
• Prefer vetted, maintained libraries; avoid custom crypto and home‑grown parsers
• Server‑side input validation; output encoding; principle of least privilege everywhere
• Secure error handling: no sensitive data in messages; structured logs with correlation IDs
• Automate code scanning (SAST/SCA), container scanning, and IaC scanning in CI
• Regular security reviews and threat modeling for critical changes

Input validation and scrubbing

• Validate type, length, range, and format server‑side
• Use allow‑lists for enums, MIME types, and file extensions
• Normalize and canonicalize inputs before validation
• Reject unexpected fields; fail closed by default
• Scrub dangerous characters and control bytes when needed for downstream sinks

Output encoding

• HTML: encode before writing to DOM or templates
• JavaScript/JSON: serialize safely; avoid string concatenation into scripts
• URLs: percent‑encode path and query components; validate origins for redirects
• SQL/NoSQL: use parameterized queries and safe ORM APIs

Error handling and logging

• Show generic error messages to users; capture detailed context in logs
• Never log secrets, tokens, session IDs, or personal data unnecessarily
• Use correlation IDs and structured logs for traceability
• Rate‑limit and alert on repeated failures (auth, payments, critical flows)

Dependencies and supply chain

Dependencies accelerate delivery but introduce supply‑chain risk (transitive vulns, typosquatting, malicious releases, license drift).

Challenges and risks

• Transitive dependencies and indirect attack surface
• Vulnerabilities and insecure defaults; stale or abandoned packages
• License incompatibilities and compliance obligations
• Integrity risks: compromised maintainers, malicious updates, repo takeovers
• Reproducibility gaps: non‑pinned versions, mutable tags, missing SBOMs

Dependency hygiene in practice

1. Pin versions and use lockfiles; prefer immutable digests for containers.
2. Generate and publish SBOMs; track components over time.
3. Enable SCA in CI (e.g., Snyk, OWASP Dependency‑Check/Track) with severity gates.
4. Automate updates (Renovate/Dependabot) with CI tests and staged rollouts.
5. Verify provenance/signatures (Sigstore), prefer official registries, and mirror artifacts.

Secure development environment

The security of code depends on the environment it is built in. Harden developer workstations, networks, and CI/CD.

Core practices

• Secure secrets: store in Vault/KMS; never in dotfiles or local scripts
• Network security: VPN when needed; firewall with strict ingress/egress; close unused ports
• Workstation hygiene: full‑disk encryption, auto‑updates, separate profiles or machines for admin vs daily work
• Strong identity: MFA everywhere; short‑lived, scoped credentials; commit signing
• Containerized/devbox workflows to isolate toolchains
• Monitoring: collect endpoint and CI logs; alert on anomalous behavior
• Access controls: just‑in‑time and least privilege for production access; break‑glass procedures
• Track all commits and changes; protect branches; enforce reviews

Insecure environment signals

• Unrestricted access to prod from dev laptops
• Missing protective monitoring and logging
• Out‑of‑date OS and tooling; weak or reused passwords; no MFA
• Secrets in repos, CI variables with broad scope, or local config files

Summary & highlights

• Security is a DevOps concern; earlier is cheaper and more effective
• Use trusted code and secure headers; validate input and encode output
• Vet and track dependencies with SCA, SBOMs, and automated updates
• Employ CodeQL and complementary scanners (SAST, DAST, IaC)
• Harden the development environment with MFA, secrets management, and monitoring

Glossary: Security best practices

Glossary: Application security for developers and DevOps