Only the latest state of the main branch and the active production deployment manifests receive security updates.

This policy covers security issues in:

Issues in the application code itself (SynapsVault/backend, SynapsVault/frontend, SynapsVault/contracts) should be reported to those repositories.

Please do not use public GitHub issues, discussions, or pull requests to report security vulnerabilities.

1. Go to the Security tab of this repository.
2. Click Report a vulnerability.
3. Fill in the advisory form with the details below.

GitHub will notify the maintainers privately and open a draft security advisory.

Send a report to security@synapsvault.xyz with the subject line:

[SECURITY] <short description>

Include:

• Affected component: which directory or file (e.g., scripts/backup.sh, k8s/secrets.yaml, .github/workflows/deploy-k8s.yml).
• Reproduction steps: the minimal sequence of actions to trigger the issue.
• Proof of concept (if applicable): a script, manifest diff, or screenshot.
• Potential impact: what an attacker could do if they exploited this.
• Suggested remediation (optional): your recommended fix.

Redact any real secrets, keys, or connection strings before sending.

We follow coordinated vulnerability disclosure. If a fix requires more than 30 days we will communicate a revised timeline.

Follow these rules in all contributions to this repository.

• Zero secrets in Git. Never commit .env, secrets.env, kubeconfig, Stellar secret keys (S...), service-role JWT tokens, or unencrypted database dumps.
• k8s/secrets.yaml is a placeholder template only and must never be added to k8s/kustomization.yaml or pushed with real values.
• Use node scripts/check-env.js before deploying to catch placeholder values (e.g. REPLACE_ME_*, change-me-*, S[X...], C[X...]) that were never replaced.
• The CI secrets job runs gitleaks on every push and pull request. A gitleaks finding blocks merging.

• Production backups (scripts/backup.sh) must use gpg or age encryption. BACKUP_ENCRYPTION_METHOD=none is forbidden in production.
• Backup archives are uploaded to S3 with server-side encryption. Never store unencrypted dumps in a public bucket.

• Contract deployments (scripts/deploy-contracts.cjs) and database restores (scripts/restore.sh) require explicit operator confirmation (interactive prompt or --yes flag) before modifying live state.
• The STELLAR_NETWORK environment variable must be set to mainnet explicitly — scripts default to testnet.

• Dependencies are pinned to exact versions in package.json and package-lock.json. Open-ended ranges (^, ~) require maintainer approval.
• Dependabot is configured to open weekly PRs for dependency updates (.github/dependabot.yml).
• Container images built in CI are scanned with Trivy; any unfixed CRITICAL CVE fails the build.
• Images pushed to production are signed with cosign (keyless, Sigstore).

• All GitHub Actions workflows use the minimum required permissions scope. contents: read is the default; write access is granted only where explicitly needed (e.g., pushing images, uploading SARIF).
• Secrets are never echoed in workflow logs (set -x is prohibited in run: blocks that handle secrets).

Changes to the following areas require a review comment explaining the security implications:

• k8s/secrets.yaml or any file that touches how secrets are injected
• .github/workflows/ — any change to how secrets are consumed or exported
• scripts/backup.sh or scripts/restore.sh
• scripts/deploy-contracts.cjs (mainnet guard logic)
• Dockerfile USER, RUN, or COPY instructions that affect the runtime attack surface

Tag such PRs with the security label so they receive a dedicated review.