ThreatModeler Platform Reviews

Our main use case for ThreatModeler Platform is application threat modeling during the design and development life cycle. We use it to analyze the application architecture, data flows, trust boundaries, and potential attack paths. This platform helps to automatically identify security threats based on the application model, allowing us to review and prioritize the findings with the application and security teams. This approach helps us identify and address security risks earlier before the application moves into production.

In a recent application onboarding, we used ThreatModeler Platform to model the applications and data flows, external interfaces, and trust boundaries before they moved towards production. During the assessment, the platform identified potential security risks around an external application component and its communication path to the back-end service. The results and findings with the application and security teams validated the actual architecture, and the team implemented the required access controls and security measures before deployment. This proactive approach helped us identify risks earlier and avoid issues during security testing.

The automated threat identification capabilities of ThreatModeler Platform are one of the most useful features for us. It quickly highlights potential risks from the application architecture itself, while the visual modeling of application components, data flows, and trust boundaries makes complex decisions easier to understand. I also find the centralized threat tracking application helpful, as it standardizes threat modeling across different applications instead of relying completely on manual assessments. Its integration with development and security workflows is another strong advantage.

ThreatModeler Platform positively impacts my organization by making application security more proactive and consistent across our development processes. It allows us to identify architectural security risks earlier, preventing significant escalation problems when moving applications into production without addressing vulnerabilities. The automated threat identification reduces manual analysis efforts from the security team, improving collaboration between security, application, and architecture teams. It provides a common view of threats and mitigations of vulnerabilities, ultimately helping us reduce late-stage security findings and making threat modeling a structured part of our SDLC.

I would like to see deeper integration of ThreatModeler Platform with CI/CD pipelines, cloud platforms, and infrastructure as code tools. More automation to automatically update threat models when application architecture changes would reduce manual maintenance. AI-driven recommendations for threat prioritization and mitigation could expedite reviews significantly. Better integration with vulnerability management and ticketing platforms would enhance end-to-end tracking. Overall, increased automation and real-time integration would make ThreatModeler Platform even more effective in the DevSecOps environment.

I would like to see improvements mainly in the user interface and integrated reporting capabilities of ThreatModeler Platform. A more modern and intuitive UI would make it easier for new users to create and navigate complex models. Reporting could offer more customizable dashboards and executive-level summaries, so more flexible report options would also assist in sharing security findings with application and management teams. These enhancements would improve the platform's usability and reporting experience.

We have covered most improvement areas needed for ThreatModeler Platform, such as real-time integration with CI/CD pipelines. In terms of reporting, I mentioned earlier the need for clear and easily understandable security documentation. The UI could become more intuitive when working with large and complex application models, and stronger AI-based threat prioritization and remediation recommendations would minimize manual review efforts. Enhanced integration with cloud and ticketing or vulnerability management platforms would also provide a more complete end-to-end security workflow.

I have been using ThreatModeler Platform for around two to three years, initially working with version seven and currently using version seven point five.

ThreatModeler Platform is very stable based on my experience, especially for our applications security workflow. We started with version seven point two and seven point three, and currently use version seven point five. The platform handles multiple application assessments and tracking mitigation activities without major disruptions. Overall, I would rate the stability around nine out of ten, with room for continuous improvements in usability and integrations.

In terms of scalability, ThreatModeler Platform has proven to be highly scalable for our environment. We manage threat models for multiple applications from a central platform, and as our application portfolio expands, we can create separate models while maintaining consistent security standards. The automated threat identification helps the security team handle more assessments without increasing manual efforts, allowing multiple application and security teams to collaborate on different models. Overall, I would rate scalability around nine out of ten for enterprise applications in a security environment.

Customer support for ThreatModeler Platform is very good, and I have had a positive experience overall.

Before ThreatModeler Platform, we primarily handled threat modeling activities using manual architecture reviews, security checklists, and documentation-based assessments. That approach worked well for individual applications but became difficult to scale as our application portfolio grew. For instance, earlier manual architecture reviews wasted two to three hours of time due to increased manual effort. We adopted ThreatModeler Platform to analyze processes and automate initial threat identification, with visible modeling and centralized tagging facilitating collaboration between security and application teams. The transition aimed to make threat modeling more consistent, scalable, reliable, and efficient.

