Part 1 — Threat Model the App

This is the deep version of Secure a Pipeline's first stage. You'll take Vulnerly — the small, deliberately vulnerable Node.js/Postgres sample app the whole capstone locks down — and produce a real STRIDE threat model of it with OWASP Threat Dragon before a single scanner runs. No tool touches Vulnerly's code in this part. What you leave with is a committed file: security/threat-model.json, with at least five ranked threats and three of them chained into full attack paths, each pointing at the exact capstone part that will close it. If you haven't met Vulnerly yet, skim the capstone hub first — this page assumes you know the shape of what you're about to draw.

What this part assumes, and the world every remaining part shares

☺ Like you're 10: Just a laptop, git, and a free account somewhere to draw on — nothing built yet, and nothing running yet.

You need git, Node.js (LTS) with npm, a text editor, and a GitHub account to push into (GitLab works identically — adjust the commands). You do not need Docker, kind, or any cloud account for this part specifically — Vulnerly's Terraform and Kubernetes manifests exist in the repo from day one, but nothing gets provisioned or deployed until Parts 4 and 5. That's deliberate, not an oversight: this is the one capstone part that's pure design-time work, the same "shift-left" argument What is DevSecOps? and Threat modeling both make — the cheapest place to find the SQL-injection path is a diagram, not a penetration test against a running service.

Here is the whole world this capstone shares, named once so nothing surprises you in a later part:

Standing up the Vulnerly scaffold

☺ Like you're 10: Before you can draw a map of the yard, the yard actually has to exist — so first you build a small, deliberately messy one.

Vulnerly isn't a hypothetical for this part — it's a real, if minimal, app you push to a real repo, because Threat Dragon needs an actual architecture to model and Parts 2 through 6 need actual files to scan, fix, and re-scan. What follows is the seed: enough real code to be genuinely vulnerable in the specific ways the hub named, not a production-grade app. Create the repo and lay down this structure:

mkdir vulnerly && cd vulnerly
git init -b main
mkdir -p app/src infra .github/workflows

// app/src/index.js — Vulnerly's whole API, seeded on purpose
const express = require("express");
const { Pool } = require("pg");
require("dotenv").config();

const app = express();
const pool = new Pool({ connectionString: process.env.DATABASE_URL });

// GET /reconciliation/search?merchant=foo
// (1) string-concatenated SQL — classic injection point
// (2) the search term is echoed back into HTML, unescaped — reflected XSS
app.get("/reconciliation/search", async (req, res) => {
  const term = req.query.merchant || "";
  const sql = `SELECT * FROM transactions WHERE merchant_name LIKE '%${term}%'`;
  const { rows } = await pool.query(sql);
  res.send(`<h1>Results for ${term}</h1>` + JSON.stringify(rows));
});

// GET /reconciliation/:id
// no check that the caller's own merchant_id owns this record — IDOR:
// increment the id, read anyone's reconciliation data
app.get("/reconciliation/:id", async (req, res) => {
  const { rows } = await pool.query(
    "SELECT * FROM transactions WHERE id = $1", [req.params.id]
  );
  res.json(rows[0] || {});
});

app.listen(3000, () => console.log("vulnerly-api listening on 3000"));

# app/.env — committed on purpose; a real-looking, revoked-in-advance key
DATABASE_URL=postgres://vulnerly:vulnerly@localhost:5432/vulnerly
PAYMENTS_PROCESSOR_KEY=sk_live_51NxVulnerlyDemoKeyDoNotUseAnywhere0000

{
  "name": "vulnerly-api",
  "dependencies": {
    "express": "^4.19.2",
    "pg": "^8.11.5",
    "dotenv": "^16.4.5",
    "lodash": "4.17.15",
    "jsonwebtoken": "8.5.1"
  }
}
// app/package.json — lodash and jsonwebtoken pinned old on purpose;
// both version lines carry real, publicly documented critical CVEs.
// Part 3's SCA gate is what's supposed to catch this.

# Dockerfile — unpinned base, root, no multi-stage. Part 4 rewrites this.
FROM node:18
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "app/src/index.js"]

