The OpenSandbox team takes security seriously. If you discover a security vulnerability, please report it responsibly.

• GitHub Private Vulnerability Reporting: Open a private security advisory

Do not report vulnerabilities in a public issue or to the Code of Conduct reporting address. The conduct@opensandbox.io address is only for community conduct reports.

• Clear description of the vulnerability
• Steps to reproduce
• Potential impact and scope
• Suggested remediation (if available)

1. Acknowledgment within 48 hours
2. Investigation and validation
3. Fix development and testing
4. Coordinated disclosure

Only the latest release and main branch are actively supported with security updates.

OpenSandbox signs public release outputs with GitHub/Sigstore attestations, cosign keyless container signatures, and Maven Central package signatures where applicable. See Release Verification for the trusted signer identities and verification commands.

When deploying OpenSandbox:

• Keep dependencies up to date
• Use network policies to restrict sandbox egress
• Monitor audit logs regularly
• Follow principle of least privilege

OpenSandbox TLS defaults are aligned with OpenSSF crypto_keylength guidance (NIST minimum strength through year 2030, as stated in 2012):

• symmetric key: at least 112 bits
• factoring modulus (RSA): at least 2048 bits
• discrete logarithm key: at least 224 bits
• discrete logarithm group: at least 2048 bits
• elliptic curve key: at least 224 bits
• hash algorithm strength: at least 224 bits

Project-owned enforcement points include:

• Go SDK default transport certificate validation
• Kubernetes controller validation for configured webhook/metrics TLS certificates

For controlled interoperability scenarios, legacy weaker key lengths can be explicitly enabled:

• Go SDK: set TransportConfig.AllowWeakServerCertKeyLengths=true
• Kubernetes controller: set --allow-weak-tls-keylengths=true