|
1 | 1 | # Security Policy |
2 | 2 |
|
| 3 | +## Supported Versions |
| 4 | + |
| 5 | +Security fixes are provided for the latest stable release and the current hosted service. Fixes |
| 6 | +normally land on `main` and are included in the next stable release. Older releases and |
| 7 | +version-pinned assets are not guaranteed to receive backports, so self-hosters should upgrade to the |
| 8 | +latest stable release before requesting a fix for an older version. |
| 9 | + |
3 | 10 | ## Reporting a Vulnerability |
4 | 11 |
|
5 | | -If you discover a security vulnerability, please report it responsibly: |
| 12 | +Please report suspected vulnerabilities privately through one of these channels: |
| 13 | + |
| 14 | +1. **Preferred:** [GitHub private vulnerability reporting](https://github.com/mean-weasel/bugdrop/security/advisories/new) |
| 15 | +2. **Email fallback:** [neonwatty@gmail.com](mailto:neonwatty@gmail.com) or |
| 16 | + [jeremy@mean-weasel.com](mailto:jeremy@mean-weasel.com) |
| 17 | + |
| 18 | +Ordinary email is not end-to-end encrypted. Use GitHub private vulnerability reporting for reports |
| 19 | +that contain sensitive details, credentials, or unpublished exploit material. Do not open a public |
| 20 | +GitHub issue. If the preferred channel is unavailable, use either email fallback rather than |
| 21 | +disclosing the issue publicly. |
6 | 22 |
|
7 | | -1. **Do not** open a public GitHub issue |
8 | | -2. **Email** security concerns to: neonwatty@gmail.com or jeremy@mean-weasel.com |
9 | | -3. **Include**: |
10 | | - - Description of the vulnerability |
11 | | - - Steps to reproduce |
12 | | - - Potential impact |
| 23 | +Include, when available: |
13 | 24 |
|
14 | | -## Response Timeline |
| 25 | +- A description of the vulnerability and its potential impact |
| 26 | +- The affected release, hosted URL, or commit |
| 27 | +- Reproduction steps or a minimal proof of concept |
| 28 | +- Relevant configuration and environmental details, with secrets removed |
| 29 | +- Whether you plan to publish the report and any requested disclosure timeline |
15 | 30 |
|
16 | | -- **Acknowledgment**: Within 48 hours |
17 | | -- **Initial assessment**: Within 7 days |
18 | | -- **Fix timeline**: Depends on severity, typically 30-90 days |
| 31 | +## Response Targets |
| 32 | + |
| 33 | +- **Acknowledgment:** Within 48 hours |
| 34 | +- **Initial assessment:** Within 7 days |
| 35 | +- **Remediation:** Typically 30-90 days, depending on severity and complexity |
| 36 | + |
| 37 | +These are best-effort targets rather than guarantees. The maintainers will share material status or |
| 38 | +timeline changes through the private reporting channel. |
19 | 39 |
|
20 | 40 | ## Scope |
21 | 41 |
|
22 | 42 | This policy covers: |
23 | 43 |
|
24 | 44 | - The Cloudflare Worker (`src/`) |
25 | 45 | - The client widget (`src/widget/`) |
| 46 | +- Release artifacts published by this repository |
26 | 47 | - The hosted instance at `bugdrop.neonwatty.workers.dev` |
| 48 | +- Dependency vulnerabilities that are reachable through or materially affect BugDrop |
| 49 | + |
| 50 | +Self-hosted deployment configuration is controlled by the instance owner. Reports about an upstream |
| 51 | +dependency with no BugDrop-specific impact should go to that upstream project, but reports showing |
| 52 | +that BugDrop is affected are in scope here. |
| 53 | + |
| 54 | +## Triage and Coordinated Disclosure |
27 | 55 |
|
28 | | -## Out of Scope |
| 56 | +The BugDrop repository maintainers own intake and triage. They will validate the report, assess |
| 57 | +severity using reachability and user impact, and prioritize critical and high-severity issues. When a |
| 58 | +dependency is involved, the maintainers will determine BugDrop's exposure, coordinate with the |
| 59 | +upstream project when appropriate, and update affected BugDrop releases or guidance. |
29 | 60 |
|
30 | | -- Self-hosted instances (contact the instance owner) |
31 | | -- Third-party dependencies (report to the upstream project) |
| 61 | +Please allow time for investigation and remediation before public disclosure. The maintainers will |
| 62 | +coordinate a disclosure date with the reporter, publish a GitHub security advisory or CVE when |
| 63 | +appropriate, and credit reporters who request attribution and consent to being named. |
0 commit comments