"What is the threat-modeling harness stack, and what inversion does it represent?"	The pipeline that ingests Terraform/IaC + OpenAPI + draw.io, merges into a normalized DFD model, renders as diff-able Mermaid, and runs STRIDE continuously. The inversion: the DFD is derived from GROUND TRUTH (the artifacts that define the system), so it cannot drift from the implementation — replacing the quarterly whiteboard ritual that decays immediately.	course2a::sdd08::recall
"What does each input modality contribute to the DFD?"	Terraform/IaC = resource topology, trust boundaries, exposure. OpenAPI = endpoints, request/response schemas, auth schemes (the API surface). draw.io/Mermaid (manual) = implicit flows and business logic the declarative artifacts don't capture. Manual augments, never replaces, the generated model.	course2a::sdd08::analysis
"Why Mermaid as the canonical DFD format?"	Mermaid is TEXT — it diffs in git, reviews in PRs, and regenerates cleanly. A visual diagram (draw.io native) is a picture; a Mermaid diagram is a source-controlled artifact. The manual layer (draw.io) feeds IN; the canonical output is Mermaid. This makes the DFD a versioned component of the architecture record.	course2a::sdd08::analysis
"How does STRIDE map to DFD element types?"	External Entity → Spoofing, Repudiation. Process → Spoofing, Tampering, Repudiation, DoS, EoP. Data Store → Tampering, Repudiation, Info Disclosure, DoS. Data Flow → Tampering, Repudiation, Info Disclosure, DoS. The rule lookup generates baseline threats per element; the LLM enriches with system-specific context.	course2a::sdd08::analysis
"Where does the LLM add value over a rule lookup in STRIDE?"	Rule lookup produces generic threats ('consider Spoofing') that engineers dismiss as boilerplate. LLM enrichment adds system-specific context from the merged model — 'the payment webhook (external entity) has no mTLS, so spoofing enables fraudulent refund issuance.' Specificity is what makes threats actionable. Rule = coverage; LLM = relevance.	course2a::sdd08::analysis
"Why derive the DFD from ground truth instead of drawing it?"	The generated DFD is parsed from Terraform and OpenAPI the team maintains. It cannot drift from the implementation because the implementation IS the input. When the IaC changes, the DFD regenerates, STRIDE re-runs, new threats appear as findings. Manual DFDs decay the day after the whiteboard session.	course2a::sdd08::analysis
"What is the key security finding regarding the stack's outputs?"	The generated DFD is an architecture map (resources, trust boundaries, exposures) and the threat list is a PRIORITIZED ATTACK PLAYBOOK with reasoning. Both are exactly what an attacker wants. Govern the DFD like the IaC it's derived from and the threat tracker like a pentest report. Read-only ingestion is safe; output handling is the surface to govern.	course2a::sdd08::analysis
"What is the LLM-enrichment attack surface, and how is it bounded?"	The STRIDE-enrichment LLM receives the merged model in its prompt. Malicious text in IaC/OpenAPI (a PR with a comment engineered to mislead) could steer it toward under-reporting. Bounded by: input treated as untrusted data, threat list is advisory (human review is the gate). Blast radius is findings-only — the LLM produces threats, not actions.	course2a::sdd08::analysis
"State the stack's score on the 12-module rubric. Why does it score high?"	47/60. Read-only (Sandboxing 5, Permission 5), composes mature parsers (Tool Design 4), LLM in bounded enrichment role (Subagents 4). Lowest: Execution Loop (3 — often on-demand, not CI-wired), State/Memory (3 — no DFD diffing or threat aging). Build-on: CI on every IaC PR, DFD diffing, threat aging.	course2a::sdd08::analysis
"Name 3 things the stack does better than manual threat modeling."	(1) DFD derived from ground truth, not memory (cannot drift, regenerates on change). (2) STRIDE threats are system-specific, not boilerplate (LLM enrichment adds resource names, data classifications, trust boundaries). (3) Mermaid is a source-controlled artifact (diffs in git, reviews in PRs, versioned).	course2a::sdd08::recall
"Name 3 things you would add to the stack."	(1) Run in CI on every IaC/OpenAPI PR — creation-time guardrail, not quarterly ritual. (2) Add DFD diffing as first-class output ('what changed, what new threats?'). (3) Add threat-aging model (stale/unaddressed/unexploited threats age down, don't clutter backlog at fresh priority).	course2a::sdd08::application
"What is a trust boundary in the DFD, and why is it a STRIDE hotspot?"	A DFD construct (VPC, subnet, security group, auth boundary) where data crosses into a different trust domain. Trust-boundary crossings are where spoofing, tampering, and information-disclosure threats concentrate — data entering a higher-trust zone is the classic attack surface. STRIDE analysis weights these crossings heavily.	course2a::sdd08::analysis
"State the stack's Architect's Verdict in one line."	Derives the DFD from ground-truth IaC + OpenAPI (cannot drift), renders as diff-able Mermaid, runs STRIDE continuously with LLM-enriched system-specific threats; build as a CI step on every IaC PR (creation-time guardrail), govern the DFD and threat list as sensitive architecture maps, add DFD diffing and threat aging.	course2a::sdd08::recall