@safegres/test 0.0.1 → 1.30.7

package/esm/checks/anti-patterns.d.ts

@@ -0,0 +1,53 @@
+import type { PgAstNode } from '../ast/parse';
+import type { PolicyInfo, TableSnapshot } from '../pg/introspect';
+import type { ProcVolatility } from '../pg/proc';
+import type { Finding } from '../types';
+/**
+ * Anti-pattern P1: policy predicate invokes a VOLATILE function (per-row
+ * evaluation, breaks the planner's ability to hoist or cache).
+ *
+ * Also flags SECURITY DEFINER wrappers here (P1b): they can't be inlined and
+ * become per-row function calls.
+ *
+ * Expected input: a volatility map keyed by `schema.name` (see pg/proc.ts).
+ */
+export declare function checkVolatileFunctions(table: TableSnapshot, expr: PgAstNode, volatility: Map<string, ProcVolatility>, policyName: string): Finding[];
+/**
+ * Anti-pattern P5: policy references `session_user`, `current_user`, or
+ * `pg_has_role(...)` for tenant gating. These bypass the role-and-JWT layer
+ * that the rest of the auth model is built on, and they silently evaluate
+ * against the *login* role instead of the `SET LOCAL role` role, which
+ * produces confusing RLS behavior across pooled connections.
+ */
+export declare function checkSessionUserGating(table: TableSnapshot, expr: PgAstNode, policyName: string): Finding[];
+/**
+ * Anti-patterns A7 / A8: trivially-permissive policy body.
+ *
+ * A permissive policy whose body is the literal `true` adds zero security —
+ * it's equivalent to not having RLS at all for the covered command. This is
+ * different from an intentional *restrictive* `true` (which would require
+ * all rows to satisfy it). We only flag `permissive = true` here because
+ * Postgres defaults to PERMISSIVE and `USING (true)` is the most common
+ * accidental "fail-open" shape.
+ *
+ * The verb matters enormously:
+ *   - A7 (critical): a WRITE verb (INSERT/UPDATE/DELETE/ALL) with literal
+ *     `true` lets every applicable role mutate every row — and, because
+ *     permissive policies OR together, it silently defeats any carefully
+ *     scoped policies on the same table.
+ *   - A8 (low): a SELECT-only `USING (true)` is the standard public-read
+ *     reference-table pattern; flag it for confirmation, not alarm.
+ *
+ * Input: the parsed USING and WITH CHECK ASTs (may be null if empty).
+ */
+export declare function checkTriviallyPermissive(table: TableSnapshot, policy: PolicyInfo, usingAst: PgAstNode | null, withCheckAst: PgAstNode | null): Finding | null;
+/**
+ * Walk a policy expression, collecting unique function `(schema, name)` tuples
+ * so we can resolve volatility in one batch query.
+ */
+export declare function collectFunctionNames(expr: PgAstNode): Array<{
+    schema?: string;
+    name: string;
+}>;
+/** Parse a policy expression or return `null` on empty input. Logs parse errors to stderr. */
+export declare function parseOrNull(expr: string | null, context: string): Promise<PgAstNode | null>;

package/esm/checks/anti-patterns.js

