Security Advisories

This page covers how to report a vulnerability in Craton HSM, what to expect from the response process, and the public advisory history. Two slightly different channels apply to the open-source Core and to the Enterprise workspace; both are private by default.

Reporting a Vulnerability

Do not open a public GitHub issue for security vulnerabilities. Public issues forfeit the coordinated-disclosure window and can put users at risk before a patch is available.

Core (craton-hsm-core)

Use GitHub's private vulnerability reporting. The report template walks you through the required fields.

Enterprise (craton-hsm-enterprise)

Email security@craton.io. A PGP key for encrypting sensitive reports is published at https://craton.io/security.asc and mirrored in the repository at .well-known/security-key.asc.

PGP key status. At the time of writing, the security PGP key has not yet been generated through Craton's offline key-ceremony process. The published placeholder file documents the absence explicitly — this is tracked in the open so that its absence cannot be used to stage a key-substitution attack. Until the key is published, reporters may use plain TLS to security@craton.io for the initial contact; the Craton security team will arrange encrypted follow-up if the report contains exploit details or other sensitive material.

When the key is published, verify its fingerprint out-of-band by cross-checking three independent sources before importing: the craton.io homepage footer, the in-repo .well-known/security-key.asc, and the fingerprint in a signed Git tag annotation on the release you intend to report against. Do not encrypt to a key whose fingerprint has not been independently verified.

What to Include

• Description of the vulnerability and the impact you believe it has.
• Steps to reproduce or a proof-of-concept (redact any key material).
• Affected versions — crate and version (e.g. craton-hsm-auth 0.1.1), commit SHA if from a branch.
• Platform: OS, kernel, architecture, containerized or not.
• Feature flags enabled in your build.
• Any suggested mitigations if you have them.

Response Timeline

We follow a 90-day disclosure policy. If the fix legitimately needs more time, we will negotiate an extension with the reporter and document the reason in the eventual advisory.

Backport SLA (Enterprise)

When a security fix ships, it is backported per the Enterprise policy:

Community backports to superseded minors are available only under a commercial support contract (support@craton.io). Security backports to EOL'd minors are not guaranteed outside the 12-month maintenance window, with the critical-severity exception above.

CVE and Advisory Process

For accepted reports the project files a GitHub Security Advisory against the relevant repository. The advisory handles CVE assignment via GitHub's CNA. The reporter is credited in the advisory unless they prefer anonymity. We will coordinate disclosure timing with the reporter before making the advisory public.

Every advisory ships with a patched version. Advisories are announced on:

• The GitHub repository's "Security advisories" tab.
• The release notes for the patched version.
• CHANGELOG.md under the version that first shipped the fix.

In-Scope Reports

The following are in scope for security reports:

• Authentication bypass, privilege escalation, or cross-tenant data access.
• Cryptographic weaknesses — key recovery, padding oracles, nonce reuse, timing side channels on verification, weak parameter acceptance.
• FIPS-mode bypass or approved-mode FSM state confusion.
• Remote-unauthenticated crashes or resource exhaustion (DoS) in the KMIP server, Raft transport, or PKCS#11 backend.
• Memory safety — unsound unsafe, use-after-free, data races.
• Key material leaks (logs, error messages, debug output, core dumps, swap).
• Audit-log integrity bypass.
• Supply-chain tampering — suspicious commits, compromised dependencies, signing-metadata mismatches.

Out of Scope

• Vulnerabilities in upstream dependencies — report those to the upstream project. We will pick them up via cargo-audit in the next triage cycle.
• Issues that require physical access to the host machine. Craton HSM is a software module; Level 2 physical tamper evidence is not a design target.
• Social-engineering attacks.
• Build failures, API ergonomics, and documentation typos — those belong in public issues.

Published Advisories

None published to date. No security advisory has been issued against either Core or Enterprise since the first public release. Security fixes that have shipped so far — including the 11 fixes in Core 0.9.1 and the security sweep in Enterprise 0.1.1 — were discovered during pre-release review rather than through external disclosure. When the first externally-reported advisory is issued, it will appear on this page with a link to the GitHub advisory entry.

Supported Versions (Security)

Contact

• Core: GitHub private vulnerability reporting on craton-co/craton-hsm-core.
• Enterprise: security@craton.io.
• Commercial / SLA expansions: support@craton.io.