INSIDE AEGISSAFEFORGE: FROM ITEM DEFINITION TO AN APPROVED TARA ARTIFACT

The first TARA in a new program is often where cybersecurity engineering slows down.

The item definition may exist, but system boundaries are still evolving. Architecture information is distributed across diagrams, requirements, interface descriptions, and supplier documents. Assets must be identified, threat scenarios developed, vulnerabilities examined, attack paths constructed, and risks evaluated before the team can make defensible treatment decisions.

The difficulty is not producing a spreadsheet full of threats.

AegisSafeForge is built for this bottleneck. The platform does not treat TARA as a document generation exercise. It treats it as a governed engineering workflow: product context enters the analysis, AI proposes structured artifacts, lifecycle rules control how those artifacts progress, engineers review the assumptions and values, and approved decisions remain connected to the work that follows.

The input is the product, not a prompt

A useful TARA begins with a sufficiently clear understanding of the item or component being analysed.

That includes its boundaries, functions, architecture, interfaces, communication paths, external dependencies, operating environment, assumptions, and relevant stakeholders. Without this context, even a technically plausible threat scenario may have little connection to the actual product.

In AegisSafeForge, TARA generation can use the item definition, applicable reference values, and existing analysis rows from the project workspace. The generation request also carries a structured prompt contract defining:

This means the model is not being asked to invent an unrestricted TARA from a loose prompt. It is being asked to propose a specific type of engineering artifact within the structure and context already defined by the platform.

That distinction matters.

A generic prompt may produce a plausible list of automotive threats. A governed workspace can produce reviewable proposals tied to the product being developed, the active analysis, and the schema the team is actually using.

TARA is a chain of connected reasoning

A TARA is not simply a list of possible attacks.

Under [ISO/SAE 21434](https://www.iso.org/standard/70918.html), cybersecurity risk management examines how cybersecurity threats could affect a road vehicle item or component and its stakeholders. This normally requires connected reasoning across assets, damage scenarios, threat scenarios, attack paths, impact, attack feasibility, risk determination, and treatment.

AegisSafeForge structures the wider cybersecurity workflow around related artifact types, including:

The workspace also extends into vulnerability management, cybersecurity events, and incident response planning.

These artifacts are related, but they are not interchangeable. An asset identifies something of value. A threat scenario describes a potential compromise. A vulnerability provides a weakness that may be exploited. An attack path describes how the threat could be realised. The resulting risk then informs treatment, goals, requirements, controls, and verification.

What the AI is allowed to do

The assistant is most useful where cybersecurity engineers lose time to discovery, repetition, and blank page work.

Propose candidate artifacts. The system can use the item definition, existing TARA content, and available reference values to generate structured candidates for specific parts of the analysis.

Draft threat scenarios and attack paths. AI can provide first pass descriptions and rationale that engineers can inspect, challenge, and refine.

Help identify coverage gaps. Existing artifacts can be supplied as generation context, allowing the assistant to consider what the team has already analysed rather than repeatedly starting from zero.

Normalize engineering language. Schema constrained outputs help teams maintain more consistent fields, terminology, and relationships across contributors.

Prepare content for review. Instead of presenting generated text as an answer, the platform places it into the same lifecycle used for manually created engineering artifacts.

These outputs are proposals. Their purpose is to accelerate analysis and give engineers something concrete to review, not to become approved cybersecurity conclusions automatically.

What the AI is not allowed to decide

A convincing threat scenario is not necessarily a credible one. An attack path that sounds technically possible is not automatically feasible in the actual architecture.

AI should therefore not silently decide:

AegisSafeForge can store structured risk values and provide ISO/SAE 21434 reference values to the analysis and generation workflow. However, the current TARA implementation does not depend on a dedicated built in risk matrix engine that automatically makes the final risk decision.

That responsibility remains with the cybersecurity engineer.

This boundary is important because a risk decision can change architecture, requirements, development effort, verification scope, and post production responsibilities. It cannot be delegated to a language model simply because the generated rationale appears reasonable.

Review state is part of the artifact

A TARA artifact in AegisSafeForge is more than the content visible in a table.

Each artifact carries a lifecycle and governance envelope containing its status, provenance, traceability, validation state, version information, creator, editor, approver, approval time, and status history.

An artifact may move through states such as:

These are not decorative labels. The backend enforces which transitions are allowed and validates the required artifact fields before approval.

This makes the human decision visible. Reviewers can distinguish an AI proposal from user authored content, identify what has been edited, see whether changes were requested, and determine who ultimately approved the artifact.

Approval depends on the engineering chain

A common weakness in spreadsheet based TARAs is that individual rows can appear complete even when the supporting analysis is missing or unapproved.

AegisSafeForge introduces dependency aware approval rules to prevent that.

For example, an attack path cannot be approved unless it references an approved vulnerability associated with the same threat scenario. A risk cannot be approved unless it references an approved attack path with matching threat scenario and vulnerability relationships.

This means the workflow does not only ask whether the current row has been filled in. It checks whether the engineering artifacts supporting that row have reached an acceptable state.

The result is a more defensible chain:

The platform still relies on engineering judgment to determine whether the content is correct. What it adds is structural enforcement that prevents downstream artifacts from being approved while their required upstream basis remains unresolved.

Traceability begins at the item definition

The current implementation explicitly links the item definition to derived TARA assets.

This relationship is represented as a “derived from” link. It can require reapproval when the upstream item definition changes, and it can prevent further derived generation when the necessary source artifact is not approved.

This is important because a TARA can become outdated without anyone directly editing it.

A new external interface, a changed communication protocol, a modified system boundary, or a different supplier component may alter the assets and assumptions on which the analysis was based. If those upstream changes are disconnected from the TARA, the analysis may continue to look complete while no longer representing the product.

By carrying traceability and lifecycle rules with the artifacts, AegisSafeForge begins turning change impact into part of the normal workflow rather than an after the fact documentation exercise.

Approval is not the end of the TARA

A TARA only becomes useful when its decisions influence development.

Approved risks and treatment decisions should lead into cybersecurity goals, requirements, controls, claims, and verification activities. The platform’s TARA workspace already represents these as connected stages of the wider cybersecurity engineering lifecycle.

This lifecycle continues after release. Vulnerability management, cybersecurity event handling, and incident response planning remain connected concerns because new vulnerabilities and field information can challenge assumptions made during development.

UN Regulation No. 155 similarly places emphasis on identifying, managing, and verifying the treatment of cybersecurity risks across the vehicle lifecycle.

The result we are building toward

Our goal is not to create a chatbot that “does TARA.”

Our goal is to make TARA easier to develop, review, maintain, and defend.

AegisSafeForge helps teams move from product context to structured candidate artifacts while keeping AI output inside a governed lifecycle. Schema validation keeps generated content within the expected structure. Status transitions make review visible. Dependency checks protect the approval chain. Traceability preserves the relationship between the item definition and the cybersecurity analysis derived from it.

The platform should accelerate the work that benefits from assistance and slow the workflow down exactly where expert judgment matters: scope, applicability, feasibility, treatment, residual risk, and approval.

Used this way, AI assisted TARA is not a shortcut around ISO/SAE 21434 discipline. It is a governed workflow for applying that discipline more consistently, with less blank page effort and a clearer record of how every cybersecurity decision was reached.

The next article in this series will step back from the platform and examine a broader engineering question: why HARA and TARA cannot remain isolated when cybersecurity threats can create safety consequences and safety decisions can introduce new cybersecurity concerns.