|
1 | 1 | # Security Policy |
2 | 2 |
|
3 | | -## Supported Versions |
| 3 | +## Supported versions |
4 | 4 |
|
5 | | -Only the latest release of TechScript receives security updates. If you find a security issue, please update to the newest stable release. |
| 5 | +Security fixes are applied to the current supported 2.0 release line. |
6 | 6 |
|
7 | | -| Version | Supported | |
8 | | -| ------- | --------- | |
9 | | -| v2.0.x | ✅ Yes | |
10 | | -| v1.0.x | ❌ No | |
11 | | -| < v1.0 | ❌ No | |
| 7 | +| Version | Support status | |
| 8 | +| --- | --- | |
| 9 | +| `2.0.x` | Supported | |
| 10 | +| `1.0.x` | Unsupported; upgrade to 2.0 where possible | |
| 11 | +| Older versions | Unsupported | |
12 | 12 |
|
13 | | -## Reporting a Vulnerability |
| 13 | +## Reporting a vulnerability |
14 | 14 |
|
15 | | -We take the security of TechScript seriously. If you discover a vulnerability, please do **NOT** open a public GitHub issue. Instead, report it privately to our security team. |
| 15 | +Do not open a public issue for a suspected vulnerability. Report it privately to `security@techscript.is-a.dev`. |
16 | 16 |
|
17 | | -### How to report: |
18 | | -1. Email us at **security@techscript.is-a.dev** with details of the vulnerability. |
19 | | -2. Include: |
20 | | - * A description of the vulnerability and its potential impact. |
21 | | - * Step-by-step instructions or proof-of-concept (PoC) code to reproduce it. |
22 | | - * Your GitHub username if you wish to be credited. |
| 17 | +Please include: |
23 | 18 |
|
24 | | -We will acknowledge receipt of your report within 48 hours and work with you to patch the issue before making a public disclosure. |
| 19 | +- A clear description of the affected component and potential impact. |
| 20 | +- The affected version, platform, and configuration. |
| 21 | +- Reproduction steps or a minimal proof of concept. |
| 22 | +- Any known mitigation or proposed fix. |
| 23 | +- Your preferred attribution name, if you want to be credited. |
| 24 | + |
| 25 | +Remove secrets, credentials, personal information, and unrelated customer data before sending a report. If the report contains sensitive attachments, mention that in the initial message rather than posting them publicly. |
| 26 | + |
| 27 | +## Response process |
| 28 | + |
| 29 | +Maintainers will acknowledge a report when practical, validate the issue, assess its severity, and coordinate a fix or mitigation. The disclosure timeline will depend on exploitability, affected users, availability of a fix, and coordination with reporters or downstream distributors. |
| 30 | + |
| 31 | +We may request additional details, provide a temporary workaround, publish an advisory, or credit the reporter after disclosure. Please do not publicly disclose the issue until maintainers have had a reasonable opportunity to investigate and release a fix. |
| 32 | + |
| 33 | +## Supply-chain and dependency reports |
| 34 | + |
| 35 | +Reports involving third-party dependencies, release artifacts, package publishing, or compromised credentials should also be sent privately. Include the package name, version, artifact digest or URL, and evidence that helps maintainers reproduce or verify the concern. |
| 36 | + |
| 37 | +For non-security bugs, use the [bug report template](ISSUE_TEMPLATE/bug_report.md). For general questions, use [Discussions](https://github.com/Tcode-Motion/techscript/discussions). |
0 commit comments