Security Policy

Supported Versions

Security fixes are provided for the latest release line on the default branch. Pre-1.0 releases may receive fixes only on the latest minor version.

Reporting a Vulnerability

Please do not report security vulnerabilities through public GitHub issues.

Use GitHub Private Vulnerability Reporting — the Report a vulnerability button under this repository's Security tab. It is the preferred channel: it is private, it needs no mail infrastructure on our side, it gives you a thread with the maintainers, and it can issue a CVE and publish an advisory when the fix ships.

Maintainer note — action required before this repository goes public. Private Vulnerability Reporting is off by default. Enable it under Settings → Code security and analysis → Private vulnerability reporting, or the link above returns 404 and this policy has no working channel.

The addresses previously listed here, security@craton-co.github.io and dev@craton-co.github.io, cannot receive mail: craton-co.github.io is a GitHub Pages hostname with no MX record, so anything sent to it bounces or is silently dropped. They have been removed rather than left as a channel that looks real and is not. The same address appears as the developer contact in pom.xml, where Maven Central publishes it — replace it with a real mailbox before the first release.

Please include:

• A description of the issue and its impact
• Steps to reproduce or a proof of concept, if available
• Affected versions (Maven coordinates: io.github.craton-co:craton-gpu)

We aim to acknowledge receipt within 3 business days and will work with you on coordinated disclosure. Please allow reasonable time for investigation and a fix before public disclosure.

What to expect

1. Acknowledgment of your report
2. Assessment and, when needed, a fix or mitigation plan
3. A release or advisory when a fix is available
4. Credit in the release notes (unless you prefer to remain anonymous)

Scope

This library is a thin Java API surface. It ships no CUDA driver and loads no native library of its own: on a stock JVM every bridge call fails with UnsatisfiedLinkError, and device-side execution happens in the CratonVM host. Vulnerabilities in the device-side execution path, the CUDA toolchain, or jit-cuda belong to CratonVM, not here.

In scope for this repository:

• The Java API surface in craton.gpu and craton.gpu.internal, including native-handle lifecycle (use-after-free, double-free, handle leaks).
• gpu4j-sidecar: the model-name resolution path and the sidecar child-process lifecycle.

One thing to be aware of when embedding gpu4j-sidecar: a model name is not trusted input. Whatever reaches ModelConfig becomes a filename under the configured models directory and then an argument to a child process. ModelResolver rejects anything that is not a plain file-name component and re-checks containment after following symlinks, but that is not authorisation — authenticate any request that carries a model name. See docs/SIDECAR_SETUP.md.

Secure development

• Run both test suites before releases: mvn -B verify (one reactor covers both modules)
• Dependabot watches both projects' Maven dependencies and the GitHub Actions workflows.
• CodeQL analysis runs on every push and pull request (.github/workflows/codeql.yml).
• Tags trigger a production publish. Limit who can push tags and who can edit Actions secrets.

Maven Central

Published artifacts use the coordinates io.github.craton-co:craton-gpu and are GPG-signed. Verify signatures where your build tooling supports it, and pin explicit versions in production builds.

Note that nothing has been published under io.github.craton-co yet — see docs/MAVEN_CENTRAL.md. Treat any artifact claiming those coordinates from another source as untrusted.