@@ -0,0 +1,240 @@
+import { boolConst } from '../ast/helpers';
+import { parsePolicyExpression } from '../ast/parse';
+import { columnRefPath, findAll, funcNameParts, funcNameQualified, visitAll } from '../ast/walk';
+/**
+ * Function names we consider "safe" (stable) for policy predicates, even when
+ * pg_proc marks them volatile. These are the well-known Postgres session
+ * primitives that the planner treats as constant for the duration of a query.
+ *
+ * This is intentionally narrow — everything else that's volatile gets flagged.
+ */
+const SAFE_VOLATILE_ALLOWLIST = new Set([
+    'current_setting', // only because PostgreSQL optimises this specially
+    'txid_current',
+    'clock_timestamp', // still flagged elsewhere — listed here to document intent
+    'now',
+    'statement_timestamp',
+    'transaction_timestamp'
+]);
+/**
+ * Anti-pattern P1: policy predicate invokes a VOLATILE function (per-row
+ * evaluation, breaks the planner's ability to hoist or cache).
+ *
+ * Also flags SECURITY DEFINER wrappers here (P1b): they can't be inlined and
+ * become per-row function calls.
+ *
+ * Expected input: a volatility map keyed by `schema.name` (see pg/proc.ts).
+ */
+export function checkVolatileFunctions(table, expr, volatility, policyName) {
+    const out = [];
+    for (const fc of findAll(expr, 'FuncCall')) {
+        const { schema, name } = funcNameParts(fc);
+        const qualified = funcNameQualified(fc);
+        const lookupKey = schema ? `${schema}.${name}` : name;
+        const info = volatility.get(qualified) ?? volatility.get(lookupKey) ?? volatility.get(name);
+        if (!info)
+            continue; // unknown function (e.g. operator expansion) — skip silently
+        // A SECURITY DEFINER call is a plan fence whatever its volatility: the
+        // planner cannot inline it, so the qual never reaches an index. Checked
+        // before the volatility filter below, which would otherwise let every
+        // STABLE wrapper — the common shape — through unreported.
+        if (info.isSecurityDefiner) {
+            out.push({
+                code: 'P1b',
+                severity: 'medium',
+                category: 'anti-pattern',
+                schema: table.schema,
+                table: table.name,
+                policy: policyName,
+                message: `Policy "${policyName}" on ${table.schema}.${table.name} calls SECURITY DEFINER function ${info.name}`,
+                hint: 'SECURITY DEFINER wrappers can\'t be inlined by the planner — every row forces a function call. Convert to a STABLE SQL function or replace with a direct expression.',
+                context: { function: info.name }
+            });
+        }
+        if (info.volatility !== 'v')
+            continue;
+        if (SAFE_VOLATILE_ALLOWLIST.has(info.name.split('.').pop() ?? ''))
+            continue;
+        if (info.isSystem && SAFE_VOLATILE_ALLOWLIST.has(name))
+            continue;
+        out.push({
+            code: 'P1',
+            severity: 'high',
+            category: 'anti-pattern',
+            schema: table.schema,
+            table: table.name,
+            policy: policyName,
+            message: `Policy "${policyName}" on ${table.schema}.${table.name} calls VOLATILE function ${info.name}`,
+            hint: 'Volatile functions re-execute for every row considered by the planner. Mark the function STABLE if safe, or precompute the result in a CTE / subquery.',
+            context: { function: info.name, securityDefiner: info.isSecurityDefiner }
+        });
+    }
+    return out;
+}
+/**
+ * Anti-pattern P5: policy references `session_user`, `current_user`, or
+ * `pg_has_role(...)` for tenant gating. These bypass the role-and-JWT layer
+ * that the rest of the auth model is built on, and they silently evaluate
+ * against the *login* role instead of the `SET LOCAL role` role, which
+ * produces confusing RLS behavior across pooled connections.
+ */
+export function checkSessionUserGating(table, expr, policyName) {
+    const out = [];
+    // session_user / current_user appear as CurrentOfExpr-adjacent nodes in some
+    // parser versions, but the common form is `SQLValueFunction` with `op:
+    // SVFOP_CURRENT_USER` (4) or SVFOP_SESSION_USER (6).
+    visitAll(expr, (node, tag) => {
+        if (tag === 'SQLValueFunction') {
+            const op = node.op;
+            const opStr = typeof op === 'string' ? op : String(op);
+            if (/CURRENT_USER|SESSION_USER/i.test(opStr)) {
+                out.push({
+                    code: 'P5',
+                    severity: 'high',
+                    category: 'anti-pattern',
+                    schema: table.schema,
+                    table: table.name,
+                    policy: policyName,
+                    message: `Policy "${policyName}" on ${table.schema}.${table.name} references ${opStr.replace('SVFOP_', '').toLowerCase()}`,
+                    hint: 'Use a JWT-backed helper (`current_setting(\'jwt.claims...\')`) or a dedicated STABLE auth function. `current_user` / `session_user` bypass the app auth layer.'
+                });
+            }
+        }
+    });
+    // pg_has_role(text, text, text)
+    for (const fc of findAll(expr, 'FuncCall')) {
+        const { name } = funcNameParts(fc);
+        if (name === 'pg_has_role') {
+            out.push({
+                code: 'P5',
+                severity: 'high',
+                category: 'anti-pattern',
+                schema: table.schema,
+                table: table.name,
+                policy: policyName,
+                message: `Policy "${policyName}" on ${table.schema}.${table.name} uses pg_has_role() for tenant gating`,
+                hint: 'pg_has_role() checks Postgres role grants — not application-level authorization. Consider a dedicated auth helper instead.'
+            });
+        }
+    }
+    // Also flag raw ColumnRef `current_user` — parser versions vary.
+    for (const cr of findAll(expr, 'ColumnRef')) {
+        const path = columnRefPath(cr);
+        if (path.length === 1 && (path[0] === 'current_user' || path[0] === 'session_user')) {
+            out.push({
+                code: 'P5',
+                severity: 'high',
+                category: 'anti-pattern',
+                schema: table.schema,
+                table: table.name,
+                policy: policyName,
+                message: `Policy "${policyName}" on ${table.schema}.${table.name} references ${path[0]}`,
+                hint: 'Use a JWT-backed helper or STABLE auth function instead of raw session/current role.'
+            });
+        }
+    }
+    return out;
+}
+/**
+ * Anti-patterns A7 / A8: trivially-permissive policy body.
+ *
+ * A permissive policy whose body is the literal `true` adds zero security —
+ * it's equivalent to not having RLS at all for the covered command. This is
+ * different from an intentional *restrictive* `true` (which would require
+ * all rows to satisfy it). We only flag `permissive = true` here because
+ * Postgres defaults to PERMISSIVE and `USING (true)` is the most common
+ * accidental "fail-open" shape.
+ *
+ * The verb matters enormously:
+ *   - A7 (critical): a WRITE verb (INSERT/UPDATE/DELETE/ALL) with literal
+ *     `true` lets every applicable role mutate every row — and, because
+ *     permissive policies OR together, it silently defeats any carefully
+ *     scoped policies on the same table.
+ *   - A8 (low): a SELECT-only `USING (true)` is the standard public-read
+ *     reference-table pattern; flag it for confirmation, not alarm.
+ *
+ * Input: the parsed USING and WITH CHECK ASTs (may be null if empty).
+ */
+export function checkTriviallyPermissive(table, policy, usingAst, withCheckAst) {
+    if (!policy.permissive)
+        return null;
+    const usingIsTrue = usingAst ? boolConst(usingAst) === true : false;
+    const withCheckIsTrue = withCheckAst ? boolConst(withCheckAst) === true : false;
+    // Figure out which clauses are "open".
+    // - If USING exists, it must be literal true to be "open" on the read side.
+    // - If WITH CHECK exists, it must also be literal true.
+    // - If a clause is absent, the command doesn't care about it (e.g. INSERT
+    //   has no USING; SELECT has no WITH CHECK) — that's a separate concern
+    //   covered by the coverage checks.
+    // We flag when *every* present clause is literal `true`.
+    const presentClauses = [];
+    const trivialClauses = [];
+    if (policy.using !== null) {
+        presentClauses.push('USING');
+        if (usingIsTrue)
+            trivialClauses.push('USING');
+    }
+    if (policy.withCheck !== null) {
+        presentClauses.push('WITH CHECK');
+        if (withCheckIsTrue)
+            trivialClauses.push('WITH CHECK');
+    }
+    if (presentClauses.length === 0)
+        return null;
+    if (trivialClauses.length !== presentClauses.length)
+        return null;
+    const clauseList = trivialClauses.join(' and ');
+    const isWrite = policy.cmd !== 'SELECT';
+    return isWrite
+        ? {
+            code: 'A7',
+            severity: 'critical',
+            category: 'anti-pattern',
+            schema: table.schema,
+            table: table.name,
+            policy: policy.name,
+            message: `Policy "${policy.name}" (FOR ${policy.cmd}) on ${table.schema}.${table.name} is trivially permissive (${clauseList} = true) — every applicable role can write every row`,
+            hint: 'Permissive policies OR together, so a literal-true write policy defeats every scoped policy on the table. Tighten the predicate or drop the policy.',
+            context: { cmd: policy.cmd, clauses: trivialClauses }
+        }
+        : {
+            code: 'A8',
+            severity: 'low',
+            category: 'anti-pattern',
+            schema: table.schema,
+            table: table.name,
+            policy: policy.name,
+            message: `Policy "${policy.name}" (FOR SELECT) on ${table.schema}.${table.name} is trivially permissive (${clauseList} = true) — all rows readable by applicable roles`,
+            hint: 'This is the standard public-read reference-table pattern. Confirm the table holds no per-tenant data; otherwise tighten the predicate.',
+            context: { cmd: policy.cmd, clauses: trivialClauses }
+        };
+}
+/**
+ * Walk a policy expression, collecting unique function `(schema, name)` tuples
+ * so we can resolve volatility in one batch query.
+ */
+export function collectFunctionNames(expr) {
+    const out = [];
+    const seen = new Set();
+    for (const fc of findAll(expr, 'FuncCall')) {
+        const parts = funcNameParts(fc);
+        const key = `${parts.schema ?? ''}.${parts.name}`;
+        if (seen.has(key))
+            continue;
+        seen.add(key);
+        out.push(parts);
+    }
+    return out;
+}
+/** Parse a policy expression or return `null` on empty input. Logs parse errors to stderr. */
+export async function parseOrNull(expr, context) {
+    try {
+        const parsed = await parsePolicyExpression(expr);
+        return parsed?.ast ?? null;
+    }
+    catch (err) {
+        // eslint-disable-next-line no-console
+        console.warn(`[safegres-audit] could not parse ${context}: ${err.message}`);
+        return null;
+    }
+}

