Turning MITRE CTI Blueprints into automated, STIX2-driven reports #

Threat intelligence teams rarely struggle to collect more data. The harder part is turning that data into a useful product, on time, for a specific reader.

A campaign report for an incident response team is not the same product as an executive threat assessment. Each needs a recognizable structure, traceable evidence, clear analytic judgments, and consistent language. Rebuilding that structure in a word processor for every reporting cycle consumes analyst time and makes quality harder to control.

The MITRE Center for Threat-Informed Defense CTI Blueprints address the first part of this problem: they provide practical reference designs for common intelligence products. We have implemented four of those designs as open-source BlackStork templates and connected them to STIX 2.1 data:

1. Campaign report
2. Executive report
3. Intrusion analysis report
4. Threat actor profile report

The result is a reporting pipeline rather than another set of static document samples. A template can load current intelligence, select the graph relevant to its subject, and render a consistent Markdown, HTML, or PDF report. It can also use an LLM for narrowly defined writing tasks without delegating the report’s structure or factual tables to the model.

What CTI Blueprints provide #

The CTI Blueprints are reference designs for producing and consuming cyber threat intelligence. They help a team answer basic but important questions:

• Who is this product for?
• What decision or activity should it support?
• Which sections should the reader expect?
• Which analytic details, sources, and qualifications should be present?
• How can STIX and MITRE ATT&CK provide structured context?

This is valuable because report quality depends on more than correct facts. A good intelligence product must make those facts usable. A security leader may need the bottom line, business relevance, and confidence level. A detection engineer may need techniques, infrastructure, indicators, and dates. The Blueprints give both authors and consumers a shared starting point.

They are deliberately reference designs, not a production reporting system. They do not decide how your team will query a threat intelligence platform, scope a large relationship graph, rerun a report when data changes, apply your brand, or publish several output formats. Those are implementation decisions, and they are where recurring manual work tends to return.

The layer BlackStork adds #

BlackStork turns the reference structure into executable templates. We retain the Blueprint’s purpose and recognizable sections, then add the mechanics needed for repeatable production:

• a STIX object ID that identifies the report’s primary subject;
• relationship-aware selection of relevant STIX objects;
• normalization into a stable report model;
• reusable sections for common CTI content;
• explicit handling of unavailable information;
• optional, bounded LLM-generated prose; and
• deterministic Markdown, HTML, and PDF presentation.

The source can be the self-contained example bundle included in each template, an input supplied by an analyst or agent, or live data loaded from another system. The reporting logic stays the same.

This distinction matters: the Blueprints still define the intelligence product. STIX still defines the exchange model. BlackStork connects them in a pipeline that can be validated and rerun.

From a STIX2 bundle to a bounded report #

A STIX2 bundle is a container, not a report scope. A large bundle may contain several campaigns, actors, victims, indicators, and unrelated historical objects. Selecting every object of a convenient type risks quietly mixing unrelated intelligence into the final product.

Each of our templates therefore accepts a primary_object_id. A campaign report expects a Campaign ID; a threat actor profile expects a Threat Actor or Intrusion Set ID. Its normalization query locates that object and follows the relationships needed by the product. For example, it can resolve:

• the actor to which a campaign is attributed;
• the attack patterns, malware, and infrastructure it uses;
• identities and locations it targets;
• indicators that indicate the selected campaign;
• observed data behind those indicators; and
• vulnerabilities exploited by related malware.

Revoked objects and expired indicators are excluded where appropriate. The template also resolves producer identity, object markings, confidence, and external references. The selected objects are normalized into a common .vars.report shape consumed by shared presentation blocks.

STIX2 graph view is not a replacement for the report with the narrative. Stixview can be used to render STIX2 graphs in HTML view, while the finished product explains what those relationships mean to its audience.

How Blueprint sections map to structured intelligence #

Not every report section maps one-to-one to a STIX object. That is expected. STIX represents observable and intelligence-domain data well, while a report also contains analytic judgment and workflow context.

The last two rows are intentionally kept outside the example STIX bundle. Priority intelligence requirements, feedback instructions, probability labels, and some remediation details are properties of the intelligence product or the team’s workflow. Forcing them into custom STIX properties would make exchange harder without improving the analysis. The templates keep that context in a separate variable and combine it with STIX during normalization.

This division also makes the templates easier to adapt. A team can replace the example context with values from its collection-management process without changing its STIX producer.

Deterministic facts, controlled prose #

The templates use BlackStork-native tables and lists for structured content: report identity, key points, ATT&CK mappings, timelines, indicators, vulnerabilities, sources, intelligence gaps, and requirements. Their presence and layout do not depend on an LLM.

When information is unavailable, a required section remains in the report and says so explicitly. That is more useful than silently omitting the section. A reader can distinguish “not available” from an accidental generation failure.

LLMs are optional. With use_llm = false, the templates render a concise summary and assessment directly from normalized fields. With it enabled, content.llm_text can synthesize those fields into audience-appropriate prose. The prompt constrains the task, provides the source data as evidence, and asks the model to identify uncertainty rather than fill gaps.

