- Concept
- Version ยท 6.0
- Govern
What is in the Liquibase Default Catalog?
Last updated: September 29, 2026
Every workspace starts with the Liquibase Default Catalog, a read-only catalog holding the 60 policy checks built into Liquibase Secure, grouped into 7 packages named after the check categories. This page lists what is in each package and which checks arrive enabled, so you can decide what to copy into your own catalog without opening every package in turn.
The catalog is read-only, so you copy the checks you want into a package of your own, then enable or disable them and set their parameters there. Organize checks and packages covers building the catalog that holds them.
Packages at a glance
Authorization and Access: Guards GRANT/REVOKE usage and privilege escalation paths. 5 checks, 4 enabled.
Data Protection: Prevents destructive or exposing operations on protected data. 17 checks, 12 enabled.
Database Compatibility: Flags vendor-specific syntax that breaks portability. 7 checks, 1 enabled.
Metadata Content: Requires labels, contexts, and comments on changesets. 11 checks, 4 enabled.
Scripting Standards: Enforces SQL scripting style and structural conventions. 12 checks, 4 enabled.
Sensitive Data: Detects PII and secrets in changesets and SQL text. 6 checks, 0 enabled.
Advanced Policies: Custom policy hooks for organization-specific rules. 2 checks, 0 enabled.
Note: Enabled here means enabled in the default catalog, which is what a copy inherits. Once a check is copied into your catalog or package, you can enable or disable it there. You can also enable or disable a check for a single assignment without changing its state in other assignments that use the same check.
Package details
Authorization and Access
Guards GRANT/REVOKE usage and privilege escalation paths.
Check | What it does | In the default catalog |
|---|---|---|
| Identifies highly sensitive GRANT statements that include WITH ADMIN OPTION, which allows recipients to grant and revoke the same administrative privileges to others, helping prevent security risks from uncontrolled admin role distribution. | Enabled |
| Detects WITH GRANT OPTION statements, which allows the recipient to pass permissions on to other users, helping you prevent privilege escalation security risks which could spread beyond intended recipients. | Enabled |
| Alerts when SQL code contains GRANT statements that assign database privileges to users or roles, helping review potential security vulnerabilities by ensuring permissions are appropriately scoped and do not provide unintended access. | Enabled |
| Flags REVOKE statements in SQL that remove database privileges from users or roles, allowing you to verify that removing these permissions will not accidentally break application functionality or prevent legitimate access to critical data. | Enabled |
| Alerts when changesets contain GRANT statements that assign particular database privileges designated as requiring review, helping maintain strict control over sensitive permissions like DELETE, DROP, ALTER, or administrative rights which pose security risks. | Disabled |
Data Protection
Prevents destructive or exposing operations on protected data.
Check | What it does | In the default catalog |
|---|---|---|
| Alerts when DROP COLUMN is detected, giving you an opportunity to verify the column removal will not cause data loss or break dependencies, and that both necessary data and application code are migrated or updated. | Enabled |
| Warns when DROP TABLE is detected, providing a safety checkpoint to confirm the deletion is intentional and prevent accidental data loss from removing important or referenced tables. | Enabled |
| Alerts you when a changeset attempts to truncate a table and remove all its data, providing an opportunity to verify this destructive operation is intentional and that any necessary data has been backed up or migrated, preventing accidental deletion of entire table contents that may be difficult or impossible to recover. | Enabled |
| Identifies database tables which lack indexes, highlighting potentially performance problems before they cause production slowdowns as data grows, ensuring efficient querying, joining, and constraint enforcement. | Enabled |
| Flags changesets with user-specified prohibited change types, allowing you to enforce policies against certain types of database modifications like raw SQL execution, dropping objects, or other change types forbidden by organizational policy. | Enabled |
| Validates DELETE statements against a configurable threshold limit to prevent removing too many rows of data, providing a safety net against runaway deletions that could remove more data than intended and helping ensure bulk delete operations are properly scoped. | Enabled |
| Alerts when an INSERT operation would add more rows than your configured limit, helping catch potential issues with bulk data loads or runaway insert statements that might impact database performance or storage. | Enabled |
| Checks UPDATE statements against a configurable limit to protect against unintended mass updates, preventing mistakes like missing WHERE clauses or overly broad conditions that could accidentally change more rows of data than intended. | Enabled |
| Flags any changes that modify the data type of an existing column, helping avoid data truncation or loss when converting between incompatible types, such as changing from a larger to smaller size or from text to numeric formats. | Enabled |
| Flags table creation statements that do not define a PRIMARY KEY, promoting database design best practices by ensuring every table has a unique identifier for rows, which is essential for data integrity, relationships, and efficient querying. | Enabled |
| Identifies SQL queries that use SELECT * to retrieve all columns from a table, encouraging best practices for query performance and maintainability by requiring developers to explicitly specify which columns they actually need rather than retrieving unnecessary data. | Enabled |
| Enforces a maximum TABLE COLUMN LIMIT to maintain database design quality and prevent overly wide tables that can indicate poor normalization, hurt query performance, and make the schema difficult to understand and maintain over time. | Enabled |
| Verifies that designated tables include required constraints like foreign keys, unique constraints, or check constraints that are essential for data integrity, helping ensure critical business rules and referential relationships are properly enforced at the database level rather than relying solely on application code. | Disabled |
| Validates that DynamoDB-specific change operations include properly configured attributes that match your organizational patterns or standards, ensuring DynamoDB changesets are correctly parameterized with appropriate table names, capacity settings, index configurations, or other DynamoDB-specific properties. | Disabled |
| Warns when changesets attempt to delete DynamoDB tables, providing a safety check specific to DynamoDB operations to prevent accidental removal of NoSQL tables and the permanent loss of data stored in Amazon's DynamoDB service. | Disabled |
| Alerts when changesets try to remove Global Secondary Indexes from DynamoDB tables, helping verify that deleting these indexes will not negatively impact query performance or break application functionality that depends on these alternative access patterns for retrieving DynamoDB data. | Disabled |
| Ensures MongoDB-specific database changes have attributes configured according to required patterns or values, helping maintain standards for MongoDB operations like collection names, document structures, or index definitions and preventing misconfigurations in your MongoDB schema changes. | Disabled |
Database Compatibility
Flags vendor-specific syntax that breaks portability.
Check | What it does | In the default catalog |
|---|---|---|
| Detects USE DATABASE statements in SQL scripts to help maintain portability and prevent unintended database switching, ensuring changesets do not accidentally execute against the wrong database context or create deployment issues across different environments. | Enabled |
| Prevents the naming of database objects using Oracle reserved keywords like SELECT, TABLE, INDEX, or WHERE, avoiding syntax errors and the need for complex quoting or escaping that makes queries harder to write and maintain while ensuring compatibility across different Oracle database versions and tools. | Disabled |
| Prevents using PostgreSQL's non-reserved keywords as object names even though they're technically allowed, promoting clearer and less ambiguous schema design by avoiding keywords that might have contextual meaning or could become reserved in future PostgreSQL versions. | Disabled |
| Enforces that PostgreSQL reserved keywords (like SELECT, USER, TABLE, or other terms with special meaning in PostgreSQL) are not used as database object names, preventing syntax conflicts and complex quoting efforts. | Disabled |
| Prevents using keywords Microsoft has earmarked for future SQL Server versions, protecting your schema from becoming incompatible when upgrading to newer database versions and avoiding the need for potentially disruptive object renaming during future migrations or newer SQL Server releases. | Disabled |
| Blocks database object names that conflict with ODBC reserved keywords to ensure compatibility with applications that access SQL Server through ODBC connections, preventing potential issues with database connectivity and query execution. | Disabled |
| Blocks the use of SQL Server reserved keywords in database object names, preventing conflicts with T-SQL syntax and ensuring tables, columns, or other objects do not use words like SELECT, TABLE, INDEX, or other terms that have special meaning in SQL Server. | Disabled |
Metadata Content
Requires labels, contexts, and comments on changesets.
Check | What it does | In the default catalog |
|---|---|---|
| Requires descriptive COMMENT on every changeset to document the purpose behind database changes, improving documentation and long-term maintainability by ensuring future developers understand why modifications were made and what problems they solve. | Enabled |
| Mandates changesets specify the CONTEXT, such as dev, test, prod, etc, enabling environment-specific deployments and ensuring certain database changes only run in appropriate environments while providing better documentation over which modifications are applied in different stages of the pipeline. | Enabled |
| Requires all changesets specify the LABEL for better organization and deployment targeting, enabling selective deployment groups, and maintaining clearer documentation of feature work or release cycles. | Enabled |
| Ensures Formatted SQL changelog files include the required Liquibase header comment, preventing execution errors and ensuring the changelog is processed by Liquibase, with all its tracking and versioning capabilities, rather than treated as raw SQL. | Enabled |
| Validates that specific changeset attributes match your required values or patterns, enabling enforcement of standards like author name formats, runOnChange settings, runWith values, or other attribute requirements that ensure changesets follow your team's configuration conventions. | Disabled |
| Validates specific CHANGESET ATTRIBUTES like runInTransaction or failOnError are explicitly set to either true or false rather than left undefined, preventing ambiguity about how changesets should behave and ensuring intentional configuration of important execution parameters. | Disabled |
| Enforces that all changeset IDs use the standard UUID or GUID format with the 8-4-4-4-12 hyphenated pattern, promoting globally unique changeset identifiers that prevent collisions and improve traceability across distributed teams and multiple changelog files. | Disabled |
| Flags database tables that do not include COMMENTS, used to explain its purpose and contents, promoting self-documenting schemas that help developers efficiently understand the data model without needing to consult external documentation. | Disabled |
| Scans TABLE COMMENTS for Regex patterns or specific text, allowing you to ensure required content is present or prohibited content is not included, according to user and organization specific policies. | Disabled |
| Ensures changeset CONTEXT contains specific words or patterns, helping enforce that all changes are properly tagged for environment targeting, helping maintain consistent environment targeting across your deployment pipeline and preventing errors from misspelled or non-standard context names. | Disabled |
| Validates changeset LABEL includes specific words or a defined pattern, enabling enforcement of requirements like ticket numbers, release versions, team names or other identifiers to track and organize database changes. | Disabled |
Scripting Standards
Enforces SQL scripting style and structural conventions.
Check | What it does | In the default catalog |
|---|---|---|
| Validates the runInTransaction attribute to enforce whether changesets must run inside or outside of transactions, ensuring operations that require transactional safety are properly wrapped while certain DDL statements in some databases that can't run in transactions are appropriately configured. | Enabled |
| Enforces the best practice of ONE CHANGE per changeset to keep changesets focused and atomic, making it easier to troubleshoot issues, rollback specific changes independently, and understand the history of individual database modifications. | Enabled |
| Ensures every changeset includes rollback instructions to reverse the change if needed, promoting safer deployments by guaranteeing you can undo database modifications if issues arise, which is critical for maintaining database recoverability and reducing deployment risk. | Enabled |
| This check triggers when SQL content has SqlPlus slash terminator issues that could cause hangs or double execution. | Enabled |
| Ensures changesets contain proper end delimiters when certain SQL patterns exist, ensuring SQL commands are properly separated, preventing syntax errors and ensuring your database scripts execute as intended across different database platforms. | Disabled |
| Enforces naming conventions for database objects like tables, columns, indexes, and constraints by requiring them to match your specified naming pattern or regex, helping maintain consistent and standardized object names across your database schema that align with organizational naming standards. | Disabled |
| Prevents database objects from being named with prohibited patterns or conventions, allowing you to block specific naming styles, reserved words, or naming patterns that conflict with your standards, ensuring objects do not use disallowed prefixes, suffixes, or formats that could cause confusion or conflicts with application code or other systems. | Disabled |
| Validates a specific Pattern A or keyword is always FOLLOWED by another expected Pattern B, helping enforce proper SQL syntax ordering, required clauses, or organizational coding conventions mandating certain statements must appear in a specific sequence in changesets. | Disabled |
| Validates a specific Pattern A or keyword is NOT FOLLOWED by another expected Pattern B, helping enforce proper SQL syntax ordering, required clauses, or organizational coding conventions ensuring your SQL adheres to organizational standards or database best practices. | Disabled |
| Validates a specific Pattern A or keyword is NOT PRECEDED by another expected Pattern B, helping enforce proper SQL syntax ordering, required clauses, or organizational coding conventions mandating certain statements must appear in a specific sequence in database scripts. | Disabled |
| Validates a specific Pattern A or keyword is always PRECEDED by another expected Pattern B, helping enforce proper SQL syntax ordering, required clauses, or organizational coding conventions mandating certain statements must appear in a specific sequence in database scripts. | Disabled |
| Allows user-defined custom Regex patterns or specific text strings to search for within SQL code, enabling enforcement of organization-specific coding standards, both detecting prohibited patterns or proving inclusion of required patterns, building an audit trail of development practices. | Disabled |
Sensitive Data
Detects PII and secrets in changesets and SQL text.
Check | What it does | In the default catalog |
|---|---|---|
| Identifies highly-sensitive Computer-related and Date information, helping avoid PII (Personally Identifiable Information) data exposure, and supporting audit and authorization requirements in highly-regulated environments. | Disabled |
| Identifies highly-sensitive Financial or Bank information, helping avoid PII (Personally Identifiable Information) data exposure, and supporting audit and authorization requirements in highly-regulated environments. | Disabled |
| Identifies highly-sensitive Health, Hospital and Doctor information, helping avoid PII (Personally Identifiable Information) data exposure, and supporting audit and authorization requirements in highly-regulated environments. | Disabled |
| Identifies highly-sensitive US Geographic Location information, helping avoid PII (Personally Identifiable Information) data exposure, and supporting audit and authorization requirements in highly-regulated environments. | Disabled |
| Identifies highly-sensitive Person-centered information, helping avoid PII (Personally Identifiable Information) data exposure, and supporting audit and authorization requirements in highly-regulated environments. | Disabled |
| Identifies multiple types of highly-sensitive Personally Identifiable Information (PII) including Financial, Banking, Personal, Location, Health, and Computer types of data, helping avoid data exposure, and supporting audit and authorization requirements in highly-regulated environments. Create focused checks by copying and customizing specific IDENTIFIERS for your specific data protection policies. | Disabled |
Advanced Policies
Custom policy hooks for organization-specific rules.
Check | What it does | In the default catalog |
|---|---|---|
| Enables checking complex or multi-part policy conditions by combining or chaining multiple Policy Checks with logical operators, allowing you to create sophisticated rules based on combinations of simpler factors, like changeset attributes, SQL content, label content, etc to match nuanced organizational requirements. | Disabled |
| Allows you to create and run completely custom policy checks using your own Python scripts and logic, providing flexibility to enforce organization-specific rules, integrate with external validation systems, or implement complex checks that are not covered by standard policy check capabilities. | Disabled |
Checks that ignore DML
The checks that look for a DDL or DCL keyword, such as GRANT or DROP TABLE, evaluate DDL and DCL statements only. They ignore any statement that begins with SELECT, INSERT, UPDATE, DELETE, MERGE, or WITH, so a keyword stored as data does not trigger them. For example, an INSERT that stores the address 101 Grant St. does not trigger SqlGrantWarn.
These checks are ChangeDropColumnWarn, ChangeDropTableWarn, ChangeTruncateTableWarn, SqlGrantAdminWarn, SqlGrantOptionWarn, SqlGrantWarn, SqlRevokeWarn, and WarnOnUseDatabase.
A changeset that mixes DML and DDL is still flagged on its DDL. Only the DML statements are ignored, so a changeset holding an INSERT followed by GRANT ALL ON sales TO admin_user triggers SqlGrantWarn on the GRANT.
SqlSelectStarWarn is the exception. It looks for SELECT *, which only appears in DML, so it evaluates every statement.
How this compares to the CLI package files
If your team runs policy checks from files, init project generates six of these packages as package files.
Going the other way, the file workflow has composite packages that bundle several themed packages together, which the catalog has no equivalent for. What are the default policy check packages? covers the file side, including the commands that target a package by name.
What to do next
You have seen what ships and which checks arrive enabled. Organize checks and packages to copy the packages you want into a catalog of your own, then define policy assignments to put them in force.