Why This Matters#

Most vulnerabilities are introduced during development. Fixing a vulnerability in production costs 30–100x more than fixing it during design. Secure development integrates security into every phase of the SDLC — shifting left means finding and fixing issues earlier, when they’re cheapest.

Secure SDLC#

flowchart LR
    Req["Requirements<br/>· Security Requirements<br/>· Abuse Cases"] --> Design["Design<br/>· Threat Model<br/>· Architecture Review"]
    Design --> Code["Code<br/>· Secure Coding<br/>· SAST + SCA"]
    Code --> Test["Test<br/>· DAST + Pentest<br/>· Fuzz Testing"]
    Test --> Deploy["Deploy<br/>· Config Review<br/>· Secrets Check"]
    Deploy --> Operate["Operate<br/>· Monitor<br/>· Respond + Patch"]

Security Activities per Phase#

Threat Modeling#

STRIDE Model#

Systematic identification of threats per component:

Threat Modeling Process#

flowchart TD
    Scope["1: Define Scope<br/>(what are we modeling?)"]
    Scope --> Diagram["2: Create Data Flow Diagram<br/>(components, data flows, trust boundaries)"]
    Diagram --> Identify["3: Identify Threats<br/>(STRIDE per element)"]
    Identify --> Mitigate["4: Define Mitigations<br/>(controls per threat)"]
    Mitigate --> Validate["5: Validate<br/>(are mitigations implemented?)"]

Data Flow Diagram Elements#

Secure Coding Practices#

Input Validation#

Output Encoding#

Authentication & Session#

Error Handling#

Security Testing#

SAST (Static Application Security Testing)#

Analyzes source code without executing it:

Strengths: Finds code-level flaws early, covers all code paths. Weaknesses: High false positive rate, no runtime context.

DAST (Dynamic Application Security Testing)#

Tests the running application from outside:

Strengths: Finds runtime issues, low false positives. Weaknesses: Only tests reachable code paths, slower.

SCA (Software Composition Analysis)#

Identifies vulnerable dependencies:

Fuzz Testing#

Sends random/malformed input to find crashes and unexpected behavior:

Supply Chain Security#

Attack Vectors#

flowchart TD
    SC["Supply Chain Attacks"]
    SC --> Dep["Dependency Attacks"]
    SC --> Build["Build Pipeline Attacks"]
    SC --> Dist["Distribution Attacks"]
    
    Dep --> Typo["Typosquatting<br/>(lodash → lodahs)"]
    Dep --> Takeover["Maintainer Takeover<br/>(compromised npm account)"]
    Dep --> Malicious["Malicious Update<br/>(event-stream incident)"]
    
    Build --> CI["CI/CD Compromise<br/>(stolen secrets)"]
    Build --> Inject["Build Injection<br/>(SolarWinds)"]
    
    Dist --> Tamper["Package Tampering<br/>(modified binary)"]
    Dist --> Mirror["Compromised Mirror<br/>(fake repository)"]

Defenses#

SLSA (Supply-chain Levels for Software Artifacts)#

Secrets Management in Code#

What NOT to Do#

# NEVER commit these:
API_KEY=sk-abc123def456
DATABASE_URL=postgres://admin:password@prod-db:5432/app
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Secrets Detection#

Secrets Management Solutions#

Security in CI/CD Pipeline#

flowchart LR
    Commit["Commit"] --> Secrets["Secrets<br/>Scan"]
    Secrets --> SAST["SAST"]
    SAST --> SCA["SCA<br/>(dependencies)"]
    SCA --> Build["Build"]
    Build --> Image["Container<br/>Scan"]
    Image --> DAST["DAST<br/>(staging)"]
    DAST --> Gate{"Security<br/>Gate"}
    Gate -->|Pass| Deploy["Deploy"]
    Gate -->|Fail| Block["Block +<br/>Notify"]

Security Gates#

Key Takeaways#

1. Shift left — security in requirements and design, not just testing
2. Threat model every significant feature — STRIDE gives structure
3. Automate in CI/CD — SAST, SCA, secrets scanning on every commit
4. Supply chain is a real threat — lock versions, verify integrity, use SBOM
5. Never commit secrets — use pre-commit hooks + secrets managers
6. Security gates prevent deployment of known-bad code — block on critical
7. Defense in depth applies to code too — validate input, encode output, fail securely