@safegres/test 0.0.2 → 1.30.7

package/corpus/cases/40-definer-view-column-overreach/case.json

@@ -0,0 +1,27 @@
+{
+  "title": "One column past the caller's grant, and the same shape is a definer-view bypass",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_view_columns_wide"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L8",
+      "relation": "c_view_columns_wide.people",
+      "role": "corpus_anon",
+      "note": "`email` is in no grant corpus_anon holds; the finding names the escaping columns, so the report says which ones"
+    }
+  ],
+  "worstSeverity": "info",
+  "fix": "Narrow c_view_columns_wide.contacts to the columns the caller is entitled to, recreate it `WITH (security_invoker = true)`, or give it an owner whose reach matches what it is meant to expose. Do not revoke the column grants — they are what the narrow projection legitimately serves.",
+  "id": "40-definer-view-column-overreach"
+}

package/corpus/cases/40-definer-view-column-overreach/schema.sql

@@ -0,0 +1,29 @@
+DROP SCHEMA IF EXISTS c_view_columns_wide CASCADE;
+CREATE SCHEMA c_view_columns_wide;
+
+DO $$ BEGIN
+  CREATE ROLE c_view_columns_wide_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_view_columns_wide TO corpus_anon, corpus_user, c_view_columns_wide_owner;
+
+CREATE TABLE c_view_columns_wide.people (
+  id bigserial PRIMARY KEY,
+  handle text NOT NULL,
+  email text NOT NULL,
+  ssn text NOT NULL
+);
+ALTER TABLE c_view_columns_wide.people OWNER TO c_view_columns_wide_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_wide.people TO corpus_anon;
+
+-- One column past the grant, and the view is a bypass: `email` escapes only
+-- because the read runs as the owner. The projection is the whole difference
+-- between this case and case 39.
+CREATE VIEW c_view_columns_wide.contacts AS
+  SELECT id, handle, email FROM c_view_columns_wide.people;
+ALTER VIEW c_view_columns_wide.contacts OWNER TO c_view_columns_wide_owner;
+GRANT SELECT ON c_view_columns_wide.contacts TO corpus_anon;

package/corpus/cases/40-stable-function-hoisted/case.json

