The Secure Software Development Lifecycle (SSDLC) integrates security activities at every phase of software development — from requirements gathering through deployment and maintenance — rather than treating security as an afterthought.

• Why important: Finding a vulnerability in requirements costs $1 to fix. In production, it costs $100x more. Early security = cheaper, faster, safer software.
• Reduces the attack surface of delivered software.
• Builds a security culture within development teams.
• Supports regulatory compliance (GDPR, PCI-DSS require secure development practices).
• Reduces reputational risk from post-deployment breaches.

Common frameworks: Microsoft SDL, NIST SSDF (Secure Software Development Framework), OWASP SAMM (Software Assurance Maturity Model).

"Shift left" means moving security testing and validation earlier in the SDLC — from the right side (production/testing) to the left side (requirements/design/coding).

• Developers run SAST tools in their IDE as they write code, not after.
• Threat modeling happens during design, not after deployment.
• Security requirements are defined alongside functional requirements.
• Pre-commit hooks enforce secret scanning and code analysis before code is pushed.

Why shift left works: Defects are exponentially cheaper to fix earlier. A design flaw found at requirements: ~$1. Found in production: ~$100–$1000. Shift left dramatically reduces cost and risk.

• SAST (Static Application Security Testing): Analyses source code, bytecode, or binaries without executing the application. Finds vulnerabilities like SQL injection, hardcoded secrets, insecure functions at the code level. Run during development in CI pipelines. Tools: SonarQube, Semgrep, Checkmarx, Fortify.
• DAST (Dynamic Application Security Testing): Tests a running application from the outside (like an attacker would) without access to source code. Finds runtime vulnerabilities: authentication issues, injection, misconfigurations. Tools: OWASP ZAP, Burp Suite, Nikto.

Threat modeling is a structured process of identifying potential security threats to a system during the design phase and designing countermeasures before building.

STRIDE model:

• S — Spoofing: Attacker pretends to be someone else. Counter: Authentication (MFA, certificates).
• T — Tampering: Attacker modifies data. Counter: Integrity checks, digital signatures, hashing.
• R — Repudiation: User denies performing an action. Counter: Audit logs, non-repudiation (digital signatures).
• I — Information Disclosure: Data exposed to unauthorized parties. Counter: Encryption, access controls, data minimization.
• D — Denial of Service: System made unavailable. Counter: Rate limiting, redundancy, DDoS protection.
• E — Elevation of Privilege: User gains more access than intended. Counter: Authorization controls, least privilege.

DevOps integrates Development and Operations for faster, continuous delivery. DevSecOps adds Security as a shared responsibility integrated throughout the pipeline.

	Traditional DevOps	DevSecOps
Security timing	Post-development security gate	Continuous, at every pipeline stage
Who owns security	Security team only	Developers, Ops, and Security jointly
Security testing	Manual pen test before release	Automated SAST/DAST/SCA in CI/CD
Feedback loop	Slow (wait for security review)	Fast (immediate developer feedback)

The OWASP Top 10 is the most authoritative list of critical web application security risks, updated periodically based on real-world data from the security community.

2021 #1: Broken Access Control — Users can access resources or perform actions beyond their intended permissions. Moved from #5 in 2017 to #1, found in 94% of tested applications.

Key changes from 2017→2021: SQL Injection dropped from #1 to part of A03 (Injection). Cryptographic Failures (formerly Sensitive Data Exposure) moved to #2. Insecure Design (A04) is a new category emphasizing security by design.

BOLA (also called IDOR — Insecure Direct Object Reference) is the #1 API vulnerability. It occurs when an API exposes object identifiers (like database IDs) in requests and doesn't verify the requesting user has permission to access that specific object.

Example:

GET /api/v1/orders/12345  ← User A's order
→ Change to:
GET /api/v1/orders/12346  ← User B's order (unauthorized!)

If the API returns User B's data without checking that the requesting user owns order 12346, it's BOLA.

Prevention:

• Implement object-level authorization checks for every request
• Use GUIDs instead of sequential integer IDs (not a complete fix but adds obscurity)
• Validate that the authenticated user owns the requested resource at the data layer
• Automated testing: fuzz IDs in API tests, use Burp Suite's Autorize extension

Securing a REST API requires defence at multiple layers:

• Authentication: OAuth 2.0 + JWT for user authentication; API keys for service-to-service; mTLS for sensitive environments.
• Authorization: Enforce BOLA checks — verify the caller owns the requested resource. Role-based access per endpoint.
• Transport security: HTTPS/TLS 1.2+ mandatory. No HTTP. Enforce HSTS.
• Rate limiting: Prevent brute force and DoS. Implement per-user and per-IP rate limits. Return 429 Too Many Requests.
• Input validation: Validate and sanitize all input. Reject unexpected fields (mass assignment prevention). Whitelist allowed values.
• Output encoding: Encode output to prevent injection. Return only necessary fields (never return passwords/hashes).
• Logging & monitoring: Log all API requests (authenticated user, endpoint, response code). Alert on anomalies.
• API gateway: Centralise auth, rate limiting, WAF, and logging (Kong, AWS API Gateway, Apigee).
• Versioning: Deprecate and remove old API versions with proper security controls.

