Understanding Threats and Actions

Once a system is modeled in Devici, threats are identified automatically based on how that system behaves.

This section explains how Devici determines which threats apply, how to interpret them, and how actions are used to respond in a deliberate, traceable way.

How Devici identifies and addresses threats

Devici follows a simple, intentional flow that connects system design decisions to identified threats and mitigation actions.

At a high level, the process works like this:

flowchart LR
  Model["Threat Model"]
  Attributes["Apply Attributes"]
  Threats["Identified Threats"]
  Actions["Mitigate Threats"]

  Model --> Attributes
  Attributes --> Threats
  Threats --> Actions

The threat model provides the structural context for analysis. It represents system components, how data moves between them, and where trust assumptions change.

Attributes are applied directly to elements and data flows within the threat model. Each attribute describes a specific aspect of system behavior, such as exposure, authentication, data sensitivity, or trust assumptions.

Each attribute has a defined relationship to one or more threats within the selected threat framework. When a user applies an attribute, the threats associated with that attribute are identified and added to the threat model.

The context of the threat comes from where the attribute is applied such as the specific element, data flow, or trust boundary.

Why a threat applies

Every threat in Devici includes context that explains:

Where the threat applies in the system
Which attributes triggered it
What assumptions or behaviors led to its identification

This transparency is intentional.

If a threat does not accurately reflect how the system works, it usually indicates that the model needs refinement, not that the threat should be ignored.

Threats are contextual, not absolute

Threats in Devici are contextual, but not speculative.

A threat applies because an attribute that maps to that threat has been applied to part of the system. Whether that threat is relevant depends on factors such as:

Where the attribute is applied
How the affected elements interact
Whether additional controls or constraints exist

As attributes or system structure change, the set of identified threats updates immediately. This allows teams to explore design decisions and understand how changes affect the threat landscape.

From threats to actions

Identifying threats is only the first step.

Actions represent deliberate decisions about how to respond to identified threats. Devici does not prescribe a single response or workflow.

An action may involve:

Implementing or validating a security control
Modifying system design to remove the threat condition
Documenting why the threat does not apply
Accepting exposure based on context and constraints

Actions help teams move from identification to intentional decision-making

Choosing appropriate actions

Not every threat requires the same response.

Depending on context, teams may decide to:

Address the threat through design or controls
Document why the threat is not applicable
Accept the exposure with a clear rationale
Track follow-up work outside of Devici

Devici supports this flexibility so threat modeling fits naturally into real engineering and security processes.

Keeping actions aligned with the system

Threat models evolve as systems change.

When elements, attributes, or data flows are updated:

New threats may appear
Existing threats may no longer apply
Previously recorded actions may need review

Devici helps maintain alignment between the current system design, identified threats, and the actions taken to address them.

What’s next

Now that you understand how threats are identified and addressed, the next step is to collaborate with others to review and refine threat models.

In the next section, we’ll explore how teams work together in Devici to review, discuss, and evolve threat models over time.

→ Reviewing and Collaborating on Threat Models