Database security posture: TLS, auth, grants, audit logs and encryption

A database's security posture comes down to five settings you can check and prove: whether every connection uses TLS that the client actually verifies, how users and services authenticate, which roles hold which grants, whether connections and privileged statements are logged somewhere the database owner cannot quietly edit, and whether data is encrypted at rest with keys you control. PostgreSQL, MySQL and MongoDB each leave at least one of these loose in a default install, so the job is to set each one on purpose, record what you set, and check it again on a schedule. This guide walks through all five, engine by engine, with the settings and queries from each vendor's own documentation, then shows where Safeguard reads the same posture for managed databases and turns it into compliance evidence.

Key takeaways

• Five controls make up database posture: transport encryption (TLS with certificate verification), authentication method, grants and least privilege, audit logging, and encryption at rest. Each engine names them differently, but the questions are the same.
• Server side TLS is not enough on its own. A PostgreSQL client in the default prefer mode will fall back to an unencrypted connection, and only verify-full checks that the server is who it claims to be.
• Self-managed MongoDB starts with access control disabled. Turning on security.authorization is the first change, before any role design.
• A general query log is not an audit log. PostgreSQL's audit extension (pgAudit), MySQL Enterprise Audit and MongoDB's auditing feature are the tools built for that job, and the last two belong to commercial editions.
• PostgreSQL has no built-in transparent data encryption; at-rest protection comes from the filesystem, the block device or the managed service. MySQL InnoDB and MongoDB's encrypted storage engine encrypt at the database layer.
• Safeguard's Database Security Posture integration (GA) checks a live database for TLS, auth rules, grants, audit logging and encryption at rest, per its Integrations page card.
• Safeguard's Compliance and GRC suite (GA) connects to managed databases such as MongoDB Atlas, Supabase, PlanetScale and Redis Cloud with read-only credentials, runs automated compliance tests, and maps passing results to SOC 2, ISO/IEC 27001, HIPAA, PCI DSS and NIST CSF 2.0 controls as evidence.
• Safeguard DSPM (GA) records encryption status and public exposure for Amazon RDS, and joins each data store with who can reach it.
• Policies and gates (GA) turn findings into Block, Warn or Notify outcomes, with approval handled through exceptions.

The situation

The trigger is usually a request with a date on it. An auditor opens the SOC 2 or PCI DSS fieldwork list and asks for evidence that cardholder or health data is encrypted in transit and at rest, that access to production databases is limited and reviewed, and that privileged activity is logged. A customer security questionnaire asks the same questions in a different order. Or a new platform lead inherits a fleet of databases and wants to know, before anyone else asks, which of them would fail.

Two people usually carry this: the platform engineer or DBA, who knows where the settings live, and the GRC lead, who knows which control each setting answers. They need the same facts in two shapes, a configuration to change and a record to keep.

A bad week looks like this. Someone pastes screenshots of postgresql.conf into a shared folder. A read replica that was built from an old image still has ssl = off. A reporting service account turns out to hold superuser because it was easier during a migration two years ago. The audit log setting is on in staging and off in production. Nobody can say when encryption at rest was last confirmed on the managed cluster, because it was "on by default" and never written down. Each of these is a small fix. Finding them all under deadline is the hard part.

What the rules ask for

None of the major frameworks name a database engine, but they all reach the same five settings. The clause numbers below come from the primary texts.

HIPAA Security Rule (45 CFR 164.312). The technical safeguards for electronic protected health information include access control at 164.312(a)(1), with encryption and decryption as an addressable specification at 164.312(a)(2)(iv); audit controls at 164.312(b), which call for mechanisms that record and examine activity in systems containing ePHI; person or entity authentication at 164.312(d); and transmission security at 164.312(e)(1), with encryption as an addressable specification at 164.312(e)(2)(ii). "Addressable" does not mean optional. It means you either implement the specification or document why an equivalent measure is reasonable.

NIST SP 800-53 Rev. 5. The control catalog gives the federal vocabulary most other frameworks borrow. AC-6 is least privilege. AU-2 (event logging) and AU-12 (audit record generation) cover what gets logged and where. IA-2 covers identification and authentication of organizational users, and IA-5 covers authenticator management, including how passwords are stored. SC-8 is transmission confidentiality and integrity, and SC-28 is protection of information at rest.

