How Devici content maps

Import from Devici extracts the attributes carried on a Devici threat model and merges them into an SD Elements project. The same Library content that powers your other SD Elements projects powers your Devici-imported projects — only the input path is new.

This page is the reference for understanding what the OTM actually writes to the SD Elements project, what it does not, and how the Reason for inclusion on each Devici-sourced Countermeasure connects it back to the originating Devici input.

Two things are written to the SD Elements project on import — attributes, and custom Countermeasures for custom Devici mitigations. In detail:

  1. Attributes from the OTM — merged into the project’s attribute pool (the same pool the survey populates). Attributes trigger standard Library Countermeasures the same way survey-driven attributes do. This is the primary path.

  2. Custom, project-specific Countermeasures for custom Devici mitigations — when a Devici mitigation is custom (authored in your Devici workspace, not part of the built-in Devici codex), it is materialized as a custom Countermeasure scoped to the project. The custom Countermeasure is tagged devici, identifies the Element it came from, and renders the Devici mitigation detail inside its Solution section. The threat that the mitigation addresses is rendered alongside it as part of the Solution — purely as metadata so the reader knows what the mitigation is for. There is no separate threat primitive on the SDE side. There is no separate mapping or processing of threats — only mitigations drive Countermeasure creation through this path.

Everything else in the OTM — Elements themselves, dataflows, trust boundaries, methodology tags, canvas layout — is preserved on the Devici tab as a read-only visualization, and is surfaced in the Reason for inclusion on generated Countermeasures where relevant, but is not turned into SD Elements primitives. In particular: Devici Elements are not created as SD Elements Components, and Devici threats are not created as SD Elements Weaknesses.

Built-in Devici codex content always matches the SD Elements Library. Security Compass maintains the built-in Devici codex and the built-in SD Elements Library in alignment at the product level, so every built-in attribute and every built-in mitigation that arrives in an OTM has a guaranteed equivalent on the SDE side. There is no manual reconciliation step, no Gap Review panel, and no "unmatched" path for built-in content. Anything that does not match — by definition, anything authored as custom in your Devici workspace — is materialized as a custom Countermeasure tagged devici as described above.

Terminology — Element vs Component. Devici and SD Elements use different names for the canvas/architecture primitive, and this guide keeps the distinction sharp.

  • In Devici, a node on the threat-model canvas is an Element (process, data store, external entity, trust boundary).

  • In SD Elements, the analogous primitive is a Component.

Import from Devici does not map Elements to Components. Elements stay in Devici and are shown read-only in the embedded diagram on the Devici tab. The SDE project’s Components (if any) are whatever was already there — added manually or via the survey-driven path.

Mapping reference

The table below distinguishes between what the OTM writes to project state on the SDE side (attributes and the Countermeasures they produce) and what it preserves only as visualization on the *Devici tab or as content in the Countermeasure’s Reason for inclusion* (everything else).

Devici concept What happens on import Writes project state?

Threat model (the OTM file itself)

Becomes an additional input alongside any survey answers and manually-set attributes. A project can use the survey, an OTM import, or both — they feed the same attribute pool.

Yes (via attributes)

Element (process, data store, external entity, sticky note)

Preserved on the Devici tab as part of the read-only embedded diagram. Not created as an SD Elements Component. The attributes carried on the Element are extracted and written to the project’s attribute pool.

No (only its attributes are written)

Trust boundary

Preserved as an Element grouping on the embedded diagram. Trust boundaries do not produce Countermeasures on their own; the attributes on the Elements inside the boundary still flow to the project’s attribute pool through the Element attribute rows below.

Yes (via attributes)

Dataflow

Preserved on the embedded diagram. Dataflow attributes (encryption, authentication, protocol) are written to the project’s attribute pool as if they were attributes on the dataflow’s source and target Elements.

Yes (via attributes)

Element attribute (built-in)

Always matches an equivalent attribute in your SD Elements Library. Added to the project’s attribute pool. This is the primary thing that drives Countermeasure generation.

Yes

Element attribute (custom — organization-specific)

Carried into the OTM document as part of the export. Custom attributes do not have a built-in Library equivalent; any mitigation associated with the attribute is handled through the custom mitigation path — see the Mitigation row below.

Via the custom mitigation path

Threat (built-in or custom codex)

