mirror of
https://github.com/jesseduffield/lazydocker.git
synced 2026-07-22 15:11:02 +00:00
SECURITY.md proposal
Expanded the security policy document with detailed sections on vulnerability reporting, scope, supported versions, disclosure policy, handling process, severity classification, third-party dependencies, security audits, acknowledgments, contact information, and legal considerations.
This commit is contained in:
Sébastien Proust
GitHub
parent
4e2f26b21e
commit
3b82c14f3a
1 changed files with 195 additions and 0 deletions
195
SECURITY.md
Normal file
195
SECURITY.md
Normal file
|
|
@ -0,0 +1,195 @@
|
|||
# Security Policy for lazydocker
|
||||
|
||||
## ⚠️ Overview
|
||||
|
||||
This document describes how to report security vulnerabilities, how we prioritize and remediate them, and our supported versions and responsibilities. We aim to make lazydocker safer, and welcome responsible disclosures.
|
||||
|
||||
---
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Reporting a Vulnerability](#reporting-a-vulnerability)
|
||||
2. [Scope & Assets](#scope--assets)
|
||||
3. [Supported Versions & Maintenance](#supported-versions--maintenance)
|
||||
4. [Disclosure Policy](#disclosure-policy)
|
||||
5. [Handling & Remediation Process](#handling--remediation-process)
|
||||
6. [Severity Classification](#severity-classification)
|
||||
7. [Third‑Party Dependencies & Supply Chain](#third-party-dependencies--supply-chain)
|
||||
8. [Security Audits & External Review](#security-audits--external-review)
|
||||
9. [Acknowledgments & Hall of Fame](#acknowledgments--hall-of-fame)
|
||||
10. [Contact Information](#contact-information)
|
||||
11. [Legal & Safe Harbor](#legal--safe-harbor)
|
||||
|
||||
---
|
||||
|
||||
## 1. Reporting a Vulnerability
|
||||
|
||||
If you discover a security issue in **lazydocker**, please do **not** open a public GitHub issue exposing the vulnerability. Instead:
|
||||
|
||||
1. Email the maintainers at **security@lazydocker.dev** (or another private contact if designated).
|
||||
2. In your report, include:
|
||||
- Your name/handle and preferred contact method
|
||||
- A clear description of the issue (what is wrong, root cause, how it can be triggered)
|
||||
- Version(s) of lazydocker affected
|
||||
- Steps to reproduce (minimal if possible)
|
||||
- Potential impact (e.g. code execution, data leak, container escape)
|
||||
- Proof-of-concept exploit or patch (if available)
|
||||
- Any constraints or environment details (OS, Docker version, configuration)
|
||||
|
||||
We commit to acknowledging receipt of a valid report within **48 hours**.
|
||||
|
||||
If you cannot use email, or you have confidentiality concerns, you may contact a maintainer privately (e.g. via GitHub private message) or use GitHub’s [security advisories] interface.
|
||||
|
||||
---
|
||||
|
||||
## 2. Scope & Assets
|
||||
|
||||
### In-Scope
|
||||
|
||||
- The **lazydocker** binary and source code, including all CLI/UI/interaction logic
|
||||
- Configuration files (e.g. in `~/.config/jesseduffield/lazydocker`)
|
||||
- Hooks, scripts, or extension mechanisms
|
||||
- Behavior when interacting with Docker daemon / API
|
||||
- Any parts of the codebase that process external input (logs, parsing, keybindings, plugins)
|
||||
|
||||
### Out-of-Scope (typically)
|
||||
|
||||
- Docker daemon itself or vulnerabilities in external dependencies (though if vulnerable, it should be flagged)
|
||||
- Issues in third-party libraries unless they are exploited in lazydocker’s usage
|
||||
- Misconfiguration or usage in insecure environments (e.g. running with overly permissive permissions)
|
||||
- Physical or OS-level vulnerabilities unrelated to lazydocker logic
|
||||
|
||||
---
|
||||
|
||||
## 3. Supported Versions & Maintenance
|
||||
|
||||
| Version Branch | Security Support | Backporting Policy |
|
||||
|----------------|------------------|---------------------|
|
||||
| `main` (latest) | Fully supported — all new security fixes go here | — |
|
||||
| Latest **stable release** | Supported for a reasonable timeframe (e.g. 12–18 months) | Critical / High fixes may be backported |
|
||||
| Older versions (>18 months out) | End-of-life for guaranteed support | Community or contributors may backport, but not guaranteed |
|
||||
|
||||
Users are encouraged to stay on recent stable releases or `main`.
|
||||
|
||||
When a release includes a security fix, it should include a **major**, **minor**, or **patch** version bump as appropriate, and release notes should clearly mention “Security fix: …”.
|
||||
|
||||
---
|
||||
|
||||
## 4. Disclosure Policy
|
||||
|
||||
We follow a **responsible disclosure** approach:
|
||||
|
||||
- We request that vulnerability details remain private until a fix is ready or an advisory is published.
|
||||
- If the reporter desires public acknowledgment (name/handle), we will credit appropriately (unless anonymity is requested).
|
||||
- Once a fix is available and users have a reasonable time to upgrade, we will publish a GitHub Security Advisory and/or release notes summarizing the issue, its impact, affected versions, and mitigation steps.
|
||||
|
||||
If a vulnerability is already public or being actively exploited, we may accelerate disclosure and fix timelines.
|
||||
|
||||
---
|
||||
|
||||
## 5. Handling & Remediation Process
|
||||
|
||||
1. **Triage & Acknowledge (within 48h)**
|
||||
Assess scope and severity. Determine whether the issue is genuine, reproducible, and in-scope.
|
||||
|
||||
2. **Reproduce & Validate**
|
||||
Confirm the issue in a controlled environment (minimized setup). Check consistency across versions/configurations.
|
||||
|
||||
3. **Root Cause & Fix Development**
|
||||
Create a patch or fix. Include tests if possible (unit test, integration test, fuzzing). Ensure the fix addresses the root cause, not just symptoms.
|
||||
|
||||
4. **Internal Review / Security Review**
|
||||
Let one or more project maintainers review the patch. For high/critical issues, consider bringing in a third-party reviewer or security consultant.
|
||||
|
||||
5. **Release & Backport**
|
||||
Publish the fix in a new version. For critical/high severity vulnerabilities, attempt backporting to supported stable versions. Label releases clearly (e.g. `v0.25.1` with “Security fix” in changelog).
|
||||
|
||||
6. **Disclosure / Advisories**
|
||||
After users have reasonable time, publish a public advisory (via GitHub, project website, mailing list). Include:
|
||||
- Description of the issue
|
||||
- Affected versions
|
||||
- How to detect exploitation
|
||||
- Steps to remediate / upgrade
|
||||
|
||||
7. **Post-Mortem / Lessons Learnt**
|
||||
Document the issue internally: what caused it, how the fix was validated, whether further fixes are needed (e.g. additional tests, fuzzing, CI checks).
|
||||
|
||||
### Timelines (target)
|
||||
|
||||
- Acknowledgment: within **48 hours**
|
||||
- Patch creation: ideally within **14 days** for high/critical issues
|
||||
- Release: as soon as fix is stabilized
|
||||
- Advisory publication: shortly after release, allowing user upgrade window
|
||||
|
||||
These are target goals, not guarantees—delays may occur depending on complexity.
|
||||
|
||||
---
|
||||
|
||||
## 6. Severity Classification
|
||||
|
||||
We use these general categories. Severity may be adjusted based on context.
|
||||
|
||||
| Severity | Description / Examples |
|
||||
|----------|--------------------------|
|
||||
| **Critical** | Remote code execution, container escape, privilege escalation, or ability to manipulate lazydocker to compromise host or Docker daemon. Active exploit or high severity. |
|
||||
| **High** | Data leak of credentials/tokens, unauthorized access to sensitive content, denial-of-service by resource exhaustion or panic conditions. |
|
||||
| **Medium** | Non-trivial bugs that require specific conditions or limited context, moderate impact. |
|
||||
| **Low** | Minor information disclosure (e.g., version banner), safe misconfigurations, UI bugs with minimal impact. |
|
||||
|
||||
Fixes for **Critical** & **High** vulnerabilities should be prioritized; **Medium/Low** should be fixed in normal maintenance cycles.
|
||||
|
||||
---
|
||||
|
||||
## 7. Third‑Party Dependencies & Supply Chain
|
||||
|
||||
- LazyDocker depends on external Go modules and possibly Docker API libraries. If a dependency has a known vulnerability, we should evaluate its impact and upgrade or patch as needed.
|
||||
- We encourage maintainers to run dependency vulnerability scanners (e.g. `go audit`, `go mod tidy`, `govulncheck`) and monitor upstream security announcements.
|
||||
- For CI or build scripts, we should validate the integrity of artifacts (e.g. verify checksums/signatures of dependencies, ensure reproducible builds where possible).
|
||||
|
||||
---
|
||||
|
||||
## 8. Security Audits & External Review
|
||||
|
||||
- We welcome external security audits, reviews, or bug bounties. If you’re a security researcher or auditor and wish to review the code, contact us under this security policy.
|
||||
- If a vulnerability is discovered by a third party audit, it will be handled through our standard reporting and remediation process.
|
||||
- We may periodically contract or solicit audits on modules that handle user input, parsing, UI, or Docker interaction logic.
|
||||
|
||||
---
|
||||
|
||||
## 9. Acknowledgments & Hall of Fame
|
||||
|
||||
We aim to recognize security researchers who responsibly disclose vulnerabilities. With permission, their name or handle may be credited in:
|
||||
|
||||
- GitHub Security Advisory
|
||||
- Release notes or changelog
|
||||
- A **SECURITY_HALL_OF_FAME.md** or dedicated section
|
||||
|
||||
If anonymity is preferred, we will withhold the name.
|
||||
|
||||
---
|
||||
|
||||
## 10. Contact Information
|
||||
|
||||
- **Primary security email**: `security@lazydocker.dev`
|
||||
- Alternative contact: private GitHub message to **Jesse Duffield** or other maintainers
|
||||
- For special handling (e.g. legal/confidentiality), indicate in your submission, and we will respect those requirements
|
||||
|
||||
---
|
||||
|
||||
## 11. Legal & Safe Harbor
|
||||
|
||||
By submitting a vulnerability report under this policy:
|
||||
|
||||
- You confirm that you have not violated laws, contracts, or confidentiality agreements in discovering it.
|
||||
- You agree to allow us to remediate and publish a public advisory (with or without attribution based on your preference).
|
||||
- We commit **not** to initiate legal action against you, to the extent you act in good faith and follow this policy's guidelines.
|
||||
- We reserve the right to refuse or ignore reports that do not follow responsible disclosure (e.g. publishing publicly without notice).
|
||||
|
||||
---
|
||||
|
||||
**Signed,**
|
||||
The lazydocker Project Team
|
||||
(GitHub: jesseduffield/lazydocker)
|
||||
License: MIT :contentReference[oaicite:0]{index=0}
|
||||
Repository: Go / Shell codebase :contentReference[oaicite:1]{index=1}
|
||||
|
||||
Loading…
Add table
Reference in a new issue