NIST SP 800-52 Rev. 2. This is NIST's guideline for selecting and configuring TLS. It requires that all government TLS servers and clients support TLS 1.2 configured with FIPS-based cipher suites, and that they support TLS 1.3 by 1 January 2024. That is a useful anchor when you pick a minimum protocol version for a database listener.

PCI DSS v4.0. Five requirement families reach a database. Requirement 3 protects stored account data, Requirement 4 protects cardholder data in transmission over open, public networks, Requirement 7 restricts access by business need to know, Requirement 8 covers identifying users and authenticating access, and Requirement 10 covers logging and monitoring. Safeguard's connector pages, covered later, map database tests to specific sub-requirements in these families, such as 3.5.1, 4.2.1, 7.2.2, 8.4.2 and 10.2.1. Read each one in the standard itself before you write a control narrative around it.

SOC 2 Trust Services Criteria. The logical and physical access criteria (the CC6 series) and the system operations criteria (the CC7 series) are where database settings land, and Safeguard's connector pages map database tests to IDs such as CC6.1, CC6.6, CC6.7 and CC7.2. A SOC 2 auditor will usually want to see the setting, the evidence that it held across the period, and the review that would catch it if it changed.

The pattern is consistent. Every framework wants the control in place, evidence that it stayed in place, and a review. The engine settings below are the first part. A repeatable check is the second and third.

The five controls, engine by engine

Each subsection lists the setting, how to check it, and the trap that catches teams most often.

1. TLS for every connection, verified by the client

Transport encryption has two halves. The server must offer TLS and refuse plaintext, and the client must insist on TLS and check the server's certificate. Teams usually do the first half and forget the second.

PostgreSQL. Turn on TLS in postgresql.conf with ssl = on, and point ssl_cert_file and ssl_key_file at the server certificate and key. The ssl_min_protocol_version parameter sets the lowest protocol the server will accept, and its default is TLS 1.2. Refusing plaintext happens in pg_hba.conf: a hostssl line matches only TLS connections, hostnossl matches only plaintext ones, and the first matching line wins. A common pattern is to accept hostssl for application networks and add a hostnossl line with the reject method before any broader host line.

# pg_hba.conf (sketch, adjust networks and databases)
hostnossl all all 0.0.0.0/0      reject
hostssl   app app_user 10.0.0.0/8 scram-sha-256

On the client side, libpq's sslmode decides what happens. The default is prefer, which tries TLS and falls back to plaintext if the server does not offer it. require insists on encryption but does not check the certificate. verify-ca checks that the certificate chains to a trusted root, and verify-full also checks that the host name matches. PostgreSQL's documentation is blunt that the default prefer "makes no sense from a security point of view" and exists for backward compatibility; verify-full is the mode that confirms you reached the server you named. To see which current sessions actually use TLS, query the pg_stat_ssl view, which reports a row per backend with whether TLS is in use, the protocol version and the cipher.

SELECT pid, ssl, version, cipher FROM pg_stat_ssl;
SHOW ssl;
SHOW ssl_min_protocol_version;

MySQL. MySQL servers support encrypted connections by default and will generate certificate files at startup if none are configured, but they still accept unencrypted connections unless you say otherwise. The require_secure_transport system variable makes the server reject any connection that is not using a secure transport. The tls_version variable controls which protocol versions the server permits. Per account, CREATE USER and ALTER USER accept REQUIRE SSL or the stricter REQUIRE X509. On the client, --ssl-mode behaves much like libpq: PREFERRED is the default, REQUIRED encrypts without checking the certificate, VERIFY_CA checks the chain and VERIFY_IDENTITY also checks the host name.

SHOW GLOBAL VARIABLES LIKE 'require_secure_transport';
SHOW GLOBAL VARIABLES LIKE 'tls_version';
SHOW SESSION STATUS LIKE 'Ssl_version';

MongoDB. On a self-managed deployment, set net.tls.mode to requireTLS so the server uses and accepts only TLS connections, and set net.tls.certificateKeyFile to the server's certificate and key. net.bindIp controls which interfaces the server listens on; MongoDB binaries bind to localhost by default, so a server that is reachable from the network was opened on purpose. To refuse older protocols, list them in net.tls.disabledProtocols. MongoDB Atlas requires TLS to encrypt connections to your databases, and issues and rotates the cluster certificates itself.