package/esm/checks/column-grants.d.ts

@@ -0,0 +1,20 @@
+/**
+ * L13: reach that exists only in `pg_attribute.attacl`.
+ *
+ * `GRANT SELECT (secret) ON t TO anonymous` writes nothing to the relation's
+ * ACL. Every grant query in this package read `relacl` alone, so a role whose
+ * entire access to a table is column-scoped was reported as reaching *nothing*
+ * — no A2, no R1, no L-series, and "0 relation(s) accessible" in the role
+ * access report. The privilege is real: the role selects those columns, and
+ * when the table has no RLS it selects every row of them.
+ *
+ * The finding is deliberately about the *invisibility* as much as the access.
+ * A column grant is a legitimate and often good way to expose a projection;
+ * what is not fine is that nothing else in the audit grades it. So L13 reports
+ * the reach, states whether RLS mediates it, and — as everywhere else — never
+ * recommends revoking the grant it cannot prove unused.
+ */
+import type { TableSnapshot } from '../pg/introspect';
+import type { Finding } from '../types';
+import { type LatticeRoleOptions, type RoleGraph } from './lattice';
+export declare function checkUntrustedColumnGrants(table: TableSnapshot, graph: RoleGraph, options?: LatticeRoleOptions): Finding[];

package/esm/checks/column-grants.js