The initial setup of ThreatModeler Platform is manageable, and we were able to integrate it into our existing application security workflows without major infrastructure changes. Licensing and pricing are handled by our procurement and vendor management teams, so I do not have direct visibility into contract values or specifics. However, the platform effectively reduces manual modeling effort and streamlines implementation. I would recommend evaluating licenses based on the number of applications, users, and required integrations, as the overall cost is reasonable compared to the security and efficiency benefits.

We purchased ThreatModeler Platform through the Azure Marketplace as part of our organization's standardized enterprise vendor and procurement process. Our technical team is responsible for using and administrating the platform, while recruitment and vendor management teams handle the commercial agreement. We use ThreatModeler Platform as part of our application and security workflow across our hybrid environment. My experience is primarily from the technical and operational side rather than the purchasing process.

We primarily see a return on investment through time savings and reduced manual effort. For typical application assessments, automated threat identification saves approximately one to one point five hours compared to manual initial assessments, and sometimes it can save even up to two hours. This helps us identify and fix assessments, enabling earlier resolution of security issues before deployment, minimizing rework during late-stage security reviews. This standardized workflow allows our security team to handle more applications without proportionally increasing manual efforts, resulting in improved efficiency and faster security assessments.

I was not offered a gift card or incentive for this review.

We did not evaluate other options before choosing ThreatModeler Platform. Our previous methods only included manual architecture reviews, which consumed considerable time and resources. Thus, we switched to models like ThreatModeler Platform, standing out due to its combination of visual architecture modeling and automated threat identification, prompting us to adopt this platform.

ThreatModeler Platform fits into our workflow mainly during the application design and security review stage. We use it before production deployment to understand the application architecture, data flows, trust boundaries, and potential threats. The security team generates findings with the application and architecture teams and tracks the required mitigations. It complements our vulnerability scanning and other security testing rather than replacing them, helping us shift security assessments earlier in the SDLC and providing a more consistent threat modeling process.

The automated threat identification feature has made our process more efficient by providing a quick initial assessment of potential threats. Instead of relying solely on manual analysis, once we build the application model, ThreatModeler Platform identifies relevant threats based on the architecture and data flows. This allows our security team to focus more on validating findings and collaborating with developers on mitigation. It also ensures a consistent approach across different applications, overall reducing manual analysis efforts and helping us identify security risks earlier in the development lifecycle.

One feature I particularly value is the combination of visual threat modeling and threat identification, which makes complex application architecture easier for both security and development teams to understand. The centralized tracking of threats and mitigations also improves collaboration and follow-up. Version seven point five provides a smoother experience compared to older versions like seven and seven point two, making features more consistent and preferable in our approach to application security.

In our hybrid cloud environment, we primarily utilize Microsoft Azure alongside our own on-premises infrastructure. ThreatModeler Platform is integrated into our application security workflow across both environments before deployment. These threat models help us maintain consistent security reviews based on both on-prem and Azure-hosted applications, which is particularly useful when applications have dependencies across both environments.

ThreatModeler Platform is deployed as part of our application security and threat modeling workflow. We have been using this platform for around three years, initially with version seven and currently with version seven point five. Security and application teams access the platform to create and maintain threat models for the application during design and review stages, considering components, data flows, trust boundaries, and external interfaces. The platform serves as our centralized threat modeling solution in a hybrid cloud environment.

ThreatModeler Platform helps us assess risks across different application attack surfaces in a structured way. We model components such as internet-facing interfaces, APIs, authentication points, data stores, and back-end services, along with the data flows between them. The platform assists in identifying threats associated with those components and trust boundaries. We review findings with application and security teams, prioritizing applicable risks for mitigation, giving us better visibility into the overall attack surface rather than considering individual components in isolation.

ThreatModeler Platform has indeed helped our security team keep pace with DevOps sprints by integrating threat modeling earlier into the application development processes. For instance, when application architecture or APIs change during a sprint, we can utilize the platform to update the threat model and quickly review newly identified risks. Automated threat identification reduces the time required for initial security assessments, allowing security and development teams to focus on validating relevant findings and tracking remediation. This integration helps avoid making threat modeling a separate activity that delays sprint production releases.

We primarily see a return on investment through time savings and reduced manual effort. For typical application assessments, automated threat identification saves approximately one to one and half hours compared to manual initial assessments, and sometimes it can save even up to two hours. This helps us identify and fix assessments, enabling earlier resolution of security issues before deployment, minimizing rework during late-stage security reviews. This standardized workflow allows our security team to handle more applications without proportionally increasing manual efforts, resulting in improved efficiency and faster security assessments.