The trap. A server that requires TLS while the client uses prefer, PREFERRED or an unverified require still leaves the connection open to interception by anything that can present a certificate. Check connection strings and driver settings in application code and secrets stores, not just the server.

2. Authentication

Authentication posture is about the method in use, where credentials are stored, and whether any path skips authentication altogether.

PostgreSQL. The method column in pg_hba.conf decides how each connection authenticates. trust lets anyone who matches the line connect as any user without a password, and it should not appear on any line that matches a network address. scram-sha-256 is the password method to use; password_encryption defaults to scram-sha-256, so new passwords are stored as SCRAM verifiers. PostgreSQL's documentation warns that support for MD5-encrypted passwords is deprecated and will be removed in a future release, so any role still stored as MD5 is a migration item. cert authenticates clients by their TLS certificate: the server compares the certificate's common name with the requested database user, and a user name map can bridge the two when they differ.

SHOW password_encryption;
SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';
SELECT type, database, user_name, address, auth_method FROM pg_hba_file_rules;

The pg_hba_file_rules view shows the parsed contents of pg_hba.conf, which is a better source than reading the file by hand, because it shows what the server actually loaded. Reading pg_authid requires superuser.

MySQL. caching_sha2_password is the default authentication plugin in MySQL 8.4. MySQL's documentation says mysql_native_password is deprecated as of MySQL 8.0.34, disabled by default in MySQL 8.4, and removed as of MySQL 9.0.0. Accounts still using it are a migration item, not just a posture item, because they will stop working on upgrade.

SELECT user, host, plugin FROM mysql.user;
SELECT user, host FROM mysql.user WHERE authentication_string = '';

MongoDB. MongoDB's documentation says it does not enable access control by default. Set security.authorization: enabled in the configuration file (or start mongod with --auth), then create users. Community Edition supports SCRAM (prefer SCRAM-SHA-256) and x.509 certificate authentication. Enterprise adds further mechanisms such as Kerberos, and LDAP authentication is deprecated starting in MongoDB 8.0. The localhost exception lets you create the first user from the local host, and on a mongod it applies only while no users or roles exist.

The trap. Shared service accounts. (Query safety is a separate topic; see SQL injection prevention and NoSQL injection in MongoDB.) The authentication method can be perfect and the posture still poor if one account is shared by five services and two humans. Every application gets its own account, and humans connect as themselves.

3. Grants and least privilege

Grants decide what each authenticated identity can do. The review question is simple to state and tedious to answer: does every role hold only what it needs?

PostgreSQL. Start with superusers and roles that can bypass row level security.

SELECT rolname, rolsuper, rolcreaterole, rolcreatedb, rolbypassrls
FROM pg_roles
WHERE rolsuper OR rolcreaterole OR rolbypassrls;

PostgreSQL 15 changed a long-standing default: the PUBLIC role no longer has CREATE permission on the public schema in new databases. Databases upgraded from older versions keep their old grants, so check them. Predefined roles such as pg_read_all_data and pg_monitor let you grant broad read or monitoring access without superuser. ALTER DEFAULT PRIVILEGES controls what new objects grant automatically, which is where many accidental grants come from. Row level security, turned on per table with ALTER TABLE ... ENABLE ROW LEVEL SECURITY, restricts which rows a role sees, but table owners and roles with BYPASSRLS skip it unless the table also uses FORCE ROW LEVEL SECURITY.

MySQL. SHOW GRANTS FOR 'user'@'host' lists an account's privileges. Look first for ALL PRIVILEGES ON *.* and for WITH GRANT OPTION, which lets the holder pass privileges on. MySQL supports roles (CREATE ROLE), so you can group privileges and grant the role to accounts, and SHOW GRANTS displays role assignments as well as privileges. The mysql.user table holds global privileges if you want a one-pass query across accounts.

SHOW GRANTS FOR 'report'@'%';
SELECT user, host FROM mysql.user WHERE Super_priv = 'Y' OR Grant_priv = 'Y';

