The Zi project takes security seriously. This document outlines our security policy, including supported versions, how to report vulnerabilities, and our disclosure process.
The following versions of Zi are currently supported with security updates:
| Version | Supported | Status |
|---|---|---|
| 0.1.x | ✅ | Current stable series |
| < 0.1.0 | ❌ | No longer supported |
We provide security updates for the latest minor version in each major version series. Users are encouraged to upgrade to the latest version to receive security patches.
If you discover a security vulnerability in Zi, please report it to us as soon as possible. We appreciate your efforts to responsibly disclose your findings.
Please do not report security vulnerabilities through public GitHub issues or Gitee issues.
Instead, please report security vulnerabilities via:
📧 Email: dunimd@outlook.com
For general questions and non-security issues, please use:
- Gitee Issues (Primary): https://gitee.com/dunimd/zi/issues
- GitHub Issues (Mirror): https://github.com/mf2023/Zi/issues
Please include the following information in your report:
- Description: A clear and concise description of the vulnerability
- Impact: What kind of vulnerability is it and what impact could it have
- Affected Versions: Which versions of Zi are affected
- Steps to Reproduce: Detailed steps to reproduce the vulnerability
- Proof of Concept: If possible, include a proof-of-concept or exploit code
- Suggested Fix: If you have suggestions for how to fix the vulnerability
- Your Contact Information: How we can reach you for clarifications (optional)
When you submit a security report, you can expect the following:
- Acknowledgment: We will acknowledge receipt of your report within 48 hours
- Initial Assessment: We will provide an initial assessment within 5 business days
- Investigation: We will investigate the vulnerability and determine its impact
- Fix Development: If confirmed, we will work on a fix and may reach out for additional information
- Disclosure: We will coordinate with you on the disclosure timeline
Our target response times are:
| Severity | Initial Response | Fix Timeline |
|---|---|---|
| Critical | 24 hours | 7 days |
| High | 48 hours | 14 days |
| Medium | 5 business days | 30 days |
| Low | 10 business days | 60 days |
Zi processes large datasets for LLM training pipelines. Consider the following security aspects:
- Always validate input data sources before processing
- Be cautious when processing untrusted data files (JSONL, JSON, CSV, Parquet)
- Use appropriate file size limits to prevent DoS attacks
- Zi provides PII redaction operators (
pii.redact) - Configure appropriate PII patterns for your use case
- Review redacted output before using in production
- Zi performs file I/O operations for data ingestion and export
- Ensure proper file permissions on input/output directories
- Use atomic write operations for critical data exports
Zi supports dynamic operator loading via shared libraries:
- Only load plugins from trusted sources
- Verify plugin integrity before loading
- Plugins run with the same privileges as the host application
- Use code signing for plugin verification
- Implement plugin sandboxing when possible
- Audit plugin code before deployment
Zi supports YAML/JSON-based pipeline configuration:
- Validate configuration files from untrusted sources
- Be cautious with template rendering in configurations
- Avoid executing arbitrary code through configuration
- Use allowlists for permitted operators
- Validate all configuration parameters
- Implement configuration schema validation
When using distributed processing features:
- Use TLS for inter-node communication
- Implement proper authentication between nodes
- Validate all incoming data from remote sources
Zi is written in Rust, which provides memory safety guarantees:
- No buffer overflows by design
- No use-after-free vulnerabilities
- No null pointer dereferences
However, unsafe code blocks and external dependencies should be audited regularly.
When using Zi in your applications:
Regularly update Zi and its dependencies to receive security patches:
cargo update
cargo audit # Use cargo-audit to check for known vulnerabilitiesAlways use the latest stable version of Zi to ensure you have the latest security fixes.
Build Zi with appropriate features:
cargo build --release --features fullAlways validate input data before processing:
use zix::{ZiRecord, ZiPipelineBuilder};
// Add validation operators at the start of your pipeline
let steps = vec![
json!({"operator": "field.require", "config": {"fields": ["text"]}}),
json!({"operator": "limit", "config": {"max_records": 1000000}}),
];Follow secure file handling practices:
- Use absolute paths for file operations
- Implement file size limits
- Use atomic writes for critical data
Enable logging and monitoring:
- Log processing statistics
- Monitor for unusual patterns
- Set up alerts for processing failures
Follow secure deployment practices:
- Use container security best practices
- Implement proper access controls
- Regular security audits
-
Plugin System: Dynamic library loading introduces potential security risks. Only load trusted plugins.
-
Large File Processing: Processing very large files may consume significant memory. Implement appropriate resource limits.
-
Distributed Mode: Network communication in distributed mode should be secured with TLS.
- Implement proper input validation
- Use resource limits to prevent DoS
- Enable audit logging
- Regular security audits of custom operators
Security updates will be announced through:
- GitHub Security Advisories
- GitHub Releases (with security fix notes)
- CHANGELOG.md (with security-related changes marked)
- We will acknowledge receipt of vulnerability reports within 48 hours
- We will provide regular updates on our progress
- We will credit researchers who responsibly disclose vulnerabilities (unless they prefer to remain anonymous)
- We will not take legal action against researchers who follow this policy
- Day 0: Vulnerability reported
- Day 1-2: Acknowledgment and initial assessment
- Day 3-14: Investigation and fix development
- Day 15-30: Testing and validation
- Day 30+: Coordinated disclosure
We aim to disclose vulnerabilities within 90 days of the initial report, or sooner if a fix is available.
We will publicly disclose vulnerabilities after:
- A fix has been developed and tested
- Affected users have had reasonable time to update
- The vulnerability has been assigned a CVE identifier (if applicable)
The following environment variables affect security:
| Variable | Description | Security Impact |
|---|---|---|
RUST_LOG |
Logging level | May expose sensitive data if set to trace |
ZI_ENV |
Environment (dev/staging/prod) | Affects security defaults |
Review security-related configuration options:
- Plugin loading paths
- File I/O directories
- Resource limits
- Operator allowlists
We welcome third-party security audits. If you are conducting a security audit of Zi:
- Please follow responsible disclosure practices
- Contact us in advance if you plan to publish findings
- We appreciate receiving a copy of the audit report
For security-related inquiries:
- Email: dunimd@outlook.com
- GPG Key: [Available upon request]
For general questions and non-security issues, please use:
- Gitee Issues (Primary): https://gitee.com/dunimd/zi/issues
- GitHub Issues (Mirror): https://github.com/mf2023/Zi/issues
- GitHub Discussions: https://github.com/mf2023/Zi/discussions
We thank the following security researchers who have responsibly disclosed vulnerabilities:
This list will be updated as vulnerabilities are reported and fixed.
Last Updated: 2026-02-28
Version: 1.0