Importing into SD Elements

Once you have a .otm file exported from Devici, import it into the destination SD Elements project. SD Elements extracts the attributes carried on the Elements in the OTM, merges them into the project’s attribute pool, and generates Countermeasures from the combined attribute set. For any custom Devici mitigation that has no matching Library Countermeasure, SD Elements creates a project-specific custom Countermeasure tagged devici. The mitigation detail and the threat it addresses live inside that Countermeasure’s Solution section. All generated Countermeasures are pushed to the project’s connected Issue Tracker using the existing tracker configuration.

The import writes attributes first and foremost: the attributes carried in the OTM are what populate the project and drive Countermeasure generation. Custom Devici mitigations are brought into SD Elements as well. They become custom Countermeasures tagged devici, so the project is a single source of truth and no requirement from the threat model is lost. Each custom Countermeasure shows the Devici threat it addresses in its Solution section, so the reader always knows what the mitigation is for. Devici threats and Elements are not created as SD Elements primitives. Threats appear only as context inside the custom Countermeasures, and Elements are preserved as a visualization on the Devici tab. See How Devici content maps for the full data-model reference.

The Devici File Import feature flag must be enabled system-wide before the import surface appears.

Two ways to import

A Devici threat model can be imported from two places on the SD Elements project, depending on whether the project has any content yet.

Entry point When to use it

Get Started Modal — Import from a Devici file

When the project has just been created and you want to set it up from a Devici threat model rather than answering the project survey. The Get Started Modal appears the first time a user opens a new or empty project and lists the available setup options. The OTM file populates the project’s attribute pool with the attributes the architect set in Devici. Best for new projects where the threat model already exists in Devici.

Devici tab on the project

When the project already has content, or when the Get Started Modal has been dismissed. Used to add a Devici-sourced threat model to a project that was previously survey-driven or otherwise manually populated, or to re-import an updated model into a project that was previously imported from Devici. Best for ongoing programs and re-imports.

Both entry points use the same import workflow, the same OTM file format, and produce the same output. Only the wrapper around the upload differs.

Importing from the Get Started Modal

Use this entry point to set up a newly created SD Elements project directly from a Devici threat model.

Steps:

  1. Open the newly created project. The Get Started Modal opens automatically the first time the project is opened. (If it has been dismissed, click Get Started on the project overview to reopen it.)

  2. In the Get Started Modal, click Import from a Devici file. The import dialog opens.

  3. Click the paperclip icon and select the .otm file you exported from Devici. See Exporting an OTM from Devici.

  4. Click Import.

SD Elements runs the import immediately. See The import workflow below for what happens during processing.

A project that leverages a Devici import can still answer the standard project survey afterward; the two are not mutually exclusive. Survey answers populate additional attributes on top of the Devici-imported attributes, and the combined attribute set drives Countermeasure generation. This is useful when the Devici model covers the architecture but the survey covers organization-wide or process-wide questions (deployment model, regulatory scope, language and framework versions) that are not naturally part of a threat model.

Importing on an existing project (the Devici tab)

Use this entry point to add Devici-sourced architecture to a project that already has content, or to re-import an updated model.

Steps:

  1. Open the project from Applications → [Application] → [Project].

  2. Click the Devici tab in the project navigation.

  3. Click the paperclip icon in the upload area and select the .otm file you exported from Devici.

  4. Click Import.

SD Elements begins processing the model. See The import workflow below.

The Devici tab appears on every project in the instance once Devici File Import is enabled. On a project that has no previously imported model, the tab shows the upload prompt. On a project that has been imported from Devici, the tab shows the embedded diagram, the import summary from the most recent import, and the option to re-import.

You will receive the error OTM document failed validation if the uploaded file is not a valid OTM v0.2.0 document. Devici exports always pass validation; this error usually indicates a file from a third-party tool or a manually edited OTM. Re-export from Devici to resolve. See Exporting an OTM from Devici.

An OTM document with more than 250 Elements returns a warning before the import begins. Very large models are supported, but the import may take several minutes to process. It runs asynchronously, so you can navigate away from the page; the progress is preserved and a notification appears in the bell menu when the import completes.

The import workflow

The import runs in three phases. Each phase is surfaced in the import progress dialog so you can confirm progress and audit what changed. If any phase fails, the import stops before project data is modified, and no partial state is written.

Phase 1 — Validation

SD Elements validates the OTM document against the v0.2.0 schema and confirms that:

  • The document is well-formed JSON.

  • All required OTM fields are present.

  • Every dataflow references Elements that exist in the document.

  • The methodology tags on threats are recognized (STRIDE, LINDDUN, MAESTRO, custom).