Note also the host part of each account. An account name with no host part is the same as 'user'@'%', which accepts that user from any host, while a pattern such as 'report'@'10.0.%' limits it. Host patterns are part of MySQL's access control, and a wildcard host is worth a second look.

MongoDB. MongoDB uses role-based access control. Built-in roles include read and readWrite per database, dbAdmin and userAdmin for administration, and root, which combines the most powerful roles. Custom roles let you grant specific actions on specific resources. db.getUsers() and db.getRoles({ showPrivileges: true }) list what exists.

The trap. Reviewing grants once. Privileges drift through migrations, incident fixes and new services. A grant review is a recurring control, and SOC 2 and PCI DSS both expect to see it repeated.

4. Audit logging

Audit logging answers who connected, when, from where, and what privileged or sensitive actions they took. Two things matter as much as the content: the logs leave the database host, and the people being audited cannot edit them.

PostgreSQL. The server log can record connections and disconnections. In current PostgreSQL, log_connections is a list of aspects to log (for example receipt, authentication and authorization), and its default empty value logs no connection details; older releases used a simple on or off switch. log_disconnections logs session ends with their duration. log_statement can log none, ddl, mod (DDL plus data-modifying statements) or all. log_line_prefix adds context such as user, database, client address and session ID to each line. These settings produce useful logs, but they are not structured audit records. For that, PostgreSQL's community uses pgAudit, an open source extension that adds session and object audit logging through the standard logging facility. pgAudit is a separate project with its own documentation, and managed PostgreSQL services often offer it as an extension you can enable.

SHOW log_connections;
SHOW log_disconnections;
SHOW log_statement;
SHOW log_line_prefix;

MySQL. The general query log records every statement the server receives, which makes it heavy and not designed as an audit trail. MySQL Enterprise Audit, an extension included in MySQL Enterprise Edition (a commercial product), provides policy-based audit logging of connections and queries through a server plugin named audit_log. It writes XML by default, and audit_log_format selects the file format. The binary log records changes for replication and recovery, which helps reconstruct what changed but says nothing about reads. If you run MySQL Community Edition, plan an audit approach explicitly rather than assuming one exists.

MongoDB. MongoDB Enterprise includes an auditing facility that can write events to the console, syslog, a JSON file or a BSON file, with an optional filter; you enable it by setting an audit destination. MongoDB Atlas supports database auditing on M10 and larger clusters, and not on Free or Flex clusters, with administrators choosing which actions and users to audit. If you run Community Edition, plan an audit approach explicitly.

The trap. Logging on, shipping off. Logs that stay on the database host are lost when the host is lost, and can be edited by anyone with root on it. Forward them to a log platform your DBAs cannot write to, and keep them for as long as your framework requires.

5. Encryption at rest

Encryption at rest protects data on disk, in backups and in snapshots from someone who gets the storage but not the running database. The posture questions are what is encrypted, at which layer, and who holds the keys.

PostgreSQL. PostgreSQL does not include transparent data encryption in the core server. Its "Encryption Options" documentation lists the layers available instead: password storage encryption, column encryption with the pgcrypto module, data partition encryption at the filesystem or block device level, encryption of data across the network, and client-side encryption where the database never sees plaintext. In practice, self-managed PostgreSQL relies on encrypted volumes, and managed services encrypt storage for you. Either way, your evidence is about the storage layer and the key management, not a database setting.

MySQL. InnoDB supports data-at-rest encryption for file-per-table tablespaces, general tablespaces, the system tablespace, and redo and undo logs, using a keyring component or plugin to hold the master key. You can encrypt a table with ENCRYPTION='Y', and default_table_encryption sets the default for new schemas and tablespaces. binlog_encryption encrypts binary log and relay log files, and its default is OFF. Check what is actually encrypted rather than what the default says.

SELECT SPACE, NAME, SPACE_TYPE, ENCRYPTION
FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
WHERE ENCRYPTION = 'Y';
SHOW GLOBAL VARIABLES LIKE 'default_table_encryption';
SHOW GLOBAL VARIABLES LIKE 'binlog_encryption';

