Start here - our help center has everything you need to get started and answer many commonly asked questions.
Kinde takes security threats very seriously as the integrity, confidentiality, and availability of our systems potentially impact our customers. If you have detected a security threat or vulnerability against Kinde systems or personnel, please reach out to your account manager or to the security mailing group at firstname.lastname@example.org.
Kinde production services are designed to be resistant to failure with multiple frontend servers and replicated backend databases. Currently, all frontend and backend services are being run from the AWS Sydney region across multiple availability zones for redundancy.
Kinde will be performing a disaster recovery test in the near future to ensure that services can be recovered from a catastrophic failure. RTO and RPO metrics will be documented publicly for customers once the test has been completed.
All customer data at rest is encrypted in the Kinde production databases using the industry standard AES256 encryption algorithm. Encryption is facilitated by AWS KMS with access to administer KMS strictly limited to privileged admins.
All network traffic to Kinde production services uses TLS 1.2 or greater with a limited set of modern secure ciphers enforced. Security headers are applied to all production endpoints where possible.
Currently Kinde has not conducted an external third party audit based on industry recognized frameworks such as Cloud Security Alliance STAR, SOC2, or ISO27001. From the beginning, Kinde has strived to embed consistent and modern security and privacy best practices throughout the business across all departments and disciplines. The company’s security strategy is based off the Cloud Security Alliance’s STAR framework, which also heavily overlaps with SOC2 and feeds nicely into ISO27001. As Kinde grows with our founders, we will engage with a third party auditor to help provide assurance and certification of the great work that’s already happening.
Internal identity is generally managed through the company’s single sign-on (SSO) platform provided by Google Workspace. All systems are connected to the company SSO platform where supported. Multi-factor authentication is enforced for all users, audit logs are enabled and monitored for systems connected to the company SSO. For systems that do not support SSO, employees are required to use the company provided password manager to generate and manage secure credentials as well as enable MFA for added protection.
Access to systems is based on the employee’s job role with the least privileges assigned. Privileged access to any system is strictly limited based on the employee’s job role and accounts are individual to that user only.
All employees are required to review and acknowledge the Kinde Information Security Policy, which includes categories such as Acceptable Use, Identity and Access Management, Data Classification, and Security Incident Response. The Information Security Policy cannot be shared publicly, however please feel free to reach out if there are any questions about the content and controls outlined in the policy.
As part of the preparation for General Availability, Kinde will be engaging a third party security service to perform a network and web application penetration test. Findings will be analysed by the Engineering team and remediations actioned based on severity and vulnerability managements SLAs.
All Kinde source code is managed by a company managed source code repository. Source code is scanned using a suite of open source tools provided by the golangci-lint, in particular the gosec module, which will alert on insecure coding that could lead to vulnerabilities. Access to the source code repository is restricted based on job role with the identity linked to the company single sign-on platform. Merges to source code require a peer review. Pull requests to the master branch are performed by senior engineers.
Production services are deployed through a CICD pipeline using container technology. Server builds are done at least once a week and replace the existing servers. The build process will use the latest patched container host and container image to reduce the risk of vulnerabilities due to unpatched software.
All container images are scanned at build using AWS Inspector for dependencies and third party library vulnerabilities. External production URLs are scanned weekly for public facing vulnerabilities. All vulnerability reports are triaged, analysed, and assigned to the engineering team for remediation based on vulnerability management SLAs.