tara.json impact.* uses high|medium|low instead of the v1.14.1 closed enum, and risk is an ad hoc score instead of the spec's combination table

[SoundMatt]

Spec reference

x-FuSa spec §9.2 (v1.14.1 addition), Closed enums (MUST):

impact.{safety,financial,operational,privacy}: critical | major | moderate | negligible... A tool MUST NOT substitute a different vocabulary (e.g. high|medium|low) for these four fields, even though that vocabulary is used for attackFeasibility.

risk: critical | high | medium | low

and the Risk combination table (SHOULD), a specific lookup of highest-SFOP-impact × attackFeasibility → risk.

What actually happens

This repo's own committed tara.json (dogfooded by PR #72) uses high/medium/low for every SFOP impact axis — never critical/major/moderate/negligible:

{
  "id": "TARA-001",
  "impact": {"safety": "high", "financial": "low", "operational": "medium", "privacy": "low"},
  "risk": "high",
  "attackFeasibility": "medium"
}

Traced to cmd/cfusa/cmd_tara.c's four hardcoded category profiles (e.g. PROFILE_MEMORY = { "memory", "local", "medium", "high", "low", "medium", "low", ... } — the SFOP fields are literally the strings "high"/"low"/"medium"), and to impact_rank()/feasibility_rank()/derive_risk():

static int impact_rank(const char *v)
{
    if (!strcmp(v, "high")) return 3;
    if (!strcmp(v, "medium")) return 2;
    return 1; /* low */
}
static const char *derive_risk(const category_profile_t *p)
{
    int score = feasibility_rank(p->feasibility) * impact_rank(max_sfop(p));
    if (score <= 2) return "low";
    if (score <= 6) return "medium";
    if (score <= 9) return "high";
    return "critical";
}

derive_risk is an independently-invented feasibility_rank × impact_rank numeric score with its own thresholds — it doesn't implement the spec's stated combination table at all (e.g. per the spec table, critical impact + medium feasibility → critical risk; this code's equivalent path can only ever produce low/medium/high/critical via arbitrary score cutoffs that don't correspond to the table's cells).

Why this matters

This is precisely the ambiguity §9.2's v1.14.1 "Closed enums" clarification was written to close — cross-tool tara.json documents from different x-FuSa tools are only comparable if they share one vocabulary and one derivation method. As written, this tool's impact values are not valid per the closed enum at all (an emitted "high" for impact.safety is not one of critical|major|moderate|negligible), and a consumer following the spec's risk combination table to sanity-check risk against impact/attackFeasibility will not be able to, since neither the vocabulary nor the derivation matches.

Suggested fix

Rename the four category_profile_t SFOP fields to values from the closed enum (critical|major|moderate|negligible), and replace derive_risk() with a literal lookup against the spec's table (highest-ranked SFOP axis × attackFeasibility → risk), keeping attackFeasibility on its own high|medium|low|very-low scale as-is (that one's correct).

[SoundMatt]

Fixed in #81 (v0.5.47) — see the PR description for the full per-issue breakdown.

[SoundMatt]

Auto-closed by merging #81 (v0.5.47). tara.json's four category profiles now emit the v1.14.1 closed enum (critical|major|moderate|negligible) for impact.* instead of high|medium|low, and risk is now a literal lookup against the x-FuSa spec §9.2 combination table (highest-ranked SFOP impact × attackFeasibility) instead of an ad hoc feasibility_rank × impact_rank score. Regression test: test_tara_standard_id_and_closed_impact_enum.