MongoDB. MongoDB Enterprise offers native encryption at rest through the WiredTiger storage engine, with keys managed locally or, as MongoDB recommends for production, through a KMIP key management server. MongoDB Atlas encrypts all cluster storage and snapshot volumes at rest by default with AES-256, and also supports encryption at rest with customer-managed keys. For field-level protection, Client-Side Field Level Encryption and Queryable Encryption encrypt selected fields in the driver before they reach the server.

The trap. Assuming backups inherit encryption. A dump file written by pg_dump or mysqldump to an unencrypted bucket undoes all of the above. Backups and exports are part of the at-rest scope.

What about Redis and other engines?

The same five questions apply to everything that stores data. Redis is a good example because its defaults have changed over time. Redis 6 added access control lists, so you can create users with specific command and key permissions instead of sharing one password. Redis supports TLS from version 6 as an optional feature enabled at compile time. Since version 3.2.0, Redis enters protected mode when it runs with the default configuration (bound to all interfaces) and no password, and then answers only on the loopback interface. Redis has no audit log comparable to the engines above, so logging posture usually means connection logging in the network layer and in a managed service's console.

Step by step: a posture review you can run this week

This works with no particular tooling. It assumes read access to each database and to its configuration.

1. List every database. Include replicas, analytics copies, staging databases that hold production data, and managed instances in every cloud account. The list is the scope; a database not on it will not be reviewed.
2. Tag each one by data class. Cardholder data, health data, personal data, internal only. The tag decides which framework's controls apply and how strict each setting must be.
3. Run the five checks using the queries above, and record the output with the date, the host and who ran it. Keep the raw output; a summary is not evidence.
4. Check the client side. For each application, find the connection string or driver settings and record the TLS mode. This is the step most reviews skip.
5. Compare against a written baseline. Use the table below as a starting point and adjust it to your frameworks.
6. Open a ticket per gap, with the owner, the setting, and the target date.
7. Decide the recheck interval. Grants and authentication drift fastest, so check them at least as often as your access review cycle. TLS and encryption change less often but break silently on rebuilds.
8. Automate the evidence. Whatever you can read through an API or a query on a schedule, read on a schedule. Screenshots age badly.

Baseline checklist

Does TLS on the server mean the connection is safe?

No. The server can offer TLS while a client accepts a plaintext fallback or skips certificate checks. In PostgreSQL's default prefer mode, a client that cannot negotiate TLS connects without it. In require mode, the connection is encrypted but the client will talk to any server that presents a certificate. Only verify-full in libpq, or VERIFY_IDENTITY in MySQL's client, checks both the chain and the host name. Treat the client setting as part of the database's posture.

Is a general query log good enough as an audit log?

Usually not. The general query log in MySQL and log_statement = 'all' in PostgreSQL record statements, which helps in an investigation, but they are verbose, hard to filter, and not designed around audit questions such as which user read which table. They can also capture sensitive values in statement text. Audit tooling records structured events with a filter you control. If you rely on statement logs, ship them off host, restrict who can read them, and be ready to explain to an auditor how they meet the requirement.

Is disk encryption enough for encryption at rest?

For many frameworks, encrypted storage with properly managed keys meets the at-rest requirement for the database files. It does not cover data once it leaves the database: dumps, exports, analytics copies and logs that capture values. It also does not help against anyone who can query the running database, which is why grants and authentication matter as much. For the most sensitive fields, consider field-level encryption in the application or driver, where the database only ever holds ciphertext.

How often should grants be reviewed?

As often as your access review cycle requires, and after any migration, incident or bulk role change. Quarterly reviews are common for production databases holding regulated data. The sign-off is the useful part: someone who knows each service confirms each grant is still needed.

How Safeguard does this

If you are new to the idea, what posture management is gives the wider picture, and setting up cloud security posture management covers the cloud account layer that sits around managed databases. Safeguard covers database posture in three places: the Database Security Posture integration for a live database, compliance connectors for managed database services, and Data Security Posture Management for cloud data stores.

The Database Security Posture integration

Safeguard's Integrations page lists a Database Security Posture integration (GA). Its card reads: "Live database posture: TLS, auth rules, grants, audit logging & encryption at rest." Those are the same five controls this post has walked through, checked against a running database rather than read from a configuration file or a screenshot. You add it from the Integrations page, alongside your repositories, registries and other integrations.