@@ -0,0 +1,23 @@
+{
+  "title": "A STABLE policy function wrapped in a scalar sub-select is hoisted",
+  "dimension": "perf",
+  "exposure": {
+    "schemas": [
+      "c_stable_hoisted"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [],
+  "forbid": [
+    "X2",
+    "X4",
+    "X9"
+  ],
+  "fix": "Nothing to fix — this is case 20 fixed: the sub-select references no column, so the planner evaluates it once per query."
+}

package/corpus/cases/40-stable-function-hoisted/schema.sql

@@ -0,0 +1,25 @@
+DROP SCHEMA IF EXISTS c_stable_hoisted CASCADE;
+CREATE SCHEMA c_stable_hoisted;
+GRANT USAGE ON SCHEMA c_stable_hoisted TO corpus_user, corpus_anon;
+
+-- LEAKPROOF as well as STABLE: reading a GUC and casting it tells a caller
+-- nothing about any row, and without the marking X4 would fire here on top of
+-- the X9 this case is about.
+CREATE FUNCTION c_stable_hoisted.current_tenant() RETURNS uuid
+  LANGUAGE sql STABLE LEAKPROOF AS $$
+    SELECT nullif(current_setting('jwt.claims.tenant_id', true), '')::uuid
+  $$;
+
+CREATE TABLE c_stable_hoisted.ledger (
+  id bigserial PRIMARY KEY,
+  tenant_id uuid NOT NULL,
+  amount numeric
+);
+CREATE INDEX ledger_tenant_idx ON c_stable_hoisted.ledger (tenant_id);
+ALTER TABLE c_stable_hoisted.ledger ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_stable_hoisted.ledger FORCE ROW LEVEL SECURITY;
+
+CREATE POLICY ledger_tenant ON c_stable_hoisted.ledger FOR SELECT TO corpus_user
+  USING (tenant_id = (SELECT c_stable_hoisted.current_tenant()));
+
+GRANT SELECT ON c_stable_hoisted.ledger TO corpus_user;

package/corpus/cases/41-index-prefix-not-redundant/case.json

@@ -0,0 +1,21 @@
+{
+  "title": "A single-column index is not redundant with a composite that ends in it",
+  "dimension": "perf",
+  "exposure": {
+    "schemas": [
+      "c_index_not_redundant"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [],
+  "forbid": [
+    "X5"
+  ],
+  "fix": "Nothing to fix — dropping either index costs a plan. X5 may only fire on a leading-column prefix, and (tenant_id) is not a prefix of (region, tenant_id)."
+}

package/corpus/cases/41-index-prefix-not-redundant/schema.sql

@@ -0,0 +1,15 @@
+DROP SCHEMA IF EXISTS c_index_not_redundant CASCADE;
+CREATE SCHEMA c_index_not_redundant;
+GRANT USAGE ON SCHEMA c_index_not_redundant TO corpus_user, corpus_anon;
+
+CREATE TABLE c_index_not_redundant.shipments (
+  id bigserial PRIMARY KEY,
+  tenant_id uuid NOT NULL,
+  region text NOT NULL
+);
+-- Neither index covers the other: tenant_id leads the first and trails the
+-- second, so only the first can serve a lookup by tenant alone.
+CREATE INDEX shipments_tenant_idx ON c_index_not_redundant.shipments (tenant_id);
+CREATE INDEX shipments_region_tenant_idx ON c_index_not_redundant.shipments (region, tenant_id);
+
+GRANT SELECT ON c_index_not_redundant.shipments TO corpus_user;

package/corpus/cases/41-unreadable-view-body/case.json

@@ -0,0 +1,33 @@
+{
+  "title": "A definer view whose body runs SQL of its own is reported as a gap, not scanned clean",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_unreadable_view"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L15",
+      "relation": "c_unreadable_view.activity",
+      "role": "corpus_anon",
+      "note": "`query_to_xml` carries its query in a string, so the relations it reaches are unknowable here — the reach is proven and its far end is not"
+    },
+    {
+      "code": "L8",
+      "relation": "c_unreadable_view.ledger",
+      "role": "corpus_anon",
+      "note": "the half the analysis *could* read is still graded: taint suppresses nothing that was proven"
+    }
+  ],
+  "worstSeverity": "info",
+  "fix": "Rewrite the body so the relations it reads are visible statically — a plain sub-select instead of `query_to_xml` — or satisfy yourself that what it returns is safe to serve corpus_anon. The gap is in what the audit could see, not proof of a leak, so nothing here justifies a revoke.",
+  "id": "41-unreadable-view-body"
+}

package/corpus/cases/41-unreadable-view-body/schema.sql

@@ -0,0 +1,28 @@
+DROP SCHEMA IF EXISTS c_unreadable_view CASCADE;
+CREATE SCHEMA c_unreadable_view;
+
+DO $$ BEGIN
+  CREATE ROLE c_unreadable_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_unreadable_view TO corpus_anon, corpus_user, c_unreadable_owner;
+
+CREATE TABLE c_unreadable_view.ledger (
+  id bigserial PRIMARY KEY,
+  subject text NOT NULL,
+  amount numeric NOT NULL
+);
+ALTER TABLE c_unreadable_view.ledger OWNER TO c_unreadable_owner;
+
+-- A definer view that reads one relation the analysis can see and one it
+-- cannot: `query_to_xml` takes its query as a *string*, so whatever it
+-- touches is invisible to any AST walk. The ledger read is still graded (L8);
+-- the part that cannot be followed is reported as a coverage gap (L15) rather
+-- than being silently treated as "reaches nothing else".
+CREATE VIEW c_unreadable_view.activity AS
+  SELECT l.id, l.subject,
+         query_to_xml('SELECT count(*) FROM c_unreadable_view.ledger', false, true, '') AS extra
+  FROM c_unreadable_view.ledger l;
+ALTER VIEW c_unreadable_view.activity OWNER TO c_unreadable_owner;
+GRANT SELECT ON c_unreadable_view.activity TO corpus_anon;

package/corpus/cases/42-invoker-view-unreadable-body/case.json

@@ -0,0 +1,30 @@
+{
+  "title": "An invoker view with the same unreadable body confers nothing, so there is no gap to report",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_invoker_unreadable"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "A2",
+      "relation": "c_invoker_unreadable.ledger",
+      "note": "the real finding here, and unrelated to the view: a grant on a table with no RLS"
+    }
+  ],
+  "forbid": [
+    "L15",
+    "L8"
+  ],
+  "worstSeverity": "high",
+  "fix": "Enable RLS on c_invoker_unreadable.ledger. The view needs no fix: `security_invoker` means the body runs with the caller's own privileges, so an unreadable body confers nothing and reporting a coverage gap on it would make every view calling a SQL-executing function into noise.",
+  "id": "42-invoker-view-unreadable-body"
+}

