Skip to main content

​
Why a Dedicated TARA Solution?

UNECE R155 requires vehicle manufacturers to demonstrate a certified Cyber Security Management System (CSMS) for type approval. At the core of CSMS evidence is the TARA — a systematic process for identifying cybersecurity threats, scoring their feasibility, assessing risk, and defining treatment. ISO/SAE 21434 standardizes this process. The TARA solution bridges the gap between the standard’s requirements and practical engineering workflow by embedding the full TARA process directly into a Risksheet-based interface. Engineers work in a familiar spreadsheet-like environment while the system enforces ISO-compliant scoring, traceability, and reporting.

​
Architecture: The MINI Solution Pattern

The TARA solution follows what Nextedy classifies as a MINI solution — a focused, single-domain tool centered around one Risksheet template and a lean set of purpose-built work item types. diagram

​
What Makes It “MINI”

CharacteristicTARA (MINI)Full Automotive Safety (MAXI)
Risksheet templates1 (TARATemplate)5+ (HAZID, SFMEA, DFMEA, etc.)
Work item types815+
PowerSheet configsNone11+ YAML files
RTM model entities5 (minimal)15+ with relationships
Domain focusCybersecurity onlyFunctional safety + multiple disciplines
The MINI classification does not mean limited capability. It means the solution is self-contained and portable: one Risksheet template, one set of work item types, one scoring system. Every TARA module in the project is a copy of the same template linked to a different system element.

​
Single-Template Design

The entire TARA analysis revolves around the TARATemplate risksheet.json configuration. When you create a new TARA module, Risksheet copies this template and associates it with a system element through the systemElementId document custom field. This design yields several benefits:
  • Consistency: All TARA modules use identical columns, formulas, and scoring logic.
  • Portability: The template can be exported and imported into other Polarion projects.
  • Maintainability: Updates to the template propagate to all modules.

​
Formulas as Business Logic

Three JavaScript formulas embedded in the risksheet.json encode the core TARA business logic:
  1. feasibilityFormula — Aggregates 5 attack potential factor scores into High/Medium/Low/Very Low using ISO 21434 Annex G thresholds.
  2. verdictFormula — Combines Impact and Feasibility via a 4x4 risk matrix to produce verdicts 1—5.
  3. description — Auto-generates a human-readable summary from the stakeholder, damage scenario, threat scenario, and threat path fields.
Because the business logic lives inside the Risksheet configuration rather than in external code, the solution is fully self-contained. No server-side plugins or custom Java code are required beyond the standard Risksheet runtime.

​
Read-Only Field Enforcement

TARA record fields (attackTime, attackExpertise, attackKnowledge, attackWoo, attackEquipment, taraImpact, damageScenario, threatPath, taraFeasibility, taraVerdict, description) are marked read-only in the standard Polarion work item form. This enforces a design principle: the Risksheet is the sole editor for TARA records. Users cannot bypass the structured workflow by editing fields directly in the tracker.

​
Color-Coded Visual Language

The solution uses 30+ CSS styles to create a heat-map visual across the Risksheet. Column groups use distinct background colors (purple for threats, blue for feasibility, red for assessment, green for treatment). Cell decorators apply graduated colors to verdicts (green V1 through red V5), impact levels, and feasibility levels. Treatment gaps are highlighted with orange outlines. This visual language enables engineers to scan a Risksheet of 15+ records and immediately identify which rows need attention.

​
Comparison with Other Approaches

Unlike general-purpose risk registers or spreadsheet-based TARAs, this solution provides:
  • Traceability: Every TARA record is a Polarion work item with typed links to goals, controls, requirements, and test cases.
  • Automation: Formulas compute feasibility and verdicts; decorators validate CAL requirements; dashboards aggregate statistics.
  • Audit readiness: The document workflow (Draft, In Review, Approved, Published) with electronic signatures satisfies ISO 21434 review requirements.
  • Scalability: Shared catalogs prevent duplication. The system element hierarchy organizes TARAs at every architecture level.