The card is the whole public description today. It does not name the engines covered or the access the check needs, so confirm both with Safeguard for your estate before you plan around it, and give the assessment account the least privilege that lets it read the settings. The connector and DSPM flows below are documented step by step on docs.safeguard.sh, and they cover managed services and cloud stores from a different angle.

Managed database connectors and DSPM, step by step

The connectors and DSPM are read-only, and neither changes a database setting. The steps below come from docs.safeguard.sh and the offering reference.

1. Open Compliance › Connectors and pick the database service. The Compliance and GRC suite (GA) includes infrastructure connectors for managed databases, among them MongoDB Atlas, Supabase, PlanetScale and Redis Cloud. Each connector page explains what the connection produces (automated compliance tests), the credential it needs, and the frameworks the tests provide evidence for.

2. Create a read-only credential in the database service, as the docs describe.

   • MongoDB Atlas: create an API key or a service account under Identity & Access › Applications with Organization Read Only, invite it to each project with Project Read Only, and add Safeguard's egress IP address or CIDR block to the key's access list. Atlas shows the private key or client secret once, so copy it before leaving the page.
   • Supabase: create a scoped access token for the organization and projects Safeguard should read, with read permissions only. Safeguard needs organizations:read, projects:read and database:read.
   • PlanetScale: create a service token and grant read_organization at the organization level, then read_database, read_branch and read_backups on each database Safeguard should read. The docs note that the compliance tests need this credential on the API token tab, because an OAuth connection cannot read everything they check.
   • Redis Cloud: make sure a Viewer (read-only) user exists, copy the account key, and create a user key bound to that Viewer user. Optionally add Safeguard's egress addresses to the CIDR allow list.

3. Connect. On the connector, click Connect, choose API token, fill in the fields, and click Connect with token. Safeguard stores secret fields encrypted and never shows them again. Supabase also offers an MCP server connection that lets Griffin AI search Supabase; the docs say the compliance evidence still comes from the API token connection.

4. Let the automated tests run. The docs say these tests are switched on per workspace by the Safeguard team. Once on, they read the service through its API and map to framework controls. The mapping each connector page lists is the useful part for this topic, because it shows which posture areas the tests speak to. The table after these steps summarizes it.

5. Read results as evidence, not as a certificate. Safeguard's docs are explicit: when a test passes, the result is evidence toward each control it maps to, in every framework listed, not proof that the control is met on its own. Evidence lands in the Compliance app, whose tabs include Frameworks, Controls, Evidence, Monitoring and Tests.

6. Add DSPM for Amazon RDS. Safeguard DSPM (GA) connects to live cloud data stores, with Amazon S3 and Amazon RDS first. For RDS, it enumerates tables, reads a small, bounded sample of rows from text columns to classify sensitive data, and records encryption status and public exposure, meaning storage encryption, public accessibility and network access. It uses credentials from your existing cloud-account integrations and never persists or logs them. Raw sensitive values are never stored: matches are redacted at the point of detection and only a redacted snippet is kept.

7. See who can reach each store. DSPM joins each data store with effective permissions to build access edges: every identity with a read, write, delete or admin path to a sensitive store, flagged as external when the principal sits outside your tenant boundary. Access breadth feeds the risk score, and an over-privileged or external principal with read access to a sensitive store raises an access finding. This is the grants question asked from the cloud side.

8. Watch for unusual access. DSPM's data detection and response tails access and query logs and compares them against a per-store, per-identity baseline to flag patterns such as mass reads, first-time sensitive access and anomalous queries. It records only the shape of the anomaly, never the data read. Alerting is always on; quarantine or deny responses are opt-in per policy.

9. Run DSPM from the CLI when you want it in a pipeline. The DSPM docs show these commands for the Safeguard CLI (GA). The connector example in the docs is S3; we did not run these commands for this post.

   safeguard dspm scan --connector s3 --account <ref>
   safeguard dspm risks
   safeguard dspm compliance --framework pci
   

   An administrator switches DSPM on for the tenant; sampling limits, exposure thresholds, the response mode and compliance frameworks are configured per tenant.

