Vulnerability Disclosure Policy

Security contact: security@lake8.dev

lake8.dev is committed to working with security researchers to verify and address potential vulnerabilities responsibly.

Reporting a Vulnerability

Send reports to: security@lake8.dev

Please include:

• Description of the vulnerability
• Steps to reproduce
• Potential impact
• Your contact information (optional)

PGP

Encrypted reports are supported.

Public key: cryptin.lake8.dev/security.asc

Fingerprint  B35B D267 08ED 3BB6 DCBF  D68A D535 58E2 1111 9C4F
Key ID       0xD53558E211119C4F
Type         RSA 4096, sign + encrypt subkey
UID          Crypt-in Security (lake8.dev vulnerability disclosure) <security@lake8.dev>
Valid until  2028-07-27

curl -sO https://cryptin.lake8.dev/security.asc
gpg --show-keys security.asc      # check the fingerprint above BEFORE importing
gpg --import security.asc

Verify the fingerprint against this page over a channel you already trust. A key served from the same host as the policy that describes it proves nothing on its own.

Our Commitments

• Acknowledge receipt within 7 days
• Assess and communicate severity within 21 days
• Fix confirmed vulnerabilities within 90 days
• Credit reporters in release notes (if desired)
• Safe harbor — we will not pursue legal action against researchers acting in good faith

Support period

• Beta period (until public launch, April 2027): best-effort, no SLA. All beta participants are considered part of the red team by default.
• After public launch (April 2027): 5 years from the date of first commercial release. You will receive at least 12 months notice before support ends.

CRA status

Crypt-in is not CRA compliant today, and we do not describe it as such. Compliance is in progress. Two obligations of the EU Cyber Resilience Act are still open, and they are named here rather than left implied:

• Secure update channel — open. Firmware images are signed and verified, but there is no OTA mechanism: during the beta updates are a manual USB flash. A secure update strategy is a blocking pre-launch item, not a solved one.
• Incident reporting (Art. 14) — open. No procedure towards the CSIRT / ENISA single reporting platform is published yet. Nothing is on sale, so no product is on the market for that obligation to bite, but the procedure is required before the first sale.

Already in place: this disclosure policy, the security contact with a PGP key, three SPDX 2.3 SBOMs at /docs/sbom/, and the support period declared above.

Two dates apply in law and they are not the same deadline — 11 September 2026 for the Art. 14 reporting obligations, 11 December 2027 for full application of the Regulation. Neither is the date we work to: the internal target is to have compliance complete by 28 February 2027, one month before the public launch.

Scope

In scope:

• Crypt-in firmware (ESP32-S3)
• License server (license.lake8.dev)
• .crin file format implementation
• HID protocol implementation

Out of scope:

• Physical attacks requiring chip-level equipment
• Attacks requiring prior compromise of the host system
• Social engineering

Known open findings

We maintain a public register of known findings at /security/red-team-2026-08/.

ID	Severity	Status	Fix milestone
F-001-REV	High	Open — accepted	Q2 2027 (session binding)
F-ISO	Medium	Open — accepted, fail-closed	Q2 2027 (session binding)
F-003/B1	Low	Open — accepted	Q2 2027 (challenge-response)

If your finding is already listed, you are welcome to report additional attack vectors we may have missed.

Safe harbour

lake8.dev will not pursue legal action against researchers who:

• Report in good faith following this policy
• Avoid accessing, modifying, or deleting data beyond what is strictly necessary to demonstrate the vulnerability
• Do not disclose findings publicly before the agreed disclosure date
• Do not use findings for purposes other than security research

During the beta period, all beta participants are considered part of the red team. Testing on your own dongle, your own files, and your own installation is explicitly permitted and encouraged.

Response process

For details on our internal response process, severity classification, and accepted risks, see the Product Security Incident Response document.