STRIDE, DREAD, PASTA, LINDDUN, and attack trees all model one system at a time. They work beautifully for an application or a service. They strain when the scope is "the whole company" or "every microservice in our pipeline" — thousands of components, hundreds of teams, no single architect.
Two methodologies fill that gap: OCTAVE (organization-wide, asset-driven, exhaustive) and VAST (visual, agile, scales across CI/CD). They solve adjacent problems from opposite directions.
The two at a glance
OCTAVE
Operationally Critical Threat, Asset, and Vulnerability Evaluation. Developed at CERT/CMU. Starts with "what are our critical assets?" and works outward to threats and risks.
VAST
Visual, Agile, Simple Threat modeling. Developed by ThreatModeler Software. Built to integrate with DevOps pipelines — threat models per application, per operational environment, automated to scale across thousands of services.
OCTAVE in three flavors
OCTAVE has been published in three variants over the years, each scoped for a different organization size:
- OCTAVE (original, 2001) — large organizations with their own security teams. Heavy, exhaustive, multi-month engagements. Largely historical now.
- OCTAVE-S (2005) — small organizations (under 100 people). Simplified version for teams without dedicated security staff.
- OCTAVE Allegro (2007) — the current recommended flavor. Streamlined and focused on information assets specifically (rather than every IT asset).
OCTAVE Allegro — the 8-step process
- Establish risk measurement criteria — what counts as low, medium, high impact for this org.
- Develop an information asset profile — the assets being modeled, with owners and value.
- Identify information asset containers — where the asset lives: technical, physical, people.
- Identify areas of concern — what could go wrong with this asset?
- Identify threat scenarios — how could those concerns be realized?
- Identify risks — what's the impact if each scenario happens?
- Analyze risks — score against the criteria from step 1.
- Select mitigation approach — accept, transfer, mitigate, avoid — for each risk.
VAST's two-model split
VAST's most useful idea is splitting the threat model into two views, each kept per service:
- Application Threat Models (ATMs) — focused on the application itself: what threats apply to this code, this data, these flows? Read by developers.
- Operational Threat Models (OTMs) — focused on how the application is deployed: networks, infrastructure, secrets, identity. Read by SREs and platform teams.
VAST — pipeline integration pattern
- Service catalog — every service has an entry. Adding a service triggers threat-model creation.
- Auto-generated DFD — the threat-model tool pulls from infrastructure-as-code, container manifests, and service-mesh telemetry to produce the diagram.
- Threat library application — rules in the threat library fire against the DFD: "this DFD has an exposed HTTP endpoint; threat T-001 (input validation) applies."
- Per-service findings — findings stream into the same backlog the team uses for bug tracking.
- Continuous re-modeling — when the architecture changes, the threat model updates. The model is never "done."
When each is the right tool
Reach for OCTAVE Allegro when:
- You're building or reviewing an enterprise risk management program.
- You need a method auditors and risk officers will recognize from compliance frameworks.
- The scope is "this asset, end to end across the organization" — e.g., "our customer database, wherever it goes."
- You have time for a structured multi-week engagement.
Reach for VAST when:
- You have tens or hundreds of microservices and per-service STRIDE doesn't scale.
- Your engineering teams use CI/CD and want threat modeling to fit in that pipeline.
- You want a model that updates itself when the architecture changes, not one that grows stale.
- You can invest in tooling (commercial or homegrown) to make the automation real — VAST without tooling is just "do STRIDE more often."
OCTAVE and VAST are the scale-up answers in threat modeling. STRIDE et al. tell you what to do for one system; OCTAVE and VAST tell you how to do threat modeling for a whole organization or a whole engineering platform.
OCTAVE's discipline is asset-centric thinking and structured risk decisions. VAST's discipline is automation and integration with the development process. Most large organizations end up using elements of both: OCTAVE-style thinking at the program level, VAST-style automation at the engineering level, STRIDE/PASTA inside each model as appropriate.
References
Formatted in APA 7. Alphabetized by first author's last name.
- Alberts, C., & Dorofee, A. (2001). OCTAVE method implementation guide, version 2.0. Software Engineering Institute, Carnegie Mellon University.
- Caralli, R. A., Stevens, J. F., Young, L. R., & Wilson, W. R. (2007). Introducing OCTAVE Allegro: Improving the information security risk assessment process (Technical Report CMU/SEI-2007-TR-012). Software Engineering Institute, Carnegie Mellon University. https://insights.sei.cmu.edu/library/introducing-octave-allegro-improving-the-information-security-risk-assessment-process/
- Shevchenko, N., Chick, T. A., O'Riordan, P., Scanlon, T. P., & Woody, C. (2018). Threat modeling: A summary of available methods. Software Engineering Institute, Carnegie Mellon University. https://insights.sei.cmu.edu/library/threat-modeling-a-summary-of-available-methods/
- ThreatModeler Software. (n.d.). VAST methodology overview. https://threatmodeler.com/threat-modeling-methodologies-vast/