From c2c8bbd2cecf056f533fc61f3a72b5fe05d5297e Mon Sep 17 00:00:00 2001 From: modernham Date: Sat, 7 Mar 2026 21:12:29 -0500 Subject: [PATCH] Removed 411 lines of Useless AI Generated Information. The SECURITY.md file was 89% AI generated garbage that is obvious to anyone in the industry, not unique to the project, and can be found online. Removed 411 lines to make is more concise and readable to attempt to turn it into an actually functional document. As a security researcher, 463-line SECURITY.md file filled with 89% AI generated garbage doesn't really reflect the other AI generated statement at the top of it "The OpenHamClock community takes security seriously." --- SECURITY.md | 474 ++++------------------------------------------------ 1 file changed, 32 insertions(+), 442 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 7c10f0d7..45521ad5 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,462 +1,52 @@ # Security Policy -The OpenHamClock community takes security seriously. We appreciate responsible disclosure and will work to resolve security issues promptly to protect the amateur radio community. +## Supported Versions ---- +Only the latest version on `main` is supported. Please reproduce issues against the latest code before reporting. -## 1. Supported Versions +## Reporting a Vulnerability -As a rapidly evolving open-source project, we primarily support the latest version of the codebase. Please reproduce issues on the latest `main` before reporting (when feasible). +> **DO NOT** open a public GitHub Issue for security vulnerabilities. -| Version | Supported | Notes | End of Support | -| :------ | :----------------- | :------------------------------------- | :------------- | -| Main | :white_check_mark: | The latest commit on the `main` branch | N/A (rolling) | -| Older | :x: | Please upgrade to the latest version | Immediate | +### How to Report ---- +1. **GitHub Private Vulnerability Reporting** (preferred): + https://github.com/accius/openhamclock/security/advisories/new -## 2. Scope +2. **Email**: chris@cjhlighting.com — use when GitHub reporting is unavailable or for highly sensitive disclosures. -### 2.1 In Scope +### What to Include -The following are within the scope of this vulnerability disclosure policy: +If reporting via email, please use the following template: -- OpenHamClock application code (frontend and backend) -- Configuration defaults and deployment artifacts in this repository -- Build, packaging, and update mechanisms owned by this repository -- Docker images and container configurations published by this project -- Installation and update scripts (`setup-*.sh`, `update.sh`) +``` +Subject: [SECURITY] Brief description of vulnerability -### 2.2 Out of Scope +Vulnerability type: (e.g., XSS, RCE, authentication bypass) +Affected component(s): (e.g., server.js, Docker config) +Affected version/commit: +Steps to reproduce: + 1. + 2. + 3. +Impact: (what can an attacker achieve?) +Suggested fix: (optional) +``` -The following are generally **not** in scope but may be considered on a case-by-case basis: +Avoid including real callsigns, grid locators, IP addresses, or API keys — use placeholders instead. -- Third-party services and APIs consumed by OpenHamClock (report to the respective vendor) -- Vulnerabilities in upstream dependencies that do not materially affect this project's usage -- Issues requiring physical access to the user's device (unless remote access was enabled in an unsafe manner by default configuration) -- Social engineering attacks against individual operators -- Issues in end-of-life or unsupported versions +## Response -### 2.3 Scope Questions +- **Acknowledgment**: Within 7 days +- **Assessment**: Within 14 days +- **Target fix**: Within 90 days for critical/high severity -If you're unsure whether something is in scope, **please report it anyway** and clearly mark it as a **"scope question"** in your submission. We will provide guidance. +We follow a 90-day coordinated disclosure timeline by default. ---- +## Safe Harbor -## 3. Security Contact +We will not pursue legal action against researchers who act in good faith, report findings privately, and avoid data destruction or service disruption. Please test only against your own deployments. -For vulnerability reports, please use one of the **private channels** below. The maintainer acts as the primary security contact and may engage additional community members under NDA for remediation when necessary. +## Security Updates ---- - -## 4. Reporting a Vulnerability (ISO/IEC 29147 §7.4) - -> **CRITICAL**: **DO NOT** open a public GitHub Issue for security vulnerabilities before coordination. - -### 4.1 Reporting Channels (in order of preference) - -#### Primary: GitHub Private Vulnerability Reporting - -- **URL**: https://github.com/accius/openhamclock/security/advisories/new -- **Advantages**: Structured submission, built-in secure communication, CVE assignment support -- **Expected acknowledgment**: Automated immediate, human review within 7 days - -#### Secondary: Encrypted Email - -- **Address**: chris@cjhlighting.com -- **PGP Key**: Available at https://github.com/accius.gpg (or keybase.io/accius) -- **Fingerprint**: `[Will be added - use PGP key for sensitive communications]` -- **Use when**: GitHub reporting is unavailable or for highly sensitive disclosures - -#### Tertiary: Direct Message - -- **Platform**: Twitter/X DM to @[handle] (if urgent and other channels fail) -- **Note**: Less secure; use only for initial contact, then switch to encrypted channel - -### 4.2 What to Include in Your Report (ISO/IEC 29147 §7.4.3) - -A complete vulnerability report should include: - -**Required**: - -- **Vulnerability type** (e.g., SQL injection, XSS, authentication bypass, RCE, information disclosure) -- **Affected component(s)** (e.g., `server.js`, auto-update mechanism, Docker configuration) -- **Affected version(s)** (commit hash or version tag) -- **Description** of the vulnerability and how it manifests -- **Steps to reproduce** or proof-of-concept (minimal example preferred) -- **Impact assessment** (what can an attacker achieve?) - -**Optional but helpful**: - -- **Severity assessment** (your opinion: Critical/High/Medium/Low) -- **Suggested remediation** or mitigation approach -- **Disclosure preferences** (embargo duration, credit preferences) -- **CVE ID** if you've already requested one - -### 4.3 Sensitive Data Handling - -To protect operator privacy, **please avoid including**: - -- Real amateur radio callsigns (use `K0XXX` or `W1ABC` as placeholders) -- Actual grid locators (use `AA00aa` as placeholder) -- Production IP addresses (use RFC5737 documentation addresses: `192.0.2.0/24`) -- API keys, tokens, session cookies, or contents of `.env` files -- Personal information of operators (names, addresses, email addresses) - -If sensitive data is **absolutely necessary** for reproduction: - -- Redact or pseudonymize it -- Clearly explain what was redacted and why it's needed -- Offer to provide actual data over a secure side-channel if essential - -### 4.4 Language - -Reports may be submitted in **English** (preferred) or other languages. We will make reasonable efforts to work with non-English reporters but may experience delays in processing. - ---- - -## 5. Vulnerability Handling Process (ISO/IEC 30111:2019 §7) - -### 5.1 Vulnerability Case Lifecycle - -Each reported vulnerability is assigned a unique **case identifier** (format: `OHC-YYYY-NNNN`, e.g., `OHC-2026-0001`) and progresses through these states: - -| State | Description | Typical Duration | -| --------------- | ------------------------------------------ | ---------------- | -| **RECEIVED** | Report received, awaiting initial review | 0-7 days | -| **ASSIGNED** | Case assigned to handler, analysis started | 1-14 days | -| **CONFIRMED** | Vulnerability validated and reproduced | - | -| **REMEDIATION** | Fix in development and testing | 7-90 days | -| **VENDOR-FIX** | Fix ready, coordinating disclosure | 0-14 days | -| **PUBLIC** | Vulnerability and fix publicly disclosed | Terminal state | -| **REJECTED** | Not a vulnerability or out of scope | Terminal state | - -**Status transitions** will be communicated to the reporter via the reporting channel. - -### 5.2 Response Timelines (ISO/IEC 29147 §7.4.4) - -We commit to the following response targets: - -- **Initial acknowledgment**: Within **7 calendar days** of receipt -- **Preliminary assessment**: Within **14 calendar days** of receipt -- **Regular updates**: At least every **14 calendar days** while case is active -- **Target remediation**: Within **90 days** for Critical/High severity issues - -> **Note**: Complex issues, multi-party coordination, or resource constraints may extend timelines. We will communicate delays proactively. - -### 5.3 Severity Classification (CVSS v3.1) - -We use CVSS v3.1 base scores to classify severity: - -| Severity | CVSS Score | Response Priority | Typical Fix Timeline | -| ------------ | ---------- | ----------------- | -------------------- | -| **Critical** | 9.0 - 10.0 | Immediate | 7-30 days | -| **High** | 7.0 - 8.9 | Urgent | 30-60 days | -| **Medium** | 4.0 - 6.9 | Normal | 60-90 days | -| **Low** | 0.1 - 3.9 | Best effort | Next release cycle | - -Reporters are encouraged to provide their own CVSS assessment, but the PSIRT makes the final determination. - -### 5.4 Remediation Development (ISO/IEC 30111 §7.5) - -Remediation may take the form of: - -1. **Code fix**: Patch applied to the codebase -2. **Configuration change**: Secure defaults or documentation update -3. **Workaround**: Interim mitigation until a full fix is available -4. **No fix**: Issue is accepted as a limitation (risk accepted, documented) - -All fixes undergo internal testing before release. For Critical issues, we may request assistance from the reporter for verification. - ---- - -## 6. Coordinated Disclosure (ISO/IEC 29147 §7.5) - -### 6.1 Disclosure Timeline - -By default, we follow a **90-day coordinated disclosure** timeline from initial report: - -- **Day 0**: Vulnerability reported -- **Day 7**: Initial acknowledgment and triage -- **Day 14-90**: Remediation development, testing, and coordination -- **Day 90**: Public disclosure (advisory + fix), unless extended by mutual agreement - -### 6.2 Early Disclosure - -We may disclose **earlier than 90 days** if: - -- Fix is ready and tested -- No multi-party coordination is required -- Reporter agrees to early disclosure -- Active exploitation is detected in the wild (emergency disclosure) - -### 6.3 Embargo Extensions - -The 90-day timeline may be **extended** if: - -- Complexity requires additional development time (negotiated with reporter) -- Multi-party coordination is in progress (see §7) -- Affected component is in a third-party dependency awaiting upstream fix - -**Maximum embargo**: Typically **180 days** from initial report, except in exceptional circumstances. - -### 6.4 Emergency Disclosure - -If we become aware of **active exploitation** or **imminent public disclosure**, we may: - -1. Immediately publish a security advisory with available mitigations -2. Notify affected parties via established channels -3. Release a patch or workaround, even if incomplete - -We will make reasonable efforts to notify the reporter before emergency disclosure. - -### 6.5 Public Disclosure Content (ISO/IEC 29147 §7.5.3) - -Our security advisories include: - -- Vulnerability description (non-technical summary + technical details) -- Affected versions and components -- CVE identifier (if assigned) -- CVSS score and severity rating -- Impact and exploit conditions -- Remediation steps (upgrade path, workarounds, configuration changes) -- Credit to reporter (unless anonymity requested) -- Timeline of disclosure - -**Disclosure channels**: - -- GitHub Security Advisory (primary) -- CHANGELOG.md and release notes -- Project README / documentation -- Mailing list or community forum (if established) - ---- - -## 7. Multi-Party Coordination (ISO/IEC TR 5895:2022) - -### 7.1 When Multi-Party Coordination is Needed - -We initiate multi-party coordination when a vulnerability: - -- Affects **upstream dependencies** (e.g., Express, Node.js, npm packages) -- Impacts **downstream projects** (forks, derivatives, or integrations) -- Is present in **multiple projects** sharing similar code -- Requires involvement of a **neutral coordinator** (e.g., CERT/CC, MITRE) - -### 7.2 Coordination Process (ISO/IEC TR 5895 §6.3) - -When multi-party coordination is required: - -1. **Identify stakeholders**: List all affected vendors/projects -2. **Establish communication**: Create a private coordination channel (email thread, CERT/CC case, GitHub security group) -3. **Share information**: Distribute vulnerability details under disclosure embargo -4. **Coordinate timelines**: Agree on a common disclosure date -5. **Synchronize patches**: Align release timing across parties -6. **Joint disclosure**: Publish advisories simultaneously (or in coordinated sequence) - -### 7.3 Coordinator Roles - -We may request assistance from: - -- **CERT/CC** (cert.org) for high-impact vulnerabilities affecting multiple vendors -- **MITRE** (cve.org) for CVE assignment and management -- **GitHub Security Lab** for coordination within the GitHub ecosystem -- **NIST NVD** for CVE publication and enrichment - -### 7.4 Information Sharing Restrictions - -When participating in multi-party coordination: - -- All parties operate under **confidentiality** until the agreed disclosure date -- Information may be shared with: - - Directly affected vendors/projects (on need-to-know basis) - - Neutral coordinators (CERT/CC, MITRE) - - Security response organizations (e.g., OS/distro security teams) -- Information **must not** be shared with: - - General public - - Media or press (except coordinated embargoed briefings) - - Unaffected third parties - -### 7.5 Disclosure Date Negotiation - -Target disclosure date is determined by: - -- Complexity of remediation across all parties -- Criticality and exploit likelihood -- Default 90-day window (may be shorter or longer by agreement) -- Active exploitation status - -If consensus cannot be reached, we follow the **earliest responsible disclosure date** that allows for remediation. - ---- - -## 8. Reporter Credit and Recognition (ISO/IEC 29147 §7.4.5) - -### 8.1 Credit Policy - -We recognize and credit security researchers who responsibly disclose vulnerabilities: - -- **Default**: Credit by name/handle in security advisories and release notes -- **Anonymous**: Opt-in anonymity respected ("Anonymous researcher") -- **No credit**: If reporter requests no attribution - -### 8.2 Hall of Fame - -We may maintain a **Security Researchers Hall of Fame** in this repository recognizing: - -- Researchers who have reported valid vulnerabilities -- Year of report and severity classification -- Link to public advisory (if applicable) - -_This section will be created when the first qualifying report is received._ - -### 8.3 Bug Bounty Program - -**Current status**: We do **not** operate a paid bug bounty program at this time. - -Reporters contribute out of goodwill to protect the amateur radio community. We are deeply grateful for their efforts. - ---- - -## 9. Safe Harbor and Legal Considerations - -### 9.1 Good-Faith Security Research - -We welcome and support **good-faith security research** conducted in accordance with this policy. We will not pursue legal action against researchers who: - -- Act in good faith to identify and report vulnerabilities -- Make a reasonable effort to avoid privacy violations, data destruction, and service disruption -- Do not exploit vulnerabilities beyond what is necessary to demonstrate the issue -- Do not access, modify, or exfiltrate data beyond minimal proof-of-concept -- Report findings promptly and privately -- Wait for our coordinated disclosure before public discussion - -### 9.2 Testing Guidelines - -When testing for vulnerabilities: - -- **Use your own infrastructure**: Test against your own deployment of OpenHamClock -- **Do not test production systems** operated by others without explicit written permission -- **Avoid service degradation**: No DoS attacks, no resource exhaustion, no brute-forcing -- **Respect privacy**: Do not access operator data, callsigns, locations, or logs of other users -- **No automated scanning** of public instances without prior approval - -### 9.3 Responsible Disclosure Commitment - -If you follow this policy, we commit to: - -- Not pursue legal action related to your research -- Work with you to understand and validate the issue -- Acknowledge your contribution publicly (unless you prefer anonymity) -- Keep you informed throughout the remediation and disclosure process - ---- - -## 10. Security Updates and Notifications - -### 10.1 How to Stay Informed - -Users and operators can stay informed of security updates via: - -- **GitHub Security Advisories**: https://github.com/accius/openhamclock/security/advisories -- **GitHub Releases**: https://github.com/accius/openhamclock/releases (security fixes tagged) -- **CHANGELOG.md**: Maintained in the repository -- **Watch/Subscribe**: Enable "Security alerts" in your GitHub repository watch settings - -### 10.2 Applying Security Updates - -When a security update is released: - -1. **Review the advisory**: Understand the impact and affected versions -2. **Check your version**: `git log -1 --pretty=format:"%H"` or `grep version package.json` -3. **Update immediately** for Critical/High severity: - ```bash - git pull - npm install - npm audit fix - docker-compose up -d --build # if using Docker - ``` -4. **Verify the fix**: Check that your version includes the patch commit -5. **Monitor for anomalies**: Review logs for signs of prior exploitation - ---- - -## 11. Best Practices for Operators (Self-Hosting) - -To reduce your vulnerability surface: - -1. **Do not expose to the public internet** - Do not port-forward OpenHamClock directly to the internet unless it is protected behind a reverse proxy with TLS, authentication, and rate limiting. - -2. **Protect your `.env` and secrets** - Treat `.env`, API keys, and configuration as secrets. Never commit them to public repositories. Use restrictive file permissions (`chmod 600 .env`). - -3. **Update regularly** - Subscribe to security advisories and apply updates promptly: - - ```bash - git pull - npm install - npm audit - npm audit fix # review changes before applying - ``` - -4. **Run with least privilege** - Use a dedicated non-root user for the application. If using Docker, ensure the container runs as non-root. - -5. **Enable security features** - - Set `NODE_ENV=production` - - Configure `AUTO_UPDATE_ENABLED=false` if you prefer manual updates - - Use HTTPS (TLS) for all connections - - Enable rate limiting and authentication on admin endpoints - -6. **Monitor for anomalies** - Review application logs regularly for suspicious activity (failed auth attempts, unusual API requests, etc.). - -7. **Backup configuration** - Maintain backups of your configuration before applying updates. - ---- - -## 12. Policy Review and Updates - -This policy will be reviewed and updated: - -- **Annually** (or more frequently as needed) -- When processes change materially -- After significant security incidents -- To align with evolving ISO/IEC standards - -**History**: - -- **v1.1** (2026-02-12): Enhanced ISO/IEC compliance, added multi-party coordination, severity classification, case lifecycle -- **v1.0** (Initial): Basic vulnerability disclosure policy - ---- - -## 13. Contact and Questions - -For questions about this policy (not vulnerability reports): - -- **General security questions**: Open a public Discussion on GitHub -- **Policy clarifications**: Email chris@cjhlighting.com (non-confidential) - -For **vulnerability reports**, see **§4 Reporting a Vulnerability**. - ---- - -## 14. Acknowledgments - -Thank you to the security research community for helping make OpenHamClock safer for the amateur radio community worldwide. Your responsible disclosures protect operators, preserve trust, and strengthen open-source security practices. - -## Metadata - -This policy aligns with international standards for vulnerability disclosure and handling: - -- **ISO/IEC 29147:2018** - Vulnerability disclosure -- **ISO/IEC 30111:2019** - Vulnerability handling processes -- **ISO/IEC TR 5895:2022** - Multi-party coordinated vulnerability disclosure and handling - -**Document version**: 1.1 -**Last updated**: 2026-02-12 -**Next review**: 2026-08-12 +Stay informed via [GitHub Security Advisories](https://github.com/accius/openhamclock/security/advisories) and [Releases](https://github.com/accius/openhamclock/releases).