The flexibility to automate specific parts of our threat modeling process with ThreatModeler Platform reduces repetitive manual training necessary for day-to-day assessments. Once we establish a standard modeling workflow, team members can follow a consistent approach rather than learning different methods for every application. While new team members still require training on ThreatModeler Platform and threat modeling, the standardized workflow simplifies onboarding. I did not measure a specific percentage reduction in training costs, but the primary benefit lies in less training effort and faster onboarding.

ThreatModeler Platform enables our organization to meet tight delivery dates for product teams by providing quick initial assessments through automated threat identification. This feature is invaluable when an application has a short release window. We can swiftly review the architecture, validate, generate threads, and focus solely on the high-priority areas on the list to reduce security review delays, allowing application teams to address issues promptly before the release. It is especially useful when multiple applications require security assessments within the same delivery cycle.

ThreatModeler Platform has benefited our team by making the threat modeling process more structured and consistent. Automated threat identification reduces the amount of manual analysis needed for each application, providing a common platform for security and applications teams to review architectural risks and track mitigations. In practice, it helps us complete the initial threat assessments faster and identify issues earlier in the SDLC. Overall, this improvement enhances team efficiency and collaboration without eliminating the need for technical validation. I rate my overall experience with ThreatModeler Platform as nine out of ten.

My use case for ThreatModeler Platform is building systems diagrams with a specific focus on the potential threats and security vulnerabilities that could arise should you make a certain change, such as if you connect one server to another server, what are the risks that you could see.

ThreatModeler Platform has positively impacted my organization by changing the approach from manual to a more efficient method. The big change was the amount of time that my team spends building the models. Before, it would take them a couple of hours to do it. Now they can do it in about 30 minutes, and then small changes are even shorter. It's difficult to say how much ThreatModeler Platform saves financially or resource-wise because it's mostly in team man-hours. The fact that a team of five usually would take 20 hours total, and now it takes them 30 minutes represents a significant reduction in what my team is doing. It gives them the ability to do other things that may be more important.

ThreatModeler Platform's ability to measure and mitigate risks across different attack surfaces has helped my organization. It provides us with a metrics platform to see what our common risks are and start to address them. If we have one particular type of risk or category of risk that's 60% of all our findings, then that's obviously something we want to focus on as an organization. It really helps us identify where we are worst and address that immediately.

ThreatModeler Platform helps my security team keep pace with DevOps sprints by allowing us to adjust and adapt quickly to any of their diagrams and feature changes that they give us late in their cycles. Being able to adjust and adapt quickly means we don't bottleneck them or fall behind. We can't always keep up because there are so many of them and so few of us, but we don't fall behind as much anymore.

It's easy to customize the threat framework components of ThreatModeler Platform to match our needs with the UI. In the catalog, you can pick specific threats that are unique to your company and add those in. It's basically click, fill it out, and apply it to which component. The same applies with customizable components - you just go in, give it a description, a name, and an icon. It's pretty easy, similar to creating a Jira ticket.

The customizability is very nice. Unlike a lot of other similar tools, you can build it exactly to your spec. I appreciate the fact that you can iterate on models, so you have the history if you make a change. I can look back on what this exact same model looked like in 2020. The fact that it integrates with our SSO for login is nice as well.

There are areas for improvement in ThreatModeler Platform, particularly in cloud integration. You can connect with your VPC and it'll build models for you. That is definitely an area that needs improvement. We've tested it a few times and it's somewhat buggy. It'll double add components, stack components on top of each other, and doesn't make a readable diagram. It's a really good idea in theory because it can build out your entire VPC, but it's unpredictable.

Aside from that major area for improvement, a minor issue with ThreatModeler Platform is being able to pin connections between components. Sometimes it won't connect to the right side of the left component. It'll circle all the way around, making an odd-looking connection. Where it could be a straight line, it does something unusual. It's a minor thing, but when you build a complex model, you want to make sure that your connection points are very concise and clear.

I have been using ThreatModeler Platform since approximately 2017, so eight years.

In regards to the stability of ThreatModeler Platform, I would rate it a ten as it has never gone down for us.