JWT (JSON Web Token) is a compact, self-contained token format used for authentication and information exchange. Structure: Header.Payload.Signature — Base64URL encoded.

Security risks:

• Algorithm confusion (alg:none): If server accepts alg:none, attacker can forge tokens with no signature.
• Weak secret: If HS256 secret is weak/guessable, attacker can brute-force and forge tokens.
• RS256 to HS256 confusion: If server accepts both algorithms, attacker can use public key as HS256 secret.
• No expiry: Tokens without exp claim are valid forever — stolen tokens stay valid permanently.
• Sensitive data in payload: JWT payload is Base64 encoded — NOT encrypted. Never put passwords or PII in payload.
• No revocation: JWTs are stateless — once issued, they can't be revoked until expiry (use short expiry + refresh tokens).

SQL Injection occurs when user-supplied input is incorporated into SQL queries without sanitization, allowing attackers to manipulate the query logic.

Example:

query = "SELECT * FROM users WHERE name = '" + username + "'"
// Attacker input: admin' OR '1'='1
// Result: SELECT * FROM users WHERE name = 'admin' OR '1'='1'
// → Returns ALL users!

Impact: Authentication bypass, data exfiltration, data deletion, remote code execution (xp_cmdshell in MSSQL).

Prevention (in priority order):

1. Parameterized queries / Prepared statements (the only real fix) — input is never interpreted as SQL.
2. Stored procedures (if using parameterized binding).
3. Input validation — whitelist expected values.
4. Least privilege — DB account should only have SELECT/INSERT on specific tables.
5. WAF as an additional layer (not a primary defence).

XSS occurs when an attacker injects malicious client-side scripts (JavaScript) into web pages viewed by other users.

• Reflected XSS: Malicious script in the URL/request is reflected back in the response and executed immediately. Non-persistent. Example: search result showing unsanitized search query.
• Stored XSS: Malicious script is permanently stored in the database (e.g., comment field) and served to every user who views it. Most dangerous — affects all users.
• DOM-based XSS: Vulnerability is in client-side JavaScript that reads from DOM (e.g., document.location) and writes to DOM without sanitization. Server never sees the payload.

Impact: Cookie theft, session hijacking, keylogging, defacement, credential harvesting.

Prevention: Output encoding (HTML encode user data before rendering), Content Security Policy (CSP), HttpOnly cookies, avoid innerHTML with user input — use textContent.

CSRF (Cross-Site Request Forgery) tricks an authenticated user's browser into making an unintended request to a target site using the user's existing session/cookie.

Example: User is logged into bank. Attacker sends email with link to evil.com. The page contains: <img src="https://bank.com/transfer?to=attacker&amount=10000">. Browser automatically sends the request with the user's auth cookie.

Mitigations:

• CSRF tokens: Unique, unpredictable token included in every state-changing form. Server validates before processing.
• SameSite cookie attribute: SameSite=Strict/Lax prevents cookies from being sent in cross-site requests (most effective modern defense).
• Origin/Referer header validation.
• Custom request headers: APIs requiring X-Requested-With: XMLHttpRequest — browsers can't set this in cross-origin requests.

SCA is the practice of automatically identifying open-source components and third-party libraries used in an application and checking them for known vulnerabilities, outdated versions, and license compliance issues.

Why critical: Modern applications are 70–90% open-source code. One vulnerable dependency (like Log4j in 2021) can affect thousands of applications.

• Tools: OWASP Dependency-Check, Snyk, Dependabot (GitHub), WhiteSource, Black Duck
• What SCA checks: CVE (vulnerability) database matches, outdated versions, license conflicts (GPL contamination), transitive dependencies
• CI/CD integration: SCA runs on every pull request — fails the build if a critical CVE is detected in dependencies

A software supply chain attack compromises a software component, build tool, dependency, or update mechanism that is trusted and widely used, so the attacker's code reaches many downstream targets.

Real-world examples:

• SolarWinds (2020): Attackers inserted malicious code into the SolarWinds Orion software update. 18,000+ organizations installed it, including US government agencies.
• Log4Shell (2021): Critical RCE vulnerability in Log4j (a ubiquitous Java logging library) used by millions of applications globally.
• XZ Utils (2024): A malicious contributor spent 2 years building trust in the XZ project, then inserted a backdoor into the compression library used in many Linux distributions.
• npm package poisoning: Typosquatting packages (e.g., lodahs instead of lodash) that steal environment variables when installed.