package/corpus/cases/42-invoker-view-unreadable-body/schema.sql

@@ -0,0 +1,27 @@
+DROP SCHEMA IF EXISTS c_invoker_unreadable CASCADE;
+CREATE SCHEMA c_invoker_unreadable;
+
+DO $$ BEGIN
+  CREATE ROLE c_invoker_unreadable_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_invoker_unreadable TO corpus_anon, corpus_user, c_invoker_unreadable_owner;
+
+CREATE TABLE c_invoker_unreadable.ledger (
+  id bigserial PRIMARY KEY,
+  subject text NOT NULL
+);
+ALTER TABLE c_invoker_unreadable.ledger OWNER TO c_invoker_unreadable_owner;
+GRANT SELECT ON c_invoker_unreadable.ledger TO corpus_anon;
+
+-- The same unreadable body, with `security_invoker`. Nothing the body does
+-- runs with privileges corpus_anon does not already have, so there is no
+-- ungraded owner-privileged reach to report. An unreadable body is only a
+-- coverage gap when the view confers something.
+CREATE VIEW c_invoker_unreadable.activity WITH (security_invoker = true) AS
+  SELECT l.id,
+         query_to_xml('SELECT count(*) FROM c_invoker_unreadable.ledger', false, true, '') AS extra
+  FROM c_invoker_unreadable.ledger l;
+ALTER VIEW c_invoker_unreadable.activity OWNER TO c_invoker_unreadable_owner;
+GRANT SELECT ON c_invoker_unreadable.activity TO corpus_anon;

package/corpus/cases/42-search-column-indexed/case.json

@@ -0,0 +1,21 @@
+{
+  "title": "A tsvector column with a GIN index is not a finding",
+  "dimension": "perf",
+  "exposure": {
+    "schemas": [
+      "c_search_indexed"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [],
+  "forbid": [
+    "X7"
+  ],
+  "fix": "Nothing to fix — this is case 23 fixed, and the index is the one full-text search can actually use."
+}

package/corpus/cases/42-search-column-indexed/schema.sql

@@ -0,0 +1,12 @@
+DROP SCHEMA IF EXISTS c_search_indexed CASCADE;
+CREATE SCHEMA c_search_indexed;
+GRANT USAGE ON SCHEMA c_search_indexed TO corpus_user, corpus_anon;
+
+CREATE TABLE c_search_indexed.articles (
+  id bigserial PRIMARY KEY,
+  body text,
+  search_doc tsvector
+);
+CREATE INDEX articles_search_idx ON c_search_indexed.articles USING gin (search_doc);
+
+GRANT SELECT ON c_search_indexed.articles TO corpus_user;

package/corpus/cases/43-anon-sequence-grant/case.json

@@ -0,0 +1,27 @@
+{
+  "title": "An untrusted role holds privileges on a sequence, which no policy filters",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_seq_grant"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L16",
+      "relation": "c_seq_grant.invoice_number",
+      "role": "corpus_anon",
+      "note": "USAGE is `nextval`/`setval` and SELECT is `last_value`; the table beside it is fully RLS-protected, and none of that protection reaches the sequence"
+    }
+  ],
+  "worstSeverity": "info",
+  "fix": "Nothing here is row-filterable, so the question is whether corpus_anon needs the sequence at all. This one feeds no column (no `OWNED BY`), so no insert depends on it — but confirm a DEFAULT elsewhere does not name it before revoking. Where a serial column is involved, `GENERATED ... AS IDENTITY` removes the need for the grant instead of breaking the insert.",
+  "id": "43-anon-sequence-grant"
+}

package/corpus/cases/43-anon-sequence-grant/schema.sql