Regarding scalability, I would rate it as a nine out of ten.

In our company, about 10 users use ThreatModeler Platform, and at the other one that I worked at, it was closer to about 30.  The use of ThreatModeler Platform is global.

I would rate the support for ThreatModeler Platform as an eight out of ten.

Positive

ThreatModeler Platform is the best that I've used in the space. The other one that I've used is Microsoft Threat Modeler, and that is a terrible tool.

It is a SaaS product, so they host it. I have done it two ways: once on-premises and once when they hosted it.

It seems fairly reasonable. I don't have a comparison point to other products, but I've used it at two companies and it's always been a reasonably priced tool.

I'm not sure that it's significantly impacted our training costs. We use it, but not specifically for training purposes. 

We did not notice any changes in application coverage percentages since implementing ThreatModeler since we already had 100% coverage with our applications. We're just more efficient now.

I would recommend ThreatModeler Platform to other users, as it scales and it's the best one that I've seen out there. It just seems the tool that suits the needs of what people who are threat modeling want.

I would rate ThreatModeler Platform an eight out of ten.

My primary use case for ThreatModeler Platform is to threat model a complex multi-container environment I designed myself, featuring Open Policy Agent and OPA, and an ABAC-based authorization layer running along Cilium network policies. To test the tool's capabilities thoroughly, I redrew that system as if it were deployed on AWS, incorporating components such as ECS or EKS, ALB, RDS, S3, and Secret Manager with IAM roles scoped individually per service. I built the model directly against that redrawn architecture to ensure I was working with genuine complexity rather than a simplified toy diagram, helping me evaluate the tool's effectiveness in a realistic, high-stakes scenario. ThreatModeler Platform was instrumental in helping me address service isolations and shared secrets, providing a structured way to identify potential vulnerabilities within that specific cloud-native setup. It serves as a perfect test case to see how the tool handles the intricacies of modern containerized infrastructure.

The real value for me with ThreatModeler Platform is in the enforced grammar of the tool. Because I am modeling a system with complex service isolation and shared secrets, I need a way to ensure my threat statements are consistent. The tool's structure forces me to define the source, prerequisite, action, impact, and asset for every threat, acting as a forcing function for my own thinking. It is not just about drawing a diagram; it is about mapping out the six distinct trust boundaries I identify in that architecture. By forcing me to articulate those boundary crossings, the tool helps me move beyond a high-level overview into much more granular AWS-native analysis. It essentially serves as a vehicle for structured thinking, which is why it is so effective for that specific high-stakes environment.

The best features ThreatModeler Platform offers include the enforced threat statement grammar, which requires me to define source, prerequisite, action, impact, and asset for every threat, effectively preventing me from writing vague worries instead of actionable claims. It acts as a forcing function that keeps my analysis rigorous and consistent. Another standout is the export workflow; unlike many tools that merely produce a static diagram, this platform generates a comprehensive document, including assumptions, data flows, threat statements, mitigations, and other relevant information that my team can actually inherit and act upon. The accessibility is a major benefit, as there is no installation or account requirement, which lowers the barrier between deciding to threat model and actually starting the work. It is a powerful structural vehicle for thinking that does not get in my way, which is why it is so effective for complex cloud-native environments.

The enforced threat statement grammar fundamentally shifts my workflow from brainstorming to formalizing. By requiring a source, prerequisite, action, impact, and asset for every entry, it forces me to treat each threat as a logical claim rather than a vague worry. This requirement means that by the time I finish the model, I am not just left with a diagram but with a series of defensible arguments that can be evaluated objectively.

The biggest improvement I see for ThreatModeler Platform would be closing the gap between the model and the architecture it describes; right now, everything is built manually. There is no importing from Terraform, CloudFormation, or CDK, so the moment the real infrastructure changes, the model quietly goes stale and nobody gets told. If it could ingest infrastructure-as-code to pre-populate the diagram and flag when a deployed architecture has drifted from the last saved model, that would remove the single biggest source of friction in the whole workflow. Additionally, I notice smaller things such as comment and collaboration features are thin, and there is no persistent link between threat statements and detection. ThreatModeler Platform is AWS-native by design, which cuts both ways. If pressed to prioritize one, I would say the infrastructure-as-code sync is most important; everything else is a usability improvement.

