Re-importing an updated model

Import from Devici is file-driven on this release — there is no live connection between SD Elements and the Devici workspace. To propagate a change from a Devici threat model into SD Elements, re-export the model from Devici and re-upload the new OTM file on the project’s Devici tab. This is deliberate: customers want auditability over the moment a threat-model change becomes a requirement-set change, and an explicit re-upload provides that signoff point.

The customer re-exports the threat model from Devici, clicks the re-import icon near the top of the embedded canvas on the Devici tab, and selects the new OTM file. SD Elements processes the file automatically using the same additive behavior as the first import: net-new attributes are added to the project’s attribute pool, net-new custom mitigations become custom Countermeasures tagged devici, and Countermeasures that are no longer triggered are marked Retired. Existing tracker tickets are not deleted. There is no diff preview, no manual review step, no confirmation dialog — the updated model just replaces the previous snapshot.

A model can be re-imported as often as you need.

Triggering a re-import

Steps:

  1. In Devici, re-export the updated threat model. See Exporting an OTM from Devici.

  2. In SD Elements, open the project and click the Devici tab.

  3. Click the re-import icon near the top of the embedded canvas.

  4. Select the updated .otm file.

SD Elements processes the file automatically. The same three steps as the initial import run (validation, attribute and mitigation mapping, Countermeasure generation), the embedded diagram refreshes to the new snapshot, and the Import Summary appears when processing completes — showing the count of net-new attributes, net-new custom Countermeasures tagged devici, and Countermeasures marked Retired relative to the previous state.

How Countermeasure statuses are handled

Re-imports preserve manual Countermeasure status changes by default — any Countermeasure that a user previously transitioned (for example to Implemented or Not Applicable) retains its status across re-imports. The re-import only adds, retires, or refreshes Countermeasures based on what changed in the source Devici model.

State before re-import Behavior

Countermeasure was generated previously and is still triggered by the updated model

Countermeasure is reused as-is. Any manual status (Implemented, Not Applicable, etc.) is preserved.

Countermeasure was not generated previously but is now triggered

Countermeasure is created.

Countermeasure was generated previously but is no longer triggered

Countermeasure is marked Retired. Its tracker ticket reference is preserved.

A Retired Countermeasure is not deleted. It remains visible on the Countermeasures page when the Status: Retired filter is selected, and it remains in standard SD Elements reports for audit purposes. If a later re-import re-triggers the same Countermeasure (for example, because the architect re-added the relevant attribute), the Retired Countermeasure is restored to Active with its previous tracker ticket reference intact.

How tracker tickets are handled

When generated Countermeasures have been pushed to an Issue Tracker (Jira, GitHub, Azure DevOps), the re-import preserves the link between SD Elements and the tracker:

  • Reused Countermeasures — the existing tracker ticket reference is preserved. If the Countermeasure content changed (for example, the description was updated by a Library change), the change is pushed to the tracker on the next sync.

  • New Countermeasures — a new tracker ticket is created on the next push, using the project’s existing Issue Tracker configuration.

  • Retired Countermeasures — the tracker ticket is not deleted, closed, or modified. It is left in whatever state the development team last put it in. SD Elements marks the Countermeasure as Retired on its side but does not touch the ticket.

The Issue Tracker handling above assumes the project’s existing Issue Tracker configuration is unchanged. If the tracker configuration has been modified between imports (for example, the destination Jira project changed), Countermeasures will push to the new destination on the next sync and the old tracker tickets will be orphaned. This is the same behavior as for survey-driven projects.

Best practices for iterating on a model

There are three supported patterns for bringing an updated Devici threat model into an SD Elements project. Choose the pattern that matches the kind of iteration you are running.

Pattern When to use it Trade-off

A. Incremental re-import (default)

Routine sprint-over-sprint iteration. Architect added a few attributes, refined some Elements, surfaced new threats. You want the developer’s existing tickets and manual statuses to carry forward.

Easy and fast. Diff at the attribute level is precise. No manual cleanup. Best default for ongoing programs.

B. Scope on the Devici side

Major release where the architect wants a focused review of only the changed surface area. Existing, unchanged architecture should not produce another wave of "already implemented" Countermeasures.

Requires Devici-side discipline (marking Out of Scope before export). Cleaner SDE-side review. Best for net-new features layered onto a large, stable existing model.

C. Reset and re-import (clean slate)

Major architecture refactor that supersedes the previous model. Codex alignment was fixed mid-program. Compliance audit asks for a known-clean baseline. The previous import was a learning iteration that should not anchor the audit trail.

Loses all manual Countermeasure status changes. Tracker tickets from the previous import are orphaned in your tracker (not deleted). Best for hard resets, not routine iteration.

Pattern A — Incremental re-import (default)

The recommended pattern for almost all iteration. The Devici architect updates the threat model in place; the AppSec engineer or project owner re-exports and re-uploads the OTM when the change is ready for SDE.

