Why Your Threat Intelligence Context Doesn't Export

Many TIP buyers say the same thing during evaluation: “We can always export to STIX and leave.” It’s the security blanket of procurement. The exit door is right there, labeled in OASIS standard formatting, and it makes the commitment feel reversible.

The exit door is real. The question is what fits through it.

What STIX actually carries

STIX 2.1 is a good standard. MalCloud’s database schema was aligned to it, and its codebase exports STIX 2.1 bundles. A STIX bundle exported from any competent TIP gives you:

• STIX Domain Objects — indicators, threat actors, malware, campaigns, attack patterns, vulnerabilities, and the other 12 SDO types defined in the spec
• STIX Relationship Objects — edges connecting those nodes (threat-actor --uses--> malware, indicator --indicates--> campaign)
• Basic metadata — created/modified timestamps, confidence scores (a single integer, 0-100), TLP markings, external references

This is the graph structure. Nodes and edges with properties. If your threat intelligence is purely structural — you imported feeds, you linked objects, you never annotated anything — then STIX export gives you most of what you had. You can reimport it into OpenCTI, MISP (via misp-stix), or another STIX-native platform and lose relatively little.

Most organizations don’t stop at structure.

What stays behind

The moment your analysts start working inside a TIP, they generate context that the platform stores in its own tables. This context is where much of the intelligence value accumulates.

Analyst annotations

Your senior analyst marks an IP indicator with a note: “False positive — this is a Cloudflare CDN egress node. Confirmed via ASN lookup and three separate customer reports. Do not alert.” That annotation is the difference between a useful indicator and a noisy one.

STIX 2.1 can carry it. A Note object holds free-text analysis and points at the objects it discusses, and an Opinion object records agreement on a five-point scale with an optional free-text explanation (sections 4.13 and 4.15 of the spec). Whether your platform writes its internal annotations out as Notes and Opinions when you export is a separate question. In our experience the answer is often no.

Annotations accumulate. Each one encodes institutional knowledge: which feeds produce false positives for your environment, which threat actor attributions your team trusts, which indicators fired in your network versus which are theoretical.

Confidence history

Most exports give you a confidence score. One number, as of now.

They don’t give you the trajectory. That indicator started at confidence 90 when it came from a trusted ISAC feed on March 3. On March 10, an analyst downgraded it to 70 after noticing the IP appeared in legitimate CDN ranges. On March 15, a false positive investigation dropped it to 40. On March 22, a new sighting from a honeypot bumped it back to 75.

That history is a signal. An indicator with stable confidence of 75 is different from one that oscillated between 40 and 90 over three weeks. STIX itself supports versioning: every revision of an object keeps its id and gets a new modified timestamp (section 3.6), so the trajectory can be expressed. Most exports ship only the latest version, and the history disappears.

Provenance chains

Your graph says threat actor APT-X is linked to campaign Y. Why? Because enrichment source Z found infrastructure overlap between APT-X’s known C2 servers and domains registered with the same privacy service used in campaign Y, corroborated by a YARA rule match on a sample first seen in honeypot session Q, which your analyst cross-referenced against a vendor report from November.

That chain of reasoning — the why behind the edge — is often the most valuable thing in a graph. STIX Relationship Objects carry a description field. In our experience, platforms store the relationship and lose the investigative trail that justified it. Export the graph, and you get “APT-X —attributed-to—> Campaign Y” with maybe a sentence of description. The enrichment logs, the honeypot session data, the analyst’s reasoning, the chronology of how the link was built: gone.

Everything else

Investigation timelines. Case management notes. Workflow state — which indicators were reviewed, which are queued, which were escalated. Dashboard configurations. Saved queries. Alert suppression rules. Integration configurations mapping your TIP outputs to your specific SIEM field names.

Most of this has no standard STIX representation. None of it is proprietary lock-in in the traditional sense. It’s operational context that accumulates through use.

What MalCloud’s Graph Context service did

We added a Graph Context service to MalCloud in April 2026 to keep some of this context. As implemented in MalCloud’s codebase (it was never offered as a hosted service):

• Provenance records. An analyst could record a provenance link between two entities: one of four relationship types, free-text reasoning, an optional evidence reference, an author ID and a timestamp. These records were separate rows. They were not attached to graph edges and were not included in MalCloud’s STIX or MISP exports.
• Annotations. Four kinds (note, tag, confidence override, false positive) could be attached to any entity ID. They were append-only and timestamped, and could be listed per entity and filtered by kind. There was no search across annotations.
• Confidence overrides. Manual overrides made through Graph Context were written to an audit table and could be queried per entity. Automatic confidence decay elsewhere in MalCloud overwrote the score without keeping history.
• Audit log. Graph Context’s annotation and provenance writes went to a Postgres table that rejects UPDATE and DELETE. Other MalCloud services did not write to it.

If you run a regulated financial entity, DORA Article 28(8) requires an exit strategy for ICT services that support critical or important functions. Knowing what your TIP export leaves behind is part of writing one.

The data gravity equation

Every day analysts use a TIP, they deposit context that increases the platform’s value to the organization. Annotations, provenance, confidence histories, investigation workflows — this context accumulates, and much of it cannot be fully reconstructed elsewhere. Not necessarily because a vendor encrypts it or locks it behind proprietary formats, but because the platform never writes it into the export. It’s the analyst equivalent of institutional memory: you can transfer the facts, but not the judgment that organized them.

This creates switching cost.

The data gravity concept isn’t new. Every SaaS platform that stores your work product creates it. Salesforce has your pipeline history. Jira has your sprint velocity data. Confluence has your team’s documentation. The question isn’t whether switching cost exists — it always does. The question is whether the value you’re accumulating justifies the gravity, and whether your export can carry it.

A test you can run

If you’re evaluating TIPs and want to understand what your export actually contains: export your current platform’s data as STIX, reimport it into a clean instance, and see what’s missing. Then check whether the missing context could have been written as Notes, Opinions or object versions. The gap between what you exported and what you had is your platform’s context gravity. Every TIP has some.