8 Practical Threat Modeling Example Methodologies for 2025

Threat modeling can feel abstract, a theoretical exercise disconnected from the daily realities of code commits and pull requests. Its real value, however, is unlocked through practical application. In fast-paced CI/CD environments, identifying vulnerabilities before they reach production is not just a security best practice; it's a critical component for maintaining development velocity and protecting your software supply chain. Proactively finding and fixing security flaws early in the lifecycle is far more efficient and cost-effective than reacting to incidents post-deployment.

This article moves beyond theory by providing a detailed threat modeling example for eight distinct methodologies. We'll explore how to apply powerful frameworks, from established models like STRIDE and PASTA to more dynamic approaches like Agile Threat Modeling, directly within the context of automated development workflows. Each example is designed to be actionable, demonstrating how to integrate security thinking into your CI/CD pipeline, particularly in automated merge queue systems like Mergify.

You will learn how to:

• Deconstruct a CI/CD workflow to identify potential attack vectors.
• Apply specific modeling techniques to uncover hidden vulnerabilities.
• Translate security insights into concrete, automatable controls.
• Build a resilient and secure development process without sacrificing speed.

By the end, you'll have a practical playbook for implementing these threat modeling techniques to secure your own development lifecycle.

1. STRIDE Methodology

The STRIDE methodology, pioneered by Microsoft, is a foundational threat modeling example that provides a structured approach to identifying and categorizing security threats. It acts as a mnemonic for six key threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. By systematically evaluating each component of a system against these categories, teams can uncover a wide range of potential vulnerabilities before they are exploited.

The power of STRIDE lies in its simplicity and comprehensive coverage. It prompts engineers and security professionals to ask critical questions about their application's data flows, processes, and storage. For instance, when analyzing a Mergify workflow that interacts with an external API, the team would consider each STRIDE category. Could an attacker spoof the API's identity? Could they tamper with the data in transit? This systematic process ensures no major threat category is overlooked.

Strategic Breakdown

• Information Disclosure: This category is crucial for protecting sensitive data. An attacker might exploit a vulnerability to access secrets, logs, or user data. A practical concern here involves network communications; for example, understanding and preventing DNS leaks is essential to stop unintended data exposure during system interactions.
• Tampering: In a CI/CD context, this involves unauthorized modification of code, build artifacts, or configuration files. A Mergify rule that is tampered with could lead to unapproved code merges.
• Elevation of Privilege: This threat focuses on an attacker gaining permissions beyond what they are authorized for. A vulnerability could allow a low-privilege user to gain admin access to the CI/CD pipeline, granting them control over deployments.

Actionable Takeaways

• Integrate with DFDs: Begin by creating a Data Flow Diagram (DFD) of your application or CI/CD pipeline. Apply the STRIDE model to each element (process, data store, external entity) and data flow in the diagram.
• Use a Threat Matrix: Map the STRIDE categories against your system components in a simple table. This visual aid helps ensure comprehensive coverage and makes it easier to track identified threats.
• Document Everything: Clearly document trust boundaries, assumptions made during the analysis, and all potential threats identified. This documentation is vital for prioritizing mitigation efforts and future security reviews.

2. PASTA (Process for Attack Simulation and Threat Analysis)

The PASTA methodology is a risk-centric threat modeling example designed to align security activities with business objectives. Standing for Process for Attack Simulation and Threat Analysis, this seven-stage framework provides a comprehensive, attacker-focused view of the system. It guides teams from defining business objectives and technical scope all the way through to threat enumeration, vulnerability analysis, and risk mitigation.

Unlike more abstract models, PASTA forces a correlation between identified threats and their potential business impact. This ensures that security efforts are prioritized based on tangible risk to the organization. For a CI/CD pipeline managed by Mergify, this means evaluating threats not just in terms of technical exploits, but also how those exploits could impact release schedules, data integrity, or regulatory compliance. It bridges the gap between technical vulnerabilities and business consequences.

Strategic Breakdown

