v2.0 is feature-complete across all three platforms (SQL Server, PostgreSQL, MySQL) and replaces v1 with no upgrade cost. v1.x is no longer maintained.

Do not open a public issue for security vulnerabilities.

Instead, please report security issues by emailing security@schemasmith.com with:

• Description of the vulnerability
• Steps to reproduce
• Affected tool(s) and version(s)
• Impact assessment if known

You should receive an acknowledgment within 48 hours. We will work with you to understand the issue and coordinate a fix before any public disclosure.

SchemaSmith tools connect to SQL Server, PostgreSQL, and MySQL databases and execute SQL. Security-relevant areas include:

• Connection credential handling — passwords are redacted in logs, but configuration files may contain credentials
• SQL generation — tools generate and execute dynamic SQL against target databases
• File handling — tools read schema packages from disk or ZIP archives

SchemaSmith is an operator-run command-line tool, intended to be run by an operator against databases and schema definitions that operator controls. In the normal case, schema definitions (table JSON, Project.json, configuration) and the chosen target connections are trusted inputs.

Hardening therefore focuses on the surfaces where input may originate from a less-trusted source than the operator's own authored schema:

• Identifiers read from a database via introspection (catalog views / INFORMATION_SCHEMA) are bound as query parameters rather than interpolated into SQL, so identifier contents cannot alter the introspection queries.
• Template and content-file references that may come from externally-authored or distributed schema packages are constrained to the template's own directory tree during path resolution.

Running SchemaSmith against a schema package or database you do not trust is outside the intended operating model; the hardening above reduces — but does not eliminate — that risk. Treat untrusted schema packages with the same caution you would any untrusted code or configuration.

• Prefer your platform's strongest non-password authentication over storing credentials in config files: Windows integrated authentication or Azure AD on SQL Server, Kerberos / GSSAPI or SCRAM-SHA-256 on PostgreSQL, socket auth or PAM auth on MySQL
• Restrict file system permissions on configuration files containing credentials
• Use environment variables (SmithySettings_ prefix) for sensitive settings in CI/CD pipelines
• Review WhatIf output before applying changes to production databases

For how the tools behave in your environment, how releases are built and verified, and answers to common security-review questions, see SECURITY-POSTURE.md.