@safegres/test 0.0.1 → 1.30.7

package/corpus/cases/33-leaky-filter-view/schema.sql

@@ -0,0 +1,29 @@
+DROP SCHEMA IF EXISTS c_leaky_filter_view CASCADE;
+CREATE SCHEMA c_leaky_filter_view;
+
+DO $$ BEGIN
+  CREATE ROLE c_leaky_view_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_leaky_filter_view TO corpus_anon, corpus_user, c_leaky_view_owner;
+
+CREATE TABLE c_leaky_filter_view.documents (
+  id bigserial PRIMARY KEY,
+  visibility text NOT NULL,
+  title text NOT NULL,
+  body text NOT NULL
+);
+ALTER TABLE c_leaky_filter_view.documents OWNER TO c_leaky_view_owner;
+
+-- The flaw: the view's WHERE is the only thing separating corpus_anon from the
+-- private documents, and without `security_barrier` the planner may evaluate a
+-- caller-supplied qual before it. A cheap leaky function
+-- (`... WHERE leak(body)`) then runs against every row, private ones included,
+-- and reports what it sees through a notice, an error or a timing difference.
+CREATE VIEW c_leaky_filter_view.public_documents AS
+  SELECT id, title, body
+  FROM c_leaky_filter_view.documents
+  WHERE visibility = 'public';
+ALTER VIEW c_leaky_filter_view.public_documents OWNER TO c_leaky_view_owner;
+GRANT SELECT ON c_leaky_filter_view.public_documents TO corpus_anon, corpus_user;

package/corpus/cases/34-barrier-view-no-leak/case.json

@@ -0,0 +1,32 @@
+{
+  "title": "The same filtering view with security_barrier is a boundary, and L12 stays silent",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_barrier_view"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L8",
+      "relation": "c_barrier_view.documents",
+      "note": "the view still executes as its owner — that is what it is for — so the definer-view reach edge is still reported; only the question of *which* rows is settled by the barrier"
+    }
+  ],
+  "forbid": [
+    "L9",
+    "L10",
+    "L11",
+    "L12"
+  ],
+  "worstSeverity": "info",
+  "fix": "Nothing on the barrier. This case is case 33 after its fix, and exists to pin that L12 stops firing once the row filter is a boundary rather than a convenience.",
+  "id": "34-barrier-view-no-leak"
+}

package/corpus/cases/34-barrier-view-no-leak/schema.sql

@@ -0,0 +1,29 @@
+DROP SCHEMA IF EXISTS c_barrier_view CASCADE;
+CREATE SCHEMA c_barrier_view;
+
+DO $$ BEGIN
+  CREATE ROLE c_barrier_view_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_barrier_view TO corpus_anon, corpus_user, c_barrier_view_owner;
+
+CREATE TABLE c_barrier_view.documents (
+  id bigserial PRIMARY KEY,
+  visibility text NOT NULL,
+  title text NOT NULL,
+  body text NOT NULL
+);
+ALTER TABLE c_barrier_view.documents OWNER TO c_barrier_view_owner;
+
+-- Case 33 with the one option that makes the filter a boundary: the planner
+-- may not push a caller's qual below the view's own, so the excluded rows are
+-- never evaluated. L12 must stay silent. L8 still fires — the view does hand
+-- corpus_anon rows of a table it holds no grant on, which is what the view is
+-- for; the barrier only settles *which* rows.
+CREATE VIEW c_barrier_view.public_documents WITH (security_barrier = true) AS
+  SELECT id, title, body
+  FROM c_barrier_view.documents
+  WHERE visibility = 'public';
+ALTER VIEW c_barrier_view.public_documents OWNER TO c_barrier_view_owner;
+GRANT SELECT ON c_barrier_view.public_documents TO corpus_anon, corpus_user;

package/corpus/cases/35-column-grant-projection/case.json

@@ -0,0 +1,27 @@
+{
+  "title": "A column grant is reach that lives only in pg_attribute.attacl",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_column_grant"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L13",
+      "relation": "c_column_grant.profiles",
+      "role": "corpus_anon",
+      "note": "column-level SELECT on an RLS-off table: every row of handle and display_name, and until this rule existed the audit reported the relation as unreachable"
+    }
+  ],
+  "worstSeverity": "info",
+  "fix": "Not a revoke. Either the projection is intended and public — in which case this is correct as written — or the relation needs RLS, because a column grant restricts which columns, never which rows.",
+  "id": "35-column-grant-projection"
+}

