Tinlyt handles untrusted web content, delegated identity, customer evidence, and network acquisition. Security reports should be handled privately.
Until the project publishes a supported release, the default branch is a development baseline. No production support or patch SLA is implied. Supported release branches will be listed here when introduced.
Do not disclose exploitable details, proof-of-concept payloads, credentials, access tokens, customer data, or private evidence in public issues or pull requests.
Preferred reporting path:
- Open this repository's Security tab.
- Select Report a vulnerability to create a private GitHub Security Advisory, if private vulnerability reporting is enabled.
- Include the affected commit/tag, impact, prerequisites, reproduction steps, and suggested mitigation. Redact secrets and personal data.
If private vulnerability reporting is unavailable, email hello@tinlance.com with the subject [SECURITY] Tinlyt vulnerability report. This mailbox is the project's public contact route; the maintainer should confirm that it is actively monitored. Do not use a public issue as a fallback for sensitive details.
The maintainer aims to:
| Activity | Target |
|---|---|
| Acknowledge a report | Within 5 business days |
| Initial triage and severity assessment | Within 10 business days |
| Status updates | At least every 10 business days while active |
| Remediation and disclosure | Coordinated with the reporter, based on severity, exploitability, affected versions, and release readiness |
These are response targets, not a guaranteed service-level agreement. Complex reports, upstream dependencies, or unavailable deployment evidence may require more time. Allow reasonable time for investigation and coordinated remediation before public disclosure.
Relevant areas include authentication and authorization, tenant isolation, SSRF and DNS rebinding, redirect handling, browser isolation and egress, prompt-injection boundaries, evidence integrity, secrets handling, dependency/supply-chain compromise, data retention, and denial-of-service/resource exhaustion.
Please include:
- A concise description and security impact.
- Affected version, commit, endpoint, or deployment topology.
- Reproduction steps and minimum required privileges.
- Relevant logs or traces after removing secrets and customer data.
- Whether the issue is reproducible against the current default branch.
- External web content and retrieved documents are untrusted data.
- Authorization is derived from verified Platform identity; caller-supplied tenant identity is not trusted.
- Network destinations and every redirect are validated; deployment egress controls remain required.
- Browser workers are isolated, resource-limited, and separated from application credentials.
- Secrets are injected at runtime and must not enter source control or logs.
- Evidence integrity does not establish source truth, source authority, or a digital signature.
- Repository tests do not certify the security of a live deployment.
See the threat model, SSRF controls, and private-beta readiness gates.