Security · Coordinated Disclosure

Security Policy

PhantomYerra is a security product. Finding and fixing vulnerabilities in our own code is a first-class part of our work. This page describes how to report an issue, the commitments we make in response, and the controls we have in place across the product’s supply chain.

Version: v45.1.0 Last updated: 2026-04-15 Contact: security@phantomyerra.com security.txt: /.well-known/security.txt

1 Reporting a vulnerability

Email security@phantomyerra.com with a clear description of the issue. Include:

Affected component and version (PhantomYerra v45.x, the license service, the marketing site, the auto-updater, etc.).
Impact: what an attacker can do, and the conditions required.
Steps to reproduce, preferably with a proof-of-concept or a short video.
Any logs, screenshots, or HTTP traces that demonstrate the issue.
Your preferred name for the credit line (or request anonymity).

Please do not File public GitHub issues, tweet details, or post to forums before we have coordinated a disclosure window. Do not exfiltrate or access user data beyond what is strictly needed to prove the issue.

2 Response SLAs

Severity	First acknowledgement	Triage decision	Fix target
Critical	24 hours	72 hours	7 days
High	48 hours	7 days	30 days
Medium	5 business days	14 days	next release
Low	5 business days	30 days	when practical

We assign severity using CVSS 3.1 plus our own exploitability weighting. “First acknowledgement” means a human has read the report; “triage decision” means we have validated the issue and set a target fix date; “fix target” is the date by which a released build contains the fix.

3 Safe harbor

Good-faith research is welcome Activity conducted consistent with this policy is (a) authorized by us and (b) considered good-faith security research for the purposes of the US Computer Fraud and Abuse Act, UK Computer Misuse Act, EU NIS2, and similar statutes, to the maximum extent we can legally extend such authorization.

To stay within scope, a researcher must:

Only test their own PhantomYerra installation or a test environment they control.
Avoid denial-of-service, data-destruction, and actions that degrade availability for other users of the license service, auto-updater, or marketing site.
Not attempt to access, modify, or exfiltrate data belonging to any other party.
Follow the reporting process in Section 1 before any public disclosure.
Keep private any sensitive information accessed during testing and delete it after the report is resolved.

4 Scope

In scope

The PhantomYerra desktop application (Windows, Linux, macOS) and its auto-updater.
The PhantomYerra CLI and CI/CD runner binaries.
The marketing site at phantomyerra.com and its sub-paths (including /contact, /api/contact).
The license service and its API.
The update manifest and installer artifacts served from /updates/ and /downloads/.

Out of scope

Denial-of-service (DoS, DDoS, resource-exhaustion) against production systems.
Social engineering, phishing, or physical attacks against employees or facilities.
Spam on the contact form or other form-abuse issues resolvable by rate-limiting.
Vulnerabilities in third-party services we use (send those directly to the vendor).
Self-XSS, clickjacking without a security impact, missing best-practice HTTP headers that do not lead to an exploit.

5 Credit and rewards

Valid, previously-unknown issues are publicly credited on the release notes for the fix (at the reporter’s option), and included in the next security advisory. We do not operate a monetary bug-bounty program at this time; enterprise customers and long-term partners may be eligible for commercial acknowledgement on a case-by-case basis.

6 Supply-chain and build integrity

Every released build is accompanied by:

A signed latest.yml / latest-linux.yml update manifest served over HTTPS from phantomyerra.com/updates/.
An SHA-256 sum for the installer and its blockmap.
An integrity seal for the marketing site (refreshed on every publish, available at /SIGNATURES.json).
A CycloneDX Software Bill of Materials (SBOM) for the bundled Python runtime and Node dependencies, available on request.

Internal build hardening:

Dependencies are pinned via lockfiles (pnpm-lock.yaml, uv.lock) and reviewed before bumps.
Python modules distributed with the application are obfuscated and validated on load (hash-based unchecked .pyc with Python -OO).
The auto-updater requires a matching publisher certificate; mismatch aborts the update.
The license service is deployed behind a restrictive nginx configuration with HSTS, rate limits, and no-cache headers on authentication endpoints.

7 Cryptography

Client credentials and AI API keys are stored encrypted with AES-256-GCM derived from a machine-bound key.
License service and marketing-site TLS requires TLS 1.2 or higher; TLS 1.0 / 1.1 are disabled at the nginx layer.
TLS cipher preference enforces forward-secret AEAD suites; legacy CBC and RC4 are disabled.
HSTS is enabled on the marketing and license-service domains (max-age=31536000; includeSubDomains).
We use Let’s Encrypt with 60-day auto-renewal via certbot.timer.

8 Encrypted communications

If your report contains sensitive reproduction data, email us the non-sensitive summary and we will reply with an ephemeral upload URL over TLS. We maintain a current PGP key at:

curl -s https://phantomyerra.com/.well-known/pgp-key.asc | gpg --import Fingerprint: published on /.well-known/security.txt

9 History

We publish security advisories at phantomyerra.com/versionhistory. Each advisory carries a CVE identifier (where assigned), severity, affected versions, fixed version, and credit.

10 Contact

Security: security@phantomyerra.com
Press / coordinated-disclosure coordination: security@phantomyerra.com (same inbox, tag subject [coord]).
Privacy: privacy@phantomyerra.com