Skip to main content

SEC.SKIPPED.* — Part of the security reading was refused

  • Category: security
  • Level: 0
  • Stability: stable
  • Suites: audit
  • Applies to: PostgreSQL 18, MySQL 8.4

What this means​

The account SQLens connected with could not read part of the security catalog. Every check that would have judged that area is unanswered — not clean. The finding names the catalog and the reason, so you can decide whether to grant the read or to accept the gap.

One id per area, so a suppression survives a change of reason:

IdThe catalog it could not read
SEC.SKIPPED.PG.ROLESpg_roles — accounts and their attributes
SEC.SKIPPED.PG.AUTHIDpg_authid — password hash types
SEC.SKIPPED.PG.AUTH_MEMBERSpg_auth_members — role membership
SEC.SKIPPED.PG.ACLpg_class.relacl and friends — grants
SEC.SKIPPED.PG.POLICYpg_policy — row-level security policies
SEC.SKIPPED.MY.USERmysql.user — accounts and global privileges
SEC.SKIPPED.MY.GRANTSmysql.db and the other grant tables
SEC.SKIPPED.MY.ROLE_EDGESmysql.role_edges — role membership
SEC.SKIPPED.PG.HBApg_hba_file_rules — who may connect, from where, with which method
SEC.SKIPPED.PG.PROCpg_proc — which routines run with their owner's privileges
SEC.SKIPPED.MY.ROUTINESMySQL's stored routines — the same question, read from information_schema
SEC.SKIPPED.OTHERan area this build does not name — please report it

This is normal on a managed database, and it is not nothing​

RDS, Aurora, Cloud SQL and Neon all withhold parts of the security catalog from the account your application connects with. That is by design, and SQLens does not treat it as an alarm — but it also refuses to let the report read as a complete security answer when it is not.

The distinction matters most where it is least visible: a run that could not read pg_authid produces no findings about password hashes. Without this notice that is byte-for-byte identical to a run that read every account and found every hash modern.

What to do​

Grant the read if you can. On PostgreSQL the built-in role pg_read_all_settings and, on version 14+, pg_read_all_data cover most of it:

GRANT pg_read_all_data TO sqlens_auditor;

Or accept the gap and record that decision, so it stops appearing as news:

// config/sqlens.php — the baseline file, not a code change
'baseline' => ['path' => base_path('.sqlens-baseline.json')],

Suppressing by id suppresses that area, not the security suite: everything the account can read is still judged and still reported.

AUDIT.CATALOG.UNREAD.* is the same statement for the schema reading. The two cover disjoint readings, so no single refusal produces both — and they are separate families because the fixes differ: a schema gap is usually a grant somebody can make, where a security gap is often a provider policy nobody can.