10. Decide what a finding means for a release. DSPM findings flow into Safeguard's unified findings model, tenant and organization scoped. Policies, gates and guardrails (GA) are how Safeguard turns findings into decisions at checkpoints: gate actions are Block, Warn and Notify, and approval for an exception runs through the exceptions flow. The policies and gates docs describe gates evaluated on the scans the platform runs for connected repositories, so treat database posture findings as a review and remediation queue unless your workspace's gate setup says otherwise.

What the connector tests map to

The connector pages list the controls each service's tests map to. Read across the rows and you can see which of the five posture areas they speak to. The pages list control IDs, not test names, so treat the area column as our reading of the mapping, not a description of individual tests.

Requirement, Safeguard, and what you still own

What Safeguard does not do

• It does not change your databases. Every credential in the connector docs is read-only, and DSPM samples rather than writes. Fixing a setting is still a change you make through your own process.
• A passing test is not a passed control. Safeguard's docs say so plainly: a pass is evidence toward a control. Your auditor still judges whether the control is designed and operating effectively.
• You cannot switch connector tests on yourself. The docs say the Safeguard team switches the automated tests on per workspace. Plan for that step when you set up.
• Coverage is something to confirm, not assume. The connector pages cover managed services such as MongoDB Atlas, Supabase, PlanetScale and Redis Cloud, and DSPM covers RDS. The Database Security Posture integration's card describes live database checks without listing engines, so confirm that each database you run is covered, and keep the engine-level checks earlier in this post for anything that is not.
• DSPM samples. It reads a small, bounded sample of rows and never a whole table. A store with no sensitive match in the sample is not proven free of sensitive data.
• It does not hold or rotate your keys. Encryption at rest depends on your key management service or the database service's own keys.
• It does not replace database audit tooling. DSPM's anomaly detection reads access and query logs that your database or cloud already produces. If auditing is off, there is less to read.
• It does not judge business need. Access fusion shows who can reach a store. Whether that access is justified is a decision for the data owner.

Common mistakes

• Fixing the server and forgetting the client. require_secure_transport or hostnossl reject stop plaintext, but clients still need to verify the certificate and host name.
• Leaving trust in pg_hba.conf after setup. It is convenient during installation and dangerous on any line that matches a network address.
• Running self-managed MongoDB without security.authorization. It is off by default. Binding to localhost is not a substitute once the server is reachable.
• Counting the general query log as audit logging. It is verbose, holds statement text, and was not built to answer audit questions.
• Treating "encrypted by default" as evidence. Managed services do encrypt storage by default, but an auditor wants to see the setting for your cluster and who manages the keys.
• Reviewing grants once. Privilege creep comes from migrations, incidents and new services. The review has to repeat.
• Granting the posture tool more than it needs. Every connector in Safeguard's docs uses a read-only role. Give any assessment tool the same.
• Forgetting backups and exports. Dumps and snapshots are data at rest too.

FAQ

What is database security posture?

It is the current state of the security settings that protect a database: transport encryption, authentication, grants, audit logging and encryption at rest, plus network exposure and backups. Posture management means checking those settings against a baseline on a schedule and keeping evidence that they held.

How do I check if PostgreSQL connections use TLS?

Query pg_stat_ssl, which shows each backend process and whether it uses TLS, with the protocol version and cipher. SHOW ssl shows whether the server offers TLS at all. To refuse plaintext, add hostnossl lines with the reject method in pg_hba.conf.

What is the default authentication plugin in MySQL 8.4?

caching_sha2_password. The older mysql_native_password was deprecated in 8.0.34, is disabled by default in 8.4 and was removed in 9.0.0, so accounts that still use it need migrating.

Is MongoDB access control enabled by default?

No. MongoDB's documentation says it does not enable access control by default. Set security.authorization to enabled in the configuration file or start mongod with --auth, then create users and roles.

Does PostgreSQL support transparent data encryption?

The core server does not. PostgreSQL's documentation lists the alternatives: filesystem or block device encryption, column encryption with pgcrypto, and client-side encryption. Managed PostgreSQL services encrypt their storage.

Which Safeguard integrations read database posture?

The Database Security Posture integration checks a live database for TLS, auth rules, grants, audit logging and encryption at rest. The documented infrastructure connectors for managed databases include MongoDB Atlas, Supabase, PlanetScale and Redis Cloud. Each runs automated compliance tests through the service's API with a read-only credential. DSPM adds Amazon RDS encryption status and public exposure.