# infra/main.tf — Part 5 fixes both of these
resource "aws_s3_bucket" "exports" {
  bucket = "vulnerly-transaction-exports"
  acl    = "public-read"                # transaction-export logs, world-readable
}

resource "aws_security_group" "db" {
  name = "vulnerly-db-sg"
  ingress {
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]         # Postgres reachable from the whole internet
  }
}

# .github/workflows/ci.yml — a pipeline that runs and reports nothing. Parts 2-6 each add a required check.
cat > .github/workflows/ci.yml <<'YAML'
name: ci
on: [pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: cd app && npm install
YAML

git add -A
git commit -m "Seed Vulnerly: the deliberately vulnerable capstone starter"
git remote add origin https://github.com/<you>/vulnerly.git
git push -u origin main

That commit is your baseline. Every later part in this capstone diffs against it — Part 2 rewrites the query and moves the key out, Part 3 bumps lodash and jsonwebtoken, Part 4 rewrites the Dockerfile, Part 5 fixes main.tf, Part 6 confirms the XSS and IDOR are gone from the outside. None of that happens today. Today you look at exactly this code and draw what it actually does, not what a tidier version of it would do.

Vulnerly's architecture, and where the one trust boundary sits

☺ Like you're 10: Four things, one arrow diagram, and a single dashed line marking the one spot a stranger can reach in from outside.

Strip away the seeded bugs for a moment and Vulnerly's runtime shape is small: a merchant's browser calls the API to search transactions or fetch a single reconciliation record; the API queries Postgres directly using the code above; and a scheduled job on the API exports transaction logs into an S3 bucket, the same export path whose Terraform-defined bucket policy Ledgerly's own incident review flagged as a real, if secondary, gap. Four elements, one trust boundary — exactly where the capstone hub said to draw it: the line where the public internet meets the API. Everything to the right of that line is Vulnerly's own environment; everything to the left is a browser you don't control, run by a person you haven't authenticated yet when the request first arrives.

Two things worth naming before you open Threat Dragon. First, this is the runtime diagram — Vulnerly's delivery pipeline (GitHub Actions → registry → the cluster Part 4 stands up) is a second, separate trust boundary, one a browser never crosses but a compromised CI credential does. Threat Dragon supports multiple diagrams inside one model file; add a second, lighter one for the pipeline rather than cramming both concerns onto a single canvas — the findings table below covers both. Second, notice what's not drawn: no authentication step sits between the merchant and the API. That's not an omission on your part — it's an accurate reflection of Vulnerly's actual code above, and it's itself a finding, not a diagram bug.

Installing OWASP Threat Dragon

☺ Like you're 10: A free drawing tool built specifically for this exercise — pick whichever version means you spend your time threat modeling, not fighting the installer.

OWASP Threat Dragon is a free, open-source threat-modeling tool that gives you a DFD canvas with the same four shapes covered on the threat modeling page — external entity, process, data store, trust boundary — plus a per-element threat editor that pre-fills a short list of likely STRIDE categories based on the shape you clicked (a Process gets all six; a Data Store gets a narrower default set). Three ways to run it, in order of least setup:

• Hosted web app. The fastest path — search "OWASP Threat Dragon" for the current hosted URL (it's moved domains before, so don't hardcode an old bookmark), sign in, and start modeling with nothing installed locally.
• Self-hosted via Docker. The project publishes an owasp/threat-dragon image; confirm the exact docker run incantation and port mapping on the project's current GitHub README before copy-pasting an old one — both have shifted across major versions.
• Desktop app. An Electron build is published as a GitHub release for macOS, Windows, and Linux — fully offline, no account needed, the right choice if Vulnerly's threat model shouldn't leave your laptop yet.

Whichever you pick, create a new, empty threat model named "Vulnerly" and confirm you're looking at a blank canvas before going further.

Drawing the DFD and running the STRIDE pass

☺ Like you're 10: Draw the four shapes, draw the one dashed line, then ask all six STRIDE questions about everything that touches that line — and about everything that doesn't, too.

Add the four elements from the diagram above to the canvas — Merchant (browser) as an external entity, Vulnerly API as a process, Postgres and S3 export job as data stores — connect them with the same three flows, and draw the trust boundary exactly where it sits above. Then open each element's threat editor and work through Threat Dragon's per-element suggestions one at a time. Treat the tool's pre-fill as a floor, not a ceiling: it tells you which STRIDE categories are usually worth asking about for a given shape, not the full extent of your obligation for this specific app — add a category by hand anywhere Vulnerly's actual code calls for it, the same warning the threat modeling page makes about STRIDE being a checklist for coverage, not a formula for precision.

Working the canvas element by element against the actual scaffold code above produces this table — nine ranked findings, comfortably past the hub's five-threat minimum, and the SQL-injection and IDOR rows are in it exactly as promised:

The top three attack paths

☺ Like you're 10: The table above is nine separate gaps in the fence. This part is picking the three worst ones and walking through exactly how a fox would actually use each — start to finish, not just "there's a gap here."

Nine ranked findings is the breadth pass — STRIDE over every element, the same sweep the threat modeling page covers. What earns the name "attack path" is the depth pass: picking a small number of findings worth walking end-to-end, as a chain an actual attacker would follow, using the same attack-tree thinking that page introduces as STRIDE's complement. These three are the ones worth that treatment, because each maps to exactly one specific control the very next capstone parts implement.

Attack path 1 — a leaked key and a SQL injection are two doors into the same room

Step one: an attacker with read access to the vulnerly repo — a public fork, a leaked clone, a former contractor's stale access — finds PAYMENTS_PROCESSOR_KEY sitting in plain text in app/.env, committed on the very first push. Step two, and this is the part that makes the finding worse than a simple leaked-key story: the attacker doesn't even need that key. The reconciliation search endpoint's string-concatenated query is a classic injection point — a crafted merchant parameter turns LIKE '%...%' into an arbitrary UNION SELECT, pulling every row out of transactions without ever touching the leaked secret. Step three: either path lands on the same table — merchant names, transaction volumes, and reconciliation data — the identical shape of exposure as the real incident in the Ledgerly case study, except this time closing only one of the two doors leaves the other one wide open.

Control landing in Part 2: gitleaks (or TruffleHog) as a required pre-merge check catches the committed key before it ever reaches a shared branch, and the key itself moves out of .env into HashiCorp Vault as a runtime-fetched credential. Semgrep as a second required check flags the string-concatenated query pattern; the fix is a parameterized query, not a rewritten error message.

Attack path 2 — a five-year-old dependency CVE is a second way into the same process

Vulnerly's package.json pins lodash@4.17.15 and jsonwebtoken@8.5.1 — both real version lines with publicly documented critical-severity advisories (verify the exact CVE identifiers and the affected code paths against the current NVD or GitHub Advisory Database entries before you write them into a real report; version-to-CVE mappings are exactly the kind of detail that's worth re-checking rather than trusting from memory). Either dependency sitting in the require graph of a route that handles untrusted input is a live exploitation surface, not dead weight — a vulnerable transitive dependency doesn't announce itself just because nobody imports it directly by name. Whatever the specific primitive turns out to be — prototype pollution, an authentication-bypass class of bug in token verification — the pod it runs in is the same pod holding the live Postgres connection and, until Part 2 fixes it, the payments key. One exploited dependency is not a contained foothold; it's standing where the API already stands.

