HexaEight takes the security of this SDK and the underlying cryptographic primitives seriously. This policy describes how to report vulnerabilities, what is considered in-scope, and what to expect after a report is filed.

Email: support@hexaeight.com

For non-trivial findings, please prefer GitHub Security Advisories (private disclosure): https://github.com/HexaEightTeam/hexaeight-sdk-node/security/advisories/new

Please include in your report:

• A clear description of the vulnerability and its potential impact
• Step-by-step reproduction against the current main branch or the latest published npm version of @hexaeight/sdk
• Exact file paths, function names, and line numbers where applicable
• Any proof-of-concept code, traces, or logs
• Your name and affiliation if you'd like attribution in the advisory

We will acknowledge receipt within 48 hours and provide a substantive response within 7 days.

• Authentication bypass in the SDK's identity / token-handling code
• Cryptographic implementation flaws in the TypeScript wrapper layer (encoding, parameter handling, key-cache logic)
• Injection vulnerabilities in the SDK's CLI tools (hexaeight-activate, hexaeight-renew, hexaeight-verify-env)
• Credential leakage through logs, error messages, or stack traces
• Insecure defaults in MemoryKeyStore or FileKeyStore that could expose ASKs to unauthorized parties on the same host
• Network-layer vulnerabilities in webhook transport (he.send, he.listen) including SSRF, request smuggling, or auth bypass
• CVEs in shipped dependencies with demonstrated impact through this SDK
• Postinstall script vulnerabilities (command injection, arbitrary download, privilege escalation)

• Reports against the HexaEight cryptographic core shipped as compiled .NET assemblies in native/. The core is distributed in binary form but, as with any .NET assembly, is inspectable via standard decompilation tools — we don't claim "binary = secret." The core's algorithm is documented in our forthcoming preprint (IACR ePrint + arXiv cs.CR), and its commercial use is governed by patent + license, not by binary obscurity. Security findings against the core's implementation should still be emailed to support@hexaeight.com with [CORE] in the subject line — but please note that the protocol design itself is in scope of the preprint review process, not this SDK's advisory process.
• License-bypass attempts — by design, the SDK enforces license validation at the CoreCLR bridge layer. Reporting "I found a way to use it without a license" is not a security vulnerability; it is a request for unauthorized use.
• Self-attacks against your own license (e.g., "my credentials were exposed because I committed env-file to git"). Operator-side credential management is the operator's responsibility.
• Theoretical attacks without working proof-of-concept
• Scanner-only findings (static analysis results without working reproduction)
• Issues in development dependencies (devDependencies in package.json) that have no impact on the published package
• Social engineering, physical access, or operator-side misconfiguration
• Denial-of-service via resource exhaustion unless it bypasses an explicit limit or causes data corruption
• Disclosure of public information (e.g., the SDK ships .NET DLLs)

We follow a coordinated disclosure model:

1. Report: You email or file a private advisory
2. Acknowledge: We confirm receipt within 48 hours
3. Investigate: We validate the report, assess scope and severity
4. Fix: We develop a patch and prepare a release
5. Coordinate: We agree with you on a disclosure date (typically 30-90 days from acknowledgment, depending on severity)
6. Release: We publish the fix, a CVE if applicable, and a public advisory crediting the reporter (unless they request anonymity)

We do not currently run a paid bug bounty program. We do offer:

• Public acknowledgment in the GitHub advisory and release notes
• A "thank you" in our security hall-of-fame (when published)
• For high-severity, well-documented reports: discretionary swag or license credits

The cryptographic primitives used by HexaEight (Dead Drop Encryption, SHAKE-256 key derivation, dynamic per-message keycounter, multi-party encryption) are documented in our preprint, forthcoming on IACR ePrint and arXiv cs.CR. Formal IND-CPA / IND-CCA2 analysis is included.

If your finding relates to the cryptographic protocol design rather than the SDK implementation, please reference the preprint in your report and tag the email subject with [PROTOCOL].

The SDK is in preview. We recommend pinning to a specific version in production and upgrading after reviewing changelogs.

• Security: support@hexaeight.com
• General: info@hexaeight.com
• Partnerships: partnerships@hexaeight.com
• Website: https://hexaeight.com
• Status: https://status.hexaeight.com