Compliance

Compliance is not a product you can buy. It is a state that must be demonstrated continuously through three elements:

• Configuration: whether security controls are enabled. Pigsty directly provides this part.
• Process: access approval, change management, recovery exercises, and related procedures. The organization must establish these.
• Evidence: records showing that configuration and process remain effective. Pigsty’s inventory, runtime logs, and monitoring system can provide part of this evidence.

This page begins with a pre-launch hardening checklist and then maps Pigsty security capabilities to common compliance frameworks. The mappings support architecture and gap analysis; they are not an MLPS assessment conclusion, a SOC 2 audit opinion, or legal advice.

Default Credentials Checklist

Pigsty default credentials are public in the documentation and source code. They are intended only for demonstrations and local development. Change every applicable default before any production or network-exposed deployment goes live:

Use -g while generating configuration to randomize built-in parameters and example strings recognized by the configuration wizard:

./configure -g     # Generate the inventory and randomize recognized default credentials

The wizard prints generated passwords to the terminal, so protect terminal history and automation logs as sensitive data. After generation, inspect the configuration and replace pgBackRest cipher_pass, MinIO example values in ha/safe that were not covered, and all custom credentials.

Launch Hardening Checklist

Before deployment:

• Define the network boundary: do not expose database ports publicly, and remove the demo firewall exception for 5432
• Select a certificate policy: use the built-in CA or integrate enterprise PKI; see Using an Enterprise CA
• Plan client verification: configure database clients with sslmode=verify-full and a trusted CA
• Design the account model: assign application accounts through the four-tier roles and declare expire_in
• Plan the backup repository, retention, encryption passphrase, and off-site copies
• Decide whether to use the ha/safe template and the CRIT parameter template

After deployment:

• Confirm that credentials covered by configure -g and uncovered backup, MinIO, and custom credentials have all been changed
• Review the effective HBA rules in /pg/data/pg_hba.conf against the declaration and intended boundary
• Query effective users, roles, default privileges, and database CONNECT grants, and compare them with the inventory
• Run one full backup and a recovery exercise to validate the backup path
• Confirm log collection, monitoring alerts, and notification channels

Periodically:

• Audit privileges: compare pg_users declarations with effective grants, and remove expired or departed-user accounts
• Rotate credentials and certificates
• Exercise recovery and failover
• Track security updates for Pigsty and upstream components

Compliance Evidence

Declarative configuration provides a stable starting point for audit evidence. Retain runtime state as well to show that the configuration was applied and remains effective.

MLPS Level 3 Mapping

The following maps database-related Pigsty capabilities to controls in the “secure computing environment” section of GB/T 22239-2019 Level 3:

MLPS also covers physical security, communication networks, and management systems beyond the scope of a database distribution. Pigsty can support database-related technical controls in a secure computing environment; facilities, network devices, and governance must be addressed in the overall system.

SOC 2 Mapping

Database-related controls in the SOC 2 Trust Services Criteria (TSC) include:

Supply Chain and Vulnerability Response

Compliance reviews increasingly cover the software supply chain. Pigsty provides the following distribution and response controls:

Package integrity: RPM and DEB packages in the Pigsty repositories (repo.pigsty.io and repo.pigsty.cc) are GPG-signed. The public-key fingerprint is 9592 A7BC 7A68 2E73 3337 6E09 E793 5D8D B9BD 8B20 (B9BD8B20) and can be verified before trust is established. Repository definitions written during deployment and the local repository on the INFRA node do not enforce signature verification for every package by default; review package-manager repository trust and signature settings in production.

Vulnerability response: report security issues privately through GitHub private vulnerability reporting or email, as documented in SECURITY.md. The project targets acknowledgment within three business days and an initial assessment within seven days.

Version support: security fixes ship with the latest stable release. Staying current is the standard way to receive them. Users who must remain on a version for longer can obtain extended support through subscription services.

Next

• 🛡️ Security Model: from the default baseline to hardening levels
• 🔰 Security Recommendations: minimum hardening for quick-start deployments
• 📄 ha/safe Template: hardening configuration example