fmea.json/tara.json content generators pick up stdlib calls and string-literal text as project functions/assets (§1.6 rule 4)

[SoundMatt]

Spec reference

x-FuSa spec §1.6, rule 4, Real referents only (MUST):

Any entry naming a file/function/component/item MUST refer to an actual file or symbol in the analyzed project — not a language keyword, a standard-library call, or a test fixture mistaken for project code.

What actually happens

cmd/cfusa/cmd_fmea.c's fmea_line() and cmd/cfusa/cmd_tara.c's asset_line() scan source text for any identifier( pattern (after skipping a short list of control-flow keywords) and treat the token before ( as a project function — with no distinction between a function definition, a call expression, or text inside a string literal/comment.

Standard-library calls treated as FMEA components

This repo's own committed fmea.json (370 entries) contains, among others:

31 entries: item "fprintf"
22 entries: item "snprintf"
14 entries: item "printf"

e.g.:

{"id": "FM-004", "item": "snprintf", "file": "cmd_coupling.c", "line": 56, "failureMode": "snprintf (general function) does not perform its intended action", ...}

Line 56 of cmd/cfusa/cmd_coupling.c is snprintf(msg, sizeof(msg), ...) — a call to the C standard library, not a function this project defines. ~67/370 entries (18%) are standard-library call sites analyzed as if they were project components, which also inflates summary.componentsInProject/coveragePct to a false 100% (componentsAnalyzed == componentsInProject == 370, both counts include the same false positives).

A test-fixture string literal parsed as a function call

This repo's own committed tara.json contains:

{"id": "TARA-001", "asset": "Data handled by \"strcpy (cmd_qualify.c)", "threat": "An attacker supplies malformed/untrusted input to \"strcpy, ..."}

Note the stray literal " glued onto strcpy. Line 427 of cmd/cfusa/cmd_qualify.c is:

{"CY001-pos: strcpy fires",             "CFUSA-CY001", "strcpy() triggers CY001",                1, cy001_pos, 0},

— a self-test description string inside a qualification test-case table, not a call to strcpy at all. The naive scanner found the ( inside the string literal "strcpy() triggers CY001", walked back to the preceding space (which happens to sit right after the opening " of that string), and extracted "strcpy (leading quote included) as the "function name" — a textbook case of the exact failure mode named in the spec ("a test fixture mistaken for project code").

Why this matters

This is a real-referent violation, not merely low-quality prose: the FMEA/TARA claim to analyze specific named project symbols, and a meaningful fraction of the entries name things that either aren't project symbols at all (stdlib calls) or are corrupted extractions from unrelated string literals. It also evades the tool's own FUSA-STUB002 distinct-value-ratio gate, because the item/function name still varies per entry (the template is what's fixed — "<name> (general function) does not perform its intended action" — while <name> differs), so cfusa fmea --strict/cfusa tara --strict both exit 0 on this content.

Suggested fix

Before accepting a match, confirm the preceding character sequence looks like a real definition (return-type-then-name at statement start, or at minimum require the match not be preceded by an unterminated " on the same line / not be inside a string literal), and exclude known standard-library identifiers (printf, fprintf, snprintf, malloc, memcpy, …) from infer_profile()/classify() outright — a data-flow argument that malloc's caller is worth a TARA/FMEA entry is defensible, but the entry should name the calling function, not the library call itself as the item/asset.

[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). The shared cfusa_extract_call_name() scanner now requires the ( to be outside a string literal (fixing the "strcpy-from-a-test-table-description misparse) and excludes standard-library identifiers via a new cfusa_is_stdlib_call() deny-list (fixing the fprintf/snprintf/printf/... false positives — 67 of 370 entries, 18%, in this repo's own previously-committed fmea.json). Also found and fixed while dogfooding: cfusa_walk_sources() only skipped a fixed directory-name enum, so a local working tree with build-type variants like build-asan/build_fortify had every one of them scanned as project source, picking up CMake's own generated CompilerIdC probe as fake entries — now skips any build/build-*/build_* directory. Regression tests: test_fmea_skips_stdlib_calls_and_string_literal_parens, test_tara_location_relative_and_skips_stdlib_calls.