Listen to this Post
Introduction:
As large language models (LLMs) increasingly penetrate cybersecurity workflows, security experts like Brook Schoenfield and Jason Haddix warn against over-reliance on AI for threat modeling. While AI can rapidly generate lists of potential threats, it lacks business context, risk tolerance, stakeholder expectations, and an understanding of manual compensating controls—outputting compliance checklists instead of nuanced risk analyses. The key is treating AI as an effort-saver, not a savior: use it to draft the obvious, then overlay human expertise to catch the wiggly, hand-wavvy details that truly define a system’s risk posture.
Learning Objectives:
- Differentiate between AI-generated compliance checklists and actionable threat models with business context.
- Implement a hybrid threat modeling workflow that leverages LLMs for baseline generation and human experts for risk calibration.
- Apply practical Linux/Windows commands and tool configurations to validate and extend AI-assisted threat models.
You Should Know:
- Extracting the Basics: Using AI to Generate a Threat Model Skeleton
Start by feeding your system architecture description into an LLM (e.g., OpenAI API, local Llama 3) with a prompt focused on STRIDE or PASTA. The output will list spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege threats. However, this is “what everyone should know”—generic and often missing critical nuances.
Step‑by‑step guide:
- Document your system’s components, data flows, trust boundaries, and external dependencies in plain text.
- Prompt the LLM: “Using the STRIDE methodology, generate a threat list for the following system: [paste your description]. Include potential threat actors and likely attack vectors.”
- Review the output. You will notice common threats (e.g., “SQL injection on the user database”) but no mention of specific business impact or existing manual approvals that mitigate them.
Linux/Windows command – Validate AI suggestions with automated scanners:
Linux – Scan for SQLi and XSS on a staging endpoint (using OWASP ZAP in headless mode) docker run -v $(pwd):/zap/wrk:rw -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \ -t https://your-staging-app.com -r zap_report.html
For Windows (PowerShell, using ZAP’s Windows executable):
.\zap-baseline.py -t https://your-staging-app.com -r zap_report.html
The report will show which AI-predicted vulnerabilities actually exist, helping you separate real from overhyped threats.
- Adding Business Context with Threat Modeling Tools (Threat Dragon + Custom Rules)
AI lacks knowledge of your organization’s risk appetite, regulatory constraints, and manual processes. To fix that, import the AI-generated baseline into an open-source threat modeling tool like OWASP Threat Dragon, then enrich it with business‑specific attributes.
Step‑by‑step guide:
- Install OWASP Threat Dragon via Docker:
docker pull owasp/threat-dragon:latest docker run -d -p 8080:80 owasp/threat-dragon:latest
- Create a new model, then manually add the threats suggested by the LLM.
- For each threat, add custom fields: `business_impact` (Low/Medium/High), `existing_control` (e.g., “Quarterly manual code review,” “MFA enforced”), and `risk_tolerance` (from the product owner).
- Use the tool’s reporting to generate a risk‑adjusted threat list. Compare it with the raw AI output—you’ll see that half the “critical” AI findings become “medium” or “informational” after controls are applied.
Windows alternative: Use Threat Dragon’s pre‑built Windows executable from GitHub Releases, or run the Docker command in WSL2.
- Command-Line API Security Checks to Validate AI‑Identified Endpoint Risks
AI often flags generic API risks (e.g., “lack of rate limiting,” “exposed debug endpoints”) without testing. Use real API security commands to verify.
Step‑by‑step guide:
- Extract API endpoints from the AI threat list.
- Test for rate limiting (Linux with `curl` and
time):for i in {1..100}; do curl -s -o /dev/null -w "%{http_code}\n" https://api.example.com/login -X POST -d 'user=test&pass=wrong'; done | sort | uniq -cIf you see only `200 OK` or `401 Unauthorized` without any
429 Too Many Requests, rate limiting is missing. - Check for exposed Swagger/OpenAPI specs:
curl -k -L https://api.example.com/swagger/v1/swagger.json | jq '.info.version'
If a JSON is returned, you may have an information disclosure risk.
Windows PowerShell equivalent:
1..100 | ForEach-Object { (Invoke-WebRequest -Uri "https://api.example.com/login" -Method POST -Body @{user='test';pass='wrong'} -UseBasicParsing).StatusCode } | Group-Object
If the AI missed these, you’ve found a “wiggly” detail that could lead to DoS or reconnaissance.
4. Cloud Hardening Commands to Mitigate AI‑Flagged Misconfigurations
AI threat models frequently output generic cloud risks like “publicly accessible S3 bucket” or “overly permissive IAM role.” Use cloud CLIs to verify and harden.
Step‑by‑step guide (AWS example):
- List all S3 buckets and check ACLs (Linux/macOS):
aws s3api list-buckets --query "Buckets[].Name" --output text | xargs -n1 aws s3api get-bucket-acl --bucket
- For any bucket showing
URI="http://acs.amazonaws.com/groups/global/AuthenticatedUsers", run remediation:aws s3api put-bucket-acl --bucket <bucket-name> --acl private
- Check IAM policies for wildcard
"Action": "":aws iam list-policies --scope Local --query "Policies[?contains(DefaultVersionId, 'v')].[bash]" --output text | while read p; do aws iam get-policy-version --policy-arn $p --version-id $(aws iam list-policy-versions --policy-arn $p --query "Versions[?IsDefaultVersion].VersionId" --output text); done | grep -B5 "\"Action\": \"\""
- Remediate by creating least‑privilege policies using AWS Managed Policies or a policy generator.
Windows CLI commands: Use the same AWS CLI commands in PowerShell after configuring aws configure.
These steps convert AI’s generic “checklist” items into measurable, mitigated security controls.
- Integrating Threat Models into CI/CD with Custom Python Scripts
AI-assisted threat modeling should be continuous. Write a lightweight Python script that runs in your pipeline, compares new architecture changes against a baseline AI model, and flags missing threat categories.
Step‑by‑step guide:
- Create a Python script (
ai_threat_diff.py) that calls an LLM API and parses the output:import openai, os, json openai.api_key = os.getenv("OPENAI_API_KEY") system_desc = open("current_architecture.txt").read() baseline_threats = open("baseline_threats.json").read() previously generated response = openai.ChatCompletion.create( model="gpt-4", messages=[{"role": "system", "content": "You are a threat modeling assistant. Output JSON only with keys: 'new_threats', 'missing_controls'."}, {"role": "user", "content": f"System: {system_desc}\nBaseline threats: {baseline_threats}\nWhat new threats appear?"}] ) print(response.choices[bash].message.content) - Integrate into a GitHub Action or Jenkins pipeline. On each PR, the script runs and posts a comment with new AI-suggested threats.
- Crucial human step: A security engineer reviews the comment, adds business context, and decides to accept, defer, or reject each item.
Linux command to run the script automatically:
python3 ai_threat_diff.py --diff-only --output report.md
This hybrid approach ensures AI does the heavy lifting of generating possibilities, while humans retain decision authority.
- Manual Compensating Controls Audit – The “Wiggly” Info AI Misses
AI has no way to know that your team uses a whiteboard threat modeling session every sprint, or that the compliance officer requires sign-off on every data store. Create a checklist to capture these human‑centric controls.
Step‑by‑step guide:
- After receiving the AI report, run a manual audit using a simple shell script to prompt engineers:
!/bin/bash echo "For each threat in the AI list, answer: Is there a manual process mitigating it? (yes/no)" while read threat; do read -p "$threat (yes/no): " answer if [[ "$answer" == "yes" ]]; then echo "$threat, manually mitigated" >> manual_controls.txt fi done < ai_threats.txt
- Merge `manual_controls.txt` into your threat model tool (e.g., Threat Dragon custom fields).
- Recalculate risk scores: any threat with an existing manual control automatically drops two severity levels.
Windows PowerShell equivalent:
$aiThreats = Get-Content .\ai_threats.txt
$manualControls = @()
foreach ($threat in $aiThreats) {
$answer = Read-Host "Does manual process mitigate '$threat'? (yes/no)"
if ($answer -eq 'yes') { $manualControls += $threat }
}
$manualControls | Out-File manual_controls.txt
This step transforms AI’s static “vulnerability” list into a dynamic risk register that reflects reality.
What Undercode Say:
- Key Takeaway 1: AI excels at generating exhaustive, generic threat lists (“what everyone should know”) but fails on business context, manual controls, and risk tolerance. Use it as a first-pass brainstorming engine, not a decision-maker.
- Key Takeaway 2: The most effective AI-assisted threat modeling workflow is bidirectional: AI drafts the obvious, then human experts overwrite, enrich, and prioritize using automated scanning tools, cloud CLIs, and manual audit scripts.
The post from Brook Schoenfield and Jason Haddix reinforces a crucial shift: security in a “post‑Mythos” world doesn’t discard AI—it circumscribes it. By layering commands (ZAP, curl, AWS CLI) and manual processes on top of LLM outputs, teams avoid the compliance‑checklist trap. The examples above show how to script this hybrid model into CI/CD, turning AI from a potential hallucination risk into a verifiable, accountable assistant. Remember: every AI‑generated threat requires a human “so what?” before it becomes actionable.
Prediction:
Within 24 months, most mature AppSec teams will adopt “threat modeling pipelines” where LLMs generate initial threat cards, automated scanners validate technical feasibility, and a risk board (human + policy engine) adjusts severity based on real‑time business context. AI will not replace threat modelers; instead, the role will shift to “AI shepherd” – tuning prompts, curating training data with internal risk registers, and coding custom connectors to CMDBs and GRC platforms. The biggest winners will be organizations that invest in API integrations between LLMs and their existing security tooling (Jira, DefectDojo, Threat Dragon). Those that just copy‑paste AI output into a Word document will drown in false positives and audit findings. The future is assisted, not autonomous—and that’s exactly how it should be.
▶️ Related Video (82% Match):
https://www.youtube.com/watch?v=61N1swhXJuQ
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Brookschoenfield Threatmodeling – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