@@ -0,0 +1,71 @@
+/**
+ * L13: reach that exists only in `pg_attribute.attacl`.
+ *
+ * `GRANT SELECT (secret) ON t TO anonymous` writes nothing to the relation's
+ * ACL. Every grant query in this package read `relacl` alone, so a role whose
+ * entire access to a table is column-scoped was reported as reaching *nothing*
+ * — no A2, no R1, no L-series, and "0 relation(s) accessible" in the role
+ * access report. The privilege is real: the role selects those columns, and
+ * when the table has no RLS it selects every row of them.
+ *
+ * The finding is deliberately about the *invisibility* as much as the access.
+ * A column grant is a legitimate and often good way to expose a projection;
+ * what is not fine is that nothing else in the audit grades it. So L13 reports
+ * the reach, states whether RLS mediates it, and — as everywhere else — never
+ * recommends revoking the grant it cannot prove unused.
+ */
+import { effectiveColumnGrants } from './lattice';
+/** SELECT/INSERT/UPDATE are the column privileges RLS has anything to say about. */
+const MEDIATED = ['SELECT', 'INSERT', 'UPDATE'];
+export function checkUntrustedColumnGrants(table, graph, options = {}) {
+    const roles = options.roles ?? [];
+    if (roles.length === 0 || table.columnGrants.length === 0)
+        return [];
+    const out = [];
+    for (const role of roles) {
+        const grants = effectiveColumnGrants(table, role, graph).filter((g) => MEDIATED.includes(g.privilege));
+        if (grants.length === 0)
+            continue;
+        const attrs = graph.get(role);
+        // Same exemption test the rest of the lattice uses: a role RLS does not
+        // apply to reads every row of the columns it is granted.
+        const rlsApplies = table.rlsEnabled
+            && !attrs?.bypassRls
+            && !attrs?.isSuper
+            && !(role === table.owner && !table.rlsForced);
+        const columns = [...new Set(grants.flatMap((g) => g.columns))].sort();
+        const privileges = grants.map((g) => g.privilege).sort();
+        const via = grants[0].via;
+        out.push({
+            code: 'L13',
+            severity: 'info',
+            category: 'anti-pattern',
+            schema: table.schema,
+            table: table.name,
+            role,
+            privilege: privileges.join(', '),
+            message: `Untrusted role ${role} holds column-level ${privileges.join(', ')} on `
+                + `${table.schema}.${table.name} (${columns.join(', ')})`
+                + (via === 'direct' ? '' : ` via ${via}`)
+                + (rlsApplies
+                    ? ' — mediated by RLS, but invisible to every rule that reads the relation ACL'
+                    : ' — with no RLS to mediate it, so every row of those columns is readable'),
+            hint: `Column grants live in \`pg_attribute.attacl\`, not \`relacl\`: \`\\dp\` shows them in `
+                + `the "Column privileges" column and nothing else in this audit graded them until now. `
+                + (rlsApplies
+                    ? 'Confirm the policies that mediate this relation are the ones you would want applied '
+                        + 'to a projection of it.'
+                    : 'If the projection is meant to be public this is correct as written; if not, enable '
+                        + 'RLS on the relation — the column grant restricts *which columns*, never which rows.')
+                + ' Do not revoke the grant on the strength of this finding alone: nothing here proves it '
+                + 'unused.',
+            context: {
+                columns,
+                via,
+                rlsMediated: rlsApplies,
+                rlsEnabled: table.rlsEnabled
+            }
+        });
+    }
+    return out;
+}