Control landing in Part 3: an SCA gate (Trivy, or Snyk/OWASP Dependency-Check) blocks any build where a direct or transitive dependency carries a critical or high-severity CVE with an available fix, backed by a Syft-generated SBOM so the next CVE announcement can be checked against exactly what's deployed in minutes, not by re-scanning everything from scratch.

Attack path 3 — an unpinned, unsigned image turns one compromise into every compromise

Nothing in Vulnerly's current pipeline distinguishes an image GitHub Actions legitimately built from one pushed by anyone else holding registry credentials — no signature, no attestation, no admission check either. Chain that with attack path 1: a leaked credential with registry scope, or a CI runner compromised through attack path 2's RCE, can swap the image the cluster is watching for a backdoored one, and because the Dockerfile never drops root, whatever runs inside that container runs with more reach than the app itself ever needed. Kubernetes pulls whatever the tag currently resolves to and runs it with the API's real permissions — no step in the deploy path would have refused an image nobody can vouch for.

Control landing in Part 4: a rewritten, pinned, non-root, multi-stage Dockerfile, signed keylessly with cosign/Sigstore at build time, enforced by a Kyverno admission policy in the vulnerly namespace that rejects any image without a signature it can verify against Rekor's transparency log — an image nobody can vouch for never gets scheduled.