package/corpus/cases/35-column-grant-projection/schema.sql

@@ -0,0 +1,21 @@
+DROP SCHEMA IF EXISTS c_column_grant CASCADE;
+CREATE SCHEMA c_column_grant;
+
+GRANT USAGE ON SCHEMA c_column_grant TO corpus_anon, corpus_user;
+
+CREATE TABLE c_column_grant.profiles (
+  id bigserial PRIMARY KEY,
+  handle text NOT NULL,
+  display_name text NOT NULL,
+  email text NOT NULL,
+  password_reset_token text
+);
+
+-- The flaw is not the projection — exposing a handle and a display name
+-- anonymously is a reasonable thing to want. The flaw is that this grant is
+-- written to `pg_attribute.attacl` and nothing at all appears in the table's
+-- `relacl`, so every relacl-only rule concludes corpus_anon reaches nothing
+-- here. RLS is off, so the grant reads every row of those columns.
+GRANT SELECT (handle, display_name) ON c_column_grant.profiles TO corpus_anon;
+GRANT SELECT (handle, display_name, email) ON c_column_grant.profiles TO corpus_user;
+GRANT UPDATE (display_name) ON c_column_grant.profiles TO corpus_user;

package/corpus/cases/35-policy-function-not-leakproof/case.json

@@ -0,0 +1,24 @@
+{
+  "title": "Policy calls a non-LEAKPROOF function",
+  "dimension": "perf",
+  "exposure": {
+    "schemas": [
+      "c_policy_fn_leaky"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "X4",
+      "relation": "c_policy_fn_leaky.invoices",
+      "note": "a non-leakproof qual cannot be pushed below a join or subquery scan, so the security filter runs late and on more rows than it needs to"
+    }
+  ],
+  "fix": "Mark c_policy_fn_leaky.tenant_of LEAKPROOF — it raises no error carrying its argument — or inline the cast so the policy calls nothing at all."
+}

package/corpus/cases/35-policy-function-not-leakproof/schema.sql

@@ -0,0 +1,27 @@
+DROP SCHEMA IF EXISTS c_policy_fn_leaky CASCADE;
+CREATE SCHEMA c_policy_fn_leaky;
+GRANT USAGE ON SCHEMA c_policy_fn_leaky TO corpus_user, corpus_anon;
+
+-- IMMUTABLE, so this is not the per-row-evaluation flaw of case 20: the only
+-- thing wrong with it is that nothing has promised it doesn't leak its
+-- argument, and the planner takes that promise seriously.
+CREATE FUNCTION c_policy_fn_leaky.tenant_of(claim text) RETURNS uuid
+  LANGUAGE sql IMMUTABLE AS $$
+    SELECT nullif(claim, '')::uuid
+  $$;
+
+CREATE TABLE c_policy_fn_leaky.invoices (
+  id bigserial PRIMARY KEY,
+  tenant_id uuid NOT NULL,
+  amount numeric
+);
+CREATE INDEX invoices_tenant_idx ON c_policy_fn_leaky.invoices (tenant_id);
+ALTER TABLE c_policy_fn_leaky.invoices ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_policy_fn_leaky.invoices FORCE ROW LEVEL SECURITY;
+
+-- Hoisted into an InitPlan and comparing an indexed column: everything else
+-- about this predicate is right. The flaw is the missing LEAKPROOF.
+CREATE POLICY invoices_tenant ON c_policy_fn_leaky.invoices FOR SELECT TO corpus_user
+  USING (tenant_id = (SELECT c_policy_fn_leaky.tenant_of(current_setting('jwt.claims.tenant_id', true))));
+
+GRANT SELECT ON c_policy_fn_leaky.invoices TO corpus_user;

package/corpus/cases/36-column-grant-rls-mediated/case.json

@@ -0,0 +1,27 @@
+{
+  "title": "A column grant under RLS is reported as reach, but as mediated reach",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_column_grant_rls"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L13",
+      "relation": "c_column_grant_rls.notes",
+      "role": "corpus_anon",
+      "note": "policies mediate the rows and the grant narrows the columns — reported because nothing else in the audit sees the grant at all, not because it is wrong"
+    }
+  ],
+  "worstSeverity": "info",
+  "fix": "Nothing. This case pins two things: that a mediated column grant is still surfaced, and that corpus_user — which holds SELECT on the whole relation — is not reported a second time for the redundant column grant.",
+  "id": "36-column-grant-rls-mediated"
+}