• Define Business Objectives (Stage I): This initial stage is critical. It involves identifying the primary business goals of the application or system. For a deployment pipeline, objectives might include "ensure 99.9% uptime" or "protect customer PII during deployment." All subsequent analysis is tied back to these goals.
• Decompose the Application (Stage III): Here, the team creates detailed diagrams, like DFDs, to understand the system's architecture and trust boundaries. This is where you map out how Mergify interacts with your code repositories, testing environments, and production servers.
• Analyze Threats (Stage IV): This stage involves using threat intelligence and attack trees to identify credible threats to the application. For instance, a threat could be an attacker exploiting a vulnerability in a third-party dependency to inject malicious code into a build. This step often incorporates insights gained from both static and dynamic application security testing to uncover potential weaknesses.

Actionable Takeaways

• Involve Business Stakeholders: Start the process by interviewing business owners and product managers to clearly define the business context and risk appetite. Their input is essential for prioritizing threats effectively.
• Leverage Attack Libraries: Use established attack libraries like the CAPEC (Common Attack Pattern Enumeration and Classification) or ATT&CK framework during the threat analysis stage to simulate realistic attacker techniques.
• Tie Mitigations to Risk: When proposing security controls, explicitly link each control back to the specific business risk it mitigates. This helps justify security investments and demonstrates clear value to leadership.

3. Attack Trees/Attack Graphs

Attack Trees offer a powerful, visual method for breaking down how a system might be attacked. Popularized by security expert Bruce Schneier, this threat modeling example uses a tree structure where the root represents the primary goal of an attacker, and the leaf nodes represent the specific, low-level actions they could take. This top-down approach allows teams to systematically map out all conceivable paths to a security breach, making abstract threats tangible and easier to analyze.

The core strength of Attack Trees lies in their intuitive and hierarchical nature. By decomposing a major threat, such as "Compromise the CI/CD pipeline," into smaller, more manageable sub-goals like "Gain access to source code repository" or "Inject malicious code into build process," teams can pinpoint the weakest links in their security posture. This method transforms threat modeling from a high-level discussion into a structured, analytical exercise, revealing the most likely and cost-effective paths for an adversary.

Strategic Breakdown

• Authentication System Bypass: A classic use case is modeling how an attacker might circumvent login mechanisms. The root goal would be "Bypass User Authentication." Child nodes could include "Steal Session Token," "Exploit 'Forgot Password' Flaw," or "Execute Credential Stuffing Attack." Each of these can be broken down further, showing exactly what needs to be protected.
• CI/CD Pipeline Compromise: In a Mergify context, an attacker's goal might be to "Force an unauthorized code merge." The Attack Tree could branch into sub-goals like "Tamper with Mergify rule configuration," "Gain unauthorized GitHub permissions," or "Spoof a required status check."
• Identifying the Path of Least Resistance: By assigning potential costs or probabilities to each leaf node (attack action), teams can quantitatively assess which attack paths are the most attractive to an adversary. This helps prioritize defensive measures against the most realistic threats.

Actionable Takeaways

• Start with the Crown Jewels: Identify the primary goal of a potential attacker. What is the worst-case scenario you want to prevent? Make this the root of your tree.
• Work Backwards: Decompose the primary goal into the intermediate steps required to achieve it. Use AND nodes for actions that must all happen and OR nodes for alternative paths an attacker could take.
• Assign Values: Where possible, assign metrics like cost, difficulty, or probability to each action. This transforms the tree from a simple diagram into a powerful risk analysis tool, highlighting the cheapest or easiest attack vectors to mitigate first.

4. Data Flow Diagram (DFD) Analysis

Data Flow Diagram (DFD) analysis is a foundational threat modeling example that visually maps how data moves through a system. By diagramming processes, data stores, data flows, and external entities, teams can clearly define trust boundaries. This visualization is critical for identifying potential attack surfaces where threats could manifest, making it an essential first step before applying methodologies like STRIDE.

The power of DFDs lies in their ability to simplify complex systems into an understandable visual format. For a CI/CD pipeline, a DFD would illustrate the journey of code from a developer's machine, through the Mergify engine, to build servers, and finally to production. This visual representation helps pinpoint exactly where data crosses a trust boundary, such as when communicating with a third-party code scanning service, highlighting a potential point of vulnerability.

Strategic Breakdown

