checks show

ChainedChecksTemplate

Advanced Policies

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.

LOGIC_CONDITIONAL = null

MESSAGE = The conditions in '<chained checks shortname>' were met for '<logic conditional>'. The chained checks include <checknames>.

disabled

0

changelog, database

sql, xml, yaml, json

CustomCheckTemplate

Advanced Policies

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.

SCRIPT_DESCRIPTION = Custom check

SCRIPT_SCOPE = CHANGELOG

SCRIPT_MESSAGE = The message to display when the check is triggered

SCRIPT_TYPE = PYTHON

SCRIPT_PATH = null

SCRIPT_ARGS = null

REQUIRES_SNAPSHOT = false

disabled

0

changelog

sql, xml, yaml, json

SqlGrantAdminWarn

Authorization and Access

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

SqlGrantOptionWarn

Authorization and Access

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

SqlGrantSpecificPrivsWarn

Authorization and Access

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.

PRIVILEGE_LIST = null

STRIP_COMMENTS = true

disabled

0

changelog

sql

SqlGrantWarn

Authorization and Access

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

SqlRevokeWarn

Authorization and Access

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

ChangeDropColumnWarn

Data Protection

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

ChangeDropTableWarn

Data Protection

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

ChangeTruncateTableWarn

Data Protection

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

CheckTablesForIndex

Data Protection

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.

<None>

enabled

0

database

ConstraintMustExist

Data Protection

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.

CONSTRAINT_OPERATOR = STARTS_WITH

TABLE_NAME = null

COLUMN_NAME = null

CONSTRAINT = PRIMARYKEY

CASE_SENSITIVE = true

MESSAGE = The specified table '<TABLE_NAME>' does not contain the required '<CONSTRAINT>' constraint.

disabled

0

database

DetectChangeType

Data Protection

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.

CHANGE_TYPE_LIST = dropTable,dropColumn

enabled

0

changelog

sql, xml, yaml, json

DynamoChangetypeAttributes

Data Protection

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.

DYNAMO_CHANGE_TYPE = null

disabled

0

changelog

sql, xml, yaml, json

DynamoDeleteDynamoTableCheck

Data Protection

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.

<None>

disabled

0

changelog

sql, xml, yaml, json

DynamoDeleteGlobalSecondaryIndexCheck

Data Protection

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.

<None>

disabled

0

changelog

sql, xml, yaml, json

MaxAffectedRowsAllowedDelete

Data Protection

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.

MAX_ROWS = 50

MESSAGE = <AFFECTED_ROWS> rows will be affected, which is more than the allowed '<THRESHOLD>' rows. The SQL statement is '<STATEMENT>'.

enabled

0

changelog

sql, xml, yaml, json

MaxAffectedRowsAllowedInsert

Data Protection

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.

MAX_ROWS = 50

MESSAGE = <AFFECTED_ROWS> rows will be affected, which is more than the allowed '<THRESHOLD>' rows. The SQL statement is '<STATEMENT>'.

enabled

0

changelog

sql, xml, yaml, json

MaxAffectedRowsAllowedUpdate

Data Protection

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.

MAX_ROWS = 50

MESSAGE = <AFFECTED_ROWS> rows will be affected, which is more than the allowed '<THRESHOLD>' rows. The SQL statement is '<STATEMENT>'.

enabled

0

changelog

sql, xml, yaml, json

ModifyDataTypeWarn

Data Protection

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

MongoChangetypeAttributes

Data Protection

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.

MONGO_CHANGE_TYPE = null

disabled

0

changelog

xml, yaml, json

PrimaryKeyOnCreateTable

Data Protection

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.

EXCEPTIONS_LIST =

CASE_SENSITIVE = true

enabled

0

changelog

sql, xml, yaml, json

SqlSelectStarWarn

Data Protection

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

TableColumnLimit

Data Protection

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.

MAX_COLUMNS = 50

enabled

0

changelog, database

sql, xml, yaml, json

OracleReservedKeywords

Database Compatibility

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.

OBJECT_TYPES = null

ALLOWED_LIST = null

CASE_SENSITIVE = true

disabled

0

changelog, database

xml, yaml, json

PostgresNonReservedKeywords

Database Compatibility

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.