Committing the threat model

☺ Like you're 10: A model that only lives inside one browser tab, on one laptop, is worth exactly as much as a photo of a whiteboard nobody saved — it disappears the next time something gets cleared.

Export the model. Threat Dragon's file menu produces a JSON document; if you connected a GitHub provider instead of working from local storage, it can commit the file directly into a repo you've linked. Either path should end with the same result: a real file, with real content, in vulnerly. The shape looks roughly like this — treat it as the shape, not a byte-for-byte schema, since field names have shifted slightly across Threat Dragon's major versions; let the tool's own export be the source of truth, not this snippet:

{
  "version": "2.4.x",
  "summary": {
    "title": "Vulnerly — Part 1 threat model",
    "owner": "you",
    "description": "STRIDE pass over Vulnerly: browser, API, Postgres, S3 export job, plus the delivery pipeline."
  },
  "detail": {
    "contributors": [{ "name": "your-name" }],
    "diagrams": [
      {
        "title": "Vulnerly runtime architecture",
        "diagramType": "STRIDE",
        "cells": [
          {
            "id": "vulnerly-api",
            "shape": "process",
            "data": {
              "type": "tm.Process",
              "name": "Vulnerly API",
              "threats": [
                {
                  "title": "SQL injection via string-concatenated query",
                  "type": "Tampering",
                  "status": "Open",
                  "severity": "High",
                  "mitigation": "Part 2: parameterized query, Semgrep required check"
                },
                {
                  "title": "IDOR on /reconciliation/:id",
                  "type": "Elevation of privilege",
                  "status": "Open",
                  "severity": "High",
                  "mitigation": "Part 6: ownership check, verified by ZAP re-scan"
                }
              ]
            }
          }
        ]
      }
    ]
  }
}

mkdir -p security
mv ~/Downloads/vulnerly-threat-model.json security/threat-model.json

git add security/threat-model.json
git commit -m "Part 1: STRIDE threat model for Vulnerly (OWASP Threat Dragon)"
git push

What "done" looks like for Part 1

☺ Like you're 10: A pushed repo, a real diagram, nine written-down gaps, three of them walked start to finish, and all of it saved somewhere permanent.

At the end of this part: a pushed vulnerly repo holding the seeded scaffold above, a committed security/threat-model.json with at least the nine findings in the table — including the SQL-injection and IDOR rows the hub's own done-when calls out by name — every one carrying an explicit disposition, and three of those findings written up as full attack paths, each pointing at the specific tool and part that closes it. Nothing here is thrown away. Part 2 opens by reading this exact file, wiring gitleaks and Semgrep into the ci.yml stub above as required checks, and closing attack path 1 for real — not by rotating the leaked key, but by fixing both doors into that room.

Milestones

☺ Like you're 10: Tick a box only once you've actually watched it happen on your own screen — a step that "sounds right" isn't the same as one you've verified.

Work these in order. Progress saves in this browser.

Part 1 leaves you with a pushed vulnerly repo and a real, committed threat model — nine ranked findings, three of them walked as full attack paths, each pointing at the exact tool that closes it. Continue to Capstone Part 2 — Wire In SAST & Secrets Scanning, where attack path 1 gets closed for real. Or step back to the full capstone hub to see how this part fits the other six, and revisit Threat modeling and the Ledgerly case study for the concepts behind what you just built.