Protocol: The Threat Modeling Mandate

Core Failure Mode

The core failure is treating security as a reactive, downstream activity. A separate security team is tasked with "finding vulnerabilities" in a system that has already been designed and built. This is fundamentally broken. It's like asking a building inspector to make a skyscraper earthquake-proof after it's already been constructed. You can patch the cracks, but you can't fix the foundation. The Threat Modeling Mandate inverts this. It forces security to be a proactive design activity, owned and executed by the engineers who are actually building the system. It is the practice of thinking like an attacker *before* a single line of code is written.

Root Cause Analysis

This failure stems from the organizational silo between development and security. The root cause is a governance model that treats security as the responsibility of a separate "security team." This creates an adversarial relationship and a culture of "throwing code over the wall." Developers are incentivized to ship features quickly, while the security team is incentivized to find flaws. This is a direct violation of the principles of a cross functional, DevOps-oriented culture. It also violates the Production Mindset Imperative, which dictates that the team building a system must own its operational security. The result is a slow, high-friction process that catches some bugs but fails to build a truly secure system.

"Amateurs talk about finding vulnerabilities. Professionals talk about designing systems where those vulnerabilities can't exist.". Lonnie McRorey, et al. (2026). Platforming the Nearshore IT Staff Augmentation Industry, Page 166. Source

System Physics: Security as a Design Loop

Threat modeling is a structured process for identifying and mitigating security risks during the design phase. It is not a one-time checklist, but a continuous loop that is part of the architectural design process. The protocol is simple and can be integrated into any agile workflow:

1. Decompose the System: Draw a simple data flow diagram of the feature. What are the external entities, the processes, and the data stores? Where does data cross a trust boundary?
2. Identify Threats (STRIDE): For each component and data flow, systematically brainstorm potential threats using a mnemonic like STRIDE:
   • Spoofing: Can an attacker pretend to be someone else?
   • Tampering: Can an attacker modify data in transit or at rest?
   • Repudiation: Can a user deny having performed an action?
   • Information Disclosure: Can an attacker access data they shouldn't?
   • Denial of Service: Can an attacker crash the system?
   • Elevation of Privilege: Can an attacker gain permissions they shouldn't have?
3. Mitigate and Document: For each identified threat, propose a mitigation. This could be a technical control (e.g., "use HMAC to prevent tampering") or a design change (e.g., "don't store PII in the logs"). The decision and its rationale are documented in an Architectural Decision Record (ADR).

This process transforms security from a mystical art into a structured engineering discipline. It is a core competency we vet for in our Security Engineering and System Design simulations within the Axiom Cortex engine.

Risk Vectors

Treating security as a downstream QA activity is a form of architectural malpractice.

• The "Bolt-On" Security Fallacy: You discover a fundamental security flaw in a feature that has already been built. The "fix" is a clumsy, bolted-on patch that is itself complex and likely to introduce new bugs. The cost of fixing a security flaw in production is 100x the cost of preventing it in the design phase. This directly impacts the Cost of Delay.
• The "Unknown Unknowns": Your team is so focused on finding specific, known vulnerabilities (like XSS or SQL injection) that they completely miss the more subtle, business-logic flaws that are unique to your application. A threat model forces you to think about these "unknown unknowns."
• A Culture of Apathy: When security is someone else's job, developers become passive and stop thinking about it. They assume the "security team" will catch any problems, leading to a steady decline in the overall security posture of the codebase.

Operational Imperative for CTOs & CIOs

You must mandate that threat modeling is a required part of the design process for every significant feature. This is not optional. It is not "extra work." It *is* the work of a professional engineering team. You need to train your developers, including your nearshore team, on how to do it and hold them accountable for the results. The output of a threat modeling session is not just a list of risks; it is a set of engineering tasks that go directly into the backlog.

This is a key part of the Platform Enforcement Model. The Nearshore IT Co Pilot can enforce this by making a link to a completed threat model a required field in a feature ticket before it can be moved to "in progress." By shifting security left, you are not just building a more secure product; you are building a faster, more efficient, and higher-quality engineering organization.