At Moztopia, the integrity of our software, pipelines, and data is paramount. We take security vulnerabilities seriously and strive to isolate, track, and remediate them before they hit production.

This document outlines how to report potential vulnerabilities, how our automated systems scan for secrets, and the explicit governance surrounding emergency infrastructure overrides.

We only maintain and patch active release lines present in our main repository (.github). Historical snapshots archived in .github-archives under the custom refs/archives/ namespace are passive, read-only audit records and will not receive security updates.

Moztopia enforces a Zero-Secret Policy across all repository branches. Our CI/CD pipeline executes automated static application security testing (SAST), dependency scans, and secret detection tools during the development cycle.

• Bypass Restrictions: Automated scans trigger on all candidate/develop/, candidate/staging/, and candidate/main/* promotion branches. Passing scans are hard prerequisites for any Pull Request approval.
• Sandbox Isolation: The wip/sandbox branches bypass automated CI/CD checks to allow developers room to iterate. However, committing hardcoded API keys, database credentials, or unencrypted private keys to a wip/ branch is a direct violation of our Code of Conduct. Use local environment configuration files (.env) wrapped in .gitignore.

If you discover a security vulnerability, do not open a public issue on our repository issue trackers. Doing so exposes Moztopia infrastructure and user data to exploitation before a patch can be deployed.

1. Draft a Private Report: Document the nature of the vulnerability, the affected code path, step-by-step instructions to reproduce the issue, and a proof-of-concept (PoC) if available.
2. Submit Privately: Email your report to our dedicated security triage team at security@moztopia.com.
3. PGP Encryption (Optional but Recommended): For highly sensitive exploits, encrypt your message using our public PGP key available at https://moztopia.com/security/pgp.asc.

• Acknowledgement: A Moztopia security officer will acknowledge receipt of your private report within 24 hours.
• Triage & Validation: The triage team will validate the exploit within 48 hours and provide an estimated remediation timeline.
• Disclosure: Moztopia operates on a 90-day coordinated vulnerability disclosure policy. We will coordinate a public release notes update only after a verified fix has successfully transitioned through develop and staging into main.

When a critical security incident or live exploit occurs in production requiring immediate remediation, standard promotion pipelines can be bypassed using our Path B Emergency Hotfix protocol. This is a highly sensitive operational state that triggers strict tracking.

• Branching Constraint: The fix must be cut into a hotfix/{issue-number} branch directly from the compromised commit on main.
• Dual-Sign Approval Required: An administrative push directly to the protected main branch is entirely blocked by default. Overriding this restriction requires mutual cryptographic or system sign-off from both:

1. A Lead Developer (validating architectural stability and minimal diff footprint).
2. A Security Officer (authorizing the administrative bypass token override).

The moment a Path B Hotfix is forced into main, the local architecture state shifts out of alignment with our development pipelines.

🚑 Mandatory Back-Merge: To prevent regression and maintain architectural integrity, the authorized administrator must immediately pull the hotfix commit(s) down and merge them into both develop and staging branches.

Every security action, repository modification, archive push, and administrative override is permanently recorded.

• WORM Architecture: All CI/CD execution records, pipeline run results, and administrative bypass logs are written directly to an append-only, external central logging engine with Write-Once-Read-Many (WORM) storage configurations.
• Tamper Protection: These logs cannot be modified, deleted, or cleared by any user account, including system administrators. They are retained for a minimum of 1 year to ensure complete audit compliance and absolute accountability.