The TARA Arrives, Its References Don't

A supplier finishes its Threat Analysis and Risk Assessment (TARA), and the OEM wants to see it. Often it arrives as an Excel file, sometimes as a PDF. Everything in it is readable: assets, damage scenarios, attack paths, risks.

What’s missing are the connections. Which attack path leads to which risk? Which impact level belongs to which function? In the supplier’s model that was a reference. In the spreadsheet it’s text in a column. At the OEM, someone then rebuilds the model. Or they just read it and tick it off.

Sergio Scabar asked how common this is in a 2025 student paper at Wrexham University, surveying people from OEMs, suppliers and consultancies. 70 percent of the 30 respondents had already run into integrity or compatibility problems when sharing TARA data. Just over half transfer the data by hand. The sample is small, and anyone who answers a survey like this has probably felt the problem already. As a direction, it’s enough for me.

This article is about openXSAM, an open exchange format for exactly this data. itemis started the format and still advises on its standardisation in the Automotive Security Research Group (ASRG), so I’m not neutral.

Three terms first

• TARA: the threat analysis and risk assessment under ISO/SAE 21434:2021. It links assets, damage scenarios, threat scenarios, attack paths and risks. How that works step by step is the subject of my series, which starts with What Is a TARA?.
• Cybersecurity interface agreement: the agreement between customer and supplier on who performs which cybersecurity activity and which work products they deliver.
• XSAM and openXSAM: XSAM is the exchange format of itemis SECURE. openXSAM grew out of it in 2020 as an open, vendor-neutral format and is now maintained by the ASRG, an open community for vehicle security.

The standard governs the process, not the file

ISO/SAE 21434 expects a TARA not to be built under one roof. Clause 7 covers cybersecurity activities distributed between customer and supplier, and the interface agreement says who delivers what. The standard doesn’t prescribe a file format. I think that’s right. It governs an engineering process, not an interface.

The interface agreement could name a format. But there has to be one that both sides can read without one of them buying the other’s tool. Until there is, people settle on Excel.

The supply chain isn’t the only boundary, either. The architecture comes from a modelling tool. Test teams derive their test plans from the risks. In operation, the security operations centre wants to know which risks sit on which interface. The openXSAM specification names exactly these cases: sharing risk information, deriving test plans, and feeding attack surface management and detection & response.

The Annex H headlamp as a file

openXSAM is XML. The specification splits the content into modules: item definition, assessment model, analysis, risks and controls.

Here’s what that looks like for the headlamp in Annex H of the standard.

The item definition holds the functions, such as switching the light on and off according to the switch and dipping it automatically for oncoming traffic. Then the components: headlamp switch, body control ECU, camera ECU and the actuator that switches the headlamp. And the data flows, among them the lamp request to that actuator. Each component references the data it stores and the functions it carries.

The assessment model travels along: the impact levels, the feasibility model and the risk matrix that turns the two into a risk value. That sounds like an add-on. I think it’s the most important part of the file. Part two of my TARA series was about how an impact rating like “major” only means something inside an assessment model. Without the model, the OEM doesn’t know which scale the supplier measured on. With it, they can look it up.

The analysis holds the damage scenario: a front collision with a tree because the light goes off while driving at night. Then the threat scenario, a spoofed lamp request. And the attack steps. The attacker compromises the navigation ECU through the cellular interface, and the gateway forwards the spoofed signals to the actuator. Each step references what it prepares. Which threats endanger a security objective is written in the file as a logical expression with “and” and “or”. So the attack tree arrives as a structure, not as a picture of one.

itemis published this example as an XSAM file in 2021, back then still taken from the draft standard. The file was a proposal for how functions, components, data flows and data could look in the open format. It holds only the item definition and is leaner than today’s Annex H: the camera ECU and automatic dipping are missing. It’s attached to this article: ISO21434_G_ItemDefinition.xsam (XML, 10 KB).

What an exchange format needs day to day

In my view, an exchange format rarely fails on its data model. It fails on the second import. Three decisions in the format aim right at that.

References by name. Elements reference each other by name, not only by ID. The reference to a feasibility factor then reads name/FeasibilityCategory/TIME instead of a cryptic ID. References like that stay valid when the assessment model around them changes.

External IDs. Every element can carry the ID from the system it came from. If you bring your architecture over from a modelling tool, you keep its IDs. The second import then updates the existing elements instead of duplicating them.

Extensions. Vendor-specific content goes into its own XML namespace. The core stays readable for everyone, and a tool that doesn’t know the extension skips it.

Partial updates, for now only an idea. The proposal itemis used to promote the initiative in 2020 had a file carry only changes, with everything else staying as it was. Its example: a threat intelligence database sets the time factor for a man-in-the-middle attack to “hours” and sends only that one change. It didn’t make it into specification 1.0. I hope the idea comes back. It would turn a format for handovers into one for ongoing changes.

From XSAM to the ASRG

The history is short. XSAM came out of the SecForCARs research project and became the exchange format of itemis SECURE, then still called YAKINDU Security Analyst. In 2020 itemis turned it into an open initiative, with its own website and partners from test houses, research and industry. In 2022 openXSAM became a Technical Committee of the ASRG. Version 1.0 of the specification came out at the end of 2023, with the XML schemas shortly after. Both are public in the ASRG GitHub repository.

Why would a tool vendor give its format away? An exchange format owned by one vendor ends up being an export function. No competitor builds an import for someone else’s format. With a neutral body there’s at least a chance.

Others are picking the format up by now. In 2025, researchers at UESTC in Chengdu and the company GoGoByte extended it as “OpenXSAM++”. They use it to describe vehicle configurations in enough detail for an LLM-based system to generate attack trees from them. Whether those extensions flow back into the standard, I don’t know. I’m still glad someone took the format as a basis instead of inventing their own.

No model, no references

An exchange format is only as good as what you can put into it. From a spreadsheet you can export rows. You can only export references if they existed in the first place. An attack step that points to “TS-12” as text in an Excel cell becomes, in XML, text that points to “TS-12”.

So the value of openXSAM depends on the TARA having been a model beforehand. In itemis SECURE it is: assets hang off elements of the item definition, attack steps off threat scenarios, and the tool calculates impact level and attack feasibility. Via XSAM, it imports and exports the complete analysis and assessment model, references included.

A TARA that freezes at release is of little use in the field. New vulnerabilities and attack techniques change ratings all the time. Inside one tool, the model recalculates the consequences. Across company lines that only works if the change arrives in a form the other tool understands. An open format is the precondition for that.

Conclusion

openXSAM solves a clearly defined problem. It moves TARA content, with its references and its assessment model, from one tool to the next. It’s open, it sits with a neutral body, and it can be checked against published schemas.

And the format keeps moving. An extension based on CycloneDX, the open standard for software bills of materials (SBOM), is being looked into right now. It would bring the TARA together with the bill of materials of the software it refers to.

My advice would be to write the format into the interface agreement before the first TARA is handed over. And to try one exchange with the tools involved beforehand. A file that has made one round trip tells you more than any datasheet.

If you want to see what a TARA from itemis SECURE looks like as a file, you can reach me on LinkedIn or through itemis.com.

I’d like to know how this works for you: how do TARAs get from supplier to OEM? As Excel, as PDF, through a shared tool, or already as a file you can import?

Cyber Security at itemis — Systematic security engineering for automotive, IoT and Industry 4.0: Cyber Security →