STIX/TAXII import and Recorded Future in Dynatrace: threat reports and IoCs

A STIX/TAXII import in Dynatrace, together with the Recorded Future one, turns external threat reports into events you can query in Grail. The documentation is recent: the STIX/TAXII extension page is dated 17 August 2026, and the SaaS 1.347 release notes (rollout started 16 September 2026) mention both integrations. I re-read them on 29 October 2026. This article applies to Dynatrace SaaS , not Managed.

Why should an SRE or a security team care? A threat report is of little use while it sits in a PDF. Once its indicators of compromise (IoCs: IP addresses, domains, hashes, CVEs) are stored to your logs and spans, “are we exposed?” becomes a query rather than a manual investigation.

I have not installed these extensions: everything below comes from the official documentation and the OASIS specifications. At each step I also say what the platform does and what remains your team’s job.

STIX/TAXII import: what the standards say

STIX (Structured Threat Information Expression) is a machine-readable format for describing threat intelligence. TAXII (Trusted Automated Exchange of Intelligence Information) is the RESTful HTTPS protocol used to exchange that content. The TAXII 2.1 specification defines four notions that matter here:

Discovery : the GET /taxii2/ entry point returns information the server and the list of its API Roots;

API Root : a logical grouping of Collections, with its own base URL;

Collection : a logical repository of intelligence objects;

Get Objects : GET {api-root}/collections/{id}/objects/ , which accepts the match[type] (object type) and added_after (UTC timestamp) filters.

On the STIX side, version 2.1 defines the Indicator object with three required properties: pattern , pattern_type and valid_from . It also defines a confidence property, an integer from 0 to 100 that expresses the producer’s confidence. This matters because Dynatrace’s extension keeps the confidence in a dedicated field.

STIX/TAXII import in Dynatrace: prerequisites and behaviour

According to the extension documentation, the source must be a TAXII 2.x-compatible platform (OpenCTI is the example given) that exposes Discovery, API Roots and Collections with readable report objects. On the Dynatrace side you need an ActiveGate version 1.310 or later that can run the Extensions 2.0 framework, with network access to the Discovery URL. Authentication uses either a username and password or an API key as a Bearer token.

An access token with the openpipeline.events_security scope is also required. The page points to Hub > Extensions > Technical information for the permission list without itemising it.

What the extension does

It discovers the API Roots and readable collections, or only the collection IDs you configure.

It polls each collection with match[type]=report and an added_after window.

On the first run it fetches reports from the last m days (configurable initial window); afterwards it checks every n minutes (configurable frequency) and ingests only new or updated reports. The page gives no default values.

When “Collect all reports” is off, three client-side filters apply: name contains, confidence greater than a value, and labels.

Recorded Future in Dynatrace: Analyst Notes

The Recorded Future integration follows the same pattern, with a commercial source. You need a Recorded Future account with access to Analyst Notes, an API token (the X-RFToken header), an ActiveGate 1.310 or later and the same openpipeline.events_security token. The extension calls the Analyst Note APIs.

It supports only Analyst Notes from the News and Research experience. On the first run it fetches notes published in the last m days; afterwards it looks every n hours. Only new notes are ingested: nothing is backfilled beyond the initial window. The documentation gives no default values here either.

Recorded Future is a paid third-party service: span.observer has no tie to it, and the Dynatrace documentation says ingestion is billed under “Events powered by Grail” consumption.

A common data model: THREAT_REPORT

In both cases each report becomes an event of type THREAT_REPORT , stored in the default_securityevents bucket and aligned with the semantic dictionary. IoCs land in the same threat.observables.* fields: they are arrays, flagged optional and experimental in the dictionary.

Each source adds its own fields: stix_taxii.title , stix_taxii.report.id and stix_taxii.report.confidence for STIX/TAXII; recordedfuture.note.portal_url , recordedfuture.note.source.name and recordedfuture.note.validated_on for Recorded Future. The original payload stays in event.original_content .

Limits to keep in mind: only these eight IoC types are mapped. On the STIX side, IoCs are extracted only from enriched indicator or vulnerability objects; the enriched object types the page lists are attack-pattern, threat-actor, identity, indicator, intrusion-set, location, malware and vulnerability.

In practice: install and verify

Step 1: prepare the source and the token

For TAXII, note the Discovery URL and the authentication mode. For Recorded Future, get the API token. In Dynatrace, create a token with the openpipeline.events_security scope, and keep it out of repositories and screenshots.

Step 2: install the extension

In Dynatrace, for “STIX/TAXII” or “Recorded Future”, choose Install, then follow the on-screen configuration instructions. Afterwards you manage it under Extensions.

Step 3: verify in Notebooks

These two queries come from the documentation. If they return events, ingestion works.

The Threat Hunting agent: what the documentation says (and does not say)

The SaaS 1.347 release notes introduce a Threat Hunting agent. Here is only what they state. The agent searches your logs, spans and security detections for the IoCs of a threat report, then scores your exposure. It accepts a report URL, pasted text, a STIX feed or a list of indicators. You start it from the ready-made threat intelligence dashboards, from Assist or from agentic workflows.

One limit is explicit: hunts cover recent telemetry, and each result states how far back it looked. A “no exposure” result therefore holds only for that window.

On 27 October 2026 I found no dedicated documentation page for this agent, and so no prerequisites, permissions or scoring method. I say nothing more it. Do not confuse it with the Threat Triage Agent, which has its own page: it extracts IoCs from threat alerts and analyses their exposure, with a separate workflow.

Platform and team: who does what

The platform polls the source, converts reports into events, extracts the IoCs of the supported types and stores them in Grail.

Your team chooses trustworthy sources, sets confidence filters, protects tokens, watches ingestion and cost, reads results together with their time window, and decides the response. The documentation describes no automatic remediation.

Start with a single source and a short initial window, then measure the event volume.

Use the confidence and label filters instead of ingesting every report.

Treat “no exposure” as bounded by the covered period, never as proof of absence.

Check ingestion regularly: an unreachable ActiveGate silently stops reports from arriving.

Keep tokens in a vault and never show one in a screenshot.

To go further, see our articles on Dynatrace Application Security , advanced DQL , log ingestion and guardrails for AI agents . Sources: STIX/TAXII ingestion , Recorded Future ingestion and TAXII 2.1 (OASIS) .

Frequently asked questions

Do I need a Recorded Future account to use the STIX/TAXII import?

No. They are two separate extensions. STIX/TAXII needs a TAXII 2.x-compatible source; Recorded Future needs an account with Analyst Notes access and an API token.

Where do I find the imported reports?

In Grail, with fetch security.events filtered on event.type == "THREAT_REPORT" and on the provider. The events are in the default_securityevents bucket.

Is the Threat Hunting agent required to use this data?

The documentation does not say so. The reports are events you can query with DQL. The agent, introduced in the 1.347 release notes, automates hunting, but its detailed documentation did not exist on 27 October 2026.

Both integrations put threat intelligence in the same store as your telemetry, with a common model and typed IoCs. They replace neither the choice of sources nor the critical reading of results. As for the Threat Hunting agent, wait for its dedicated documentation before building a procedure on it.

span.observer is an independent community blog, not affiliated with Dynatrace LLC or Recorded Future. Cited trademarks belong to their owners. Features evolve quickly: check them in the official documentation.