If validation fails, the dialog shows the specific validation errors with line numbers. Nothing is written to the project.

Phase 2 — Attribute and mitigation mapping

SD Elements reads each Element in the OTM document and processes its content as follows. Built-in Devici codex content always has a matching equivalent in the SD Elements Library (maintained by Security Compass at release time), so the mapping for built-in content is automatic. Custom Devici codex content (anything an organization has authored specifically in their Devici workspace) does not have a Library equivalent and is materialized as project-specific custom Countermeasures tagged devici.

Attributes. SD Elements extracts the attributes carried on the Element. Built-in attributes are matched on ref_id to the equivalent attribute in your SD Elements Library and merged into the project’s attribute pool (the same pool the project survey populates). The Element itself is not created as an SD Elements Component; only the attributes are written to project state.

Mitigations. For each mitigation attached to a threat on the Element, SD Elements checks whether the mitigation is built-in.

Mitigation type Behavior

Built-in mitigation

Always has a matching Countermeasure in your SD Elements Library. No custom Countermeasure is created; the matching Library Countermeasure is generated through the attribute path above, and the Devici mitigation appears in that Countermeasure’s Reason for inclusion.

Custom mitigation (organization-specific, authored in Devici)

A custom Countermeasure tagged devici is created for it. The mitigation detail and the threat it addresses render inside the custom Countermeasure’s Solution section.

Threats are not processed. Devici threats do not have their own mapping logic. They are display-only metadata: rendered on the embedded diagram, and rendered inside the Solution section of any custom Countermeasure that was created for a mitigation attached to them.

See How Devici content maps for the full data-model reference.

Phase 3 — Countermeasure generation

Countermeasures are generated from two sources:

From the project’s attribute pool (the primary path):

  • Every attribute in the project’s pool (Devici-imported attributes plus any pre-existing survey-driven or manually-set attributes) produces the Countermeasures associated with that attribute in your Library.

  • The project’s existing compliance-framework mappings are applied: PCI DSS, SOC 2, NIST 800-53, HIPAA, ISO 27001, FedRAMP, plus any custom framework configured on the project.

  • Each Library Countermeasure produced from a Devici-imported attribute carries a Reason for inclusion pointing back to the originating Devici Element. These Countermeasures are not tagged devici; they are standard Library Countermeasures, indistinguishable from Countermeasures triggered by the same attribute coming from a survey answer (except for the Devici-sourced Reason for inclusion).

From custom Devici mitigations (the custom mitigation path):

  • For each custom Devici mitigation, a project-specific custom Countermeasure is created.

  • The custom Countermeasure is tagged devici for filtering.

  • It identifies the source Devici Element in its metadata.

  • Its Solution section renders the Devici mitigation detail alongside the threat the mitigation addresses (the threat appears as metadata inside the Solution; it is not created as a separate Weakness on the project).

  • The methodology tag (STRIDE, LINDDUN, MAESTRO, custom) on the originating threat is preserved on the Countermeasure for filtering.

The dialog shows: Countermeasures generated: 184 (178 from attributes + 6 custom devici).

On a project that already had survey answers before the Devici import, the Countermeasure set generated after the import reflects the combined attribute pool: Devici-imported attributes plus existing survey-driven attributes. This is intentional. Devici-imported attributes do not replace or override survey-driven attributes; both are inputs to the same generation logic.

Viewing the embedded Devici diagram

Once an OTM document has been imported, the Devici tab on the project renders the original Devici canvas inline alongside the upload and re-import controls. The canvas is displayed read-only with the same layout, Elements, dataflows, and trust boundaries as the source Devici model. The diagram is a visualization of the Devici threat model; the Elements on it are not SD Elements primitives, and clicking around does not navigate the SD Elements project.

Each Element on the canvas is clickable as a visualization aid:

  • Clicking an Element opens a side panel listing every Countermeasure whose Reason for inclusion points back to that Element: both Library Countermeasures triggered by the Element’s attributes and custom Countermeasures (tagged devici) created for custom mitigations attached to threats on the Element.

  • Sort the side panel by attributes to view the mapped attributes between Devici and SD Elements.

The embedded diagram is a snapshot of the OTM document at import time. To pick up changes made in Devici after the import, re-export from Devici and re-upload the new OTM file on the Devici tab. See Re-importing an updated model.

Next steps

  • How Devici content maps — understand the relationship between Devici concepts and SD Elements primitives, including the Reason for inclusion each Devici-sourced Countermeasure carries.

  • Re-importing an updated model — propagate Devici model changes into the project.

results matching ""

    No results matching ""