Security

1. Infrastructure

• The platform runs on Amazon Web Services in the Asia Pacific (Mumbai) region.
• Compute and database resources run inside a private network with no public addressing; public traffic reaches the platform only through the API gateway and the content delivery network.
• A managed web application firewall sits in front of the public entry points, with managed rule sets and per-address rate limiting.
• Infrastructure is defined as code and changed by deployment, not by hand. There is no interactive shell access to production servers.

2. Data protection

• All traffic is encrypted in transit with TLS. Insecure transport is refused, not downgraded.
• Data is encrypted at rest, with customer data held in buckets and databases encrypted using managed keys.
• Databases run across multiple availability zones with automated backups and a defined retention window.
• Personal data is classified, and the handling rules for each classification are enforced in code review and in the logging rules below.

3. Authentication and access

• User authentication is handled by a managed identity provider. We never see or store your password.
• Every request to a protected endpoint has its token signature, expiry, issuer and audience validated before any application code runs.
• Authorisation is enforced in the application layer against roles and permissions, not only at the edge.
• Machine access uses OAuth 2.0 client credentials. There are no shared static API keys for internal service communication.
• Tenant isolation is resolved from the authenticated principal on every request and is never accepted from client input.

4. Secrets

• Credentials live in a managed secret store, never in source code, environment variables, configuration files or infrastructure state.
• Access to a secret is granted to a specific role, by exact resource, and is audited.
• Secrets are never written to logs in any form — not masked, not truncated, not partially.
• There is no interface, including for administrators, that reads a stored credential back out of the platform. A lost credential is replaced, not recovered.

5. Payments

• Card details are collected and stored by our payment provider. They never reach ZenOrbit’s systems, so we hold no cardholder data.
• Incoming payment notifications are authenticated by cryptographic signature over the exact received payload, compared in constant time, and are rejected outright if the signature is missing or wrong.
• Payment notifications are processed idempotently, so a redelivery is acknowledged without being applied twice.
• Payment records are reconciled against the provider on a schedule; disagreements are raised for a person to judge rather than automatically corrected.

6. Software supply chain

• Dependency vulnerability scanning runs on every change, and high or critical findings fail the build.
• Container images are scanned before they can be deployed, and the scan is a blocking gate.
• Security gates are never bypassed, downgraded or ignored in order to ship. A failing gate is fixed.
• Dependencies are pinned, and updates are reviewed rather than applied blindly.

7. Monitoring

• Structured logs, distributed tracing and per-service metrics across the platform.
• Alerts on error rates, latency and failed background processing, each with a written response procedure.
• Logs exclude credentials, tokens and personal data; records are referenced by identifier instead.

8. Reporting a vulnerability

If you believe you have found a security issue, please tell us before telling anyone else. Write to support@zenorbit.app with the subject line beginning SECURITY, and include enough detail to reproduce it.

What we commit to in return:

• We will acknowledge your report as quickly as we can.
• We will keep you updated on what we find and when it is fixed.
• We will not pursue legal action against you for good-faith research that respects the limits below.

Please, while testing:

• Use only accounts you own. Do not access, modify or retain anyone else’s data.
• Do not run denial-of-service tests, automated scanning at volume, or social engineering against our people or our providers.
• Give us a reasonable opportunity to fix the issue before publishing it.

We do not currently operate a paid bug bounty. We do say thank you, properly, and we mean it.

9. What we do not claim