package/esm/checks/coverage.d.ts

@@ -0,0 +1,43 @@
+import type { PgPrivilege, PolicyCmd, PolicyInfo, TableSnapshot } from '../pg/introspect';
+import type { Finding } from '../types';
+/**
+ * Coverage rules for row-level security.
+ *
+ * The security posture of a table is determined per `(role, privilege)` — not
+ * per individual policy. A grant is "covered" iff at least one applicable
+ * *permissive* policy supplies the clause that privilege requires:
+ *
+ *   - INSERT  → a `WITH CHECK` clause (USING is not valid on FOR INSERT).
+ *   - SELECT  → a `USING` clause.
+ *   - UPDATE  → a `USING` clause (the FOR UPDATE visibility gate). If absent,
+ *               writes against the row are impossible and the grant is dead.
+ *   - DELETE  → a `USING` clause.
+ *
+ * Postgres fails writes at runtime when the required clause is missing across
+ * *every* applicable permissive policy, so that's the only bar this check
+ * holds us to. Whether an UPDATE policy also pairs a WITH CHECK (defense in
+ * depth against row smuggling) is a separate, weaker concern that is
+ * covered by `checkUpdateWithCheckCoverage` below as an INFO-level finding.
+ */
+/** What clause kind satisfies coverage for a given privilege. */
+export type ClauseKind = 'USING' | 'WITH CHECK';
+export declare const CLAUSE_REQUIRED: Partial<Record<PgPrivilege, ClauseKind>>;
+/** `polcmd` → the single verb the policy can satisfy (`ALL` satisfies every verb). */
+export declare const POLICY_CMDS: Record<PolicyCmd, PgPrivilege[]>;
+/**
+ * A4 / A5: Grant of INSERT/UPDATE/DELETE (A4, high) or SELECT (A5, medium) to
+ * a role but no applicable permissive policy supplies the clause that verb
+ * needs. A4 means "writes silently fail at runtime". A5 means "queries
+ * silently return 0 rows".
+ */
+export declare function checkCoverageGaps(table: TableSnapshot): Finding[];
+/**
+ * A6 (informational): UPDATE coverage exists for a role but no applicable
+ * permissive UPDATE policy pairs a `WITH CHECK`. This is defense-in-depth —
+ * without WITH CHECK, updates can move rows out of the visible scope (a
+ * "row smuggling" pattern). Low severity because it does not cause runtime
+ * failures and in many designs is by construction safe (e.g. the columns
+ * that define scope are not writable, or a trigger re-asserts scope).
+ */
+export declare function checkUpdateWithCheckCoverage(table: TableSnapshot): Finding[];
+export declare function policyProvidesClause(p: PolicyInfo, role: string, privilege: PgPrivilege, clause: ClauseKind): boolean;