OBJECT_TYPES = null

ALLOWED_LIST = null

CASE_SENSITIVE = true

disabled

0

changelog, database

xml, yaml, json

PostgresReservedKeywords

Database Compatibility

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.

OBJECT_TYPES = null

ALLOWED_LIST = null

CASE_SENSITIVE = true

disabled

0

changelog, database

xml, yaml, json

SQLServerFutureReservedKeywords

Database Compatibility

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.

OBJECT_TYPES = null

ALLOWED_LIST = null

CASE_SENSITIVE = true

disabled

0

changelog, database

xml, yaml, json

SQLServerODBCReservedKeywords

Database Compatibility

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.

OBJECT_TYPES = null

ALLOWED_LIST = null

CASE_SENSITIVE = true

disabled

0

changelog, database

xml, yaml, json

SQLServerReservedKeywords

Database Compatibility

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.

OBJECT_TYPES = null

ALLOWED_LIST = null

CASE_SENSITIVE = true

disabled

0

changelog, database

xml, yaml, json

WarnOnUseDatabase

Database Compatibility

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

ChangesetAttributesAndValue

Metadata Content

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.

ATTRIBUTE = null

SEARCH_STRING = null

disabled

0

changelog

sql, xml, yaml, json

ChangesetAttributesSetTrueOrFalse

Metadata Content

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.

ATTRIBUTE = null

SEARCH_STRING = null

disabled

0

changelog

sql, xml, yaml, json

ChangesetCommentCheck

Metadata Content

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

ChangesetContextCheck

Metadata Content

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

ChangesetLabelCheck

Metadata Content

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

FormattedSqlHeaderRequired

Metadata Content

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.

SQL_FILE_EXCEPTIONS_LIST =

enabled

0

changelog

sql, xml, yaml, json

RequireChangesetIDisUUID

Metadata Content

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.

<None>

disabled

0

changelog

sql, xml, yaml, json

TableCommentCheck

Metadata Content

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.

<None>

disabled

0

changelog, database

sql, xml, yaml, json

TableCommentPatternCheck

Metadata Content

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.

OPERATOR = CONTAINS

SEARCH_STRING = null

MESSAGE = A match for regular expression <SEARCH_STRING> was detected in <IDENTIFIER>.

disabled

0

changelog, database

sql, xml, yaml, json

UserDefinedContextCheck

Metadata Content

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.

OPERATOR = STARTS_WITH

SEARCH_STRING = null

disabled

0

changelog

sql, xml, yaml, json

UserDefinedLabelCheck

Metadata Content

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.

OPERATOR = STARTS_WITH

SEARCH_STRING = null

disabled

0

changelog

sql, xml, yaml, json

CheckRunInTransactionValue

Scripting Standards

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.

RUN_IN_TRANSACTION_VALUE = false

MESSAGE = A match for regular expression <SEARCH_STRING> was detected in Changeset <CHANGESET>.

enabled

0

changelog

sql, xml, yaml, json

EndDelimiterExistsWhenPatternExists

Scripting Standards

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.

SEARCH_STRING = null

CASE_SENSITIVE = true

STRIP_COMMENTS = true

MESSAGE = The pattern '<SEARCH_STRING>' was found without an end delimiter in Changeset '<CHANGESET>'.

disabled

0

changelog

sql, xml, yaml, json

ObjectNameMustMatch

Scripting Standards

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.

OPERATOR = STARTS_WITH

SEARCH_STRING = null

OBJECT_TYPES = null

CASE_SENSITIVE = true

disabled

0

changelog, database

sql, xml, yaml, json

ObjectNameMustNotMatch

Scripting Standards

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.

OPERATOR = STARTS_WITH

SEARCH_STRING = null

OBJECT_TYPES = null

CASE_SENSITIVE = true

disabled

0

changelog, database

sql, xml, yaml, json

OneChangePerChangeset

Scripting Standards

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

PatternAFollowedByPatternB

Scripting Standards

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.

PATTERN_A = null

PATTERN_B = null

CASE_SENSITIVE = true

MESSAGE = Match found: '<PATTERN_A>' is followed by '<PATTERN_B>' in Changeset '<CHANGESET>'.

STRIP_COMMENTS = true

disabled

0

changelog