package/corpus/cases/36-column-grant-rls-mediated/schema.sql

@@ -0,0 +1,32 @@
+DROP SCHEMA IF EXISTS c_column_grant_rls CASCADE;
+CREATE SCHEMA c_column_grant_rls;
+
+GRANT USAGE ON SCHEMA c_column_grant_rls TO corpus_anon, corpus_user;
+
+CREATE TABLE c_column_grant_rls.notes (
+  id bigserial PRIMARY KEY,
+  author text NOT NULL,
+  title text NOT NULL,
+  body text NOT NULL
+);
+ALTER TABLE c_column_grant_rls.notes ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_column_grant_rls.notes FORCE ROW LEVEL SECURITY;
+
+-- The column grant is mediated: only published rows are visible, and the
+-- column list narrows that further. The point of this case is the pairing —
+-- L13 still reports the reach, because nothing else in the audit can see it,
+-- but it reports it as mediated and recommends nothing.
+CREATE POLICY notes_published ON c_column_grant_rls.notes
+  FOR SELECT TO corpus_anon
+  USING (author = (SELECT current_setting('app.author', true)));
+CREATE INDEX notes_author_idx ON c_column_grant_rls.notes (author);
+
+GRANT SELECT (title) ON c_column_grant_rls.notes TO corpus_anon;
+
+-- The negative half: corpus_user holds the whole relation, so its column
+-- grant adds no reach and must not be reported twice.
+GRANT SELECT ON c_column_grant_rls.notes TO corpus_user;
+GRANT SELECT (title) ON c_column_grant_rls.notes TO corpus_user;
+CREATE POLICY notes_own ON c_column_grant_rls.notes
+  FOR SELECT TO corpus_user
+  USING (author = (SELECT current_setting('app.author', true)));

package/corpus/cases/36-policy-function-leakproof/case.json

@@ -0,0 +1,24 @@
+{
+  "title": "A LEAKPROOF policy function is not a planner obstacle",
+  "dimension": "perf",
+  "exposure": {
+    "schemas": [
+      "c_policy_fn_leakproof"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [],
+  "forbid": [
+    "X2",
+    "X3",
+    "X4",
+    "X9"
+  ],
+  "fix": "Nothing to fix — this is case 35 fixed, and a rule firing here would be telling you to undo the fix."
+}

package/corpus/cases/36-policy-function-leakproof/schema.sql

@@ -0,0 +1,22 @@
+DROP SCHEMA IF EXISTS c_policy_fn_leakproof CASCADE;
+CREATE SCHEMA c_policy_fn_leakproof;
+GRANT USAGE ON SCHEMA c_policy_fn_leakproof TO corpus_user, corpus_anon;
+
+CREATE FUNCTION c_policy_fn_leakproof.tenant_of(claim text) RETURNS uuid
+  LANGUAGE sql IMMUTABLE LEAKPROOF AS $$
+    SELECT nullif(claim, '')::uuid
+  $$;
+
+CREATE TABLE c_policy_fn_leakproof.invoices (
+  id bigserial PRIMARY KEY,
+  tenant_id uuid NOT NULL,
+  amount numeric
+);
+CREATE INDEX invoices_tenant_idx ON c_policy_fn_leakproof.invoices (tenant_id);
+ALTER TABLE c_policy_fn_leakproof.invoices ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_policy_fn_leakproof.invoices FORCE ROW LEVEL SECURITY;
+
+CREATE POLICY invoices_tenant ON c_policy_fn_leakproof.invoices FOR SELECT TO corpus_user
+  USING (tenant_id = (SELECT c_policy_fn_leakproof.tenant_of(current_setting('jwt.claims.tenant_id', true))));
+
+GRANT SELECT ON c_policy_fn_leakproof.invoices TO corpus_user;

package/corpus/cases/37-sort-column-unindexed/case.json

@@ -0,0 +1,24 @@
+{
+  "title": "Sort-shaped column leading no index",
+  "dimension": "perf",
+  "exposure": {
+    "schemas": [
+      "c_sort_no_index"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "X8",
+      "relation": "c_sort_no_index.feed_items",
+      "note": "every page of a feed ordered by created_at sorts the whole RLS-filtered result; keyset pagination degenerates into scan-and-discard"
+    }
+  ],
+  "fix": "CREATE INDEX ON c_sort_no_index.feed_items (created_at DESC) — or turn X8 off if nothing orders by it, which is why the rule ships as info."
+}

package/corpus/cases/37-sort-column-unindexed/schema.sql

@@ -0,0 +1,14 @@
+DROP SCHEMA IF EXISTS c_sort_no_index CASCADE;
+CREATE SCHEMA c_sort_no_index;
+GRANT USAGE ON SCHEMA c_sort_no_index TO corpus_user, corpus_anon;
+
+CREATE TABLE c_sort_no_index.feed_items (
+  id bigserial PRIMARY KEY,
+  body text,
+  -- The flaw, such as it is: a timestamp column that leads no index. A
+  -- heuristic — nothing here proves anything orders by it — so the rule is
+  -- info and costs the score nothing.
+  created_at timestamptz NOT NULL DEFAULT now()
+);
+
+GRANT SELECT ON c_sort_no_index.feed_items TO corpus_user;

package/corpus/cases/37-unaudited-base-relation/case.json

@@ -0,0 +1,30 @@
+{
+  "title": "A definer view reads a relation in a schema the audit never introspected",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_unaudited_view"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L14",
+      "relation": "c_unaudited_hidden.credentials",
+      "role": "corpus_anon",
+      "note": "the reach is proven from the view body; nothing on the far end was graded, because c_unaudited_hidden is outside the audited schemas"
+    }
+  ],
+  "forbid": [
+    "L8"
+  ],
+  "worstSeverity": "info",
+  "fix": "Bring c_unaudited_hidden into the audit (add it to `schemas`, or drop it from `excludeSchemas`) so the base relation's ACL and policies are graded — then L8 can answer whether this is a bypass. Excluding a schema scopes what is scored, never what is reachable.",
+  "id": "37-unaudited-base-relation"
+}

