AI
Why STRIDE Alone Fails Kubernetes Architectures
STRIDE was developed by Microsoft in the 1990s. It categorizes threats into six types and still serves as a baseline, but it was built for monolithic perimeters. In Kubernetes, trust boundaries shift constantly. Ephemeral ports, service meshes, and cross-tenant identity propagation create attack surfaces STRIDE was never designed to see. Manual assessments compound the problem: a threat model finished today is outdated by the next deploy. CNCF and the security technical group have adapted STRIDE for containers, but the core gaps remain.
Block Decomposition: Focusing Teams on High-Risk Domains
Most teams skip threat modeling entirely or tick a compliance box. The block decomposition approach breaks an architecture into manageable security domains, then assigns the highest-priority STRIDE categories to each block. For the cross-tenant identity governance platform used as the worked example, the architecture splits into four blocks. Block three, covering cross-tenant identity and API management, gets the deepest analysis because it sits at the trust boundary where delegation drift, policy inheritance abuse, and token context loss produce the highest-impact attack surface. A compromised Helm chart or Argo CD repo in this block can escalate to cross-tenant privilege escalation.
Threat Actors and DREAD Risk Scoring
Four actor types appear in this architecture: external attackers probing APIs, malicious or accidentally misconfiguring insiders, supply chain actors targeting container images and GitOps repos, and automated bots running environment scans. Threat actor mapping aligns each type to STRIDE categories and MITRE ATT&CK stages. Spoofing dominates at the API gateway layer; privilege escalation dominates at the service-to-service plane. DREAD then scores each identified threat across five factors to produce a numeric risk level. The GitOps repo compromise example scores high, triggering documented mitigation steps.
Threat Modeling as Code in CI/CD
Threat modeling as code treats the threat model like any other pipeline artifact. Architecture components, data flows, and trust boundaries are declared in YAML or Terraform. Tools such as Threagile parse those files, generate a JSON risk report, and map each finding back to the declared architecture. Quality gates in the pipeline detect drift in trust boundaries whenever code changes. Tickets can auto-open in Jira when a threshold is breached. DREAD scores embed in the same config. Human judgment still covers final risk decisions; full automation is not achievable.
AI-Assisted Threat Modeling with stride-GPT
Hanna Papirna demos stride-GPT, an open-source tool that runs as a local Streamlit app and supports locally hosted models for strict data-sensitivity requirements. A generic high-level prompt returns broad risks like database tampering and MTLS bypass with no cross-tenant kill chain. Constraining the prompt to block three, seeding it with real STRIDE threat examples, and adding organizational context produces specific findings: SPIRE agent compromise, GitOps as a supply chain vector, and RBAC delegation drift. The block-focused model explains how an attacker forges an API gateway identity to bypass RBAC in a delegated tenant.
Stabilizing AI Output for Pipeline Use
Reproducible AI output requires tuning three parameters. Temperature drops to 0.3 so results are diffable in git. Top-P nucleus sampling constrains token selection to the top 90% of likely tokens, cutting outliers. Thinking budget, supported by Google Gemini, lets the model perform multi-hop checks and context-aware ranking before returning the full threat model. These values are starting points that need testing per environment. Combined with block-focused prompting, they produce a versioned, reproducible threat model that can run inside any CI/CD pipeline without manual re-seeding each iteration.
Notable Quotes
it’s because it’s simple, comprehensive, it’s structured coverage. So not no major threat category gets missed. Hanna Papirna · ▶ 05:09
your model becomes outdated by your next deploy Hanna Papirna · ▶ 06:05
when you decompose your architecture into specific blocks I gives you more actionable items rather than just a checklist of threats Hanna Papirna · ▶ 29:52
no matter what you do with your thread modeling exercise, there will be some level of human judgment required Emma Yuan Fang · ▶ 23:02
Key Takeaways
- STRIDE misses cross-tenant identity risks in Kubernetes without architectural decomposition first.
- Block decomposition cuts threat modeling scope to four focused domains, each with priority STRIDE categories.
- stride-GPT with temperature 0.3 and a scoped block prompt produces versioned, CI/CD-compatible threat models.
About the Speaker(s)
Emma Yuan Fang is a Senior Security Architect and Regional Practice Lead at EPAM Systems, overseeing security initiatives across UK&I, Switzerland, and Germany. She specializes in cloud-native security and leads diversity and inclusion efforts including the Women in Cybersecurity UK affiliate.
Hanna Papirna is a Lead Security Systems Engineer at EPAM Systems specializing in cloud-native platforms for enterprise clients. She designs identity guardrails, policy-as-code, and secure landing zones, bridging leadership strategy and hands-on engineering.