Zabbix Security Policy

Zabbix follows a strict process when developing new versions of our software, according to the  Zabbix life cycle and release policy. All tasks are subject to strict standards imposed by Zabbix: 

• All Zabbix developers adhere to project  coding guidelines
• All code is reviewed by a senior developer before being merged into the Zabbix code base
• All tasks are tested by Quality Assurance engineers
• Root Cause Analysis is performed for found vulnerabilities and results are added to secure code trainings performed for developers to avoid similar vulnerabilities in the future.
• Zabbix Cloud development and testing environments maintain a separate access control, completely isolated from the production environment.
• No testing is ever done in Zabbix Cloud customer production environments, and account data/contact information as well as customer content (in Zabbix nodes) is never copied and used for testing/troubleshooting.

• A Zabbix node in the cloud is almost the same as a standalone version, and we provide you the latest version with fixed security vulnerabilities and findings from HackerOne and other sources.
• Zabbix Cloud is continuously scanned and assessed by internal tools and teams, and security issues are passed down to the infrastructure or development team to increase our security posture.
• Although the development process is designed to reduce security issues, it is still possible that new vulnerabilities might be discovered. Zabbix treats security issues in maintained versions as a high priority. Please note that Zabbix does not fix security issues in versions that are no longer supported. If this is required, it is custom development charged by an hourly rate.

To assure our customers that Zabbix is a well-managed and professional organization, that appropriate information security measures are applied as necessary, and that customers can trust the source code, our professional services, and our Zabbix Cloud service, Zabbix has: 

• Implemented a security program consistent with and conforming to the ISO/IEC 27001:2022 standard for Information Security Management
• Implemented the ISO/IEC 27017:2015 extension for cloud security controls
• Used other cybersecurity best practices to compliment the standard

Every customer's Zabbix instance is isolated from one another. 

Every customer's Zabbix instance data is on EBS volumes and encrypted at-rest with AES-256.

Every customer node uses Amazon Time Sync Service NTP pools (time.aws.com) as a time source.

AWS Snapshot technology and EBS encryption with AES-256 at-rest data encryption is used for customer backups.

All in-transit communications both internally and externally use at least TLS 1.2 and (where possible) TLS 1.3 certificates.

Zabbix Cloud provides multiple ways of user authentication:

Local accounts: Users can sign up with a valid email address and set their password in the Zabbix Cloud platform. OTP codes are used for security purposes.

Existing accounts: Users can also leverage their existing Github, Google, and Microsoft accounts to use Zabbix Cloud with the single sign-on functionality.

Customer passwords for local accounts are protected with a BCRYPT hashing algorithm, so Zabbix employees do not have access to your password and cannot retrieve it for you. The only option if you lose your password is to reset it.

In cases where Zabbix employees need to connect to a customer's backend or frontend components, review log files, solve any issue with Services, at a customer’s explicit request for technical support reasons, or as required by law, we use combination of enterprise grade key management services and secret management technologies. There are no standing privileges for engineers or support team. We practice Just-in-Time access for as brief a period as possible.  

Every employee working within Zabbix and accessing Zabbix Cloud in any way is using company owned and managed devices with XDR and at-rest encryption.

Multiple sets of best practices are used – systems are hardened using CIS, AWS VPC best practices, AWS IAM best practices, etc.

We have several internal solutions in place that are used for monitoring our systems, availability, performance, and other critical parameters.

System availability can be checked at https://cloud-status.zabbix.com/

Before reporting the issue:
Make sure that the issue you are submitting is not related to server configuration, 3rd party scripts and utilities. In order to avoid any possible issues with server configuration we advise Zabbix users to read Best practices for secure Zabbix setup.

To report a security issue, create a new issue in the Zabbix Security Reports (ZBXSEC) section of the public bug tracker describing the problem (and a proposed solution if possible) in detail. This way, we can ensure that only the Zabbix security team and the reporter have access to the case.

The following information will be helpful for the Zabbix Security team:

• Date and time when you identified the security defect.
• Affected Zabbix version range.
• Type of security issue you are reporting, e.g.: XSS, CSRF, SQLi, RCE.
• Affected components, e.g.: Frontend, Server, Agent, API.
• Any details you can provide, e.g. screenshots, screen recordings, http(s) transaction logs, POC exploits (please do not share any evidence via unauthenticated file sharing services and avoid sharing sensitive information, as if the Zabbix Security team decides that this issue does not fit the security defect description it might be moved to the ZBX project and the issue will be visible to all users).
• Step-by-step instructions on how to reproduce the issue, as the problem might not be easily identifiable.

1. The Zabbix Security team reviews the issue and evaluates its potential impact.
2. If the security issue is found not to be related to security, then the issue will be moved to an internal development project.
3. The Zabbix security team works on the issue to provide a solution and keeps all details on the problem until the next version of impacted Zabbix product is out. If Zabbix source code and Zabbix Cloud node is impacted by the same vulnerability, details will be kept internal until both products are updated.

4. New packages are created and made available for download on  https://zabbix.com/download section and Zabbix Cloud node version is updated as well.
5. Zabbix requests CVE identifiers for the security issue for Zabbix source code.
6. Clients with valid support agreements are emailed giving a period of time when it is possible to upgrade before the issue becomes known to the public.
7. Fixed vulnerabilities or any other security advisories are published to our Security advisory page https://www.zabbix.com/security_advisories

Developed in partnership with HackerOne, the world's leading platform for ethical hackers, the Zabbix bug bounty program contributes to the security of the product by allowing hackers to discover potential security vulnerabilities in different Zabbix components. The program offers up to $3,000 as a reward for discovering and reporting a bug. More information can be found in the Zabbix bug bounty page.