package/corpus/cases/37-unaudited-base-relation/schema.sql

@@ -0,0 +1,45 @@
+DROP SCHEMA IF EXISTS c_unaudited_view CASCADE;
+DROP SCHEMA IF EXISTS c_unaudited_hidden CASCADE;
+CREATE SCHEMA c_unaudited_view;
+CREATE SCHEMA c_unaudited_hidden;
+
+DO $$ BEGIN
+  CREATE ROLE c_unaudited_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_unaudited_view TO corpus_anon, corpus_user, c_unaudited_owner;
+
+-- Deliberately *not* in the case's exposure surface, so the audit never
+-- introspects it: no ACL, no policy and no owner of this table is ever read.
+CREATE TABLE c_unaudited_hidden.credentials (
+  id bigserial PRIMARY KEY,
+  subject text NOT NULL,
+  secret text NOT NULL
+);
+ALTER TABLE c_unaudited_hidden.credentials OWNER TO c_unaudited_owner;
+ALTER TABLE c_unaudited_hidden.credentials ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_unaudited_hidden.credentials FORCE ROW LEVEL SECURITY;
+
+-- A table in scope, so the case has an audited surface of its own and the
+-- finding below is clearly about the *other* schema.
+CREATE TABLE c_unaudited_view.sessions (
+  id bigserial PRIMARY KEY,
+  subject text NOT NULL
+);
+ALTER TABLE c_unaudited_view.sessions ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_unaudited_view.sessions FORCE ROW LEVEL SECURITY;
+CREATE POLICY sessions_own ON c_unaudited_view.sessions
+  FOR SELECT TO corpus_user
+  USING (subject = (SELECT current_setting('app.subject', true)));
+CREATE INDEX sessions_subject_idx ON c_unaudited_view.sessions (subject);
+GRANT SELECT ON c_unaudited_view.sessions TO corpus_user;
+
+-- The flaw: the view is in scope and its body names a relation that is not.
+-- It executes as its owner, so corpus_anon reads a table the audit never
+-- graded — every rule that needs the base relation's ACL or policies drops
+-- the edge, and the view scans clean.
+CREATE VIEW c_unaudited_view.subject_directory AS
+  SELECT subject FROM c_unaudited_hidden.credentials;
+ALTER VIEW c_unaudited_view.subject_directory OWNER TO c_unaudited_owner;
+GRANT SELECT ON c_unaudited_view.subject_directory TO corpus_anon, corpus_user;

