Security operations

Keep release signing keys and customer certificate signing keys separate, offline where practical, and outside Git. Verification must use a trusted key provided by the deployment operator; never trust a key shipped inside the artifact as the root of trust.

Do not commit .env, credentials, payment secrets, webhook secrets, customer backups, or production media. Rotate any credential that has appeared in a repository, log, test fixture, or artifact.

Use separate credentials and storage in test or restored environments. Disable scheduled jobs, queues, email, payment capture, courier booking, accounting sync, seller payouts, and real webhook endpoints. Scrub personal data and define a deletion date for any restored copy.

Apply security updates through a tested release. Review dependency advisories, failed jobs, authentication events, webhook signature failures, export access, and backup freshness. Report suspected vulnerabilities through the private security route supplied by your organization or service agreement. If Vendorzo has supplied a named security contact for the installation, use that route; never post vulnerability details, credentials, or customer data publicly. Preserve relevant audit evidence.

Every distributable artifact includes SBOM.spdx.json, generated from the locked production Composer packages. Verify the signed manifest before using the SBOM or installing the artifact. Keep a verified database backup and a separate media recovery copy; a database backup alone does not preserve uploaded files.

Customer certificates use a versioned payload and a certificate-key identity; the certificate public key is not the release-artifact public key. Release archives are created with fixed timestamps, ownership, and sorted entries, and their detached SHA-256 checksum must be published with the signed artifact.