INSIDE AEGISSAFEFORGE: CONNECTING HARA AND TARA WITHOUT MERGING THEIR DECISIONS

A cybersecurity engineer adds command authentication to a braking interface. A safety engineer needs braking requests processed within a defined response time. Both decisions can be reasonable, yet their interaction can remain invisible when the teams review separate documents. The engineering problem is concrete: establish whether the control prevents a hazardous behavior, whether it introduces another failure path, and which evidence supports those conclusions.

The connected ASF workflow makes that interaction reviewable through governed relationships. This walkthrough follows a clearly hypothetical vehicle item and illustrative identifiers. It describes the completed cross-domain design: engineers work within a shared item scope, connect selected artifacts and review the resulting dependencies. HARA and TARA retain their own methods, judgments and approval responsibilities throughout.

Begin with the same item and a plausible causal path

Consider a hypothetical braking control item with a gateway that accepts requests from another vehicle controller. Its item definition records the interface, operating modes, trust boundary and assumptions about message handling. The safety and cybersecurity teams use the same item scope and identify the relevant baseline before proposing a relationship. Similar names alone cannot establish that two artifacts concern the same function or configuration.

In TARA, threat scenario TS-17 describes an attacker injecting a braking request through a compromised communication path. In HARA, hazardous event HE-08 combines unintended braking with a specific operating situation: the vehicle is travelling while another vehicle follows closely. The proposed relationship says that TS-17 can cause the malfunctioning behavior involved in HE-08, subject to the recorded interface and attacker-access assumptions. It does not assert that every injected request produces that event.

This systems perspective has a useful research foundation. NIST’s Framework for Cyber-Physical Systems describes interacting digital, physical and human components and organizes analysis around concerns including timing, trustworthiness, boundaries and lifecycle. Those concerns help frame the interface discussion here. The framework does not establish the validity of our hypothetical threat-to-hazard link or prescribe ASF’s approval workflow.

Connect goals without translating risk scores

The safety team records Safety Goal SG-04: prevent unintended braking associated with the identified malfunction. The cybersecurity team records Cybersecurity Goal CG-12: prevent unauthorized braking requests from being accepted across the defined interface. A typed goal-to-goal relationship captures how CG-12 supports SG-04 under the scenario assumptions. Each goal remains owned and reviewed within its domain.

HARA evaluates severity, exposure and controllability for its hazardous event. TARA evaluates the threat and its risk using its own assessment method. ASF preserves those independent decisions. A relationship neither converts a cybersecurity risk rating into an ASIL nor supplies a missing safety assessment. If the safety operating situation or attacker assumptions change, specialists must reconsider the affected conclusions using the appropriate method.

Make support and constraints explicit

The hypothetical functional safety requirement FSR-21 requires prevention of unintended brake actuation from invalid requests. Technical safety requirement TSR-33 specifies request validation and a defined reaction to rejected input. Cybersecurity requirement CR-09 requires authentication and freshness checks. A support relationship records why CR-09 contributes to FSR-21 and TSR-33. Its rationale identifies the particular unauthorized-input path being addressed.

A second relationship records a constraint: authentication processing must fit the response-time budget associated with TSR-33. Rejecting a message also requires careful interpretation. An invalid request and a missing legitimate request can require different system responses. The reviewers therefore examine latency, resource exhaustion and fallback behavior together. None of these illustrative requirements is a validated braking design; their purpose is to expose decisions that need coordinated engineering.

Review one canonical relationship from either workspace

ASF stores each cross-domain connection as one canonical governed relationship. Opening TS-17 from the cybersecurity workspace or HE-08 from the safety workspace reaches the same threat-to-hazard relationship. Bidirectional traceability means traversing that common record from either endpoint. It does not mean that the causal statement becomes reversible: a hazardous event does not prove the existence of a particular attack.

The relationship carries its type, shared item scope, rationale, supporting sources and endpoint versions. In this example, it references TS-17 version 3 and HE-08 version 2, together with the relevant item baseline. It also records the proposer, responsible reviewers and review history. Supporting sources might include an interface specification, an architecture decision and an analysis note. Reviewers inspect their applicability rather than treating an attachment as sufficient justification.

An engineer can create the link manually. AI can also propose a candidate with a rationale and references for inspection. The proposal remains pending until the responsible human specialists approve it. A reviewer may reject a superficially plausible match because the operating mode differs or the supposed attack path cannot reach the function. The recorded decision preserves that reasoning for later reviews.

Use the matrix to find questions that remain open

The cross-domain review matrix brings relevant threat scenarios, hazardous events, goals and requirements into a common review view. Engineers examine approved connections, pending proposals and unresolved relationships within the item. The unresolved-gap queue gives open questions an accountable follow-up path. For example, the team may need to determine whether loss of valid braking requests has been addressed before accepting the authentication control’s safety contribution.

Completeness requires judgment about the defined scope. An empty matrix cell may indicate a missing analysis, or it may represent an interaction that reviewers have considered irrelevant. A populated cell can still contain weak reasoning. Reviewers must distinguish approved applicability decisions from unresolved gaps and identify evidence that remains outstanding. Counting links cannot establish adequate treatment of the system’s safety and cybersecurity interactions.

Share evidence with separate acceptance decisions

For the hypothetical item, a verification campaign injects unauthorized requests, exercises freshness checks and measures response timing under defined load. The resulting report can support both the cybersecurity requirement and the technical safety requirement. Each domain records what the report demonstrates against its own acceptance criteria, including test configuration, coverage and limitations. A passing authentication test alone does not establish acceptable braking behavior.

Shared evidence reduces the need to reconstruct the same configuration context during separate reviews. It also exposes incompatible expectations early: a control may reject malicious input correctly while exceeding the safety timing budget. The relationship provides a place to record that tension and its resolution. Additional analysis or testing may still be required for conditions outside the campaign.

Treat change as a review trigger

Now suppose the gateway design changes its validation sequence, producing CR-09 version 4. A relationship approved against version 3 no longer demonstrates reviewed applicability to the new endpoint. ASF marks the affected relationship stale and opens a cross-domain review task. The earlier rationale, endpoint versions and approvals remain available. Approved goals, risk assessments and requirements are not silently rewritten.

The reviewers assess whether the change affects unauthorized-request rejection, timing or fallback behavior and whether existing evidence remains applicable. They can reaffirm the relationship with current versions, revise its rationale or reject it. Related gaps remain visible until resolved through review. This is change impact analysis with an explicit decision boundary: detecting a dependency initiates engineering work rather than deciding its outcome.

Completeness and export gates depend on reviewed coverage, relationship status and unresolved gaps in the selected scope and baseline. Stale or pending links require disposition before they can serve as approved coverage. Export preparation therefore makes the review state visible instead of presenting every connection as settled. The engineering advantage is a clearer route from a changed interface to accountable decisions and applicable evidence. Publication, release acceptance and any conformity conclusion remain separate human responsibilities.