@@ -0,0 +1,23 @@
+DROP SCHEMA IF EXISTS c_seq_grant CASCADE;
+CREATE SCHEMA c_seq_grant;
+
+GRANT USAGE ON SCHEMA c_seq_grant TO corpus_anon, corpus_user;
+
+-- A free-standing sequence: nothing inserts through it, so the grant is not
+-- load-bearing for any write path. USAGE lets corpus_anon burn the counter
+-- and SELECT lets it read `last_value`. RLS has nothing to say about either:
+-- a sequence cannot carry a policy.
+CREATE SEQUENCE c_seq_grant.invoice_number;
+GRANT USAGE, SELECT ON SEQUENCE c_seq_grant.invoice_number TO corpus_anon;
+
+CREATE TABLE c_seq_grant.invoices (
+  id bigserial PRIMARY KEY,
+  subject text NOT NULL
+);
+ALTER TABLE c_seq_grant.invoices ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_seq_grant.invoices FORCE ROW LEVEL SECURITY;
+CREATE POLICY invoices_own ON c_seq_grant.invoices
+  FOR SELECT TO corpus_user
+  USING (subject = (SELECT current_setting('app.subject', true)));
+CREATE INDEX invoices_subject_idx ON c_seq_grant.invoices (subject);
+GRANT SELECT ON c_seq_grant.invoices TO corpus_user;

package/corpus/cases/44-serial-sequence-usage/case.json

@@ -0,0 +1,27 @@
+{
+  "title": "The same grant on a sequence that backs a serial insert path",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_seq_serial"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L16",
+      "relation": "c_seq_serial.tickets_id_seq",
+      "role": "corpus_anon",
+      "note": "reported with the column it feeds, which is what turns the advice from `REVOKE` into `AS IDENTITY`: a `serial` column cannot be written by any role without USAGE on its sequence"
+    }
+  ],
+  "worstSeverity": "info",
+  "fix": "Establish whether corpus_anon writes c_seq_serial.tickets before touching this grant — a `serial` column cannot be inserted without USAGE on its sequence, so a revoke on the wrong assumption breaks the write path rather than closing a hole. Converting the column to `GENERATED ALWAYS AS IDENTITY` removes the need for any grant on the sequence, which is the fix that does not trade one break for another.",
+  "id": "44-serial-sequence-usage"
+}

package/corpus/cases/44-serial-sequence-usage/schema.sql

@@ -0,0 +1,25 @@
+DROP SCHEMA IF EXISTS c_seq_serial CASCADE;
+CREATE SCHEMA c_seq_serial;
+
+GRANT USAGE ON SCHEMA c_seq_serial TO corpus_anon, corpus_user;
+
+-- The load-bearing shape: `tickets.id` is a `serial`, so the sequence backs a
+-- real insert path and USAGE on it is a prerequisite for writing the table,
+-- not an ornament. corpus_anon holds that USAGE. Whether it is gratuitous or
+-- required depends on a write path the ACL alone does not show, which is
+-- exactly why the finding must carry the OWNED BY link and must not turn into
+-- a revoke recommendation.
+CREATE TABLE c_seq_serial.tickets (
+  id bigserial PRIMARY KEY,
+  subject text NOT NULL
+);
+ALTER TABLE c_seq_serial.tickets ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_seq_serial.tickets FORCE ROW LEVEL SECURITY;
+CREATE POLICY tickets_own ON c_seq_serial.tickets
+  FOR ALL TO corpus_user
+  USING (subject = (SELECT current_setting('app.subject', true)))
+  WITH CHECK (subject = (SELECT current_setting('app.subject', true)));
+CREATE INDEX tickets_subject_idx ON c_seq_serial.tickets (subject);
+
+GRANT SELECT, INSERT ON c_seq_serial.tickets TO corpus_user;
+GRANT USAGE ON SEQUENCE c_seq_serial.tickets_id_seq TO corpus_anon;

package/corpus/cases/45-anon-foreign-table/case.json

@@ -0,0 +1,27 @@
+{
+  "title": "A grant on a foreign table, where RLS is not merely absent but impossible",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_foreign_grant"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L17",
+      "relation": "c_foreign_grant.remote_customers",
+      "role": "corpus_anon",
+      "note": "the table snapshot reads relkind 'r'/'p' and never saw this relation at all, so no rule graded the grant before"
+    }
+  ],
+  "worstSeverity": "info",
+  "fix": "Expose the foreign table through a view that carries the filter and grant on the view instead, or push the filter to the remote side. Adding RLS is not an option here — Postgres refuses it on a foreign table — so the usual A2 remedy does not apply.",
+  "id": "45-anon-foreign-table"
+}

package/corpus/cases/45-anon-foreign-table/schema.sql