Does Safeguard need write access to my database?

No. The connector docs ask for read-only roles, such as Organization Read Only and Project Read Only in MongoDB Atlas, read scopes in Supabase and PlanetScale, and the Viewer role in Redis Cloud.

Is a passing Safeguard test enough for my auditor?

It is evidence toward the controls it maps to, which is what Safeguard's docs call it. Your auditor decides whether the control is effective, usually with other evidence such as reviews and change records.

Which frameworks do the database connector tests map to?

The connector pages list SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS and NIST CSF 2.0, with the specific control IDs for each service.

Does Safeguard DSPM store the sensitive data it finds?

No. The DSPM docs describe a redaction mandate: raw sensitive values are never stored, matches are redacted at the point of detection, and only a redacted snippet is kept. DSPM findings are also held under tighter access control than normal findings, and every read is audited.

The configuration work in this post is about settings, but database engines are also software you depend on, along with their drivers, extensions and client libraries. When one of those has a vulnerability, the fix path below applies to it the same way it applies to any other dependency.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The CLI demo shows a real terminal session: you install the CLI, run safeguard to open the interactive terminal, ask it to fix a lodash CVE, and watch it read the finding and the advisory, ask before any command that changes something, update the dependency, run the install and tests with your approval, and push nothing. For database work, the same pattern applies when a driver or client library needs an update: the CLI asks before it changes anything.

Click through it at your own pace, or open it full screen.

The local runner demo shows setting up a runner on your own machine, approving it with its device code, and scanning from the terminal. Safeguard's application security testing docs point to a runner inside your network for private addresses that the hosted scanner cannot reach, which is where many databases live.

Click through it at your own pace, or open it full screen.

The Claude demo shows connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. Once connected, you can ask about findings and evidence in plain language from the assistant you already use.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard docs: Integrations overview
• Safeguard docs: Compliance connectors
• Safeguard docs: MongoDB Atlas connector
• Safeguard docs: Supabase connector
• Safeguard docs: PlanetScale connector
• Safeguard docs: Redis Cloud connector
• Safeguard docs: Data Security Posture Management (DSPM)
• Safeguard docs: Policies and gates
• Safeguard docs: Application security testing
• 45 CFR 164.312, Technical safeguards (eCFR)
• NIST SP 800-52 Rev. 2, Guidelines for TLS implementations
• NIST SP 800-53 Rev. 5, Security and privacy controls
• PostgreSQL: Connections and authentication settings
• PostgreSQL: The pg_hba.conf file
• PostgreSQL: SSL support in libpq
• PostgreSQL: Password authentication
• PostgreSQL: Certificate authentication
• PostgreSQL: pg_hba_file_rules
• PostgreSQL: pg_authid
• PostgreSQL: Schemas
• PostgreSQL: Predefined roles
• PostgreSQL: Row security policies
• PostgreSQL: Error reporting and logging
• PostgreSQL: The cumulative statistics system (pg_stat_ssl)
• PostgreSQL: Encryption options
• pgAudit README
• MySQL 8.4: Using encrypted connections
• MySQL 8.4: Encrypted connection TLS protocols and ciphers
• MySQL 8.4: Native pluggable authentication
• MySQL 8.4: Caching SHA-2 pluggable authentication
• MySQL 8.4: Specifying account names
• MySQL 8.4: Using roles
• MySQL 8.4: The general query log
• MySQL 8.4: MySQL Enterprise Audit
• MySQL 8.4: InnoDB data-at-rest encryption
• MySQL 8.4: Encrypting binary log files and relay log files
• MongoDB: Configure TLS/SSL
• MongoDB: IP binding in self-managed deployments
• MongoDB: Role-based access control
• MongoDB: Authentication on self-managed deployments
• MongoDB: SCRAM
• MongoDB: Localhost exception
• MongoDB: Built-in roles
• MongoDB: Auditing
• MongoDB: Encryption at rest
• MongoDB: Queryable Encryption
• MongoDB Atlas: Security features and setup
• MongoDB Atlas: Database auditing
• Redis: Security
• Redis: ACL
• Redis: TLS

To try this on your own estate, download Safeguard at https://safeguard.sh/download or read the docs at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.