Mitigations: SCA/SBOM, pin dependency versions, verify package checksums, review transitive dependencies, use private package registries, code signing.

Never hardcode secrets (API keys, passwords, certificates) in source code or configuration files checked into version control. Instead:

• Use secrets managers: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager — inject secrets at runtime.
• CI/CD environment variables: Store secrets as encrypted environment variables in GitHub Actions secrets, GitLab CI variables, Jenkins credentials — never in the pipeline YAML file.
• Pre-commit secret scanning: TruffleHog, detect-secrets, GitGuardian — scan code for credential patterns before committing.
• If a secret is leaked: Immediately rotate/revoke the secret, scan git history for all occurrences, audit access logs for abuse, rewrite git history (git filter-branch / BFG Repo-Cleaner).
• Short-lived credentials: Use OIDC (OpenID Connect) with cloud providers — pipeline assumes an IAM role for each run rather than storing long-lived credentials.

Input validation is verifying that all data entered into a system conforms to expected format, type, length, and range before it is processed.

It prevents: SQL injection, XSS, command injection, path traversal, buffer overflows, business logic bypass.

Types:

• Whitelist validation: Only accept known-good values (preferred). E.g., phone number = digits only, max 15 chars.
• Blacklist validation: Reject known-bad patterns (weaker — hard to be exhaustive).
• Type validation: Ensure input is the expected data type.
• Length/Range validation: Reject inputs outside expected bounds.

Golden rule: Validate on the server side. Client-side validation (JavaScript) is easily bypassed using Burp Suite — it's only for user experience.

An API gateway is a centralized entry point that sits between clients and backend services, handling cross-cutting concerns for all API traffic.

Security features provided:

• Authentication: Validate API keys, OAuth tokens, JWTs before routing to backend
• Authorization: Enforce RBAC — only allow permitted operations per endpoint
• Rate limiting & throttling: Prevent abuse, DoS, and brute force attacks
• WAF integration: Inspect and block malicious payloads (SQLi, XSS)
• TLS termination: Enforce HTTPS at the edge
• Logging & monitoring: Centralized audit trail of all API calls
• IP allowlisting/blocklisting
• Request/response transformation: Strip sensitive headers before forwarding

Examples: AWS API Gateway, Kong, Apigee (Google Cloud), Azure API Management, Nginx.

OAuth 2.0 is an authorization framework that allows a third-party application to obtain limited access to a user's account on another service without exposing the user's credentials.

Key roles:

• Resource Owner: The user who owns the data
• Client: The third-party application requesting access
• Authorization Server: Issues access tokens (e.g., Google's OAuth server)
• Resource Server: The API that holds the protected data

Authorization Code Flow (most secure):

1. User clicks "Login with Google" on the client app
2. Client redirects to Google's auth server with scope, redirect_uri, state
3. User authenticates and grants permission
4. Auth server returns authorization code to redirect_uri
5. Client exchanges code for access token (server-side, with client secret)
6. Client uses access token to call the API

Container security involves securing the entire container lifecycle: image build, registry storage, orchestration (Kubernetes), and runtime.

Common vulnerabilities:

• Vulnerable base images: Using ubuntu:latest with unpatched CVEs. Fix: Use minimal base images (distroless), scan with Trivy/Snyk.
• Running as root: Container processes running as root can escape to host. Fix: Add USER nonroot in Dockerfile.
• Secrets in images: API keys baked into image layers. Fix: Use secrets managers, multi-stage builds.
• Privileged containers: --privileged flag gives near-host-level access. Avoid unless necessary.
• Writable filesystems: Allow malware persistence. Fix: Read-only root filesystem.
• Kubernetes RBAC misconfiguration: Over-permissive service accounts enabling privilege escalation.
• Container escape: Breaking out of container namespace via kernel exploits (e.g., runc vulnerability).

Implementing JWT securely requires addressing multiple attack vectors:

• Use asymmetric signing (RS256/ES256): Private key signs, public key verifies. Eliminates HS256 secret sharing risk.
• Short access token expiry: 5–15 minutes max. Use refresh tokens (stored in HttpOnly cookies) with rotation.
• Validate all claims: Check exp (expiry), iss (issuer), aud (audience) on every request.
• Explicitly specify allowed algorithms: Never accept alg:none. Hardcode the expected algorithm server-side.
• Never put sensitive data in payload: JWT payload is Base64 — readable by anyone. Use opaque tokens for sensitive data.
• Store in HttpOnly, Secure, SameSite cookies — not localStorage (vulnerable to XSS).
• Implement token revocation: Maintain a revocation list (Redis-based blocklist) or use short expiry + refresh rotation for compromise detection.