This is the boundary we recommend:

• facts, identifiers, relationships, required sections, and layout belong to the template;
• analytic judgments belong to the analyst and structured report context; and
• an LLM may help express supplied intelligence as readable prose.

The model does not decide which indicators belong to the campaign or whether a mandatory section exists. Those decisions are made before generation and can be inspected independently.

Replace example data with live intelligence #

The public templates include inline STIX data so they are easy to download, inspect, and render. A production report should normally load current data from an input or an upstream system.

The simplest option is an HTTP data block that downloads a STIX bundle:

data http "campaign_bundle" {
  url = "https://intel.example.org/exports/night-freight.stix2.json"
  format = "json"
}

BlackStork also has data providers for threat intelligence platforms. The OpenCTI data source can query an organization’s OpenCTI GraphQL API. Its exact query and normalization depend on that organization’s schema, labels, and reporting workflow, so we do not prescribe a generic query here.

An EclecticIQ data source can retrieve selected entities together with related entities and observables:

data eclecticiq_entities "campaign_intelligence" {
  query = <<-EOT
      data.title:"EMBER BEAR"
  EOT

  with_related_entities_of_type = [
    "malware",
    "threat-actor",
    "indicator",
  ]
  with_observables = true
  limit            = 500
}

EclecticIQ returns its own entities, relationships, and observables. The data is STIX-adjacent, but it is not a ready-to-use STIX 2.1 bundle. It must be mapped and normalized for the organization’s data model before being passed to these templates. That organization-specific mutation is intentionally not included in the examples.

The same caveat applies to any integration: a live connection removes copying, but it does not remove the need to define scope, semantics, and quality rules.

A predictable document layer for AI agents #

An agent can participate in this workflow without being asked to manufacture a complete report file.

BlackStork input values carry runtime data and decisions into a template. An agent can supply a schema-compliant STIX bundle, the primary object ID, report context, and whether optional summarization is enabled. The bundle can be validated before rendering, and the same payload can be stored, reviewed, or replaced later.

llm_text content provider has a different purpose. It is a content provider inside the template. It receives already selected and normalized evidence and performs a bounded writing task. It is not the mechanism used to ingest intelligence, and it does not control the document structure.

Keeping these concerns separate has practical benefits:

• Agent-produced STIX can later be replaced with data from a TIP without redesigning the report.
• The same template can be used from an agent, the BlackStork CLI, or BlackStork SaaS.
• A smaller model may be sufficient for summarization after graph selection and normalization are complete.
• LLM generation can be disabled while preserving a complete, useful report.
• Reviewers can inspect the structured input separately from the generated prose.
• Layout and mandatory content remain predictable across runs.

This is a narrower job for an agent, and that is a strength. The agent focuses on collection, transformation, and analysis. BlackStork owns the repeatable document structure and presentation.

Four products, one reporting foundation #

The four templates do not duplicate every implementation detail. They share a library of report identity, summaries, assessments, probability language, intelligence gaps, ATT&CK activity, timelines, indicators, vulnerabilities, sources, requirements, and feedback blocks. Each document selects and orders the blocks appropriate for its audience and purpose.

This makes maintenance less risky. A correction to a shared indicator table or probability matrix can flow to every product that uses it, while the campaign and executive reports remain distinct documents.

The formats are reusable too. We built two visual themes, each with HTML and PDF variants. A team can change its producer name, unit, handling label, tagline, and logo through report metadata rather than editing presentation logic throughout the files.

What this automation does and does not replace #

It replaces repetitive production work:

• copying fields from structured data into tables;
• manually maintaining the same section structure;
• reformatting the same report for web and PDF delivery;
• pulling unrelated objects into a report because they share a bundle; and
• asking an LLM to reproduce layout and required sections on every run.

It does not replace intelligence work:

• defining intelligence requirements;
• assessing source reliability and evidence quality;
• deciding whether relationships and attribution are justified;
• calibrating confidence and probability;
• identifying the relevance to the organization; or
• reviewing the finished product before distribution.

Templates make analyst judgment easier to apply consistently. They do not make that judgment for the analyst.

Downloads #

The complete implementation is available in the BlackStork community template repository.

Rendered Examples #

• Campaign report, HTML, Midnight theme
• Executive report, HTML, Midnight theme
• Executive report, Markdown
• Intrusion analysis report, PDF, Signal theme
• Threat actor profile report, PDF, Midnight theme

Document templates #

• Campaign report
• Executive report
• Intrusion analysis report
• Threat actor profile report
• Shared CTI report blocks

Presentation formats #

• Midnight HTML and Midnight PDF
• Signal HTML and Signal PDF

Next steps #

Download one template and render its included example data with the BlackStork CLI. Then replace the example bundle with an input or data source, adapt the normalization to your intelligence model, and update the report metadata for your organization.

If your CTI team wants to build a live reporting workflow around its existing TIP and review process, apply to the BlackStork Design Partner Program. We are working directly with teams that need predictable, high-quality document generation for analysts and AI agents.