package/esm/checks/coverage.js

@@ -0,0 +1,104 @@
+export const CLAUSE_REQUIRED = {
+    SELECT: 'USING',
+    INSERT: 'WITH CHECK',
+    UPDATE: 'USING',
+    DELETE: 'USING'
+};
+/** `polcmd` → the single verb the policy can satisfy (`ALL` satisfies every verb). */
+export const POLICY_CMDS = {
+    SELECT: ['SELECT'],
+    INSERT: ['INSERT'],
+    UPDATE: ['UPDATE'],
+    DELETE: ['DELETE'],
+    ALL: ['SELECT', 'INSERT', 'UPDATE', 'DELETE']
+};
+/**
+ * A4 / A5: Grant of INSERT/UPDATE/DELETE (A4, high) or SELECT (A5, medium) to
+ * a role but no applicable permissive policy supplies the clause that verb
+ * needs. A4 means "writes silently fail at runtime". A5 means "queries
+ * silently return 0 rows".
+ */
+export function checkCoverageGaps(table) {
+    if (!table.rlsEnabled)
+        return []; // A2 covers the "RLS off entirely" case.
+    const out = [];
+    for (const grant of table.grants) {
+        if (grant.role === table.owner)
+            continue;
+        if (grant.role === 'PUBLIC')
+            continue;
+        if (grant.bypassRls)
+            continue; // Superusers and BYPASSRLS roles aren't subject to policies.
+        const requiredClause = CLAUSE_REQUIRED[grant.privilege];
+        if (!requiredClause)
+            continue; // TRUNCATE / REFERENCES / TRIGGER don't participate in RLS.
+        const covered = table.policies.some((p) => policyProvidesClause(p, grant.role, grant.privilege, requiredClause));
+        if (covered)
+            continue;
+        const [code, severity] = grant.privilege === 'SELECT'
+            ? ['A5', 'medium']
+            : ['A4', 'high'];
+        out.push({
+            code,
+            severity,
+            category: 'coverage',
+            schema: table.schema,
+            table: table.name,
+            role: grant.role,
+            privilege: grant.privilege,
+            message: `Role ${grant.role} has ${grant.privilege} grant on ${table.schema}.${table.name} but no permissive policy supplies ${requiredClause} for ${grant.privilege}`,
+            hint: grant.privilege === 'SELECT'
+                ? 'Queries by this role will silently return 0 rows. Add a permissive policy FOR SELECT TO that role, or revoke the grant.'
+                : `${grant.privilege} by this role will fail at runtime. Add a permissive policy FOR ${grant.privilege} TO that role supplying ${requiredClause}, or revoke the grant.`
+        });
+    }
+    return out;
+}
+/**
+ * A6 (informational): UPDATE coverage exists for a role but no applicable
+ * permissive UPDATE policy pairs a `WITH CHECK`. This is defense-in-depth —
+ * without WITH CHECK, updates can move rows out of the visible scope (a
+ * "row smuggling" pattern). Low severity because it does not cause runtime
+ * failures and in many designs is by construction safe (e.g. the columns
+ * that define scope are not writable, or a trigger re-asserts scope).
+ */
+export function checkUpdateWithCheckCoverage(table) {
+    if (!table.rlsEnabled)
+        return [];
+    const out = [];
+    const updateGrants = table.grants.filter((g) => g.privilege === 'UPDATE'
+        && g.role !== table.owner
+        && g.role !== 'PUBLIC'
+        && !g.bypassRls);
+    if (updateGrants.length === 0)
+        return [];
+    for (const grant of updateGrants) {
+        const usingCovered = table.policies.some((p) => policyProvidesClause(p, grant.role, 'UPDATE', 'USING'));
+        if (!usingCovered)
+            continue; // already reported as A4.
+        const withCheckCovered = table.policies.some((p) => policyProvidesClause(p, grant.role, 'UPDATE', 'WITH CHECK'));
+        if (withCheckCovered)
+            continue;
+        out.push({
+            code: 'A6',
+            severity: 'info',
+            category: 'coverage',
+            schema: table.schema,
+            table: table.name,
+            role: grant.role,
+            privilege: 'UPDATE',
+            message: `Role ${grant.role} has UPDATE on ${table.schema}.${table.name}; USING is supplied but no applicable permissive policy provides WITH CHECK`,
+            hint: 'Without a WITH CHECK on UPDATE, rows can be updated to values that move them outside the role\'s visible set. Add WITH CHECK if the scoped columns are writable by this role.'
+        });
+    }
+    return out;
+}
+export function policyProvidesClause(p, role, privilege, clause) {
+    if (!p.permissive)
+        return false;
+    if (!POLICY_CMDS[p.cmd].includes(privilege))
+        return false;
+    if (!p.roles.includes('PUBLIC') && !p.roles.includes(role))
+        return false;
+    return clause === 'USING' ? p.using != null : p.withCheck != null;
+}