package/corpus/cases/38-foreign-key-with-index/case.json

@@ -0,0 +1,22 @@
+{
+  "title": "A foreign key with a covering index is not a finding",
+  "dimension": "perf",
+  "exposure": {
+    "schemas": [
+      "c_fk_indexed"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [],
+  "forbid": [
+    "X1",
+    "X5"
+  ],
+  "fix": "Nothing to fix — this is case 17 fixed. X5 is forbidden too: a single-column index on a foreign key is not made redundant by the primary key it references."
+}

package/corpus/cases/38-foreign-key-with-index/schema.sql

@@ -0,0 +1,17 @@
+DROP SCHEMA IF EXISTS c_fk_indexed CASCADE;
+CREATE SCHEMA c_fk_indexed;
+GRANT USAGE ON SCHEMA c_fk_indexed TO corpus_user, corpus_anon;
+
+CREATE TABLE c_fk_indexed.authors (
+  id bigserial PRIMARY KEY,
+  name text NOT NULL
+);
+
+CREATE TABLE c_fk_indexed.books (
+  id bigserial PRIMARY KEY,
+  author_id bigint NOT NULL REFERENCES c_fk_indexed.authors (id) ON DELETE CASCADE,
+  title text NOT NULL
+);
+CREATE INDEX books_author_idx ON c_fk_indexed.books (author_id);
+
+GRANT SELECT ON c_fk_indexed.authors, c_fk_indexed.books TO corpus_user;

package/corpus/cases/38-invoker-view-unaudited-base/case.json

@@ -0,0 +1,30 @@
+{
+  "title": "An invoker view over the same out-of-scope table confers nothing, so nothing is reported",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_invoker_unaudited"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "A3",
+      "relation": "c_invoker_unaudited.sessions",
+      "note": "the only finding left, and it is about the in-scope table: RLS is not FORCEd, so the owner still reads every row"
+    }
+  ],
+  "forbid": [
+    "L14",
+    "L8"
+  ],
+  "worstSeverity": "low",
+  "fix": "Nothing on the view. This case pins the boundary: L14 reports an out-of-scope *reach*, not an out-of-scope *reference*. `security_invoker` means the caller reads with its own privileges, so no edge crosses the schema boundary and reporting one would be noise on every view that touches a system catalog.",
+  "id": "38-invoker-view-unaudited-base"
+}

package/corpus/cases/38-invoker-view-unaudited-base/schema.sql

@@ -0,0 +1,39 @@
+DROP SCHEMA IF EXISTS c_invoker_unaudited CASCADE;
+DROP SCHEMA IF EXISTS c_invoker_hidden CASCADE;
+CREATE SCHEMA c_invoker_unaudited;
+CREATE SCHEMA c_invoker_hidden;
+
+DO $$ BEGIN
+  CREATE ROLE c_invoker_unaudited_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_invoker_unaudited TO corpus_anon, corpus_user, c_invoker_unaudited_owner;
+
+CREATE TABLE c_invoker_hidden.credentials (
+  id bigserial PRIMARY KEY,
+  subject text NOT NULL,
+  secret text NOT NULL
+);
+ALTER TABLE c_invoker_hidden.credentials OWNER TO c_invoker_unaudited_owner;
+
+CREATE TABLE c_invoker_unaudited.sessions (
+  id bigserial PRIMARY KEY,
+  subject text NOT NULL
+);
+ALTER TABLE c_invoker_unaudited.sessions ENABLE ROW LEVEL SECURITY;
+CREATE POLICY sessions_own ON c_invoker_unaudited.sessions
+  FOR SELECT TO corpus_user
+  USING (subject = (SELECT current_setting('app.subject', true)));
+CREATE INDEX sessions_subject_idx ON c_invoker_unaudited.sessions (subject);
+GRANT SELECT ON c_invoker_unaudited.sessions TO corpus_user;
+
+-- The same cross-schema shape as case 37, with `security_invoker`. The view
+-- confers nothing: corpus_anon reads the hidden table only if it holds its own
+-- grant on it (it does not, and it has no USAGE on the schema either), so
+-- there is no reach to report and L14 must stay silent. An out-of-scope
+-- *reference* is not a finding; an out-of-scope *reach* is.
+CREATE VIEW c_invoker_unaudited.subject_directory WITH (security_invoker = true) AS
+  SELECT subject FROM c_invoker_hidden.credentials;
+ALTER VIEW c_invoker_unaudited.subject_directory OWNER TO c_invoker_unaudited_owner;
+GRANT SELECT ON c_invoker_unaudited.subject_directory TO corpus_anon, corpus_user;

