Digital Library

Threat Modeling, 2nd Edition A Practical Guide for Development Teams [early release] (Izar Tarandach, Matthew J. Coles)（Z-Library）

,

Share E-Book
Read Without Registration

Threat Modeling, 2nd Edition A Practical Guide for Development Teams [early release] (Izar Tarandach, Matthew J. Coles)（Z-Library）

Author

,

Rating 3.5 AI initial rating

Log in to rate

Cybersecurity
Language English

Threat modeling is the most misunderstood part of development. Applied early, threat modeling is a cost-effective way to address risk before changes become a strain on your resources. Whatever your role, Izar Tarandach and Matthew Coles show you how to apply threat modeling to protect everything you're creating. This second edition of Threat Modeling builds on the original book's coverage of principles, techniques, and integrations.

Format PDF
Size 4.7 MB
(First 20 pages)

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

Page 1
(This page has no text content)
Page 2
Threat Modeling 2ND EDITION A Practical Guide For Development Teams With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles. Izar Tarandach and Matthew J. Coles
Page 3
Threat Modeling by Izar Tarandach and Matthew J. Coles Copyright © 2027 Izar Tarandach and Matthew J. Coles. All rights reserved. Published by O’Reilly Media, Inc., 141 Stony Circle, Suite 195, Santa Rosa, CA 95401. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (https://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Andy Kwan Development Editor: Shira Evans Production Editor: Beth Kelly Copyeditor: FILL IN Proofreader: FILL IN Indexer: FILL IN Cover Designer: FILL IN Cover Illustrator: FILL IN Interior Designer: David Futato Interior Illustrator: Kate Dullea August 2027: Second Edition
Page 4
Revision History for the Early Release 2026-11-04: First Release See https://oreilly.com/catalog/errata.csp?isbn=9798341674684 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Threat Modeling, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author(s) and do not represent the publisher’s views. While the publisher and the author(s) have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author(s) disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. 979-8-341-67464-6 [LSI]
Page 5
Brief Table of Contents (Not Yet Final) Chapter 1 Introduction (unavailable) Chapter 2 Modeling Systems (unavailable) Chapter 3 A Generalized Approach to Threat Modeling (unavailable) Chapter 4 Threat Modeling Methodologies (unavailable) Chapter 5 Automated Threat Modeling (unavailable) Chapter 6 Continuous Threat Modeling (unavailable) Chapter 7 Threat Modeling with AI (available) Chapter 8 Threat Modeling of AI (available) Chapter 9 Privacy (unavailable) Chapter 10 Own Your Role as a Threat Modeling Champion (unavailable)
Page 6
Chapter 1. Threat Modeling With AI A NOTE FOR EARLY RELEASE READERS With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles. This will be the 7th chapter of the final book. The GitHub repo will be made active later on. If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at sevans@oreilly.com. “A fool with a tool is still a fool.” , —Grady Booch There is a version of this chapter that opens with gasping excitement about large language models (LLMs), lists the seventeen ways AI will transform, nay, obliterate your security practice, and ends with a call to action that would make a startup pitch deck blush and run for the hills. This is not that version. There is another version that spends twenty pages telling you why AI is dangerous, unreliable, and will hallucinate your threat model into a pile of confidently wrong nonsense. This is not that chapter either. The truth, as usual, lives somewhere in the productive middle - which is, frankly, a more interesting place to be. AI tools, and specifically LLMs, are genuinely useful for threat modeling. They are also genuinely limited in ways that matter a lot. Getting the most out of them means understanding both sides of that balance well enough to use the right tool for the right job, without outsourcing the thinking that you are uniquely equipped to do, which would lead to insufferable cognitive debt. That is what this chapter is about. We’ll cover what AI cannot do (and why the limits are structural, not accidental), what it can do well (and there is real value here), how to think about the human-AI working relationship, how these tools interact with the continuous threat modeling (CTM) methodology we explored in Chapter X, the specific skills that make this practical, and close up with a full exploration of an AI-infused continuous threat modeling workflow that weaves all of it together. The Silver Bullet Problem Almost every generation of security technology pops up as the silver bullet that will finally make security easy. Firewalls, intrusion detection systems, vulnerability scanners, static analysis, just-in-time security training, each one of these was once introduced with a promise of transformation, and each required years of hard-won experience before practitioners understood what these tools were actually good for. AI is no different, but the specific nature of its limitations makes it somewhat distinct, because they are not the same limitations as a scanner or a firewall. A firewall doesn’t hallucinate new rules or packets it hasn’t seen. A vulnerability scanner doesn’t give you a confident answer when it has no idea what it’s talking about (well, at least the good ones don’t). A static analysis tool doesn’t know what the security collective knowledge is, beyond that embedded in its rules, but it also doesn’t pretend to know things it can’t possibly know. AI does all of these things, which makes it both more interesting and more treacherous. And definitely not a silver bullet. The Wall
Page 7
Here is a most useful mental model for AI in threat modeling: imagine you are playing tennis, but you are alone on the court. You could keep smashing balls into the net, or you could find a wall to hit against. The wall isn’t a partner. It doesn’t have strategy, it can’t lob a surprise shot over your head, and it will never surprise you by knowing that your serve is weak because it watched your last match. But it does something valuable: it bounces the ball back. It forces you to move. It makes you think about return angles you wouldn’t encounter just shooting balls into an empty court. That is roughly the best relationship between AI and threat modeling. The model rebounds. It prods. It occasionally produces something genuinely useful that forces you to reconsider a design choice, stretching your own capabilities and talent. When you’re a lone security practitioner in a ten-person startup, or a developer trying to evaluate the security angles of a story at eleven in the morning before the sprint planning call, having a wall to practice against is meaningfully better than having nothing at all. But the wall is not your doubles partner. It doesn’t have ownership over what is being secured. It doesn’t know your production secrets (well, it shouldn’t!), your specific architecture decisions, or the reason the authentication service has that peculiar little backdoor that nobody wants to discuss. That tribal knowledge lives with the humans in the room. And if you’re going to say “there are tools out there that inform the LLM of all that!” then we will retort: do you actually want your LLM to know all that, knowing it doesn’t care who it will share with ? What AI Knows (and Doesn’t) AI knows what the security community knows, collectively. The training corpus of a large language model is, in some sense, a compressed representation of everything that has been written about software security up to some point in time. That is genuinely useful. You should not be surprised by what the model comes up with, and if you are, that is actually a sign it has done its job as the partner wall, and you have some studying to do. But knowing what everyone knows is different from imagining what nobody has imagined yet. The new attack class, the specific quirk of your CI/CD pipeline, the implicit trust assumption that developed organically over all those years of organic growth, these are not in any training corpus. Sure, you can fine-tune the model. Add a RAG. Thousands of lines of markdown. But still, an AI can not divine them from a description of your system. That kind of higher-level reasoning is still on you. You will need to follow, control and direct the living changes of your system faster than the LLM can learn them, simply because reality and the LLM body of knowledge live in different time scales. Then there is the confidence problem. A language model will always have an answer. It will speak confidently about things that are matters of opinion, contested by experts, or simply wrong. This is not a failure mode that a model can be trained out of, because the model has no reliable mechanism to know what it doesn’t know, and it aims to please. It is rewarded for giving a “good” explanation, not a correct one. The responsibility for that calibration rests with the human reading the output. WARNING: VIBE THREAT MODELING The temptation is real. You paste a system description into a chat window, the model produces a list of threats with CVSS scores and mitigation recommendations, and you ship it as the threat model. This is vibe threat modeling, and it ages badly. The model is producing what a threat model looks like, not what a threat model is. The difference shows up six months later when a finding that was never in the list, because it wasn’t in the training data, or wasn’t derivable from the description alone, becomes a real incident. Don’t let the model create threats on autopilot. The Context Management Problem At the time of writing, LLMs and the interfaces we use to “talk” to them don’t have memory. There is a window of context that is passed to the LLM, subject to restrictions like memory (RAM) size, number of tokens, all the auxiliary parts of the prompt that get passed around, compression and repetition. The length of the context
Page 8
becomes a factor that dictates which model to use, at times. Maintaining your context under control, within a size that will allow useful output but not lead the LLM to get lost in the length, is paramount. Large contexts lead to failures, and even the positioning of information inside the context is relevant to the quality of the output. Remember, you are talking to a golden fish. It has no memory of your previous interaction beyond what appears in its ever lengthening context. From its point of view, when you ask “but what happens if I put the Frabjous server inside a VPC by itself and require authentication to the Chortler by adding a new certificate?”, it will need to rebuild its attention map from scratch. It doesn’t remember the components or their relationships and can “just” add this new factor then rethink the whole thing. It gets even worse if, like most security professionals, you are doing six things at the same time while thinking of the seventh and eight, and you do not confine your querying to the same area of interest, instead jumping from this component to that dataflow and back. For each query, the previous (and its answer) becomes spurious, just tokens filling the window that don’t really relate to what you want to know. The result is contradictory information between turns, or stale facts that get superseded in the same context window. Of course, the field is moving fast, and advancements happen every day. Who knows, by the time you’re reading these lines, a new architecture may have appeared that renders all this discussion moot. But meanwhile, this is the truth: context engineering leading to an appropriate relevant signal to total token ratio is necessary for appropriate results. How does this translate to treat modeling with LLMs ? The right unit of AI-assisted threat modeling is the story, the user flow, or the specific component, not the whole system at once. Let the pytm model-in-code carry the system-level context; let the AI reason about the specific change at hand. Have high-level but concise architectural documentation in Markdown that the agent can consume in small bites, rather than encyclopedic PDFs chunked in a RAG somewhere. CTM is story-focused by design. Each story is a small, bounded context. This is actually where AI assistance shines, as keeping the context small keeps the noise manageable. Working with LLMs, the attentive reader will also notice that long contexts may lead to “instruction amnesia”: those facts and instructions you gave early in the session get forgotten later (“avoid using third-party solutions; instead, direct me to mitigations I can develop myself” later turning into “download this, subscribe to that, let me use an external API for the other one”). And let’s not forget the “that’s a great idea! Let’s remove the authorization system altogether” aspect of LLM interaction: they will be much less willing to push back on something that did not fit the constraints 10 turns ago than now, when the length of the context has established a pattern of agreement between you and it. What AI Can Actually Do Given these limitations, let us be specific about where AI genuinely earns its keep in the threat modeling process. These address different aspects of the total problem, and may be best suited for different roles in the development process. Story Evaluation As mentioned, the most immediately practical use is evaluating user stories for security significance. CTM asks developers to identify stories that are security notable events, stories where the change touches authentication, authorization, data flows, trust boundaries, cryptography, or input handling, among others. When sprints move fast and backlogs grow faster, this is exactly the kind of first-pass filter where AI can add value. Consider this user story concerning the development of a typical developer portal: As a developer, I want to deploy a service via the developer portal so I don’t have to write system manifests manually.
Page 9
You can give this to a model, alongside the CTM secure developer checklist, and ask whether it has a security value. The model will respond, if it is behaving well, with something like: This story touches several checklist items: it adds web/REST functionality (new /api/v1/deployments endpoint), creates a new process and actor (a service account the portal uses to create resources), receives untrusted input (user-provided service name, image, and configuration values), and transmits data over the network (to the cluster API server). This story is a security notable event. Recommended label: potential- tm-update. What the model is doing here is not deep thought, it is pattern-matching the story against a structured checklist. But it does it quickly, and without the cognitive overhead of the developer having to remember the checklist while also trying to write the acceptance criteria. The value is not in the model’s insight, it is in the reduction of activation energy to get the secure design process going. The model will also catch obvious candidates: injection risks, access violations, things that smell like authorization holes. It will not, unprompted, catch that the internal identifier for a deployment is predictably incremented and therefore enumerable. That is a slightly deeper angle, requiring knowledge of development so far, or a lower-level level of design information. Think of it as the friend who always asks awkward questions at the worst time, it is useful and may make you think, but not necessarily comprehensive. Threat Brainstorming Beyond checklist evaluation, a model can be useful as a brainstorming surface when you are trying to answer “what can go wrong?”, again, as the wall to play ball with. You give the model a description of the system or change, ask what could go wrong, and use the output not as a definitive finding list but as a conversation starter. The output will reliably surface injection risks, access control issues, information disclosure vectors, and availability concerns. What it produces first are the low-hanging fruit threats , the things that are on every checklist. What it will occasionally produce, when asked to look harder, is a framing of the problem that forces you to think about something you might have skipped. The value here is not accuracy, since as we discussed the model will appear to have some opinion about things it cannot possibly know enough about to have an authoritative one. The value is in the nudge. Security analysis is partly about having the right questions at the right time, and a model that reliably surfaces the most common threat categories is a useful sparring partner even if it occasionally argues for something implausible, or misses something important. Just-in-Time Education One of the underappreciated use cases for AI in threat modeling is the micro-education moment. The CTM methodology deliberately keeps the security knowledge bar low for developers. The whole point is that you do not need to be a security expert to participate, you just need to know enough to recognize when a story is security notable, and the checklist handles that sufficiently well, to a point. But sometimes a developer identifies a story as a security notable event, and the curator or security champion or architect responds with “we need to address SQL injection risk here,” and the developer’s honest reaction is: “wait, what is SQL injection?” (you’d be surprised). In a traditional setting, that requires scheduling a training session, or pointing the developer at a document they will never fully read, or to a training module they will spacebar through, or hoping that the comment on the ticket is sufficient. With an AI, the developer can ask immediately, in context, and get an explanation calibrated to their specific change. That explanation is available at precisely the moment when the developer is motivated to understand it , which is far more effective than any brown-bag session. Who knows, depending where you are in the process, you may even get a PR out of it! (Verify it. Twice.) This is not a substitute for a security training program, but it dramatically lowers the barrier to developing security intuition over time.
Page 10
Language Normalization The fourth use case is unglamorous but genuinely valuable: normalizing the language in which findings are expressed. In a team where multiple people are contributing to a threat model over time, you will accumulate findings described in seventeen different ways. “User can access others’ data,” “IDOR vulnerability in profile endpoint,” “Missing object-level authorization,” and “BOLA” might all describe the same class of issue. Folding these back into a coherent threat model during updates is cognitive overhead that discourages updates, which means the model drifts from reality. An AI can standardize the language of findings, map informal observations to standard categories, and produce consistent output regardless of who wrote the original note. This is the kind of janitorial task that has no glory but meaningfully reduces the friction of maintaining a living threat model. It will also help recognize reappearing patterns across multiple systems that may share common components, strengthening the security contracts between them and allowing for developing centralized, common security patterns and services that would remove whole classes of findings directly. A Different Kind of Partner The four use cases above share a structural characteristic: in every one of them, the AI is doing something that is pointedly bounded and verifiable, and a human is making the decision about what to do with the output. The model evaluates a story, the developer decides whether to label it. The model brainstorms threats, the threat modeler decides which are relevant. The model educates while the developer decides whether the mitigation is appropriate. The model normalizes language, the security champion verifies accuracy. This is the right architecture for the human-AI relationship in threat modeling, and we should be explicit about it because the alternative is tempting: letting the AI make the determination, file the finding, and move on. “That way madness lies; let me shun that. No more of that.” (“King Lear”, Act 3, Scene 4. Shakespeare.) The Threat Modeling Manifesto states plainly that threat modeling is a team sport. It is a central motif that the authors have championed over our professional lives, and talked extensively about. The AI is a new kind of member in that team, one with unusual strengths (broad knowledge, constant availability, infinite patience with repetitive checklist work) and unusual weaknesses (no grounding in your specific system, no understanding of context beyond what you have given it, no accountability, and a propension to hallucinate). Treating it as an all- knowing oracle rather than a tool with specific capabilities will degrade the quality of the threat model and, eventually, the security of the system, not to mention the overall “quality” of the team work.
Page 11
Table 1-1. Weaknesses and Strenghts of Humans and LLMs in Threat Modeling Characteristic Human LLM Broad knowledge At a price - experts By definition Constant availability At a price - everyone By definition Infinite patience No. Yes! Lack of localized grounding No. Yes. Everything is everywhere all the time. Context beyond immediate Yes, and able to go fish No. GIGO. Accountability Yes. No. Propension to hallucinate At times. Many times. NOTE An AI used wisely in threat modeling is roughly analogous to a reference manual that can answer follow-up questions. You would not cite the reference manual as the author of a security finding; you would use it as one input among many. You are the owner of whatever the LLM helps you create. There is also an ethical dimension worth naming: an AI that makes security determinations without human oversight creates a class of risks that is structurally different from a scanner or a checklist. The scanner cannot argue with you. The checklist cannot misapply its own rules in ways that seem plausible. A language model can, and occasionally will. The human in the loop is not a formality, it is a load-bearing part of the architecture. If accountability is important to you and your team, you should take that into consideration every time an LLM is pulled in to participate in the dialog. “Because the LLM said so” should never be part of a conversation. Beyond the Checklist The CTM secure developer checklist is a practical, proven tool. It gives developers who are not security experts a concrete list of conditions under which they should label a story as security notable: added functionality, new actors, cryptography changes, untrusted input, new data flows. It works because it translates abstract security principles into concrete if-this-then-that rules. But checklists have a structural limitation that becomes visible at scale: they test for known conditions, and they test for them one at a time. A developer working through the CTM checklist is asking, in effect, “does my story match any of these rows?”, which is a filtering exercise. What the exercise does not do is reason about combinations, emergent properties, or changes to the system’s risk posture that are not captured by any individual row. This is where AI can move beyond checklist amplification and start doing something more interesting. Given the constraints and modes of failure we examined above regarding building the context for interaction between a model of your system and a LLM, there are very tangible advantages that can be achieved. We are sure that as you went over the reading, at times you stopped and said “but wait, I can give it much better context if I do X or don’t do Y”. And that is true.
Page 12
When you ask a model “does this story have a security value?” and provide the checklist, you are asking it to be a faster, more consistent version of the developer doing the filtering manually. That is useful. But when you ask the model “given everything you can infer about this system, given this carefully engineered context, what is the security impact of this change?” , and if the provided system context is reliably meaningful, you are asking it to do something the checklist cannot do: reason about the change in relationship to the larger system model. The model might theorize that a new endpoint, which on its own looks benign, creates a combination with an existing endpoint that enables an authorization bypass that neither endpoint enables independently. That is not a checklist item. That is threat reasoning. The model will not always succeed at this, not every model is even capable of this, and the output requires careful evaluation. But the capability to move beyond row-by-row checklist matching toward something closer to compositional reasoning is real, and it is one of the more interesting directions for AI in threat modeling. It is where the state of the art is taking us, with models being able to infer real vulnerabilities independently, starting from source code or executables. From there to a better threat modeling experience based on other artifacts is a short leap. If this sounds like a contradiction with the earlier parts of this chapter, it is not. It is a realization that the technology and the state of the art is moving blazingly fast, and that all signs point to movement towards more deductive capabilities in LLMs. We recognize that what we are writing here is a point in time set of assumptions, and we realize that soon all our assumptions here may be moot. But today, the practical implication is that checklist-based AI use is a starting point, not a destination. Use the checklist to reduce false negatives at scale , catching the obvious cases quickly. Then, for stories that warrant deeper analysis, move into a more open-ended conversation with the model where you provide system context and ask for reasoning, not just classification. And then bring the results to the curator for validation. NOTE When asking an AI to evaluate a story for security significance, do not just paste the story. Include a brief description of the surrounding system: what other components it touches, what trust boundaries exist, what data is involved. The model’s reasoning improves substantially when it has something to reason about beyond the story text itself. But know when to stop adding, as there is a clear point of diminishing returns. The checklist is not the enemy here. It is the foundation. AI does not replace it , AI extends it, at the cost of requiring more careful human oversight of what the extension produces, including a more pointed craft of the input that is given to it. Remember, always: GIGO. The Skills Understanding the theory is necessary but not sufficient. The practical path from “AI could help with threat modeling” to “AI is actively helping with threat modeling on my team” runs through tooling that is integrated into existing workflows, requires minimal context-switching, and produces output in a form that can be acted on immediately. To operationalize many of the concepts we presented above you can refer to https://www.github.com/izar/tm_skills. This is a set of useful coding agent skills, presented as Markdonw files, and easily ported to any of the different agents. These are not standalone applications. They are skills: prompts, context, and light automation that live in your development environment and can be invoked in the same place where the code already lives. There are three of them. The ctm Skill The ctm skill takes a user story and evaluates it against the CTM secure developer checklist. You invoke it with a story:
Page 13
/ctm “As a developer, I want to deploy a service via the portal so I don’t have to write manifests manually” The skill evaluates the story, identifies which checklist conditions apply, and produces a recommendation. ❯ /ctm "As a developer, I want to deploy a service via the portal so I don't have to write manifests manually." Start checklist. First find baseline threat model in current dir. Checklist progress: - Find baseline threat model → none found in /home/izar (user home, not project dir) - Enrich request - Run CTM Developer Checklist ★ Insight ───────────────────────────────────── - Story smells security-notable even before enrichment: portal = new input vector, manifest gen = command/template interpreter, service deploy = privileged op creating new processes. - CTM exists to catch exactly this class of story — one innocuous user story can trigger 4+ rows of the checklist. - Without baseline TM, analysis becomes generic. Baseline gives trust boundaries, existing authn/authz model, secret stores — without it we guess. Questions before proceed: 1. Baseline threat model — pick one: - (a) Point me at existing TM doc in some project dir - (b) Run /pytm or /4qpytm skill to build one now - (c) Proceed without baseline (degraded analysis — OK?) 2. Enrichment (story very thin): - Portal = existing internal devportal, or new build? - "Deploy service" = k8s manifests? Terraform? Cloud run? What target? - Manifest generation = templated by portal, or LLM/codegen? - Who authenticates to portal? SSO? What authz model — per-namespace, per-env, per-team? - Does deploy reach prod directly or through GitOps/PR gate? - Secrets injection part of scope? - Portal stores deploy history/logs? Answer 1 + as many of 2 as you know. Then run checklist. In the example above, a user story is provided with no context whatsoever. If you follow the output, the model has noticed that: first the skill asks the model to identify an existing threat model (remember, CTM begins with a baseline threat model that is enriched over time). It does not find one, so it suggests one is built first using the pytm or 4qpytm skills (see bellow). But then, it suggests another alternative: 1c, “proceed without baseline (degraded analysis - OK ?)”, which is actually emergent behavior coming from the model. Even without enrichment, the model has offered the insight that the story appears to be security notable. Let’s take the easiest path available, and proceed with option 1c: ❯ proceed without baseline Checklist updated: - Find baseline TM → none, proceeding degraded - Enrich → skipped (assumptions noted below) - Run CTM Developer Checklist Assumptions (flag if wrong): portal = authenticated web app; generates manifests (k8s/tf/etc) from user params; applies to cluster/cloud API; multi-tenant devs; some form of SSO expected. ★ Insight ───────────────────────────────────── - Self-service deploy portals classic supply-chain-into-prod surface. One form field reaches prod workload specs. - Manifest templating = injection sink. User value flows into YAML/HCL → into API server. Treat like SQL injection analog.
Page 14
- "Don't write manifests manually" literally means "give portal privilege user had". Portal becomes confused deputy. Biggest risk. Notable-event matches 1. Added functionality changing sensitive properties/objects - AuthN on portal (SSO/OAuth/SAML). - AuthZ per namespace/env/team, least-priv. Coarse now, design for fine-grained. - Secrets never cleartext in manifest templates / portal DB. - Server-side enforce — no client-side-only gating. 2. Created new process or actor - Portal service account to cluster/cloud = least privilege. Scope to target namespaces only, no cluster-admin. - Harden portal host (patching, minimize surface). - Credentials to deploy target stored in KMS/Vault, rotated. 3. Added Web/REST functionality - AuthN + AuthZ on every endpoint (including "preview manifest"). - Validate tokens/headers/cookies as untrusted. - TLS with current cipher suite, cert validation. - POST for deploy params, not GET (keeps values out of logs/URL). - Session fixation defense, rotate ID post-login, Secure+HttpOnly cookies. - CSRF protection on deploy endpoint (destructive op via browser). 4. Received uncontrolled input from untrusted source - Validate every form field server-side (image name, replicas, ports, env vars, resource limits). - Known-good allowlist for image registries, namespaces, service names. - Bound numeric fields (replicas, limits) — prevents resource-exhaustion manifests. - Encode values on injection into YAML/HCL templates. Prefer structured builders (e.g. k8s client objects) over string templating. - Fuzz parser of any custom DSL. 5. Used cryptography - Approved toolkit only. No custom crypto. - Secrets for deploy (registry creds, kubeconfigs) → Vault/KMS/Sealed Secrets. - No hardcoded keys in portal code or manifests. 6. Added embedded component - Template engine (Jinja/Helm/Kustomize), k8s/cloud SDKs → inventory them. - Threat-model each; check for template-injection CVEs (Helm/Jinja history). - Restrictive defaults, keep patched. 7. Transmitted data over network - mTLS or signed API calls portal→target cluster. - Replay protection on deploy requests (nonce/timestamp). - Session cannot be hijacked — HSTS, secure cookies. 8. Created install/patching capability (deploy = install analog) - Sign manifests / use image signature verification (cosign, Sigstore) at cluster admission. - Key rotation supported for portal→cluster credential. - Admission controller (OPA/Kyverno) gates portal output — defense in depth. 9. Created command interpreter / executes system command - Manifest templating = interpreter. Avoid shell=True, eval, raw kubectl apply -f <user-string>. - Use SDK objects, not string concatenation. - Path traversal check if user picks files/charts. - YAML loader = safe_load only. 10. Destroys/alters/invalidates system resources - 2FA/step-up auth on deploy-to-prod, delete, scale-to-zero. - Log requester identity + timestamp + target + diff. - Non-repudiation: signed log entries to append-only store. - Consider approval workflow (second reviewer) for prod. 11. Added log entry - No secrets/tokens/PII in logs (env vars often leak DB URLs, API keys — redact). - Tamper-evident log store. Centralized SIEM.
Page 15
Ticket recommendation Create potential-tm-update ticket. Suggested body: Title: [TM] Self-service deploy portal — update threat model Change: new web portal generates and applies deployment manifests on behalf of developers. TM impact areas: - new trust boundary: portal ↔ deploy target (cluster/cloud) - new privileged actor: portal service account - new input vector: portal form fields → manifest templates - new destructive capability: deploy/scale/delete via web UI - new secret custody: deploy creds held by portal Requested: TM curator review, confirm controls map to existing baseline (authn, authz, secret store, admission policy, audit log), identify gaps. High-risk items to prioritize: template injection, portal service-account blast radius, prod-deploy step-up auth. What the skill delegates to the AI: the checklist evaluation itself, the identification of applicable conditions, the initial mitigation suggestions. What the human decides: the enrichment to the context of the story, whether the assessment is accurate, whether the story should actually be labeled, which mitigations are appropriate given the specific system context, and whether the curator needs to be involved now or after implementation. The ctm skill does not replace the developer’s judgment. It gives the developer a structured analysis to agree with, push back on, or enrich. It might even give them a nudge to learn more. But remember: your mileage will vary, depending on the model and version you use. Expect uncertainty! The pytm Skill The pytm skill takes a plain-language description of a system and generates a complete pytm Python script that models the system. You invoke it like this: /pytm “The developer portal is a web app where developers log in via OIDC, manage their services, store API keys, and deploy to Kubernetes. It has a PostgreSQL database and writes audit logs.” ❯ /pytm "The developer portal is a web app where developers log in via OIDC, manage their services, store API keys, and deploy to Kubernetes. It has a PostgreSQL database and writes audit logs." Checklist: - Analysis - Mapping to pytm elements - Adding attributes - Create pytm script - Execute script - Validate script - Use case analysis Read pytm reference + check env. Analysis: - Actors: Developer (human), OIDC Provider (external IdP) - Servers: Portal web app - External entities: Kubernetes API, OIDC Provider - Datastores: PostgreSQL (service metadata + API keys), Audit log store - Boundaries: Internet, Corp/VPC, Cluster - Dataflows: dev→portal (HTTPS), portal↔OIDC, portal↔PG, portal→k8s API, portal→audit sink - Data: OIDC tokens, API keys (secret), service metadata, k8s manifests, audit events
Page 16
★ Insight ───────────────────────────────────── - API keys stored in PG = storesPII/high classification. pytm flags secret storage threats. - OIDC provider external = trust boundary crossing at auth. Redirect flow = separate dataflow from token exchange. - Audit log = separate Datastore with isLog=True, stops noise from write-only threats. Build script now. [ … redacted for brevity … ] Script syntax OK. Execute with --json. [ … redacted for brevity … ] JSON generated. Now DFD. [ … redacted for brevity … ] DFD rendered. Now seq — needs plantuml. Generate PUML first, render if possible. [ … redacted for brevity … ] All three artifacts present. Now business_tm.md. Peek findings.json first. [ … redacted for brevity … ] Checklist complete: - Analysis - Mapping - Attributes - Script - Execute (json + dfd + seq) - Validate - Use case analysis ★ Insight ───────────────────────────────────── - DS06 Data Leak + DR01 Unprotected Sensitive Data flagged on every dataflow = pytm default assumes data unprotected unless isEncrypted=True set on Data. Tighten by marking cookies/tokens/keys encrypted once TLS confirmed. - XML/SOAP threats (INP19/21/22/34, INP36/37) noise-spam for JSON-only portals. Add implementsAuthenticationScheme, providesConfidentiality, providesIntegrity on portal + mark flows to suppress. - Portal holds cluster SA token = AA03 Exploitation of Trusted Credentials. Priority mitigation: short-lived tokens via Workload Identity / projected SA tokens, not long-lived secret. Artifacts in /home/izar/tm/: - developer_portal_pytm.py — model script - findings.json — 120 findings, 33 unique threats - dfd.png — data-flow diagram - seq.png — sequence diagram (rendered via /home/izar/tools/plantuml.jar) - business_tm.md — use-case summary TODOs left in script: IdP location (SaaS vs on-prem), portal OS, PG at-rest encryption, audit sink type/port. ✻ Worked for 2m 0s The skill produces a complete portal_tm.py script that defines trust boundaries, actors, servers, datastores, and data flows. It runs the script to generate the data flow diagram and the initial threat report. It then summarizes the key findings, calling out the most significant ones with recommended mitigations into a “business level” threat model. This is not a trivial piece of work to do manually. Writing a complete pytm model from scratch, even for a reasonably simple system, requires familiarity with the library’s API, an understanding of which property flags
Page 17
affect which threat categories, and the patience to translate a system description into Python objects correctly. The skill handles the translation, while the human handles the evaluation of what was translated, but not before taking into account the fact that the input needs to be, as we have repeatedly pointed out, of sufficient quality and the fact that two runs of the same prompt may well generate quite distinct pytm models. The output of the pytm skill is not the end of the analysis. The generated model will not capture every nuance of the system. Properties may be set incorrectly because the description was ambiguous or because the model made wrong assumptions. The threat report will include findings that are not applicable. What the skill has done is produce a first draft of the machine-readable threat model that the team can now refine, version-control, and build on , instead of starting from a blank file: ❯ more tm/business_tm.md # Project: Developer Portal ## Structure The Developer Portal is a corporate self-service web application fronting the platform's deployment pipeline. A human Developer authenticates through an external OIDC Provider and, once a session is established, interacts with the portal over HTTPS to perform three primary operations: (1) manage service definitions, (2) store developer-owned API keys, and (3) trigger deployments to a Kubernetes cluster. The portal persists service metadata and API keys in a PostgreSQL datastore, emits audit events to a dedicated append-only audit log store, and calls the Kubernetes API server to apply generated manifests. Trust boundaries separate the public Internet (where the Developer and the OIDC Provider live) from the Corporate/VPC zone (portal, PostgreSQL, audit store) and from the Kubernetes Cluster zone. ## Apparent business case The portal exists to reduce deployment friction for internal developers: it removes the need to hand-author Kubernetes manifests and to directly hold cluster credentials. It centralises authentication through corporate OIDC, concentrates API-key custody in one audited store, and provides a single point of policy enforcement and audit for what would otherwise be scattered `kubectl apply` activity. The value is velocity (developers ship faster), governance (every action is attributable and logged), and blast-radius control (portal service account holds narrowly scoped cluster permissions instead of each developer holding cluster admin). ## Findings 120 threats raised across 33 unique threat IDs. Very High severity: - AC06 Using Malicious Files — Developer Portal Web App - AC17 Session Hijacking (Server Side) — Developer Portal Web App - DS06 Data Leak — all dataflows (login, manage services, OIDC token, PostgreSQL read/write, audit write, apply manifest, deploy trigger, session cookie, API-key submission) High severity: - AA03 Exploitation of Trusted Credentials — Portal - AA04 Exploiting Trust in Client — Portal - AC16 Session Credential Falsification through Prediction — Portal - AC22 Credentials Aging — PostgreSQL dataflows and API-key submission - CR03 Dictionary-based Password Attack — Portal - CR06 Communication Channel Manipulation — all dataflows - DE04 Audit Log Manipulation — Audit Log Store, PostgreSQL - DR01 Unprotected Sensitive Data — all dataflows - INP22 XML Attribute Blowup — Portal - INP34 SOAP Array Overflow — Portal - INP37 HTTP Request Smuggling — Portal - SC03 Embedding Scripts within Scripts — Portal - SC05 Removing Important Client Functionality — Portal Medium severity: - AC01 Privilege Abuse — Portal, PostgreSQL, Audit Log Store
Page 18
- AC05 Content Spoofing — all dataflows - AC07 Incorrectly Configured Access Control — Portal - AC08 Manipulate Registry Information — Portal - AC09 Functionality Misuse — Portal - AC11 Session Credential Falsification through Manipulation — Portal - CR08 Client-Server Protocol Manipulation — all dataflows - DE01 Interception — all dataflows - DE03 Sniffing Attacks — all dataflows - DO01 Flooding — Portal - DO02 Excessive Allocation — Portal, PostgreSQL, Audit Log Store - INP17 XSS Using MIME Type Mismatch — Portal - INP19 XML External Entities Blowup — Portal - INP21 DTD Injection — Portal - INP36 HTTP Response Smuggling — Portal Low severity: - CR05 Encryption Brute Forcing — Portal, PostgreSQL, Audit Log Store - HA03 Web Application Fingerprinting — Portal The 4qpytm Skill The 4qpytm skill is the most interactive of the three. It implements Adam Shostack’s Four Questions framework as a guided conversation, then proceeds to use pytm to beef up the analysis and create artifacts that can be taken further. The skill asks: What are we working on? It guides you through describing the system, asking clarifying questions, and building the data flow diagram. It then asks: What can go wrong? It runs pytm on the model you have built together, presents categorized threats, and invites discussion of each one. The next question is What are we going to do about it?, guiding you through mitigation selection for each finding, and helping you understand the security principles behind each decision. Finally: Did we do a good enough job?, when it reviews the coverage and grades the overall threat model. This skill is the fastest path from “I have an idea for a system” to “I have a threat model with tracked mitigations.” For a new project, a new service, or a major feature addition, it compresses what would otherwise be a multi-hour facilitated workshop into a focused conversation that can run in less than an hour. ❯ /4qpytm Start threat model. Question 1: What are we building? (Stop anytime: "I don't have more answers" / "go ahead with what you have".) ❯ I want to build a developer's portal. It is a web application that serves as an interface that my organization will exposed to developers who want to build on top of our platform, using our APIs and services. Good. Dev portal = web app for external devs to access APIs. Next questions: 1. Who uses it? External devs only, or internal too? Anonymous browse allowed, or login required? 2. Auth mechanism? OAuth, API keys, SSO? 3. What backend services sit behind portal? API gateway? Direct service calls? 4. Data stored? User accounts, API keys, usage metrics, docs content? 5. Hosted where? Cloud (AWS/GCP/Azure), on-prem?
Page 19
❯ Internal developers only. There will be no anonymous users. Login is required and done via our identity provider. Developers will be using SSO, but OAuth and API keys will be available as well. There will be an API gateway providing all functionality. We will store usage metrics, docs content, and metadata about the services developed. It is hosted on- prem. Noted. Internal only, SSO+OAuth+API keys, API gateway front, on-prem, stores metrics/docs/service metadata. More questions: 1. Identity provider = which? (Okta, AzureAD, Keycloak, custom?) 2. API keys stored where? Same DB as metadata, or secrets vault (Vault/HSM)? 3. Docs content = static (markdown repo) or user-editable CMS? Who can edit? 4. Service metadata = self-registered by devs, or curated by admin team? 5. Portal calls gateway directly, or through backend-for-frontend? 6. Any outbound integrations? (Git, CI/CD, Slack, ticketing?) 7. Admin role exists? What can admin do vs regular dev? ❯ We have a custom identity provider. The API keys are stored in a cleartext file. Noted. Custom IdP, API keys in cleartext file (flag for threat phase). More: 1. Docs = static or editable CMS? Who edits? 2. Service metadata = self-registered by devs, or curated by admins? 3. Portal → gateway direct, or via BFF/middleware? 4. Outbound integrations? (Git, CI, Slack, ticketing?) 5. Admin role? Privileges vs regular dev? 6. DB type for metrics/metadata? (Postgres, Mongo, etc.) 7. TLS everywhere, or internal plaintext? ❯ I have no more information Building pytm model now. In this excerpt, it is possible to see the initial behavior of the skill - the agent will keep asking for questions for as long as it needs to create a picture of the system being built. The user has the choice to answer those questions or simply say “i have no more answers”. The skill then proceeds with building the pytm model as the base for the threat inference. But check the first phase - see where it was said that the API keys would be stored in a cleartext file? The model already flagged that as a possible finding. Will it appear in the final threat model? Let’s see: Write(/home/izar/tm/tm/devportal_pytm.py) ⎿ Wrote 194 lines to /home/izar/tm/tm/devportal_pytm.py [ … redacted for brevity … ] Bash(xdg-open /home/izar/tm/tm/dfd.png >/dev/null 2>&1 & disown echo opened) ⎿ opened DFD opened. File: /home/izar/tm/tm/dfd.png.
Page 20
Diagram contents: - Actors: Internal Developer, Portal Admin (Corporate Network) - Servers: Developer Portal Web App (DMZ), Custom IdP + API Gateway (Backend) - Datastores: Service Metadata DB, Usage Metrics DB, Docs Content Store, API Keys Cleartext File - Flows: dev↔portal (HTTPS), portal↔IdP (SSO/OAuth), portal→gateway, portal→{metadata, metrics, docs, keys file}, admin→portal Do you recognize this as the system you are building? Any correction before I move to Step 2 (threats)? At this stage, the agent is showing (by way of xdg-open) the diagram it created based on the pytm script. It is requesting the user validate its view of the system, guaranteeing that both user and model have the same understanding of what is being built. If there are no corrections to be made, the skill moves to step 2: what could go wrong? ❯ This looks like my system. Moving to Step 2. Analyzing threats. Bash(source /home/izar/venv/bin/activate && python -c " import json from collections import Counter data = json.load(open('/home/izar/tm/tm/findings.json')) findings = data.get('findings', data) if isinstance(findings, dict): findings = findings.get('findings', []) print('Total findings:', len(findings)) ids = Counter(f.get('threat_id') for f in findings) print('Unique threat classes:', len(ids)) for tid, c in ids.most_common(8): sample = next(f for f in findings if f.get('threat_id')==tid) print(f'{tid}: {c}x | {sample.get(\"description\",\"\")[:80]}') ⎿ Total findings: 220 Unique threat classes: 52 DE01: 11x | Interception AC05: 11x | Content Spoofing DE03: 11x | Sniffing Attacks CR06: 11x | Communication Channel Manipulation CR08: 11x | Client-Server Protocol Manipulation DS06: 11x | Data Leak DR01: 11x | Unprotected Sensitive Data AC01: 7x | Privilege Abuse pytm findings: 220 threats, 52 unique classes. Top 5 threat classes (each 11x): 1. DE01 — Interception Adversary eavesdrops on communication between portal and backend (gateway, DBs, IdP, keys file reads). On-prem plaintext between portal → Metadata DB/Metrics DB/Docs/API Keys file likely unencrypted. 2. DE03 — Sniffing Attacks Attacker on internal network captures SSO assertions, OAuth tokens, API keys traversing dev↔portal↔IdP↔gateway. API keys in cleartext file especially at risk during transit/backup. 3. CR06 — Communication Channel Manipulation MITM modifies portal↔gateway or portal↔IdP traffic. Without mutual TLS, attacker forges auth responses or tampers API requests to backend services. 4. CR08 — Client-Server Protocol Manipulation Attacker crafts malformed HTTPS/SQL/file protocol messages portal→metadata_db or dev→portal. Example: tamper OAuth flow parameters, replay tokens. 5. DS06 — Data Leak / DR01 — Unprotected Sensitive Data API keys cleartext file = direct leak vector. Anyone with filesystem access (ops, backups, compromised portal process) reads all keys. Also usage metrics + service metadata leak dev identities.
The above is a preview of the first 20 pages. Register to read the complete e-book.

Recommended for You

Loading recommended books...
Failed to load, please try again later

Tip the Site

Scan the WeChat Pay or Alipay code to tip. No login required.

WeChat Pay
Alipay
← Back to List