Security Policy

Last updated: July 2026

1. Reporting a vulnerability

If you believe you've found a security vulnerability in Git-Zen, email security@git-zen.com with a description of the issue, steps to reproduce, and any relevant logs or screenshots. We ask that you:

• Give us a reasonable window to investigate and remediate before any public disclosure.
• Avoid accessing, modifying, or deleting data that isn't your own while testing.
• Avoid automated scanning or load testing that could degrade the service for other customers.

We acknowledge new reports within 2 business days and aim to provide an initial assessment within 5 business days. We do not currently run a paid bug bounty program, but we credit researchers who report valid issues responsibly, with their permission.

2. Vulnerability management

• Dependency scanning. Application dependencies are monitored for known vulnerabilities, and updates are applied on a regular cadence, with critical or actively exploited issues patched on an expedited basis.
• Code review. Changes to the Git-Zen codebase go through review before deployment.
• Severity triage. Reported and discovered vulnerabilities are triaged by severity (impact and exploitability) to determine remediation priority and timeline.
• Patching. Critical vulnerabilities in Git-Zen infrastructure or dependencies are prioritized for same-week remediation. Lower-severity issues are addressed in the normal release cycle.

3. Security incident response

We maintain an incident response process covering detection, containment, remediation, and notification:

• Detection. Application and infrastructure logs are monitored for anomalous activity, failed authentication patterns, and service errors.
• Containment and remediation. Confirmed incidents are contained (revoking credentials, isolating affected systems, or rolling back a change) and the root cause is fixed before we consider the incident resolved.
• Customer notification. If an incident affects your data, we notify your account admin without undue delay, typically within 72 hours of becoming aware of the issue, with the information we have at the time. This mirrors the notification commitment in our Privacy Policy.
• Post-incident review. After resolution, we review what happened and what changes (technical or process) reduce the chance of recurrence.

4. Encryption

• In transit. All connections to Git-Zen, between Git-Zen and Zendesk, and between Git-Zen and your engineering tool use TLS 1.2 or higher.
• At rest. Connection credentials and customer-identifying configuration are encrypted at rest in our database. Backups are encrypted.
• Secrets. OAuth refresh tokens and Personal Access Tokens are stored encrypted with keys held outside the application database, and are never logged or exposed in plaintext.

5. Access controls

• Least privilege. Access to production systems and customer data is restricted to the Git-Zen engineering team members who need it to operate the service or respond to support.
• Authentication. Administrative and infrastructure access requires strong authentication; we do not share standing credentials across team members.
• Auditability. Access to production systems is logged. We do not grant production database access to sales, marketing, or any third party.
• Offboarding. Access is revoked promptly when a team member's role changes or they leave.

6. Infrastructure and hosting

Git-Zen runs on US-based infrastructure operated by Third South Capital. Infrastructure and network configuration are managed to limit exposed surface area, with production systems isolated from development and staging environments. We rely on the security controls of our infrastructure and sub-processor vendors as a baseline, and layer application-level controls (encryption, access restriction, logging) on top.

7. Application security practices

• Authentication to third-party services (GitHub, GitLab, Azure DevOps, Linear, Jira) uses OAuth where the provider supports it, or Personal Access Tokens scoped as narrowly as the provider allows.
• Zendesk-side requests are validated using Zendesk's signed-request mechanism.
• Input from Zendesk tickets and connected engineering tools is treated as untrusted and validated before use in sync operations.
• Backups are taken regularly and tested for restorability.

8. Sub-processors

Git-Zen uses a small number of trusted sub-processors to run the service: a US cloud hosting provider for compute and storage, a payment processor for billing, an email sender for transactional support replies, and a privacy-respecting analytics tool for aggregate page metrics. Each is evaluated for its own security practices before we rely on it. The current list is available on request to security@git-zen.com. See our Privacy Policy for what data each sub-processor may handle.

9. Your responsibilities

Git-Zen's security depends in part on how it's configured on your side:

• Grant Git-Zen only the Zendesk admin roles and third-party scopes it actually needs.
• Use the shortest reasonable expiration on Personal Access Tokens, and rotate them periodically.
• Remove Git-Zen's access promptly if you stop using it or change engineering tools.
• Report anything that looks like unauthorized access to your Git-Zen configuration to security@git-zen.com.

10. Changes to this policy

If we make material changes to this policy, we will update the "Last updated" date at the top of this page.

11. Contact

Vulnerability reports and other security questions: security@git-zen.com.