We take the security of Cosmian VM seriously. If you discover a security vulnerability, please report it responsibly by following these steps:
Please do not report security vulnerabilities through public GitHub issues. Instead, please use one of the following methods:
- GitHub Security Advisories (Preferred): Use the private vulnerability reporting feature on GitHub
- Email: Send details to [email protected]
When reporting a vulnerability, please include as much of the following information as possible:
- A clear description of the vulnerability
- Steps to reproduce the issue
- Potential impact of the vulnerability
- Suggested fix (if you have one)
- Your contact information
- Initial Response: We will acknowledge receipt of your vulnerability report within 48 hours
- Investigation: We will investigate and validate the vulnerability within 5 business days
- Fix Development: We will work to develop and test a fix as quickly as possible
- Disclosure: We will coordinate the disclosure timeline with you
The following versions of Cosmian VM are currently supported with security updates:
| Version | Supported |
|---|---|
| 1.3.x | ✅ Yes |
| 1.2.x | |
| < 1.2 | ❌ No |
Note: Base images are also regularly updated. Please refer to our base images changelog for security updates to the underlying OS images.
The following table lists security advisories that are currently being tracked or have been assessed for this project:
| ID | Description | Status | Reason |
|---|---|---|---|
| RUSTSEC-2020-0071 | Potential segfault in time crate | Ignored | Dependency via certtool->acme-lib - limited impact |
| RUSTSEC-2023-0071 | RSA crate vulnerability affecting signature verification | Ignored | Under evaluation - specific use case may not be affected |
| RUSTSEC-2021-0145 | atty unmaintained | Ignored | Waiting for tdx-attest-rs to be upgraded |
| RUSTSEC-2021-0139 | ansi_term unmaintained | Ignored | Waiting for tdx-attest-rs to be upgraded |
| RUSTSEC-2024-0375 | atty unmaintained | Ignored | Low priority - related to terminal handling |
These security advisories are tracked in our deny.toml configuration file and are regularly reviewed by our security team. Most ignored advisories are due to:
- Transitive dependencies: Issues in dependencies of dependencies that we cannot directly control
- Limited impact: Vulnerabilities that don't affect the core security model of Cosmian VM
- Waiting for upstream fixes: Issues that require updates from upstream maintainers
Cosmian VM is built around a comprehensive security model that includes:
- AMD SEV-SNP: Secure Encrypted Virtualization with Secure Nested Paging
- Intel TDX: Trust Domain Extensions for memory encryption
- Hardware-based memory encryption protecting against host-level attacks
- TPM 2.0 / vTPM: Secure storage of cryptographic keys and measurements
- Attestation: Remote verification of platform integrity
- Secret storage: Secure key management for LUKS containers
- Runtime measurement: Continuous monitoring of file integrity
- Measurement log: Cryptographic record of all executed binaries
- Baseline comparison: Verification against known-good snapshots
When deploying Cosmian VM, we recommend:
- Network isolation: Deploy VMs in private networks with appropriate firewall rules
- Certificate management: Use valid TLS certificates (Let's Encrypt or enterprise CA)
- Access control: Implement strict SSH key management and disable password authentication
- Monitoring: Enable logging and monitoring for security events
- Snapshot verification: Always verify snapshots before production deployment
- Regular snapshot verification: Periodically re-verify IMA measurements against baselines
- Attestation verification: Always verify TEE attestations before trusting a VM
- Hardware validation: Ensure cloud instances support required TEE features
- Measurement validation: Regularly compare IMA measurements against baselines
- Encrypted storage: Use TPM-backed LUKS encryption for sensitive data
Cosmian VM is designed to protect against:
- Honest-but-curious cloud providers: Memory encryption prevents unauthorized access
- Malicious cloud infrastructure: TEE attestation validates platform integrity
- Compromised hypervisors: Hardware-based isolation provides protection
- Memory attacks: Encrypted memory prevents direct access to sensitive data
- Application-level vulnerabilities: Secure coding practices still required
- Side-channel attacks: Some advanced attacks may still be possible
- Physical access: Direct hardware access by attackers is not protected
For general security questions or concerns, please contact us at [email protected].
For immediate security issues, please use the private reporting methods described above.