map: resolve a client imported from a local module to its dependency

[patchstackdave]

A regression I introduced, found while reviewing the integration plan against the code rather than by a test.

The attributable-receiver rule treats a relative receiver as app code. Correct for a lookalike helper — wrong for the layout generated apps actually use:

// src/lib/db.ts
export const db = createClient(url, key);          // @supabase/supabase-js

// src/server.ts
import { db } from './lib/db';
app.post('/orders', (req, res) => db.from('orders').insert({ title: req.body.title }));

db resolved to the specifier ./lib/db and nothing followed it, so the endpoint reported zero sinks.

Before the attribution work it at least surfaced as an unattributed sink — inventory only, never a candidate. After, it was invisible, which is worse: correlating a CVE to an endpoint joins on the sink's package, so no vulnerability in pg or @supabase/supabase-js could be pinned to a route in the most common case. It's the difference between the map working on real projects and working on single-file examples.

The fix

The module graph already resolves relative specifiers and parses the target module — that's how imported helper functions are followed. This asks a different question about the same data: not "what sinks are in there" but "what does this export trace to".

importedPackage(fromFile, specifier, exportName) {
  const mod = load(resolveInProject(fromFile, specifier));
  return npmPackageOf(mod.bindings.resolve(exportName));   // the module's own view of its export
}

baseOf asks it when the receiver is relative. A package means the receiver is that dependency, via an import-to-import chain that is fully static — so it earns attribution: 'import', not the weaker inferred.

The narrowness is the point

The hop only produces a sink when the export actually terminates in a dependency, which is exactly what keeps #129's guard intact:

shape	result
db.from('orders').insert({title})	db sink, @supabase/supabase-js, attribution: import
pool.query(req.body.sql) (pg, from lib/pool.ts)	exact-local → sql-injection candidate (previously invisible)
import { db as renamed }	followed via its exported name
helper.exec(req.body.cmd) where ./util exports plain functions	still no sink — including one named from
export { db } from './client'	still no sink — one hop only, asserted as a limitation

The project boundary applies to the new resolver too: a symlink leading out of the project is refused, and that's asserted rather than assumed.

Verification

Corpus gains the lib/-client layout as a stack case, not an adversarial one — this is what normal generated code looks like, so it belongs with the recall cases. Corpus now 7 stack + 6 adversarial · 14 candidates.

Every new assertion was checked against a build with the hop disabled: 5 fail without it, so none is decorative. 918 tests, typecheck clean.

[coderbuds]

Resolves client imports through local modules into real package sinks

🎯 Quality: 100% Elite · 📦 Size: Medium

📈 This month: Your 62nd PR — above team average · Averaging Excellent

_{See how your team is trending →}

[patchstackdave]

Confirmed and fixed in this PR. One correction to the framing, from checking it against main rather than assuming: the class is older than this branch and is live in main today.

main   const local = new ApolloClient(); local.query(req.body.sql)   →  GEN=true sql-injection   ← shipped
main   import { client } from './lib/gql'; client.query(...)         →  no sink
#132   both shapes                                                  →  GEN=true sql-injection

The same-file client already resolved to @apollo/client directly, so it already produced a precise SQL-injection candidate for a GraphQL call. The imported-client hop widened the reach; it didn't open the hole. Which means fixing it here is right, and it also closes something already shipped.

The fix, at the root

Package provenance was standing in for API provenance. A DB recognizer now requires the resolved package to actually establish a database API — isDbPackage, covering the inference list plus real drivers missing from it (postgres, mssql, mongodb, @planetscale/database, @neondatabase/serverless, …) and subpath imports like drizzle-orm/node-postgres.

Per your suggestion the sink stays in the inventory — a .query() on an unknown client is worth a human's attention — marked apiUnconfirmed:

/gql-imported   db/@apollo/client/import  apiUnconfirmed=true  provider=undefined
                GEN=false | sink package "@apollo/client" is not a known db provider:
                            it does not establish a db API (method name alone is not evidence)
/pg             db/pg/import              provider=sql   → GEN=true sql-injection
/orm            db/drizzle-orm/import     provider=sql   → GEN=true sql-injection

Two things I added beyond the suggestion, both for the same reason — a refused sink shouldn't keep making claims it can't support:

• it does not get provider: 'sql', since calling a GraphQL call a SQL sink is wrong in the inventory too;
• it does not get a candidateFamily, because a consumer reading candidateFamily without also checking ruleGeneratable would mis-classify it.

The reason string distinguishes this from the existing untraceable-receiver and inferred-package refusals — three different things for a reviewer to check, three different sentences.

Coverage: both Apollo shapes, controls for pg and the drizzle subpath, and a new adversarial corpus case (a non-DB client with a .query() method is exactly a lookalike, so it belongs there — now 7 stack + 7 adversarial). Verified 5 assertions fail with the gate disabled. 927 tests, typecheck clean.

[patchstackdave]

Taken now rather than deferred — it's the same mistake one field over, and #132 is already the PR about not overstating what we know.

Reproduced first:

/traced    pool.query(...)            provider=sql  pkg=pg  attr=import      ← fine
/inferred  res.locals.db.query(...)   provider=sql  pkg=pg  attr=inferred    ← overstated

provider is now set only when the receiver resolved (attribution: 'import'/'global'), for the SQL and prisma paths alike. package still carries the hint that made us look, and attribution already states how strong it is.

On providerConfidence: I went the other way, deliberately. That value would be derived from attribution + provider, and a second confidence field is precisely what drifts — this codebase has already had confidence: 'precise' survive in prose for a full round after it stopped existing in code. Deriving the claim at the point of construction keeps one source of truth; a consumer that later wants "possible DB API" as a display state can compute it from the two fields it already has. Happy to add the field if you think a server would rather be handed the conclusion than derive it, but I'd rather not ship two things that can disagree.

Worth keeping the two states distinct, since they ask a reviewer for different work:

state	meaning
apiUnconfirmed: true	the package is wrong for the API (@apollo/client for a .query())
provider absent, attribution: 'inferred'	the package is right, the receiver is unknown

One existing test looked its sink up by provider === 'prisma' — the exact claim being removed — so it now finds the sink by package and asserts the absent provider. Verified the new assertion fails with the gate reverted. 928 tests, typecheck clean.

[patchstackdave]

/review