I have been using ThreatModeler Platform for about four weeks, and during this time, I engage in focused, hands-on work that culminates in the creation of one complete exported model. My experience has been very stable, and I have not encountered any crashes or technical issues. It is a lightweight, web browser-based tool with a well-defined scope, which makes it quite reliable for the specific tasks I have been performing. I generally prefer to be precise about this timing because those four weeks involve genuine intensive building rather than casual exploration, allowing me to thoroughly test the tool's capabilities against a complex multi-container environment I designed. This helps me evaluate its effectiveness in a practical, real-world scenario. Being honest about the duration of use provides a much more accurate picture of the tool's performance than inflating the tenure.

Regarding the export workflow, my team uses those comprehensive documents as a living foundation for security reviews. Because the export includes clear assumptions, data flows, threat statements, mitigations, and open items, it is something a reviewer can actually interrogate line by line rather than just a picture.

I would frame ThreatModeler Platform's impact not as organizational transformation but as workflow impact. Since my hands-on use has been focused and recent rather than a long-term deployment across a team, the clearest gain is speed to a usable output. Before, building a threat model meant starting from a blank diagram and hoping the resulting document held together. With ThreatModeler Platform, the enforced grammar regarding threat source and prerequisite, action, impact, and asset means every entry survives being stated as a real claim rather than a vague concern. That structure alone cuts the time from needing to think about security to having a reviewable artifact significantly. It also improves the quality of the review itself because the output is structured. With assumptions, data flows, threat statements, mitigations, and open items, it is something a reviewer can actually interrogate line by line.

I rate ThreatModeler Platform an eight out of ten because AWS-native modeling with a real reviewable export for free is valuable. It loses points only for manual diagramming and no infrastructure-as-code sync, which is a genuine limitation and not a nitpick. Eight reflects strong execution with one honest, unresolved gap.

We have applications in multiple clouds, and we use it to review our apps to ensure that they are going to be designed in a secure manner.

It helped us in multiple ways. It's easy to present to leadership where they can get the big picture, and they can ask their questions based on what they see in the drawings. Also, it's a good tool in that it drills down and gets down to the actual requirements. Sometimes we can get buried in the risks, but the risks all translate into requirements. The requirements are the meat and potatoes for our developers. To remediate what's needed, the sooner we get them involved and the sooner we are involved in the process, the sooner the results are designed into the solution. We are also able to reuse the work we put in. When we do something once and there is a revision to the same application, we can start with the previous version. It saves a huge amount of time.

It's a time saver. As we've gotten along, we've determined what we've already remediated. We're not going through a huge list that we used to go through in the beginning. We're going through things that only need to be gone through, and it helps maintain the sprints.

ThreatModeler Platform has enabled our company to meet tight delivery dates for the product teams. I've had several instances where things were brought to my attention late in the game. The tool has been excellent in getting in there and getting it done quickly and with less effort. It's a great time saver, so we can get in and get done, and get out. Sometimes we can do it at astounding speed if we have to. It's better to have enough time to get the job done, but when you're under a crunch, you still can get the job done.

We've customized quite a few components to suit our needs. When we have met the requirements, we put standards around a component. We then deploy it and mark it such that the component is remediated by control or by some standards. In that circumstance, the security requirements don't flow through. They're marked as already met, so it saves us a great deal of time. It's very customizable.

I found that not all of our security architects are fluent in each and every cloud. We're supporting all the major clouds and some SaaS environments. We're finding ways to use the tool and expanding it beyond just the typical clouds that we have today. It has allowed an AWS expert to work on a Google Cloud platform and apply their knowledge quickly and faster, and learn those platforms without necessarily having to be certified in every platform.

ThreatModeler has reduced the hours needed to complete threat modeling projects or secure an app in our organization. It takes about a third of the time doing it through ThreatModeler than it would otherwise. It would greatly vary depending on the actual individual person and how developed our standards are. The company I worked at prior did not have ThreatModeler, and I knew what it took to get the same functionality or similar functionality. It took much longer, and it would be much less uniform across.

Initially, we had ten people working on threat models. Today, within our organization, we probably have four. Fewer folks are working on ThreatModeler, and other security architects are being dedicated to specific environments and specific domains. It has allowed us to be more specialized because we need fewer people to do threat modeling.