@@ -0,0 +1,23 @@
+DROP SCHEMA IF EXISTS c_foreign_grant CASCADE;
+CREATE SCHEMA c_foreign_grant;
+
+GRANT USAGE ON SCHEMA c_foreign_grant TO corpus_anon, corpus_user;
+
+CREATE EXTENSION IF NOT EXISTS postgres_fdw;
+
+DO $$ BEGIN
+  CREATE SERVER c_foreign_grant_srv FOREIGN DATA WRAPPER postgres_fdw
+    OPTIONS (host 'localhost', dbname 'postgres');
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+-- A foreign table cannot carry RLS: Postgres rejects
+-- `ALTER FOREIGN TABLE ... ENABLE ROW LEVEL SECURITY` outright. So unlike the
+-- A2 shape it resembles, the remedy "add a policy" does not exist, and every
+-- row the remote side returns is returned to corpus_anon.
+CREATE FOREIGN TABLE c_foreign_grant.remote_customers (
+  id int,
+  email text
+) SERVER c_foreign_grant_srv OPTIONS (schema_name 'public', table_name 'customers');
+
+GRANT SELECT ON c_foreign_grant.remote_customers TO corpus_anon;

package/corpus/cases/46-unchecked-writable-view/case.json

@@ -0,0 +1,41 @@
+{
+  "title": "A writable view's row filter is a read filter: no WITH CHECK OPTION, so writes escape it",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_unchecked_view_write"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L18",
+      "relation": "c_unchecked_view_write.notes",
+      "note": "the view filters on `tenant` and carries no WITH CHECK OPTION, so corpus_anon's INSERT/UPDATE through it stores rows for any tenant \u2014 rows the view will not then show it"
+    },
+    {
+      "code": "L9",
+      "relation": "c_unchecked_view_write.notes",
+      "note": "the same view is auto-updatable and not security_invoker, so the write reaches `notes` as c_unchecked_write_owner at all \u2014 L9 is *whether* the write lands, L18 is whether the view's own condition constrains it"
+    },
+    {
+      "code": "A3",
+      "relation": "c_unchecked_view_write.notes",
+      "note": "RLS is not FORCEd, which is why the owner's rewritten write is not filtered by the table's own policy either"
+    }
+  ],
+  "forbid": [
+    "L8",
+    "L10",
+    "L11",
+    "L12"
+  ],
+  "worstSeverity": "low",
+  "fix": "Recreate c_unchecked_view_write.tenant_notes WITH LOCAL CHECK OPTION so a row written through it must satisfy the condition it is served under, or put the tenant predicate in an RLS policy's WITH CHECK clause on `notes`, which applies however the row arrives. Do not revoke corpus_anon's INSERT on the view \u2014 that grant is what the API serves."
+}

package/corpus/cases/46-unchecked-writable-view/schema.sql

@@ -0,0 +1,37 @@
+DROP SCHEMA IF EXISTS c_unchecked_view_write CASCADE;
+CREATE SCHEMA c_unchecked_view_write;
+
+DO $$ BEGIN
+  CREATE ROLE c_unchecked_write_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_unchecked_view_write TO corpus_anon, corpus_user, c_unchecked_write_owner;
+
+CREATE TABLE c_unchecked_view_write.notes (
+  id bigserial PRIMARY KEY,
+  tenant text NOT NULL,
+  body text NOT NULL
+);
+ALTER TABLE c_unchecked_view_write.notes OWNER TO c_unchecked_write_owner;
+ALTER TABLE c_unchecked_view_write.notes ENABLE ROW LEVEL SECURITY;
+
+CREATE POLICY notes_own_tenant ON c_unchecked_view_write.notes
+  FOR ALL TO corpus_user
+  USING (tenant = (SELECT current_setting('app.tenant', true)))
+  WITH CHECK (tenant = (SELECT current_setting('app.tenant', true)));
+CREATE INDEX notes_tenant_idx ON c_unchecked_view_write.notes (tenant);
+GRANT SELECT, INSERT ON c_unchecked_view_write.notes TO corpus_user;
+GRANT USAGE ON SEQUENCE c_unchecked_view_write.notes_id_seq TO corpus_user;
+
+-- The flaw: the view's `WHERE` decides which rows come *out* and nothing about
+-- which rows go *in*. `WITH CHECK OPTION` is not the default, so an INSERT
+-- through this view may name any tenant at all — the row lands in `notes`,
+-- checked against the view's owner, and the writer cannot then see it. The
+-- condition reads like a boundary and is not one.
+CREATE VIEW c_unchecked_view_write.tenant_notes AS
+  SELECT id, tenant, body
+  FROM c_unchecked_view_write.notes
+  WHERE tenant = current_setting('app.tenant', true);
+ALTER VIEW c_unchecked_view_write.tenant_notes OWNER TO c_unchecked_write_owner;
+GRANT INSERT, UPDATE ON c_unchecked_view_write.tenant_notes TO corpus_anon;