• Process Identification: Each step in a workflow, like "Validate Pull Request" or "Deploy Artifact," is a process. Analyzing these helps identify potential points of tampering or spoofing. For instance, a compromised build process could inject malicious code into a deployment artifact.
• Trust Boundaries: These are the most critical elements in a DFD for security analysis. A line drawn between your internal network and an external API represents a trust boundary. Any data crossing this line must be scrutinized for potential information disclosure, tampering, or denial of service attacks.
• External Entities: These are actors or systems outside of your control, such as GitHub or an external package repository. Mapping interactions with them is crucial for understanding risks related to spoofing or repudiation, as you have less control over their security posture.

Actionable Takeaways

• Create Layered DFDs: Start with a high-level Context Diagram (Level 0) showing the entire system as one process. Then, break it down into more detailed diagrams (Level 1, 2) to analyze specific components and interactions more closely.
• Mark Trust Boundaries Explicitly: Use a distinct visual style, like a red dashed line, to clearly mark every trust boundary on your diagram. This immediately draws attention to the most sensitive areas of your system architecture.
• Validate with System Experts: Always review your DFDs with the architects and developers who built the system. Their input is invaluable for ensuring the diagram accurately reflects reality and that no critical data flows or interactions have been missed.

5. Persona-Based Threat Modeling

Persona-based threat modeling shifts the focus from abstract threats to realistic, human-centric attack scenarios. This approach involves creating detailed profiles of potential attackers, known as personas, complete with their motivations, skills, resources, and goals. By thinking like specific adversaries, such as a disgruntled insider or a sophisticated nation-state actor, teams can develop a more intuitive and relatable understanding of the risks their system faces.

The strength of this threat modeling example lies in its ability to make security personal and concrete. Instead of asking "How could data be tampered with?", the team asks, "How would 'Alex,' our persona for a financially motivated cybercriminal, try to tamper with our CI/CD pipeline to inject malicious code?" This perspective helps prioritize defenses against the most likely and impactful attackers, ensuring security efforts are targeted and effective.

Strategic Breakdown

• Insider Threat Persona: This persona is critical for CI/CD security. An insider, like a disgruntled developer, might have legitimate access to the Mergify configuration. Their goal could be to bypass required checks to merge a backdoor into production, making them a high-priority threat.
• Script Kiddie Persona: This represents an opportunistic, less-skilled attacker using publicly available tools. They might exploit a known vulnerability in a third-party dependency used in the build process. Their motivation is often curiosity or notoriety rather than financial gain.
• Organized Crime Persona: This persona has clear financial motives and significant resources. They would target the CI/CD pipeline to steal proprietary code, API keys, or customer data stored in build artifacts, looking for vulnerabilities that provide direct access to valuable assets.

Actionable Takeaways

• Develop 3-5 Core Personas: Start by defining a small, manageable set of attacker personas that represent the most relevant threats to your system. Include their background, technical skills, motivations, and likely targets.
• Map Personas to System Components: For each component in your Data Flow Diagram (DFD), analyze how each persona would try to attack it. A nation-state actor might target the underlying infrastructure, while an insider focuses on the application logic.
• Review Personas Regularly: The threat landscape is constantly changing. Revisit and update your personas quarterly or annually based on new threat intelligence to ensure your security posture remains relevant and robust.

6. Cyber Kill Chain Analysis

The Cyber Kill Chain, a model developed by Lockheed Martin, provides another valuable threat modeling example by outlining the sequential stages an attacker typically follows to achieve their objective. This framework helps organizations understand the entire lifecycle of an attack, from initial reconnaissance to final execution. By mapping defenses to each stage, teams can identify opportunities to disrupt the attack chain and prevent a successful breach, moving beyond just point-in-time vulnerability fixes.

This model's strength is its focus on the attacker's process. Instead of just asking "what can go wrong?", it asks "how would an attacker get from the outside all the way to our critical assets?". Applied to a CI/CD pipeline, this helps visualize how an attacker might first perform reconnaissance on public repositories, then deliver malware through a compromised developer tool, and eventually gain control over the build server to achieve their goals.

Strategic Breakdown