ThreatModeler Platform is a big timesaver, helping to provide consistent output. Without it, interpretations would vary. Everything would be developed from scratch, and consistency would be lacking. By having this as our tool, we've developed a more consistent output. It didn't start out that way because everybody has their own ideas, but it is a great tool for making things consistent and making them faster. It allows for drawing solutions to get most of what is needed for threat models, aiding the design team in remediating security requirements. 

It measures and mitigates risks across attack surfaces, presents big pictures to leadership, and translates risks into requirements for developers, resulting in security design solutions that save time. Through customization, they can adapt the platform components to match specific needs, significantly streamlining processes.

We meet with our customer rep on a regular basis and go over new features we request. The team has been quite responsive in fulfilling most of the things we've requested in the revisions as we go along. They implemented changes related to colors. That was one of the things we asked for. 

One feature that I would like to see is related to comments. Comments need to be layered so that they are always on top. When you click on the comment feature, a dialogue box pops up, and you start entering a comment and put it into a VPC or a group of some sort. When you click on that group, the comment shouldn’t disappear behind the group. That's a problem that I would like to see fixed. The comment should always stay on top. It should be at the top layer above everything else because I can't see a reason why the comments should be under the things that you're commenting on. ThreatModeler Platform needs an enhancement so that comments always remain on top layers in diagrams, preventing them from disappearing when interacting with other components.

I have been using ThreatModeler Platform for about three years.

ThreatModeler Platform's AI-driven component suggestions assist with scalability, especially when undertaking new tasks. However, since this feature was implemented after a few years of using the solution, it is sometimes less impactful as we are already accustomed to our existing methods. We move it out of the way just because we're already set in our ways, and we already know what we want to put next. If we didn't know that, it would be a good time saver.

We get a very quick initial response. Traditionally, they have been quite fast in resolving issues. We've had a few issues that took a little longer to resolve, and they were resolved in a few days. As a whole, we've had multiple issues because we use the tool all the time and run into problems. They're quick to fix them. Sometimes, we could get a better explanation of what was done to fix it, but all in all, we're happy with the results in the sense that things get resolved quickly. We have somebody who takes our requests and resolves them quickly. Of all the time, all the years that we've had it, we've only had a couple of issues that took a little while longer to resolve.

Positive

Prior to ThreatModeler Platform, threat models were done manually, but this approach was less efficient.

I joined after it was selected, so I wasn't a part of the selection process, but I have evaluated it a couple of times since then and compared it to current products. It seems to be head and shoulders above the rest as far as multi-cloud support. A big thing about it is that we've now integrated it into our work environment such that we can go into and run a report on the security requirements and export them into Jira, and then they can be assigned to a particular team to go through each one of those requirements. They can go through the open ones and fix them. It can automatically, or nearly automatically, be tied into our work environment. It's pretty slick. It's a big time saver. We've integrated it into our platforms. We're doing more and more integration as we go along. A lot of these things didn't exist earlier, at least not to the extent they do now. They've been a result of us working with the ThreatModeling team and them being responsive to our needs.

We initially attempted to port diagrams from draw.io or Visio to ThreatModeler Platform, expecting integration with threat tools. It might have improved now, but at the time, the results were unsatisfactory, leading to manual interpretation and entry processes. 

We now get drawings in multiple formats. I'd love to say that we are standardized in the way we should be, but we have multiple teams, and we get multiple formats. We take that drawing and interpret that, and enter it into the tool manually. However, when we are grabbing things, clicking, and dragging them over and making boxes and just sliding things over, as long as the component selection is fairly robust, it's fine. It's a very fast process.

ThreatModeler Platform has reduced training and education costs by enabling security architects to extend their knowledge across various cloud platforms without needing specific certification, leveraging AWS expertise in other environments efficiently.

It's like everything. If you look at the pricing, it sounds like a lot. If you look at the time it saves you and the fact that it repeatedly saves you that time, it pays for itself. That's what you want out of your tools. If they pay for themselves, you can easily justify them, even if they are expensive. Security architects are very expensive, and we're already doing more with less. Our team is smaller than it was a few years ago, and we have had fewer people doing threat modeling because we're getting more done with the tool.

We aren't using the governance part yet. I need to look at that more and incorporate that. We aren't using it yet, but it's a good feature. I'd like to find a way to use it. Right now, we're doing governance outside of the tool using other platforms. Maybe we can do it more inside the tool.

I would rate ThreatModeler Platform an eight out of ten.