Threat Model → Copilot Design Guardrails
Warm-Up: Threat Model → Copilot Design Guardrails (~8 min)
Goal: Derive Copilot custom instructions directly FROM the threat model — turning identified threats into AI-enforced design guardrails.
📝 Open
docs/threat-to-instructions-worksheet.md— you’ll map threats to instructions as you work through this warm-up.
Every guardrail should map back to a threat. But in the AI-native era, we can go further: the threat model can directly PROGRAM the AI to avoid vulnerable patterns.
Step 1: Review the Threat Model
Open THREAT-MODEL.md and review:
- Assets (Section 1): What do we need to protect? (source code, secrets, dependencies, deployed app)
- Data Classification (Section 2): How sensitive is each asset?
- Threat Actors (Section 3): Who might attack us?
- Attack Vectors (Section 4): How could they do it? (Note the ”?” in the Current Control column)
Step 2: Derive Copilot Instructions from Threats
For each attack vector in rows 1–3 and 8, ask: “What Copilot instruction would PREVENT this threat at code generation time?”
| Threat Row | Attack Vector | → Derived Copilot Instruction |
|---|---|---|
| 1 | Secret leaked in commit | “Never hardcode credentials, API keys, or secrets” |
| 2 | SQL injection pushed to main | “Always use parameterized queries — never string concatenation” |
| 3 | Vulnerable dependency introduced | “Pin dependency versions; prefer well-maintained libraries” |
| 8 | Copilot suggests insecure pattern | “Validate all input; prefer established crypto libraries” |
This is NIST SSDF PW.1.1 in practice — risk modeling produces security requirements that are encoded directly into the AI assistant.
Step 3: Review the Threat-Derived Instructions
Open .github/copilot-instructions.md — this file was created by mapping each threat row to a concrete Copilot instruction. Every instruction traces back to a specific attack vector.
Step 4: Quick Verification
Ask Copilot to write a database query function:
@copilot Write a function that queries users by email from a PostgreSQL database.
Verify the response follows the threat-derived instructions:
- ✅ Uses parameterized queries (from Threat Row 2)
- ✅ No hardcoded credentials (from Threat Row 1)
- ✅ Uses environment variables for connection (from Threat Row 1)
- ✅ Includes input validation (from Threat Row 8)
Step 5: Frame the Exercises
“Each exercise today adds a guardrail. Each guardrail fills a gap in this threat model. The threat model doesn’t just identify risks — it programs the AI to avoid them.”
[!NOTE] NIST SSDF PW.1.1 calls for risk modeling — including threat modeling and attack surface mapping — to determine where security controls are needed. In this warm-up, we went beyond identification: we derived executable security requirements as Copilot instructions. Traditional security scans code AFTER it’s written. Threat-driven AI instructions prevent vulnerable patterns BEFORE code is generated.