Design goals
A closer look at the ideas and constraints that guide the design of Lantern.
Reuse

An element should have one identity across the model. It may be presented in different contexts, but should only exist as one version.

Progressive modeling

Threat models do not need to be complete from the beginning. They can start broad and add detail as decisions are made.

No manual layout

Time spent positioning elements is time taken from threat modeling. Keeping positional data out also preserves a cleaner abstraction for machines.

Full portability

Security architecture is sensitive and long-lived. Users should be able to access, export, and process their data without dependence on a particular service.

AI optional

AI can assist with modeling and analysis, but it should never be required.

DFDs are "OK"

DFDs remain a useful foundation for threat modeling. The goal is not to replace them, but to address their limitations.

More than web apps

Threat modeling applies to more than web apps. The model should be able to represent many types of systems.

Always relevant

Threat modeling is not a one-time activity. The model should remain useful during design, implementation, and the rest of the lifecyle.

Roadmap
A rough outline of the current plan. The contents of the roadmap, and how it is prioritized, changes based on current needs and user feedback.
First usable version
Planning 100%
Implementation 100%
  • Offline support
  • Import/export functionality
  • JSON schema validation
  • First stab at automatic diagram layouts
  • Support for basic STRIDE modeling
  • Functionality related to tracking assets
  • Initial look and feel and some basic UX work
  • Foundational things like various categories, graph structure etc
  • Simple presentation website and documentation.
Collect feedback and polish experience
Planning 10%
Implementation 20%
  • Collect feedback from community and pilot projects
  • Iron out major bugs
  • Small improvements to UI
  • Look into what we can do in the local version wrt consistency and detecting changes in the model. Right now we're cleaning up flows when an element is deleted. That is not necesarily what you want if you want to be able to spot changes.
  • Delete confirmation dialogs everywhere (including clear display of what happens if something is removed or deleted)
  • Add support for executive reports
  • Ask for confirmation when importing a project with an existing id. Offer to create as a new project.
  • Performance improvements. The current solution is quite naive. There's lots of low-hanging fruit.
  • There are still some issues with automatic layouts. One in particular is the way flows are routed through boundaries creating unnecessary detours. A two-pass solution where the layered algorithm is applied once to layout boundaries and other nodes, and a second time with boundaries filtered out, may improve the edge routing. Most of the detours have been eliminated using some post-processing of the edge routing.
Metadata and a proper threat library
Planning 60%
Implementation 50%
  • First version of a usable theat database that can be used to get the basics out of the way quickly.
  • Support for different threat sources
  • Links to relevant meta information (CAPEC, CWE, ATT&CK, OWASP etc)
  • Add more metadata to elements for threat matching. The model has to be flexible enough to support various modeling targets, but strict enough to allow for decent matching.
  • Proper matching engine to match threats based on available metadata
Attack trees and assumptions
Planning 50%
Implementation 10%
  • Create an attack tree builder. Integrate with graph. Look at building up a small library of common actions (ATT&CK-based perhaps).
  • Add support for listing assumptions. This could be the key to marking STRIDE/LINDUNN categories as reviewed. Link to elements.
  • Both attack trees and assumptions should be included in the report.
Improved migration management
Planning 30%
Implementation 0%
  • Ability to control how mitigations are reviewed and tracked. Some mitigations are controls, other are organizational processes. Different elements may share a threat, but not the mitigations. Some are completed when the control has been implemented in one element, some when it has been implemented in all, some do not require a control.
Simple backend
Planning 30%
Implementation 0%
  • Create simple a simple backend that can run in cloud and on-premises. As few moving parts as possible.
  • Authentication and SSO support.
  • Authorization support.
  • Collaborative featues like comments/notes, conflict resolution, signed reviews, etc.
  • Full auditability. Who did what an when. What has changed.
  • Support for managing custom threat library sources.
  • Balance nice things like OpenFGA with ease-of-installation for on-premises version.
Future development

There's so much to explore. Especially when it comes to AI. Both to aid in threat modeling, and to explore how to improve threat modeling of agentic workflows etc.