<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>BareSQL Audit on BareSQL.com</title>
    <link>https://baresql.com/tags/baresql-audit/</link>
    <description>Recent content in BareSQL Audit on BareSQL.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 26 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://baresql.com/tags/baresql-audit/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>A Quarterly Access Review Finds a New Table of Bank Accounts That Every Role Can Read</title>
      <link>https://baresql.com/a-quarterly-access-review-finds-a-new-table-of-bank-accounts-that-every-role-can-read/</link>
      <pubDate>Mon, 26 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://baresql.com/a-quarterly-access-review-finds-a-new-table-of-bank-accounts-that-every-role-can-read/</guid>
      <description>&lt;p&gt;The shop in this case study is made up: it’s the sample shop database that BareSQL’s tests build, and the outputs are what BareSQL printed. It reviews database access once a quarter. The first review with BareSQL Audit covers every login and ends with a file kept for next time, &lt;code&gt;audit.json&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Three months later the review runs again against that file. The reviewer then reads what changed, with no need to compare two long reports by eye.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Support View Showed Card Numbers to Every Support Login</title>
      <link>https://baresql.com/a-support-view-showed-card-numbers-to-every-support-login/</link>
      <pubDate>Mon, 26 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://baresql.com/a-support-view-showed-card-numbers-to-every-support-login/</guid>
      <description>&lt;p&gt;This case study runs on the sample shop database that BareSQL’s tests build, so the shop is made up, and the outputs are what BareSQL printed. Its support team looks customers up through one view, &lt;code&gt;support.customer_lookup&lt;/code&gt;, and has no grant on the customers table itself, which sounds like the careful way to do it.&lt;/p&gt;&#xA;&lt;p&gt;The view was meant to show a name, an email address and a phone number, enough to help someone who calls in. At some point a column was added to it. The team has two logins, &lt;code&gt;shop_alice&lt;/code&gt; and &lt;code&gt;shop_bob&lt;/code&gt;. Bob is in the team without inheriting its rights, a setup often taken to mean he can’t read what the team reads.&lt;/p&gt;</description>
    </item>
    <item>
      <title>BareSQL Launches With an Access Audit for PostgreSQL and a Portability Check for SQL</title>
      <link>https://baresql.com/baresql-launches-with-an-access-audit-for-postgresql-and-a-portability-check-for-sql/</link>
      <pubDate>Mon, 26 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://baresql.com/baresql-launches-with-an-access-audit-for-postgresql-and-a-portability-check-for-sql/</guid>
      <description>&lt;p&gt;BareSQL is a free, open-source command-line program with two tools in it. BareSQL Audit lists every column each PostgreSQL login can read, with the route that gets it there, and marks the ones that hold personal data. BareSQL Portable finds the SQL that fails or answers differently on SQLite, PostgreSQL, MySQL and MariaDB. Version 0.1.0 is the first release.&lt;/p&gt;&#xA;&lt;p&gt;Who can read the customers&amp;rsquo; email addresses? In a PostgreSQL database the answer is spread over role memberships, grants made years ago, views that read tables with their owner’s rights, default privileges and row security policies. Working it out by hand means an afternoon with the system catalogs, and the answer is out of date the next time someone runs a GRANT. BareSQL Audit logs in, reads the catalogs inside a read-only transaction and writes the answer down: a report for people and a JSON file for the next audit to be compared with.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How BareSQL Audit Finds Every Column a PostgreSQL Login Can Read</title>
      <link>https://baresql.com/how-baresql-audit-finds-every-column-a-postgresql-login-can-read/</link>
      <pubDate>Mon, 26 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://baresql.com/how-baresql-audit-finds-every-column-a-postgresql-login-can-read/</guid>
      <description>&lt;p&gt;PostgreSQL keeps the answer to “who can read this column?” in many places. Grants sit in access lists on tables and on single columns. Role memberships nest, and since PostgreSQL 16 each one says separately whether its rights are inherited and whether SET ROLE is allowed. Views read their tables with their owner’s rights unless they say otherwise, row security policies filter what a table hands out, and default privileges hand out tables that don’t exist yet.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How BareSQL Audit Was Tested Against Planted Leaks on Six PostgreSQL Versions</title>
      <link>https://baresql.com/how-baresql-audit-was-tested-against-planted-leaks-on-six-postgresql-versions/</link>
      <pubDate>Mon, 26 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://baresql.com/how-baresql-audit-was-tested-against-planted-leaks-on-six-postgresql-versions/</guid>
      <description>&lt;p&gt;An access audit can be wrong in two directions. If it misses a route, a leak goes unnoticed because the report said all was well. If it invents one, people spend a day chasing access that was never there and stop trusting the report. So BareSQL Audit is tested against databases where every right answer is known in advance, and against the one judge that can’t be argued with, the PostgreSQL server itself.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What an AI Support Agent Could Read Before Its Database Login Went Live</title>
      <link>https://baresql.com/what-an-ai-support-agent-could-read-before-its-database-login-went-live/</link>
      <pubDate>Mon, 26 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://baresql.com/what-an-ai-support-agent-could-read-before-its-database-login-went-live/</guid>
      <description>&lt;p&gt;This case study runs on the sample multi-tenant database that BareSQL’s tests build. The software company in it is made up: it runs one PostgreSQL database for all its customers, the tenants, and row security keeps each tenant’s rows apart. Every output below is what BareSQL printed.&lt;/p&gt;&#xA;&lt;p&gt;The support team wants an AI agent to answer tickets, so the agent gets a login of its own, &lt;code&gt;saas_agent&lt;/code&gt;, in the &lt;code&gt;saas_support&lt;/code&gt; group that support’s views are granted to. The views were written for people, months ago, and nobody remembers exactly what they return. So before the login goes live, the team audits that one login.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