package/corpus/cases/39-definer-view-column-subset/case.json

@@ -0,0 +1,30 @@
+{
+  "title": "A definer view exposing only the columns the caller already holds is not a bypass",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_view_columns"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L13",
+      "relation": "c_view_columns.people",
+      "role": "corpus_anon",
+      "note": "the column grant itself is real reach, and L13 reports it — that is the baseline the definer view adds nothing to"
+    }
+  ],
+  "forbid": [
+    "L8"
+  ],
+  "worstSeverity": "info",
+  "fix": "Nothing. corpus_anon reads (id, handle) by column grant and the view returns exactly those columns of exactly those rows, so the owner's read launders nothing. Reporting L8 here would recommend rewriting a view that gives away nothing the ACL did not already give away.",
+  "id": "39-definer-view-column-subset"
+}

package/corpus/cases/39-definer-view-column-subset/schema.sql

@@ -0,0 +1,29 @@
+DROP SCHEMA IF EXISTS c_view_columns CASCADE;
+CREATE SCHEMA c_view_columns;
+
+DO $$ BEGIN
+  CREATE ROLE c_view_columns_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_view_columns TO corpus_anon, corpus_user, c_view_columns_owner;
+
+CREATE TABLE c_view_columns.people (
+  id bigserial PRIMARY KEY,
+  handle text NOT NULL,
+  email text NOT NULL,
+  ssn text NOT NULL
+);
+ALTER TABLE c_view_columns.people OWNER TO c_view_columns_owner;
+
+-- corpus_anon already reads these two columns, by column-level grant. No RLS,
+-- so the owner's read returns exactly the rows corpus_anon's own read would.
+GRANT SELECT (id, handle) ON c_view_columns.people TO corpus_anon;
+
+-- A definer view over the *same two columns* launders nothing: every value it
+-- returns was already readable by the caller. L8 must stay silent, which it
+-- can only do by knowing the projection, not just the relation.
+CREATE VIEW c_view_columns.handles AS
+  SELECT id, handle FROM c_view_columns.people;
+ALTER VIEW c_view_columns.handles OWNER TO c_view_columns_owner;
+GRANT SELECT ON c_view_columns.handles TO corpus_anon;

package/corpus/cases/39-policy-cast-with-expression-index/case.json

@@ -0,0 +1,23 @@
+{
+  "title": "A cast in a policy is fine when a matching expression index exists",
+  "dimension": "perf",
+  "exposure": {
+    "schemas": [
+      "c_policy_cast_indexed"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [],
+  "forbid": [
+    "X2",
+    "X3",
+    "X9"
+  ],
+  "fix": "Nothing to fix — this is case 19 fixed with an expression index rather than by moving the cast, and X3 must recognize the index it asked for."
+}

package/corpus/cases/39-policy-cast-with-expression-index/schema.sql

@@ -0,0 +1,19 @@
+DROP SCHEMA IF EXISTS c_policy_cast_indexed CASCADE;
+CREATE SCHEMA c_policy_cast_indexed;
+GRANT USAGE ON SCHEMA c_policy_cast_indexed TO corpus_user, corpus_anon;
+
+CREATE TABLE c_policy_cast_indexed.accounts (
+  id bigserial PRIMARY KEY,
+  tenant_id uuid NOT NULL,
+  email text
+);
+-- The expression index X3 asks for: it serves the cast comparison below,
+-- which a plain index on tenant_id could not.
+CREATE INDEX accounts_tenant_text_idx ON c_policy_cast_indexed.accounts ((tenant_id::text));
+ALTER TABLE c_policy_cast_indexed.accounts ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_policy_cast_indexed.accounts FORCE ROW LEVEL SECURITY;
+
+CREATE POLICY accounts_tenant ON c_policy_cast_indexed.accounts FOR SELECT TO corpus_user
+  USING (tenant_id::text = (SELECT current_setting('jwt.claims.tenant_id', true)));
+
+GRANT SELECT ON c_policy_cast_indexed.accounts TO corpus_user;