You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[docs] Describe reporting security issues on the chromium tracker.
To track security issues, we're starting with the chromium bug tracker
(using the llvm project there).
We considered using Github Security Advisories. However, they are
currently intended as a way for project owners to publicize their
security advisories, and aren't well-suited to reporting issues.
This also moves the issue-reporting paragraph to the beginning of the
document, in part to make it more discoverable, in part to allow the
anchor-linking to actually display the paragraph at the top of the page.
Note that this doesn't update the concrete list of security-sensitive
areas, which is still an open item. When we do, we may want to move the
list of security-sensitive areas next to the issue-reporting paragraph
as well, as it seems like relevant information needed in the reporting
process.
Finally, when describing the discission medium, this splits the topics
discussed into two: the concrete security issues, discussed in the
issue tracker, and the logistics of the group, in our mailing list,
as patches on public lists, and in the monthly sync-up call.
While there, add a SECURITY.md page linking to the relevant paragraph.
Differential Revision: https://reviews.llvm.org/D100873
Copy file name to clipboardexpand all lines: llvm/docs/Security.rst
+23-17
Original file line number
Diff line number
Diff line change
@@ -15,6 +15,15 @@ The LLVM Security Group has the following goals:
15
15
16
16
The LLVM Security Group is private. It is composed of trusted LLVM contributors. Its discussions remain within the Security Group (plus issue reporter and key experts) while an issue is being investigated. After an issue becomes public, the entirety of the group’s discussions pertaining to that issue also become public.
17
17
18
+
.. _report-security-issue:
19
+
20
+
How to report a security issue?
21
+
===============================
22
+
23
+
To report a security issue in the LLVM Project, please `open a new issue`_ in the LLVM project page, on the chromium issue tracker. Be sure to use the "Security bug report" template.
24
+
25
+
We aim to acknowledge your report within two business days since you first reach out. If you do not receive any response by then, you can escalate by sending a message to the `llvm-dev mailing list`_ asking to get in touch with someone from the LLVM Security Group. **The escalation mailing list is public**: avoid discussing or mentioning the specific issue when posting on it.
26
+
18
27
19
28
Group Composition
20
29
=================
@@ -141,22 +150,28 @@ Members of the LLVM Security Group are expected to:
141
150
Discussion Medium
142
151
=================
143
152
144
-
*FUTURE*: this section needs more work! Where discussions occur is influenced by other factors that are still open in this document. We can figure it out later.
145
-
See other existing systems: `chromium issue tracker`_, tentative `GitHub security`_. It seems like bugzilla and email don’t meet security requirements.
153
+
*FUTURE*: this section needs more work! Where discussions occur is influenced by other factors that are still open in this document. We can finalize it later.
154
+
It seems like bugzilla and email don't meet security requirements.
146
155
147
156
The medium used to host LLVM Security Group discussions is security-sensitive. It should therefore run on infrastructure which can meet our security expectations.
148
157
149
-
This is where all security discussions occur:
158
+
We are currently using the `chromium issue tracker`_ (as the `llvm` project) to have security discussions:
150
159
151
160
* File security issues.
152
-
* Nominate new members.
153
-
* Propose member removal.
154
-
* Suggest policy changes.
155
161
* Discuss security improvements to LLVM.
156
162
157
-
158
163
When a new issue is filed, a template is provided to help issue reporters provide all relevant information.
159
164
165
+
*FUTURE*: The `Github security`_ workflow allows publicly disclosing resolved security issues on the github project page, and we would be interested in adopting it for that purpose. However, it does not easily allow confidential reporting of security issues, as creating Github Security Advisories is currently restricted to Github project admins. That is why we have started with the `chromium issue tracker`_ instead.
166
+
167
+
168
+
We also occasionally need to discuss logistics of the LLVM Security Group itself:
169
+
170
+
* Nominate new members.
171
+
* Propose member removal.
172
+
* Suggest policy changes.
173
+
174
+
We often have these discussions publicly, in our :ref:`monthly public sync-up call <online-sync-ups>` and on public LLVM mailing lists. For internal or confidential discussions, we also use a private mailing list.
160
175
161
176
Process
162
177
=======
@@ -204,18 +219,9 @@ The parts of the LLVM Project which are currently treated as non-security sensit
204
219
* Language front-ends, such as clang, for which a malicious input file can cause undesirable behavior. For example, a maliciously-crafter C or Rust source file can cause arbitrary code to execute in LLVM. These parts of LLVM haven't been hardened, and compiling untrusted code usually also includes running utilities such as `make` which can more readily perform malicious things.
205
220
* *FUTURE*: this section will be expanded.
206
221
207
-
.. _report-security-issue:
208
-
209
-
How to report a security issue?
210
-
===============================
211
-
212
-
*FUTURE*: this section will be expanded once we’ve figured out other details above. In the meantime, if you found a security issue please follow directly the escalation instructions below.
213
-
214
-
Not everyone who wants to report a security issue will be familiar with LLVM, its community, and processes. Therefore, this needs to be easy to find on the LLVM website, and set clear expectations to issue reporters.
215
-
216
-
We aim to acknowledge your report within two business days since you first reach out. If you do not receive any response by then, you can escalate by sending a message to the `llvm-dev mailing list`_ asking to get in touch with someone from the LLVM Security Group. **The escalation mailing list is public**: avoid discussing or mentioning the specific issue when posting on it.
217
222
218
223
.. _CVE process: https://cve.mitre.org
224
+
.. _open a new issue: https://bugs.chromium.org/p/llvm/issues/entry
0 commit comments