map: require an attributable receiver before a sink can auto-generate a rule

[patchstackdave]

Three follow-ups from an external review of the map. I reproduced all three before changing anything, and each has a committed regression test.

1. Member-call sinks had no justification requirement — the one that matters

The bare-call path already required that a dangerous name resolve to a module plausibly providing that API. The member-call path only asked "is the receiver a local binding?" — and a namespace import of a relative module is neither local nor a package:

import * as helper from './util';
helper.exec(req.body.cmd);       // → exec sink → command-injection candidate
helper.query(req.body.sql);      // → db sink   → sql-injection candidate
helper.readFileSync(req.body.p); // → fs sink   → path-traversal candidate

Three precise, auto-generatable candidates for ordinary app code. Same defect as the bare-call one fixed earlier — one syntax over, which is the real lesson: two paths recognizing the same thing under different rules.

baseOf now carries the resolved specifier, so a relative receiver is a positive fact (app code) rather than a missing package, and fs/exec member calls must resolve to a filesystem/process package just as bare calls must.

Recall is preserved rather than traded away. sinksFrom now follows a relative namespace receiver into its module, so a helper that really does reach a sink still reports it, attributed to the file it lives in:

shape	before	after
helper.exec(...) → harmless local fn	exec sink + candidate	no sink
store.save(...) → really calls fs.writeFileSync	(also mis-attributed locally)	fs sink, file: src/store.ts, not generatable
res.locals.db.query(...)	precise candidate	inventory only, refused with a reason
fs.readFileSync(...) / exec(...) from real imports	candidate	candidate (unchanged)

Untraceable receivers keep the inventory/candidate split the map is built on: reported for a human, never auto-ruled. Any object can own a method called query; a coordinate pinned on that guess is a rule that blocks real traffic for no reason. The new Sink.attribution field (import / global / inferred / absent) makes that distinction explicit in the schema instead of leaving consumers to infer it from a missing package.

2. Sink ids were not unique map-wide

The schema promises map-wide identity, but the hash covered the span and not the owning file — so duplicated route boilerplate in two files put the same call at the same offsets and the two sinks shared an id. The endpoint's repo-relative file is now part of the identity (relative, never absolute, so ids stay stable across machines). Covered by a two-file collision test.

3. Namespace capture only worked in the parameter list

const { query: q } = req — the same capture one statement later — left the fields read off q invisible. Nothing was mis-addressed (no coordinate was emitted), but an unreported surface reads as "nothing here", which is the more misleading failure. Those inputs are now reported.

Their flows stay heuristic, so they are visible without being auto-ruled — deliberate: making alias flows precise widens candidate generation and belongs in its own change with corpus coverage.

Verification

860 tests (81 files), typecheck clean. The golden corpus and every pre-existing candidate assertion pass unchanged — that's the point: this removes false candidates without removing true ones.

[coderbuds]

Well-scoped attribution feature with clear, consistent sink-handling enhancements.

🎯 Quality: 100% Elite · 📦 Size: Large — consider splitting if possible

📈 This month: Your 60th PR — above team average · Averaging Excellent

_{See how your team is trending →}

[patchstackdave]

Confirmed and fixed — this was a real contradiction in the change itself, not an edge case: I added the inferred tier and then only refused generation for a missing attribution, so the guarantee stated in this PR's description didn't hold for the case the description was about.

Reproduced first:

-- /x  res.locals.db.query(req.body.sql)   [file imports pg]
   sink db sql pkg=pg attr=inferred
   flow sql precise GEN=true sql-injection      <-- the hole

Generation now requires attribution: 'import' (the receiver resolves to that dependency) or 'global'. Inferred sinks keep the package as a reviewer hint and stay in the inventory, but cannot compile a rule. After:

-- /x   GEN=false | sink package "pg" was inferred from the file's other imports, not from the
                    receiver (db.query): the receiver may be any app object
-- /ok2 pool.query(...) with a resolved `new Pool()`   GEN=true sql-injection   (unchanged)

The refusal distinguishes inferred from untraceable, because those ask a reviewer to check different things.

Fixtures added for all three paths as suggested — raw .query(), .from().insert(), and prisma-shaped — plus resolved controls. Worth noting on the .from().insert() one: it was already refused, but only because its argument role is values, i.e. accidentally safe rather than safe by design. The fixture asserts the attribution reason specifically so it can't pass for the wrong reason and regress silently.

Two things the fixtures surfaced:

• Inference picks the first known db package in table order, so a file importing supabase, pg and prisma labels a .query() call @supabase/supabase-js. Fine as a hint, unusable as an address — my first draft of the test asserted pg and failed for exactly this reason.
• The full suite passes unchanged, which is the useful signal: refusing inferred receivers removed no true candidate.

864 tests (81 files), typecheck clean.

[patchstackdave]

/review