• Reconnaissance & Weaponization: These early stages are often overlooked. An attacker might analyze public git commits to find developer credentials or study open-source dependencies for known vulnerabilities. They could then craft a malicious pull request or dependency package to exploit the system.
• Delivery & Exploitation: This involves getting the malicious code into the CI/CD environment. A common vector is a compromised third-party Action or Orb. Once delivered, the exploit could be a script that runs during the build process, taking advantage of overly permissive runner permissions.
• Installation & Command & Control (C2): After a successful exploit, the attacker establishes a foothold. This could involve installing a reverse shell on a build agent that communicates with an external C2 server, giving them persistent access to the pipeline infrastructure.

Actionable Takeaways

• Map Controls to Stages: For each stage of the kill chain, identify and document the corresponding security controls you have in place. For example, your defense against "Delivery" might be dependency scanning and mandatory PR reviews.
• Focus on Disruption: The primary goal is to "break the chain." Even if you cannot prevent the initial reconnaissance, strong controls at the "Exploitation" or "Installation" stage can stop the attack from progressing.
• Leverage Threat Intelligence: Use threat intelligence feeds to understand the specific tactics, techniques, and procedures (TTPs) that attackers are using. This makes the Cyber Kill Chain model less theoretical and more grounded in real-world attack scenarios.

7. MITRE ATT&CK Framework Integration

The MITRE ATT&CK framework is a globally accessible knowledge base of real-world adversary tactics and techniques. Unlike abstract models, ATT&CK provides a concrete, empirically-validated catalog of attacker behaviors, making it an invaluable threat modeling example for teams wanting to base their defenses on known, observed threats. Integrating this framework shifts threat modeling from a theoretical exercise to a data-driven process focused on how attackers actually operate.

When applied to a system like Mergify, ATT&CK helps teams move beyond generic threats. Instead of just considering "tampering," a team can model specific techniques like T1199, "Trusted Relationship," where an attacker might compromise a trusted third-party service that integrates with the CI/CD pipeline. This level of detail provides a much clearer picture of the attack surface and informs the creation of highly specific security controls.

Strategic Breakdown

• Initial Access: This tactic is critical for understanding how an adversary could first penetrate the CI/CD environment. A relevant technique might be T1189, "Drive-by Compromise," where a developer visits a compromised website that exploits a browser vulnerability to gain access to their machine and, subsequently, their Git credentials.
• Execution: This covers techniques for running malicious code within the environment. For instance, T1059.004, "Command and Scripting Interpreter: Unix Shell," could be used by an attacker who has gained access to a build runner to execute arbitrary commands, potentially stealing secrets or manipulating artifacts.
• Credential Access: This focuses on how attackers steal account names and passwords. Technique T1552, "Unsecured Credentials," is highly relevant in CI/CD pipelines, where secrets might be unintentionally exposed in logs, environment variables, or unsecured configuration files.

Actionable Takeaways

• Map Controls to Techniques: Use the ATT&CK framework to assess your existing security controls. For each component in your Mergify workflow, identify which ATT&CK techniques are mitigated by current defenses and which represent gaps.
• Prioritize Based on Relevance: Start by focusing on tactics and techniques most relevant to your technology stack and threat landscape. For a cloud-native CI/CD pipeline, tactics like "Initial Access" via cloud accounts and "Execution" within containers are high-priority areas.
• Leverage ATT&CK Navigator: Use the ATT&CK Navigator tool to visualize and analyze your coverage. This helps communicate security posture to stakeholders and plan defense improvements, a key aspect of robust enterprise software security.

8. Agile Threat Modeling

Agile threat modeling adapts traditional security practices to fit the fast-paced nature of modern development cycles. Instead of a single, upfront security assessment, this approach integrates continuous, lightweight threat analysis directly into sprints. It emphasizes collaboration and empowers development teams to own security by making it a recurring activity within their existing CI/CD workflows, much like testing or code reviews.

This iterative model ensures security keeps pace with development, preventing it from becoming a bottleneck. For instance, a team using Mergify could incorporate a quick threat modeling discussion during sprint planning for a new feature that handles sensitive user data. This proactive, just-in-time approach allows teams to identify and address potential security risks early and often, making it an excellent threat modeling example for DevOps environments.

Strategic Breakdown

