Skip to content

Commit 01afb3b

Browse files
NikolaRHristovNikolaRHristov
committed
1 parent 38278c7 commit 01afb3b

1 file changed

Lines changed: 216 additions & 0 deletions

File tree

‎SECURITY.md‎

Lines changed: 216 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,216 @@
1+
# Security Policy for Land Ecosystem Elements
2+
3+
The Land development team and the community of contributors are deeply committed
4+
to the security of all software components within the Land Code Editor
5+
ecosystem. We value the community's efforts in identifying and responsibly
6+
disclosing security vulnerabilities. This document outlines the unified security
7+
policy and reporting process for **this specific Element**, which is an integral
8+
part of the broader Land project.
9+
10+
Your vigilance and responsible reporting help us maintain a safe and trustworthy
11+
environment for all users and developers. Please adhere to this policy to ensure
12+
that your findings are addressed effectively and efficiently.
13+
14+
## Guiding Principles
15+
16+
- **Proactive Security:** We strive to build security into our software from the
17+
ground up.
18+
- **Responsible Disclosure:** We encourage private reporting of vulnerabilities
19+
to prevent premature public exposure that could put users at risk.
20+
- **Timely Response:** We are committed to acknowledging, investigating, and
21+
addressing reported vulnerabilities in a timely manner.
22+
- **Transparency:** We aim to be transparent about vulnerabilities once they are
23+
resolved, often through security advisories and crediting reporters.
24+
- **Collaboration:** We believe in working collaboratively with security
25+
researchers and the community.
26+
27+
## Scope of this Policy
28+
29+
This security policy applies to vulnerabilities discovered within:
30+
31+
1. **The codebase of this specific Land Element repository.** This includes all
32+
source code, build scripts, and configuration files contained herein.
33+
2. **Direct dependencies explicitly managed and bundled by this Element.**
34+
3. **The interaction points and APIs this Element exposes to other Land
35+
Elements or to the end-user through the Land application.**
36+
37+
Vulnerabilities in third-party libraries that are general dependencies (e.g., a
38+
widely used open-source library not uniquely modified or configured by this
39+
Element) should ideally be reported to the maintainers of those libraries first.
40+
However, if such a vulnerability directly and significantly impacts the security
41+
of this Element or the Land ecosystem through its usage in this Element, please
42+
report it to us as well. We will assess how to mitigate it within our project
43+
(e.g., by updating the dependency, applying a workaround, or temporarily
44+
disabling affected functionality).
45+
46+
**Examples of vulnerabilities relevant to Land Elements might include (but are
47+
not limited to):**
48+
49+
- **Remote Code Execution (RCE):** If an Element allows untrusted input to
50+
execute arbitrary code.
51+
- **Privilege Escalation:** If an Element allows an unprivileged component or
52+
extension to gain higher privileges within the Land application or on the
53+
user's system.
54+
- **Information Disclosure:** If an Element improperly exposes sensitive user
55+
data, configuration details, or system information.
56+
- **Cross-Site Scripting (XSS):** Particularly relevant for UI-focused Elements
57+
(like `Sky` or `Wind`'s preload environment if it renders HTML content) where
58+
untrusted data could be injected into web views.
59+
- **Denial of Service (DoS):** If an Element can be made unresponsive or crash
60+
due to specially crafted input or excessive resource consumption.
61+
- **Path Traversal/Arbitrary File Access:** For Elements interacting with the
62+
filesystem (like `River`, `Sun`, or `Mountain`'s FS handlers), ensuring that
63+
path inputs are properly sanitized.
64+
- **Insecure IPC/Communication:** For Elements involved in inter-process
65+
communication (`Vine`, `Track`, `Echo`, `Mist`), vulnerabilities in the
66+
protocol or handling of messages.
67+
- **Sandbox Escapes:** For Elements designed to run untrusted code (like
68+
`Cocoon` or a future `Grove`), vulnerabilities that allow code to escape its
69+
intended sandbox.
70+
- **Authentication/Authorization Flaws:** If any Element implements access
71+
control mechanisms, flaws in these systems.
72+
- **Data Integrity Issues:** If an Element allows unauthorized modification of
73+
critical data or configuration.
74+
75+
## Supported Versions
76+
77+
We are committed to providing security updates for the following versions of
78+
this Land Element:
79+
80+
| Version Category | Supported | Notes |
81+
| :------------------------------- | :----------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
82+
| `Current` Branch / Latest Commit | :white_check_mark: | Actively developed version; security fixes are typically applied here first. |
83+
| Latest Tagged Pre-release | :white_check_mark: | If pre-releases are used, the latest one is generally supported. |
84+
| Latest Stable Release | :white_check_mark: | The most recent officially "released" version of this Element, if applicable (some Elements may only exist on `Current`). |
85+
| Previous Stable Releases | :x: | Generally, only the latest stable release is supported. Critical vulnerabilities in widely used older stable versions might be considered on a case-by-case basis, but this is not guaranteed. |
86+
| End-of-Life (EOL) Versions | :x: | Versions explicitly marked as EOL are not supported. |
87+
88+
Please ensure you are testing against and reporting vulnerabilities for a
89+
supported version. Reports for unsupported versions might not be prioritized or
90+
addressed. If unsure, please report against the `Current` branch.
91+
92+
## Reporting a Security Vulnerability
93+
94+
**IMPORTANT: DO NOT report security vulnerabilities through public GitHub
95+
issues, pull requests, or discussion forums for this repository.**
96+
97+
Public disclosure of a vulnerability before a fix is available can put the Land
98+
ecosystem and its users at risk.
99+
100+
**To report a security vulnerability, please send a detailed email to our
101+
central security address:**
102+
103+
➡️ [Security@Editor.Land](mailto:Security@Editor.Land) ⬅️
104+
105+
Please make sure your email includes:
106+
107+
1. **Subject Line:** Clearly indicate it's a security vulnerability report and,
108+
if known, the affected Element. Example:
109+
`Security Vulnerability Report: [Element Name] - [Brief Vulnerability Type]`
110+
2. **Element Name:** The specific Land Element repository this vulnerability
111+
pertains to (e.g., "Wind", "Mountain", "Cocoon").
112+
3. **Affected Version(s):** The specific version(s) or commit hash(es) of the
113+
Element where the vulnerability was identified.
114+
4. **Vulnerability Type:** A classification of the vulnerability (e.g., RCE,
115+
XSS, Path Traversal, Information Disclosure).
116+
5. **Detailed Description:** A clear, concise, and comprehensive explanation of
117+
the vulnerability. What is it? How does it work?
118+
6. **Steps to Reproduce (Proof of Concept):** This is crucial. Provide
119+
detailed, step-by-step instructions that allow us to reproduce the
120+
vulnerability reliably.
121+
- Include any necessary setup, configuration, specific inputs, or code
122+
snippets.
123+
- A minimal, self-contained Proof of Concept (PoC) is highly preferred.
124+
7. **Potential Impact:** Describe the potential consequences if this
125+
vulnerability is exploited (e.g., "An attacker could read arbitrary files,"
126+
"This could lead to application crash," "Sensitive user tokens could be
127+
stolen").
128+
8. **Environment Details (if relevant):** Operating System, browser version
129+
(for UI elements), specific configurations of Land or the Element.
130+
9. **Your Contact Information:** Your name/alias and an email address for
131+
follow-up communication. This is essential for us to ask clarifying
132+
questions.
133+
10. **Disclosure Intentions:** Please state if you have any intentions or
134+
timelines for public disclosure. We strongly prefer to coordinate disclosure
135+
once a fix is available.
136+
11. **Credit/Acknowledgement:** Let us know if and how you would like to be
137+
credited if the vulnerability is confirmed and fixed.
138+
139+
Providing as much detail as possible will help us investigate and respond more
140+
quickly.
141+
142+
## Our Vulnerability Management Process
143+
144+
Upon receiving your private vulnerability report at
145+
[Security@Editor.Land](mailto:Security@Editor.Land), we will follow this
146+
process:
147+
148+
1. **Acknowledgement (within 3 business days):** We will send an email
149+
acknowledging receipt of your report.
150+
2. **Initial Triage & Validation (within 7-10 business days of
151+
acknowledgement):**
152+
- Our security team and relevant Element maintainers will review your report
153+
to understand and attempt to reproduce the vulnerability.
154+
- We will make an initial assessment of the vulnerability's validity and
155+
potential severity.
156+
- We may contact you for additional information or clarification during this
157+
phase.
158+
3. **In-Depth Investigation & Remediation Planning:**
159+
- If the vulnerability is confirmed, we will conduct a more thorough
160+
investigation to understand its full scope and impact.
161+
- We will prioritize the vulnerability based on its severity and begin
162+
planning and developing a fix. The timeline for a fix can vary
163+
significantly based on complexity.
164+
4. **Communication & Updates:** We will strive to keep you informed of our
165+
progress, especially regarding significant milestones like confirmation, fix
166+
development, and planned release of the fix.
167+
5. **Fix Development & Testing:** A patch will be developed, reviewed, and
168+
tested.
169+
6. **Coordinated Disclosure:** Once a fix is ready and deployed (e.g., merged
170+
to `Current` or included in an upcoming release), we will coordinate with
171+
you on the public disclosure of the vulnerability.
172+
- This may involve a GitHub Security Advisory, release notes, and
173+
appropriate credit to you as the reporter (if desired).
174+
- We generally request a period of 90 days for remediation before public
175+
disclosure, but this can be negotiated based on the circumstances.
176+
177+
## Confidentiality
178+
179+
We will treat your report and all communications as confidential. We will not
180+
share information about the vulnerability with third parties without your
181+
permission, except as necessary to investigate and remediate the issue (e.g.,
182+
with core maintainers of an affected upstream dependency).
183+
184+
## Scope Exclusions (What Not to Report Here)
185+
186+
- **Denial of Service (DoS) on Public Infrastructure:** Please do not perform
187+
DoS testing against any public Land project infrastructure (e.g., websites,
188+
build servers).
189+
- **Social Engineering:** Reports of successful social engineering (e.g.,
190+
phishing of project members) are out of scope for this code vulnerability
191+
policy.
192+
- **Missing Security Best Practices (without exploitable impact):** For example,
193+
missing HTTP security headers on a non-sensitive static documentation site,
194+
unless you can demonstrate a direct exploitable vulnerability. Such issues are
195+
better raised as regular GitHub issues for improvement.
196+
- **Reports from Automated Scanners:** While scanner results can be helpful
197+
starting points, please manually validate findings and provide a proof of
198+
concept demonstrating actual exploitability. Generic scanner output without
199+
context is unlikely to be acted upon as a priority security issue.
200+
- **Self-XSS:** Cross-Site Scripting vulnerabilities that require the victim to
201+
paste code into their own browser console or modify their own client-side
202+
environment are generally not considered high-impact unless a plausible attack
203+
vector is demonstrated.
204+
- **Issues requiring physical access to an unlocked device.**
205+
206+
When in doubt, please err on the side of reporting to
207+
[Security@Editor.Land](mailto:Security@Editor.Land).
208+
209+
## Questions & Contact
210+
211+
For any questions regarding this security policy or the vulnerability reporting
212+
process for any Land Ecosystem Element, please contact us at
213+
[Security@Editor.Land](mailto:Security@Editor.Land).
214+
215+
Thank you for your commitment to helping us make the Land Code Editor ecosystem
216+
more secure for everyone.

0 commit comments

Comments
 (0)