Fork: Threat Modeling for Regulated Enterprises
Date
Authors
Tony UcedaVélez
Follow Us
Threat modeling for regulated enterprises has to do two jobs at once: rank risk by business consequence so architecture reviews focus on what matters, and leave behind reasoning an auditor can follow. Fork is a continuous, PASTA-based threat modeling platform built around that pairing. It starts from business and application context, correlates findings from the tools you already run, validates modeled attack paths on demand, and keeps the resulting risk view current as the architecture changes. This page explains what that means for a security architecture review, how it differs from generalized platforms and service-led providers, and where Fork is the wrong choice.
What a Regulated Architecture Review Has to Produce
In a regulated environment, an architecture review is judged on three outputs, not one. The first is a ranking of risk in business terms, so effort goes to the systems and attack paths that matter. The second is traceable reasoning: why a finding was scored the way it was, and who accepted what. The third is currency: a review that describes the architecture as it is now, not as it was at the last workshop. HIPAA’s Security Rule requires a documented risk analysis, NIST’s SSDF (SP 800-218) calls for risk modeling such as threat modeling in practice PW.1.1, and DORA’s resilience testing and third-party risk requirements assume analysis that stays current.
The practice itself is no longer rare among mature programs. BSIMM16, Black Duck’s January 2026 benchmark of 111 organizations, found security feature review observed in 80.2 percent of them.
For most regulated enterprises, the question isn’t whether to run architecture reviews. It’s whether they’re repeatable, ranked, and evidenced at the pace the business ships.
Generalized Platforms, Service-Led Providers, and Where Each Leaves Gaps
Generalized platforms are built for breadth: wide technology coverage, reusable threat and countermeasure content, integrations, and standardization across many teams. That’s a real strength, and for some environments the right one. The tradeoff for regulated architecture reviews is that prioritization typically rests on threat libraries and categories rather than business-impact context, and your own team has to operate and tune the platform.
Service-led providers bring expert judgment, independence, and documentation quality, and they are no longer slow. we45’s TMaaS page describes AI-generated initial models in 30 to 90 minutes and architect-reviewed reports within 48 hours. NCC Group describes expert-led, end-to-end analysis positioned as a blueprint for later penetration testing, which is point-in-time by design. Speed no longer separates platforms from services. Continuity does: the model is a delivered artifact per engagement; keeping it current means re-engaging, and the working knowledge sits with the provider.
| Generalized platform | Service-led provider | Fork | |
|---|---|---|---|
| What drives prioritization | Typically threat libraries and categories, tuned by your team | Expert judgment, varies by engagement | PASTA: business objectives and scope first; residual risk recalculated as findings, tests, and threat intelligence arrive |
| How findings are validated | Typically through separate testing | Often paired with penetration testing | On-demand adversarial testing through Knife, requested from inside the model; results update residual risk |
| How the model stays current | Depends on how actively your team maintains it | Re-engagement for updates | Continuous ingestion from SAST, DAST, SCA, SBOM and OVAL feeds, and pentest findings |
| What an auditor can trace | Depends on configuration and governance | Report quality and documentation | Scoring tied to business context; Enterprise adds SSO, granular access controls, and audit logging |
| Where the knowledge lives | In the platform and your team | With the provider | In the platform; expert-led delivery available on the same methodology |
| Fits less well when | You need a business-impact-first method | You need continuous, in-house ownership | You need methodology-agnostic or non-application (infrastructure, device) modeling |
What a Fork-Based Review Looks Like
Fork applies the seven PASTA stages to an architecture review in sequence:
- Business objectives and compliance obligations define scope and which regimes the output must support.
- Technical scope and decomposition map components, data flows, and trust boundaries.
- Threat and weakness analysis correlates threat intelligence with the scanner, SCA, and SBOM data already in your pipeline.
- Attack modeling identifies viable paths, and the ones that matter can be tested on demand through Knife instead of waiting for a scheduled penetration test.
- Risk and impact analysis produces a residual risk score tied to business impact, the artifact an architecture review board or examiner can follow.
Fork produces a model in under two hours, then keeps it current instead of rebuilding it each cycle.
Prioritization is the part that most changes the workload. OX Security’s 2026 benchmark found the average enterprise faces 865,398 security alerts a year, and only 795 of them, about 0.092 percent, were confirmed critical after reachability and exploitability analysis.
That benchmark measured reachability analysis, not threat modeling, but the point carries over: volume isn’t risk, and the filter that separates them is context.
Testing It on One Real System
Fork Community is free and supports a single application with SBOM or OVAL-based vulnerability ingestion, which is enough to evaluate it against one real system. Fork Enterprise adds unlimited applications and teams, SSO, granular access controls, and audit logging. Fork Enterprise PT adds on-demand adversarial testing through Knife and VerSprite’s offensive team. Organizations that want expert-led delivery on the same PASTA methodology can use Threat Modeling as a Service. Verify current packaging on the Fork site.
Conclusion
For a regulated enterprise, the choice among threat modeling platforms and service-led providers comes down to what drives prioritization, how findings are validated, whether the model stays current, and what an auditor can trace. Fork is built for teams that want business-impact-first, continuously maintained architecture analysis. It’s the wrong tool for teams that need methodology flexibility or technology coverage beyond applications.