Steps:

  1. In Devici, update the threat model (add Elements, add or remove attributes, surface new threats, refine dataflows).

  2. In Devici, re-export the threat model as OTM.

  3. In SD Elements, open the project, click the Devici tab, click the re-import icon near the top of the embedded canvas, and select the updated .otm file.

SD Elements processes the file automatically. No diff preview, no confirmation step.

Result:

  • Countermeasures that were previously generated and are still triggered by the updated model are reused as-is. Manual status transitions (for example to Implemented in Jira) are preserved.

  • Countermeasures that are newly triggered by the updated model are added.

  • Countermeasures that are no longer triggered are marked Retired — they are not deleted, and their tracker tickets are not closed.

  • Net-new attributes from the updated Devici model are added to the project’s attribute pool.

  • The embedded diagram on the Devici tab is refreshed to the new model snapshot.

Pattern A is the assumed pattern when developers see a ticket appear in Jira / GitHub / Azure DevOps that references a Devici-sourced Countermeasure. The link in the ticket points back to the originating Devici threat, which always reflects the state of the model as of the most recent re-upload.

Pattern B — Scope on the Devici side

For a major release where the goal is to bring only the new architecture into SD Elements — for example, a new payments service being added to an existing platform — the architect can mark the unchanged portion of the threat model as Out of Scope in Devici before exporting. The OTM export honors the Out of Scope status; the resulting import in SD Elements adds only the in-scope portion to the project.

Recommended flow:

  1. In Devici, open the threat model.

  2. Select the existing, unchanged Elements (and their attributes) that should not produce Countermeasures in this iteration.

  3. Mark them as Out of Scope. (Refer to the Devici documentation for the exact UI for the Out of Scope status.)

  4. Export the OTM. The export includes the Out of Scope markers; SD Elements honors them on import.

  5. In SD Elements, click the re-import icon on the Devici tab and select the new OTM. SD Elements processes it automatically — only the in-scope portion is brought in, since the Out of Scope markers are honored at import time.

When the new release ships and the new architecture is no longer "net new", re-mark those Elements as in-scope in Devici for the next iteration. This keeps the import surface focused on the iteration being worked on without losing the broader architecture from the threat model.

Pattern B does not retire previously generated Countermeasures whose triggering attributes came from now-out-of-scope Elements — those attributes remain in the project’s attribute pool from the previous import, and the Countermeasures they triggered remain Active on the SD Elements side. The Out of Scope marker only governs what new attributes get added in this iteration. To retire Countermeasures for a deprecated portion of the architecture, remove the relevant Elements or attributes from the Devici model rather than marking them Out of Scope.

Pattern C — Reset and re-import (clean slate)

For a hard reset — major architecture refactor, codex realignment, a compliance audit that needs a known-clean baseline — discard the previously imported state and re-run the import from scratch.

Steps:

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

  2. Click the Devici tab.

  3. Follow Removing imported Devici content to delete every Devici-imported attribute, every Library Countermeasure generated from those attributes, every custom devici-tagged Countermeasure, and the embedded diagram.

  4. Upload the new .otm file from the Devici tab’s upload area (the project now has no Devici content, so the upload area appears again instead of the re-import icon).

Result:

  • A fresh set of Devici-imported attributes is added to the project’s attribute pool, and a fresh Countermeasure set is generated from them.

  • All previously preserved manual Countermeasure statuses are lost.

  • Tracker tickets from the previous import are not deleted from your tracker — they are orphaned (the SD Elements Countermeasure they were linked to no longer exists). Clean them up manually in Jira / GitHub / Azure DevOps if required.

Pattern C is destructive on the SD Elements side. Use it deliberately. For routine iteration, Pattern A (incremental re-import) gives you the same end-state with statuses and ticket history intact.

Removing the Devici model from a project

Removing the Devici-sourced content from a project (Pattern C, step 3 above) is the canonical cleanup operation. Remove Devici Content deletes every attribute that an Import from Devici operation wrote to the project’s attribute pool, every Countermeasure generated from those attributes, and the embedded diagram on the Devici tab. Manually-set attributes, survey-driven attributes, survey-driven Countermeasures, and any Components on the project are not affected.

See Removing imported Devici content for the full procedure.

Deleting the source threat model in Devici (rather than removing the imported content in SD Elements) does not affect the imported content on the SD Elements project. Because Import from Devici is file-driven and SD Elements does not maintain a live connection to the Devici workspace, the SD Elements project has no way to know the source was deleted. The previously imported attributes, the Countermeasures generated from them, and the embedded diagram remain on the SD Elements project unchanged until a user explicitly removes them. To remove the SDE-side content after a source deletion, use the Remove Devici Content action on the project’s Devici tab.

Next step

  • FAQ — answers to common questions about scheduling, automation, on-prem behavior, and the future bi-directional roadmap.

results matching ""

    No results matching ""