Security disclosure

Security and Product Disclaimer

FFDB is designed around explicit authorization and isolation boundaries, but safe operation still depends on deployment configuration, providers, patching, backups, and application policy. This page states the public reporting path and the claims FFDB does not make.

Effective August 3, 2026

1. The documented security model

FFDB keeps organization and project control-plane state in PostgreSQL, uses a separate SQLite application database per project, constrains SQL in isolated workers, applies supported row-level policies, and authorizes S3-compatible operations through short-lived provider requests. Authentication, sync, backup, billing, provider, proxy, and administrative paths remain part of the security boundary.

The production-security documentation and repository threat model describe the intended boundaries. They are engineering inputs, not a certification or a guarantee that any particular deployment is secure.

2. Operator responsibility

  • Terminate TLS at a reviewed boundary and keep PostgreSQL, worker IPC, direct Axum diagnostics, project files, metrics, and backups private.
  • Generate independent secrets, protect provider credentials, restrict administration, and rotate credentials after suspected exposure.
  • Configure exact storage origins, CORS, email, Stripe webhooks, trusted proxies, limits, and row-level policies for the deployment.
  • Verify signed releases, apply supported security updates, and test rollback before an internet-facing upgrade.
  • Run adversarial isolation, authorization, backup, restore, and provider-boundary acceptance tests against the deployed topology.

3. Report a suspected vulnerability privately

Use the official GitHub repository's private vulnerability-reporting or security-advisory channel when it is available. If that channel is unavailable, email admin@forever-frameworks.com with "FFDB security" in the subject. Do not open a public issue until the report has been assessed and coordinated disclosure is agreed.

Include the affected release or commit, prerequisite configuration, reproducible steps, impact, and a suggested mitigation if known. Remove credentials, access tokens, signed URLs, customer records, and production database content. Use synthetic data and the minimum evidence needed to reproduce the problem.

4. Research boundaries

Do not access another person's account or deployment, impair availability, run denial-of-service tests, use social engineering, send malware, persist after proving impact, or exfiltrate data. Testing must stay within systems you own or have explicit permission to assess. This page does not create a bug bounty, payment promise, safe-harbor commitment, or response deadline.

5. Disclosure process

We aim to acknowledge enough information to begin triage, reproduce valid reports, develop and test a fix, identify affected releases, and coordinate publication. Complexity, incomplete reproduction, dependency ownership, and release safety can affect timing. Do not assume a report is accepted or a fix is complete until that is confirmed through the private channel or an official release advisory.

6. Supported versions and authentic artifacts

The repository SECURITY.md and official release notes are the source of truth for supported versions and security fixes. Do not infer support from an npm version, container tag, branch, fork, cached documentation page, or similarly named package.

Install through official tagged releases, verify checksums and Sigstore material, keep immutable version pins, and review the release manifest. Report suspicious packages, signatures, download redirects, or repository impersonation privately.

7. Secrets and reports

Never place bootstrap tokens, signing material, Stripe or storage secrets, JWT keys, database credentials, backups, or live user information in issues, screenshots, logs, or example projects. Revoke and rotate any secret included in a report; deleting a message does not guarantee the value was never copied or logged.

8. No certification or compliance claim

FFDB does not claim SOC 2, ISO 27001, PCI DSS, HIPAA, FedRAMP, or another formal certification in the current repository materials. Features such as encryption support, row-level policy enforcement, audit-oriented records, signed releases, or Stripe integration do not make an operator compliant. Compliance depends on the complete deployed system, policies, people, contracts, providers, and evidence.

9. Product and security disclaimer

FFDB Software is provided under Apache-2.0, including that license's warranty and liability terms. Public documentation and examples are provided for general engineering information and may not cover every threat, dependency failure, migration, jurisdiction, or application requirement.

No security control eliminates all risk. You remain responsible for architecture review, data classification, legal requirements, capacity limits, application logic, incident response, provider configuration, and recovery testing. Do not use a passing test suite or a statement on this site as the sole basis for a high-risk deployment decision.

10. Security resources