package/corpus/cases/47-checked-writable-view/case.json

@@ -0,0 +1,37 @@
+{
+  "title": "The same writable view WITH LOCAL CHECK OPTION constrains its writes, and L18 stays silent",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_checked_view_write"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L9",
+      "relation": "c_checked_view_write.notes",
+      "note": "the write still reaches `notes` as the view's owner \u2014 the check option constrains which rows may be written, not whose privileges write them"
+    },
+    {
+      "code": "A3",
+      "relation": "c_checked_view_write.notes",
+      "note": "RLS is still not FORCEd, unchanged from case 46"
+    }
+  ],
+  "forbid": [
+    "L18",
+    "L8",
+    "L10",
+    "L11",
+    "L12"
+  ],
+  "worstSeverity": "low",
+  "fix": "Nothing on the check option. This case is case 46 after its fix, and exists to pin that L18 stops firing once the view's condition governs writes as well as reads."
+}

package/corpus/cases/47-checked-writable-view/schema.sql

@@ -0,0 +1,38 @@
+DROP SCHEMA IF EXISTS c_checked_view_write CASCADE;
+CREATE SCHEMA c_checked_view_write;
+
+DO $$ BEGIN
+  CREATE ROLE c_checked_write_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_checked_view_write TO corpus_anon, corpus_user, c_checked_write_owner;
+
+CREATE TABLE c_checked_view_write.notes (
+  id bigserial PRIMARY KEY,
+  tenant text NOT NULL,
+  body text NOT NULL
+);
+ALTER TABLE c_checked_view_write.notes OWNER TO c_checked_write_owner;
+ALTER TABLE c_checked_view_write.notes ENABLE ROW LEVEL SECURITY;
+
+CREATE POLICY notes_own_tenant ON c_checked_view_write.notes
+  FOR ALL TO corpus_user
+  USING (tenant = (SELECT current_setting('app.tenant', true)))
+  WITH CHECK (tenant = (SELECT current_setting('app.tenant', true)));
+CREATE INDEX notes_tenant_idx ON c_checked_view_write.notes (tenant);
+GRANT SELECT, INSERT ON c_checked_view_write.notes TO corpus_user;
+GRANT USAGE ON SEQUENCE c_checked_view_write.notes_id_seq TO corpus_user;
+
+-- Case 46 with the one clause that makes the filter apply to writes: a row
+-- written through the view must satisfy the view's own condition. L18 must
+-- stay silent. L9 still fires — the write does still land on `notes` as the
+-- view's owner, which is what the view is for; the check option only settles
+-- *which* rows may be written.
+CREATE VIEW c_checked_view_write.tenant_notes AS
+  SELECT id, tenant, body
+  FROM c_checked_view_write.notes
+  WHERE tenant = current_setting('app.tenant', true)
+  WITH LOCAL CHECK OPTION;
+ALTER VIEW c_checked_view_write.tenant_notes OWNER TO c_checked_write_owner;
+GRANT INSERT, UPDATE ON c_checked_view_write.tenant_notes TO corpus_anon;

package/corpus/cases/48-definer-function-reach/case.json

@@ -0,0 +1,38 @@
+{
+  "title": "Anonymous role reads a locked table by executing a SECURITY DEFINER function",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_definer_fn"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L19",
+      "relation": "c_definer_fn.secrets",
+      "role": "corpus_anon",
+      "note": "the body runs as c_definer_fn_owner, who owns `secrets`, so corpus_anon reads every row through EXECUTE alone — a privilege no ACL entry on the table confers on it"
+    },
+    {
+      "code": "A3",
+      "relation": "c_definer_fn.secrets",
+      "note": "RLS is not FORCEd, which is why the owner's read inside the body is not filtered by the table's own policy"
+    }
+  ],
+  "forbid": [
+    "L8",
+    "L9",
+    "L15",
+    "L20"
+  ],
+  "worstSeverity": "low",
+  "fix": "Narrow the body to what the function is meant to expose, authorize the caller inside it, or give the function an owner whose reach matches its job — and make it SECURITY INVOKER if the hand-off of c_definer_fn_owner's privileges was not intended. Revoking EXECUTE is not the fix: that grant is what the API serves.",
+  "id": "48-definer-function-reach"
+}