Skip to content

Threats & Mitigations

Threats and mitigations are the primary output of threat modeling in Devici.

Based on the attributes applied to elements, Devici uses the Devici Codex to identify relevant threats and recommend mitigations. This allows you to move from system structure and behavior directly to actionable security decisions.

Use this guide when reviewing risk, planning remediation, or validating the security posture of a system.

How threats and mitigations work in Devici

Threats and mitigations in Devici are derived from attributes defined in the Devici Codex.

The Codex is Devici’s curated intelligence library and is informed by leading security and privacy frameworks, including:

  • OWASP Top Ten
  • OWASP Top Ten for APIs
  • OWASP Top Ten for LLMs
  • STRIDE
  • LINDDUN
  • MAESTRO
  • And more

As attributes are applied to elements—and combined with data flows and trust boundaries—Devici determines which threats apply and which mitigations are relevant.

Tip

If a threat appears unexpected or irrelevant, review the element’s attributes, data flows, and trust boundaries before dismissing it. Most “bad threats” are caused by incomplete context, not Codex errors.

Where threats and mitigations appear

Threats and mitigations are reviewed in the right-side drawer when working with a threat model.

Threats are generated per element, based on: - The element’s attributes - Its role in the system - How data flows to and from it - Whether it crosses trust boundaries

This means the same threat may appear differently—or not at all—on different elements.

Step 1: Review threats for an element

Start threat review one element at a time.

How to approach threat review

For each threat, ask: - Why does this threat apply? - What assumption is it challenging? - What would failure look like if this threat were exploited?

Your goal is to validate relevance, not immediately decide on mitigation.

Tip

Treat threat review as a design validation exercise, not a checklist. If a threat forces you to rethink an assumption, the model is doing its job.

Step 2: Validate or dismiss threats

Not every generated threat will require action.

When a threat is valid

A threat is valid if: - The condition described could realistically occur - The impact would matter to the system or users - The threat highlights a real design or control gap

Valid threats should be kept and reviewed further.

When a threat may be dismissed

A threat may be dismissed if: - The condition cannot occur due to architectural constraints - The risk is explicitly accepted and documented - The threat is addressed by systemic controls not visible in the model

Warning

Dismissing a threat should be a deliberate decision. If you cannot explain why it does not apply, it probably does.

Step 3: Review mitigations

Each threat includes one or more recommended mitigations.

Mitigations represent actions or controls that reduce the likelihood or impact of a threat.

How to review mitigations

For each mitigation, decide: - Is this already implemented? - Is it planned? - Will it not be implemented—and why?

This step connects threat modeling directly to engineering and operational work.

Mitigation status states

Devici provides multiple status states to track mitigation progress:

  • Green check mark
    The mitigation is already implemented

  • Yellow clock
    The mitigation is planned or needs to be implemented

  • Red clipboard X
    The mitigation will not be implemented

Statuses provide immediate visibility into security posture and remediation gaps.

Warning

Marking a mitigation as “not implemented” does not remove the underlying risk. Ensure the rationale is understood and documented.

Step 4: Decide what “done” looks like

Threat review does not require every threat to be mitigated.

A threat review is usually “done enough” when: - All threats have been reviewed for relevance - Mitigations have an explicit status - High-risk threats have a clear path forward - Risk acceptance decisions are intentional, not accidental

Tip

Threat modeling is iterative. You are aiming for clarity and prioritization, not perfection.

Custom threats and mitigations

Devici Codex threats and mitigations support limited note-taking and metadata updates.

Use Custom Threats and Mitigations when you need to: - Capture system-specific risks not covered by the Codex - Add organization-specific controls - Track architectural risks unique to your environment

Tip

Prefer Codex threats when possible. Use custom threats sparingly to avoid fragmenting your threat model.

How threats and mitigations affect reporting

Threats and mitigation statuses are reflected in exported reports.

Reports can be used to: - Support remediation planning - Create engineering backlog items - Communicate risk to stakeholders - Track changes over time

Exports represent a point-in-time snapshot of risk and mitigation state.

What’s next

After reviewing threats and mitigations, you can:

Threats and mitigations are where threat modeling turns into action.