Back to path
LargePortfolio centerpiece ~31h· 6 milestones

Build a secure-by-default pipeline and threat-model an app

You own security for a service end-to-end: you threat-model it, build defenses into the pipeline and runtime, manage its secrets properly, wire up detection and alerting, then prove it all works by attacking it yourself in a controlled purple-team exercise.

Threat modelingIaC scanningSecrets management (Vault)Runtime/admission policyDetection & alertingIncident responseSecurity control cost modelingChaos / failover testingBlameless postmortems
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

A threat model driving a secure pipeline (IaC scanning, signed artifacts, runtime policy, managed secrets) plus detection/alerting and an incident runbook, validated against a simulated attack that detection actually catches.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

threat-model.mdmarkdown
# Threat model: <service>

## Data-flow (components, trust boundaries, data stores, entry points)
- [ ] diagram link / sketch

## STRIDE
| Element | Threat (STRIDE) | Likelihood×Impact | Control / Accepted risk |
|---|---|---|---|
| API edge | Spoofing | High | mTLS + authn |
| Secrets   | Info disclosure | High | Vault dynamic creds |
| Pipeline  | Tampering | High | signed artifacts + admission |

## Defend first (ranked)
1. ...

Reading this file

  • ## Data-flow ... trust boundariesMapping where data crosses from less- to more-trusted is key, the biggest threats almost always live on those lines.
  • | Threat (STRIDE) |STRIDE is a checklist of six threat types, walking it per element stops you from forgetting whole categories.
  • | Likelihood×Impact |Scoring each threat lets you rank them, so you defend the few that matter most instead of everything equally.
  • ## Defend first (ranked)The shortlist that drives every later milestone, controls get built in priority order.

A STRIDE table keyed to your data-flow diagram, the doc that decides which controls you build first.

That's 1 of 10 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Threat-model the system

    5 guided steps

    Security work without a threat model is a pile of random controls. The model tells you what actually matters so you defend the real attack paths, not the convenient ones.

  2. 2

    Harden the pipeline

    5 guided steps

    Misconfigured infrastructure (a public bucket, an open security group) is a top breach cause. Catching it in code, before it’s provisioned, is far cheaper than catching it in prod.

  3. 3

    Manage secrets properly

    5 guided steps

    Long-lived secrets in env files and Git history are a perennial top breach vector. A managed store with short-lived, scoped credentials shrinks both the exposure and the blast radius.

  4. 4

    Detect & alert

    6 guided steps

    Prevention always has gaps. Detection is how you find the attacker who got through, and how you measure whether your controls actually held.

  5. 5

    Break the controls on purpose (chaos & failover)

    5 guided steps

    A control that silently dies is worse than no control: you think you’re protected while you’re blind. Chaos testing answers "does the gate fail open or fail closed, and do we even notice?" before an attacker finds out for you.

  6. 6

    Run a purple-team test

    6 guided steps

    Controls and detections are unproven until attacked. A purple-team exercise turns "we think we’re covered" into evidence, and shakes out the gaps before a real adversary does.

What's inside when you start

4 starter files, ready to clone
6 guided milestones
6 full reference solutions
10 code blocks explained line-by-line
6 "is it working?" checks
4 interview questions it prepares you for

You'll walk away with

A threat model (data-flow diagram + ranked threats) and a matching control map
A secure pipeline + runtime policy repo with IaC scanning, signed artifacts, and managed secrets
An incident runbook and a write-up of the simulated attack with detection evidence and fixed gaps
A chaos/failover report showing each control’s fail-open/fail-closed behavior, plus a detection-stack cost model
A blameless postmortem with a timeline, time-to-detect/contain, and dated action items

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building