sql, xml, yaml, json

PatternANotFollowedByPatternB

Scripting Standards

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.

PATTERN_A = null

PATTERN_B = null

CASE_SENSITIVE = true

MESSAGE = Match found: '<PATTERN_A>' is NOT followed by '<PATTERN_B>' in Changeset '<CHANGESET>'.

STRIP_COMMENTS = true

disabled

0

changelog

sql, xml, yaml, json

PatternANotPrecededByPatternB

Scripting Standards

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.

PATTERN_A = null

PATTERN_B = null

CASE_SENSITIVE = true

MESSAGE = Match found: '<PATTERN_A>' is NOT preceded by '<PATTERN_B>' in Changeset '<CHANGESET>'.

STRIP_COMMENTS = true

disabled

0

changelog

sql, xml, yaml, json

PatternAPrecededByPatternB

Scripting Standards

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.

PATTERN_A = null

PATTERN_B = null

CASE_SENSITIVE = true

MESSAGE = Match found: '<PATTERN_A>' is preceded by '<PATTERN_B>' in Changeset '<CHANGESET>'.

STRIP_COMMENTS = true

disabled

0

changelog

sql, xml, yaml, json

RollbackRequired

Scripting Standards

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.

<None>

enabled

0

changelog

sql, xml, yaml, json

SqlUserDefinedPatternCheck

Scripting Standards

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.

SEARCH_STRING = null

MESSAGE = A match for regular expression <SEARCH_STRING> was detected in Changeset <CHANGESET> in changelog path <PATH_FILTER_REGEX>.

STRIP_COMMENTS = true

PATH_FILTER_REGEX = null

SPLIT_STATEMENTS = false

disabled

0

changelog

sql, xml, yaml, json

PIIcomputerAndDate

Sensitive Data

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.

COMPDATE_IDENTIFIERS = ALL

MESSAGE = Policy violation: raw {filter_type} detected in {stmt_type} at statement #{statement_number}, line {line_number}, positions {start}-{end}.{file_line_info}

DATE_VALIDATE = false

enabled

0

changelog

sql, xml, yaml, json

PIIfinancial

Sensitive Data

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.

FINANCIAL_IDENTIFIERS = BANK_ROUTING_NUMBER, BITCOIN_ADDRESS, CREDIT_CARD, CURRENCY, IBAN_CODE, TRACKING_NUMBER, VIN

MESSAGE = You can not include credit card information in the database.

CREDIT_CARD_VALIDATE = true CREDIT_CARD_IGNORE_UNIX_TIMEST

AMP = true

IBAN_ALLOW_SPACES = true

enabled

2

changelog

sql, xml, yaml, json

PIIhealth

Sensitive Data

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.

HEALTH_IDENTIFIERS = ALL

MESSAGE = Policy violation: raw {filter_type} detected in {stmt_type} at statement #{statement_number}, line {line_number}, positions {start}-{end}.{file_line_info}

enabled

0

changelog

sql, xml, yaml, json

PIIlocation

Sensitive Data

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.

LOCATION_IDENTIFIERS = ALL

MESSAGE = Policy violation: raw {filter_type} detected in {stmt_type} at statement #{statement_number}, line {line_number}, positions {start}-{end}.{file_line_info}

ZIP_CODE_VALIDATE = false

enabled

0

changelog

sql, xml, yaml, json

PIIpersonal

Sensitive Data

Identifies highly-sensitive Person-centered information, helping avoid PII (Personally Identifiable Information) data exposure, and supporting audit and authorization requirements in highly-regulated environments.

PERSONAL_IDENTIFIERS = ALL

MESSAGE = Policy violation: raw {filter_type} detected in {stmt_type} at statement #{statement_number}, line {line_number}, positions {start}-{end}.{file_line_info}

EMAIL_VALIDATE_RFC = true

EMAIL_VALIDATE_TLD = false

enabled

0

changelog

sql, xml, yaml, json

SensitiveInfoCheck

Sensitive Data

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.

IDENTIFIERS = null

MESSAGE = Policy violation: raw {filter_type} detected in {stmt_type} at statement #{statement_number}, line {line_number}, positions {start}-{end}.{file_line_info}

disabled

0

changelog

sql, xml, yaml, json