• Continuous Integration/Continuous Deployment (CI/CD) Security: Agile threat modeling is perfectly suited for CI/CD pipelines. Security checks and threat assessments can be automated and embedded into the build and deploy stages, ensuring that security is not an afterthought. For example, integrating automated security scanning tools becomes a natural extension of the agile process.
• Microservices Architecture: In a microservices architecture, where services are developed and deployed independently, agile threat modeling allows teams to assess the security of each service individually. This targeted approach is more manageable and effective than trying to model a large, monolithic application.
• Integrating into Stories: Security requirements are treated like any other user story. Acceptance criteria for a new feature might include "The new API endpoint must be protected against SQL injection." This makes security work visible, trackable, and part of the team's regular cadence.

Actionable Takeaways

• Use Threat Modeling Cards: Create simple cards for common vulnerabilities or security patterns relevant to your technology stack. During sprint planning, teams can quickly review these cards against new user stories.
• Automate Where Possible: Integrate automated tools into your pipeline to handle repetitive checks. You can explore a variety of code security scanning tools that fit seamlessly into a CI/CD workflow, providing rapid feedback.
• Hold Brief, Focused Sessions: Dedicate 15-30 minutes during sprint planning or backlog grooming to discuss the security implications of upcoming work. Keep the focus narrow and on the features being developed in that sprint.

Threat Modeling: 8-Method Comparison

Securing Your Merge Queue with Smart Threat Modeling

Throughout this guide, we've explored a diverse set of threat modeling methodologies, moving from high-level frameworks to granular, tactical approaches. Each threat modeling example, from the foundational STRIDE and PASTA methods to the dynamic application of Attack Trees and the MITRE ATT&CK framework, offers a unique lens through which to view and secure your software development lifecycle. We saw how Data Flow Diagrams (DFDs) provide a visual map of potential risks and how persona-based modeling puts you in the mindset of a potential attacker.

The common thread connecting these powerful techniques is their ultimate goal: to shift security left, making it an integral, proactive part of development rather than a reactive, post-deployment scramble. The examples demonstrated that threat modeling is not a monolithic, one-size-fits-all discipline. Instead, it is a flexible toolkit that can be adapted to your team's specific needs, whether you're building a complex enterprise application or a nimble microservice.

From Theory to Actionable CI/CD Security

The true power of threat modeling is realized when it moves from a theoretical exercise to an automated, continuous practice. This is where its integration into your CI/CD pipeline, specifically within your merge strategy, becomes a game-changer. By codifying security checks and threat assessments into your pull request lifecycle, you create a powerful, self-enforcing security gate.

Here are the most critical takeaways to implement immediately:

• Start Small and Iterate: You don't need to implement a comprehensive PASTA analysis on day one. Begin by creating a simple DFD for a new feature or using STRIDE-per-story during sprint planning.
• Automate Where Possible: Leverage your CI/CD tools to enforce security gates. A great threat modeling example in practice is automatically flagging a pull request for a manual security review if it modifies authentication logic or introduces a new external dependency.
• Focus on the Merge: The merge queue is your last line of defense before code reaches the main branch. Use this critical control point to ensure that security considerations have been met, reviewed, and signed off on.
• Combine Methodologies: The most robust security postures often result from blending techniques. Use DFDs to identify key data flows, then apply Attack Trees to explore potential exploits against those specific flows.

The Lasting Impact of Proactive Threat Modeling

Ultimately, mastering these threat modeling concepts transforms your team’s culture. It fosters a shared sense of ownership over security, empowering every developer to think like a defender. By embedding these practices directly into your workflow, you move beyond periodic audits and create a system of continuous assurance. This proactive stance not only prevents vulnerabilities but also accelerates development by catching issues when they are cheapest and easiest to fix. Your merge queue becomes more than just an organizational tool; it becomes a sophisticated security checkpoint that ensures resilience is built into every commit.

Ready to turn these threat modeling examples into automated reality? Mergify empowers you to build sophisticated, security-first workflows directly into your pull request process. Define rules that automatically enforce security checks, require specific reviews for sensitive code changes, and ensure every merge is secure by design. Visit Mergify to see how you can automate your merge queue and secure your CI/CD pipeline today.