package/esm/checks/definer-function.d.ts

@@ -0,0 +1,91 @@
+/**
+ * L19 and L20: privilege that arrives through a *function body*.
+ *
+ * L8 modelled the view half of "SQL bodies confer privilege". This is the
+ * other half, and the larger one:
+ *
+ *   - **L19, SECURITY DEFINER functions.** A definer function executes as its
+ *     owner, so every relation its body touches is touched with the owner's
+ *     privileges — including tables the caller holds nothing on, and, when
+ *     the owner owns the table or bypasses RLS, without the row filter the
+ *     table's policies would have applied. EXECUTE on the function is the
+ *     only grant the caller needs, and no ACL on the base relation names it.
+ *     Verified on PostgreSQL 18: an anonymous role with EXECUTE read every
+ *     row of an RLS-protected table it had no grant on, while the invoker
+ *     twin of the same function was denied.
+ *
+ *   - **L20, `INSTEAD OF` triggers.** A write against a view carrying one
+ *     never reaches a base relation: it *becomes* the trigger function's
+ *     body. L9 suppressed those views because nothing followed that body —
+ *     this rule follows it. The body is permission-checked against the
+ *     function's effective user, so the escalation exists only when the
+ *     trigger function is SECURITY DEFINER; the view's own owner and its
+ *     `security_invoker` setting do not govern it. Both halves were probed on
+ *     PG 18: the invoker trigger function was denied on the relation its body
+ *     wrote, the definer one wrote it as its owner.
+ *
+ * The conservatism is L8's, unchanged. A body that cannot be read is unknown,
+ * not empty: its fragmentary access list is discarded and the function is
+ * reported as a coverage gap (L15) rather than scanned clean. And the fix is
+ * never a revoke — EXECUTE on the function is what the API serves; the defect
+ * is what the body does with the owner's rights.
+ */
+import { type SchemaAclInfo } from '../pg/acl';
+import type { FunctionSnapshot } from '../pg/functions';
+import type { ViewSnapshot } from '../pg/indexes';
+import type { TableSnapshot } from '../pg/introspect';
+import type { Finding } from '../types';
+import { type SuppressedView } from './definer-view';
+import { type LatticeRoleOptions, type RoleGraph } from './lattice';
+import { type FunctionReachInput, type TriggerWriteInput } from './role-reach';
+export interface FunctionBodyAnalysis {
+    /** Functions that execute as someone other than the caller, as reach inputs. */
+    functions: FunctionReachInput[];
+    /** `INSTEAD OF` triggers whose function re-owns the write. */
+    triggers: TriggerWriteInput[];
+    /** Bodies deliberately left out, with why — an unread body is not a clean bill. */
+    suppressed: SuppressedView[];
+}
+/**
+ * Read every SECURITY DEFINER function's body and resolve what it reaches.
+ *
+ * Calls are followed: an invoker function called from a definer still runs
+ * with the definer's owner in force, while an inner definer switches the
+ * executing role again — the same rule as nested views, because it is the
+ * same rule. Views read from a body are followed too, through the existing
+ * view walk, so a definer function selecting from a definer view reaches that
+ * view's bases as well.
+ */
+export declare function analyzeFunctionBodies(functions: FunctionSnapshot[], views: ViewSnapshot[], tables: TableSnapshot[], auditedSchemas?: Iterable<string>): Promise<FunctionBodyAnalysis>;
+/**
+ * L19: an untrusted role reaches a relation by executing a SECURITY DEFINER
+ * function.
+ *
+ * Fires once per (role, function, relation, privilege) where the role can
+ * EXECUTE the function, the body touches the relation as someone else, and
+ * the role holds no such privilege on the relation itself. The invoker twin
+ * of the same function produces nothing: its body runs as the caller, so the
+ * relation's own ACL and policies apply and there is no edge to report.
+ */
+export declare function checkDefinerFunctionReach(functions: FunctionReachInput[], tables: TableSnapshot[], graph: RoleGraph, schemaAcls: Map<string, SchemaAclInfo>, options?: LatticeRoleOptions): Finding[];
+/**
+ * L20: an untrusted role writes a relation through an `INSTEAD OF` trigger
+ * whose function is SECURITY DEFINER.
+ *
+ * This is the suppression L9 has carried since it shipped. A write against a
+ * view with `INSTEAD OF` triggers never reaches a base relation — Postgres
+ * runs the trigger function instead — and where that write lands is in the
+ * body. Following it makes the edge provable; where the body is unreadable,
+ * or the trigger function runs as the caller, the suppression stands.
+ */
+export declare function checkInsteadOfTriggerWrite(triggers: TriggerWriteInput[], tables: TableSnapshot[], graph: RoleGraph, options?: LatticeRoleOptions): Finding[];
+/**
+ * L15, asked of a function instead of a view: an untrusted role can execute a
+ * definer function whose body this analysis could not fully read.
+ *
+ * The same coverage statement the view producer makes, for the same reason —
+ * the execution is proven and the far end is unknown, so no grading rule saw
+ * it. Reporting the gap is the alternative to a silent clean bill; it is
+ * `info`, score-neutral, and recommends no revoke.
+ */
+export declare function checkUnreadableFunctionReach(functions: FunctionReachInput[], graph: RoleGraph, schemaAcls: Map<string, SchemaAclInfo>, options?: LatticeRoleOptions): Finding[];