Skip to content

Security & disclosure

How to report a vulnerability, and what AppGantry does on its side of the line.

Reporting a vulnerability

Email security@appgantry.com.

We publish a machine-readable security.txt following RFC 9116 on every AppGantry host. This documentation site serves it at /.well-known/security.txt and, for older scanners, at /security.txt; both copies are byte-identical and each names both locations in its Canonical fields, so a retrieval from either one validates. The REST API serves its own copy at https://api.appgantry.com/.well-known/security.txt.

What helps:

  • What you found, and why it matters.
  • Reproduction steps precise enough for us to follow.
  • Affected URLs, endpoints, or app areas.
  • Anything you observed that you weren't supposed to see.

What we ask:

  • Report it to us before disclosing it publicly, and give us reasonable time to fix it.
  • Use your own account and your own organization for testing.
  • Don't access, modify, or exfiltrate other customers' data. If you stumble into someone else's data while proving an issue, stop, and tell us exactly what you saw.
  • Don't run denial-of-service tests, spam, or social engineering against our staff or customers.

We'll acknowledge your report and keep you informed as we work on it.

Not a support channel

For account problems, billing questions, or things that are broken but not a security issue, email support@appgantry.com. Security reports get routed differently and there's no benefit to sending support requests there.

What AppGantry protects

Credentials

  • Access tokens are short-lived (10 minutes).
  • Refresh tokens are single-use. Presenting one twice is treated as theft: the whole token family descended from that sign-in is revoked, so the legitimate client and whoever replayed the token are both signed out of it. See Authentication.
  • Personal, project, and SDK secrets are shown once and stored hashed. We cannot show them to you again, which also means we cannot leak them back to someone impersonating you.
  • Passkeys and TOTP are available to every developer, and organizations can require MFA of their members. See MFA, passkeys & sessions.

Build artifacts

  • Uploads and downloads use short-lived signed URLs, not long-lived public links.
  • The SHA-256 you supply at upload-complete is recorded as the build's integrity fingerprint, so you can compare it later against a copy you downloaded. AppGantry does not recompute the digest from the stored bytes, so it will not reject a mismatched checksum for you — the fingerprint is evidence, not a gate. What is checked server-side is the stored object's size, against the artifact cap. See Uploading a build.
  • Over-the-air install manifests and download links expire in minutes, not days. See Build lifecycle.

Access

  • Every operation is scoped to an organization or project role. See Authorization.
  • Anonymous install links grant access to exactly one release and nothing else, and can be turned off.
  • Security-relevant actions are recorded in an audit trail you can read and export. See Audit events.

Transport

Everything is served over HTTPS.

Your side of the line

Security is shared. The parts you own:

  • Protect your tokens. A personal access token acts as you. Store tokens in your CI system's secret store, never in the repository. See CI with project access tokens.
  • Scope tokens minimally. A CI pipeline that uploads builds needs Upload Build, not Admin.
  • Rotate on departure. When someone leaves, remove their membership and revoke tokens they created. Membership removal doesn't revoke a project access token, because the token belongs to the project.
  • Review sessions and passkeys periodically.
  • Watch your audit feed. It's there so you notice things.
  • Treat SDK app secrets as public. They ship in your binary by design. Their authority is deliberately narrow. Don't put anything else in your app that you'd mind a stranger reading.

BYOSA and the trust boundary

With BYOSA, build artifacts live in your storage account. That changes the boundary in ways worth being explicit about:

  • You control the data. Retention, geography, encryption keys, network rules, and legal hold are yours.
  • AppGantry holds delegated access, scoped to the container you designate, in order to write uploads and mint short-lived download URLs.
  • You can revoke it. Removing the delegation stops AppGantry accessing your storage. Builds stay where they are; AppGantry can no longer serve them, so installs and downloads will fail until access is restored.
  • Metadata stays with AppGantry. Project names, release history, tester lists, and audit records live in AppGantry regardless of where bytes are stored.

Final activation of a BYOSA connection is assisted by AppGantry after automated validation, which is a deliberate check rather than an oversight.

Confirming the app you are consenting to

BYOSA onboarding asks a tenant admin to grant admin consent to an AppGantry multi-tenant application. So that you can check what you are consenting to without taking a link at face value, these are the identifiers we publish:

Property Value
Display name AppGantry BYOSA Access
Application (client) ID 63c04479-2f32-4a1d-909c-b546d98bc4c8

Both are public identifiers, not secrets. After consent, the enterprise application should appear in Azure Portal → Enterprise applications under that display name with that application ID. If what you see doesn't match, stop and contact support@appgantry.com through a channel you initiated — not a link in an email.

The application itself holds no credential of yours: it can do nothing until you assign it a role on a specific container, and it loses all access the moment you remove that role assignment. See BYOSA setup for the step-by-step.

Availability and degraded modes

Some responses tell you the platform is temporarily unable to do something rather than that you did something wrong:

  • 503 with storage_backend_unavailable — the storage backend isn't reachable. May carry Retry-After.
  • 429 — you're being rate limited at the edge. See Rate limits.
  • 402 — a billing state is blocking writes. The organization-level write locks carry a lock_reason; the per-request gates don't. Existing builds stay reachable in every case except trial_ended, which also refuses downloads until a payment method is added. See Errors.

None of these mean data loss. Retry with backoff, and if a 503 persists, tell us.

Data handling

  • Export. Download a copy of your personal data, subject to the published limits on how often a fresh copy can be generated. See Account & data management.
  • Deletion. Account deletion locks you out immediately, runs a cancellation window, then removes your profile, credentials, tokens, sessions, and memberships.
  • Retention. Build artifacts are retained for 30 days on Team and 365 days on Business. Audit records are retained for 90 days on Team and 365 days on Business — a different window, not the same one. See Build lifecycle and Audit events.

See also