LightShuttle follows the semver policy. During the 0.x phase, only the latest minor release receives security fixes.
| Version | Supported |
|---|---|
| 0.1.x | ✅ |
| < 0.1 | ❌ |
The supported window will be widened once LightShuttle reaches 1.0.
If you find a security vulnerability in LightShuttle, please do not open a public GitHub issue. Disclosure rules:
- Email a detailed report to security@nubster.com with the subject prefix
[lightshuttle security]. - The report should include:
- A description of the vulnerability and the attacker model.
- Affected versions and crates.
- Reproduction steps or a proof of concept.
- The impact you anticipate (data leak, denial of service, privilege escalation, etc.).
- Suggested mitigation if you have one.
- You will receive an acknowledgement within 7 calendar days. If you do not, please follow up at the same address.
- We will work with you to validate, scope and remediate the issue. A coordinated disclosure timeline will be agreed in writing. The default embargo period is 90 days from acknowledgement.
- Once a fix is published, you will be credited in the release notes unless you prefer to remain anonymous.
If your report includes confidential proof-of-concept material, please encrypt it with the Nubster security GPG key. The fingerprint and public key are published at https://nubster.com/.well-known/security.txt (once Nubster publishes them).
The following are explicitly out of scope for vulnerability reports:
- Issues in unsupported versions.
- Vulnerabilities in third-party dependencies that are already publicly disclosed and tracked upstream. Report them to the upstream project.
- Reports based on theoretical attacks without a working proof of concept.
- Attacks that require a malicious or compromised Docker daemon, or a malicious operator with local control of the host. The threat model assumes a trusted local Docker daemon, used by a developer on their own workstation; LightShuttle is a local development orchestrator and is not a production-hardened sandbox.
- Resource exhaustion caused by manifests authored by the developer themselves (LightShuttle runs what you ask it to run).
Confirmed and fixed vulnerabilities are published on the GitHub Security Advisories page of the repository. RustSec advisories are also coordinated for severe issues when applicable.