Foreign server, user mapping or subscription created with an embedded credential
Critical — a working credential committed to the repository; rotate it, git history keeps it.
What it catches
CREATE USER MAPPING … OPTIONS (password '…'), CREATE SERVER … OPTIONS (secret_key '…') and CREATE SUBSCRIPTION … CONNECTION 'host=… password=…' are the three places Postgres itself asks for a remote credential — and a migration is the wrong file to answer in. The value lands in git history, pull-request diffs and CI output, and pg_user_mappings / pg_subscription keep it readable to superusers afterwards. Silent when the option holds a placeholder, is empty, or points at a passfile / certificate instead.
Fires on
CREATE USER MAPPING FOR app_user SERVER analytics OPTIONS (user 'reporter', password 's3cret');Do this instead
Keep the object in the migration and the credential out of it: create the mapping or subscription connection from the deploy job with the value read from the secret store, or authenticate without a password — a client certificate (sslcert/sslkey) or a passfile on the server (passfile= in the conninfo, password_required 'false' on postgres_fdw mappings).
CREATE SERVER analytics FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 'analytics.internal', dbname 'reports');
CREATE USER MAPPING FOR app_user SERVER analytics OPTIONS (user 'reporter', password_required 'false');
-- and a certificate or passfile on the server, provisioned by the deploy, not committed. This rule runs locally in the free CLI — or with the full corpus through the hosted service: npx bolvrk check migration.sql