Not mapped to anything. Threats are display-only metadata in two places: rendered on the embedded diagram on the Devici tab, and rendered inside the Solution section of any custom Countermeasure that was created for a mitigation attached to the threat (see Mitigation row below). They are not created as Weaknesses on the SDE project, and they do not drive Countermeasure creation on their own. Methodology tag (STRIDE, LINDDUN, MAESTRO, custom) is preserved on the Reason for inclusion of any Countermeasure whose chain of origin includes the threat.

No (display metadata only)

Mitigation (built-in)

If the mitigation has a matching ref_id to a Countermeasure in your SD Elements Library, no separate primitive is needed — the Library Countermeasure is generated through the attribute path above and the Devici mitigation appears in that Countermeasure’s Reason for inclusion. No custom Countermeasure is created.

No (covered by the attribute path)

Mitigation (custom — no matching Library Countermeasure)

Materialized as a project-specific custom Countermeasure, tagged devici. The custom Countermeasure identifies the Devici Element it came from. Its Solution section renders the Devici mitigation detail alongside the threat the mitigation addresses (the threat is shown purely as metadata, not created as a separate primitive).

Yes — as a custom Countermeasure tagged devici

Canvas layout (positions, sizes, colors)

Rendered on the Devici tab on the project view. Read-only. Preserved from the source Devici canvas so the embedded diagram looks like what the architect drew.

No

In short: the Writes project state? column has only two kinds of "Yes" rows — attributes (the primary path) and custom Devici mitigations (the secondary path, materialized as custom Countermeasures tagged devici). Everything else, including all Devici threats, lives on the Devici tab as a visualization or as metadata on generated Countermeasures.

The two kinds of Countermeasures on a Devici-imported project

After an import, the project’s Countermeasure list contains two kinds of Countermeasures whose ultimate source is Devici. They are filterable separately on the Countermeasures page.

Kind Behavior

Library Countermeasures triggered by Devici-imported attributes

Standard SD Elements Library Countermeasures, no different from Countermeasures that would have been generated if the same attribute had been set by a survey answer. They are not tagged devici — the attribute carries the Devici provenance through the Countermeasure’s Reason for inclusion. These come from the attribute path.

Custom Countermeasures tagged devici

Project-specific custom Countermeasures created for custom Devici mitigations that have no matching Library Countermeasure. Tagged devici for filtering. Each one identifies the Devici Element it traces back to. The Devici mitigation detail lives inside the Solution section of the Countermeasure, alongside the threat the mitigation addresses (rendered as metadata, not as a separate primitive). These come from the custom mitigation path.

Both kinds are pushed to the project’s connected Issue Tracker using the existing tracker configuration. Both kinds appear on standard SD Elements reports. The distinction matters for audit traceability (custom devici-tagged Countermeasures are not in your Library and cannot be generated by a survey on another project — they are unique to this project’s Devici import).

Attribute-driven generation: a worked example

Two Devici Elements illustrate why the attribute is the only thing that matters for SDE-side output. The Elements themselves never appear on the SDE side — only the attributes carried on them do.

Devici Element (visualization only) Attributes on the Element (written to the project’s attribute pool) What gets generated on the SDE side

Payments API

internet-facing, processes-pii, accepts-payment-card-data

Countermeasures for input validation on a public endpoint, PII handling, PCI-DSS-scoped controls (tokenization, key management, audit logging), and authentication on a public surface.

Order Queue

internal-only, transient-data

Countermeasures for internal-only access control and basic message integrity. No PII or PCI controls — those attributes are not set.

The two Elements produce very different Countermeasure sets even though both are of the same Devici Element type (process). The attributes the architect modeled in Devici are what determined the output. Add an attribute in Devici → re-import → the Countermeasures for that attribute appear. Remove an attribute → re-import → the Countermeasures for that attribute are Retired.

All built-in Devici attributes match equivalent attributes in your SD Elements Library, so no manual reconciliation is needed. If the architect added a custom mitigation in Devici — for example, an organization-specific control for a unique business requirement — that mitigation is materialized as a custom Countermeasure tagged devici on the SDE side, regardless of which Element it was attached to.

Reason for inclusion

Every Countermeasure on an SD Elements project carries a Reason for inclusion — the field that answers why is this Countermeasure in my project? For Countermeasures whose generation is influenced by a Devici import, the Reason for inclusion traces back to the originating Devici Element and the specific Devici input that produced it. The exact answer depends on which path produced the Countermeasure.

Next steps

  • Re-importing an updated model — how the mapping behaves when the source Devici model changes.

  • FAQ — answers to common questions about codex alignment, supported frameworks, and roadmap items.

results matching ""

    No results matching ""