LLVM 安全回應小組

LLVM 安全回應小組有以下目標

  1. 允許 LLVM 貢獻者和安全研究人員向 LLVM 社群成員揭露影響 LLVM 專案的安全相關問題。

  2. 組織針對上述問題的修復、程式碼審查和發布管理。

  3. 在廣泛傳播漏洞或緩解措施缺陷之前，讓發行商有時間調查和部署修復程式。

  4. 確保及時通知為基於 LLVM 的工具鏈和專案打包和發行的供應商。

  5. 透過 CVE 流程，確保及時通知基於 LLVM 的工具鏈使用者，其編譯程式碼是安全敏感的。

注意：這些目標確保及時採取行動，在報告問題時提供揭露時程，並尊重供應商/封裝商/使用者的限制。

LLVM 安全回應小組是私人的。它由受信任的 LLVM 貢獻者組成。在問題調查期間，其討論內容保留在 LLVM 安全回應小組（加上問題報告者和主要專家）內部。在問題公開後，小組關於該問題的所有討論也將公開。

如何報告安全問題？

若要報告任何 LLVM 專案中的安全問題，請使用 報告漏洞 功能，位於 github 上 llvm/llvm-security-repo 儲存庫的「安全性」標籤下。

我們的目標是在您首次聯繫後的兩個工作日內確認您的報告。如果您在屆時沒有收到任何回覆，您可以透過在 Discourse 論壇 上發文，要求與 LLVM 安全回應小組的某人取得聯繫來升級。升級郵件列表是公開的：在上面發文時，請避免討論或提及具體問題。

小組組成

安全回應小組成員

小組成員代表了社群的廣泛橫截面，並符合以下納入標準。列表格式為 * ${full_name} (${affiliation}) [${github_username}]。如果個人的 github 使用者名稱不可用，則括號將為空。

  • Abhay Kanhere (Apple) [@AbhayKanhere]

  • Ahmed Bougacha (Apple) [@ahmedbougacha]

  • Artur Pilipenko (Azul Systems Inc) []

  • Boovaragavan Dasarathan (Nvidia) [@mrragava]

  • Dimitry Andric (個人；FreeBSD) [@DimitryAndric]

  • Ed Maste (個人；FreeBSD) [@emaste]

  • George Burgess IV (Google) [@gburgessiv]

  • Josh Stone (Red Hat；Rust) [@cuviper]

  • Kristof Beyls (ARM) [@kbeyls]

  • Matthew Riley (Google) [@mmdriley]

  • Matthew Voss (Sony) [@ormris]

  • Nikhil Gupta (Nvidia) []

  • Oliver Hunt (Apple) [@ojhunt]

  • Peter Smith (ARM) [@smithp35]

  • Pietro Albini (Ferrous Systems；Rust) [@pietroalbini]

  • Serge Guelton (Mozilla) [@serge-sans-paille]

  • Sergey Zverev (Intel) [@offsake]

  • Shayne Hiet-Block (Microsoft) [@GreatKeeper]

  • Tim Penge (Sony) [@tpenge]

  • Tulio Magno Quites Machado Filho (Red Hat) [@tuliom]

  • Will Huhn (Intel) [@wphuhn-intel]

  • Yvan Roux (ST) [@yroux]

標準

  • LLVM 安全回應小組成員的被提名人應屬於以下群組之一

    • 個人貢獻者

      • 專門修復基於編譯器的安全相關問題，或經常參與其探索和解決。

      • 擁有發現安全漏洞和負責地揭露這些漏洞的記錄。

      • 是編譯器專家，對了解、解決和預防未來安全漏洞有特定興趣。

      • 在過去一年中，積極為 LLVM 專案貢獻了重要的程式碼。

    • 研究人員

      • 擁有發現安全漏洞和負責地揭露這些漏洞的記錄。

      • 是編譯器專家，對了解、解決和預防未來安全漏洞有特定興趣。

    • 供應商聯絡人

      • 代表組織或公司，其產品出貨包含自己的 LLVM 副本。由於其在組織中的職位，被提名人有合理的需要了解安全問題和揭露禁運。

  • 此外，以下是 LLVM 安全回應小組成員的必要但不充分的標準

    • 如果已在 LLVM 安全回應小組中，則在過去一年中積極參與了一個（如果有的話）安全問題。

    • 如果已在 LLVM 安全回應小組中，則在過去一年中積極參與了大多數成員資格討論。

    • 如果已在 LLVM 安全回應小組中，則在過去一年中積極參與了撰寫或審查透明度報告。

    • 當受僱於公司或其他實體時，母公司在 LLVM 安全回應小組中已有的成員不超過三名。

    • 當被提名為供應商聯絡人時，其在該供應商中的職位與最初被提名時保持不變。

    • 被提名人受到現有 LLVM 安全回應小組成員的信任，能夠在仍活躍時保持通訊禁運。

提名流程

任何認為自己符合這些標準的人都可以自我提名，或由第三方（例如現有的 LLVM 安全回應小組成員）提名。提名應說明被提名人是以個人、研究人員還是供應商聯絡人的身分被提名。它應清楚描述提名的理由。

目前，提名通常是使用 github pull request 提出、討論和投票的。此處提供了一個 提名範例。pull request 的使用有助於使成員資格討論保持開放、透明，並易於 LLVM 開發人員以多種方式存取。如果出於任何原因，完全公開可讀的提名似乎不合適，您可以透過 報告漏洞 途徑聯繫 LLVM 安全回應小組，並且可以討論在個人受限的情況下，處理提名的最佳方式。

選擇新成員

如果 LLVM 安全回應小組成員資格的提名獲得大多數現有 LLVM 安全回應小組成員的支持，則在五個工作日內將會通過，除非現有的安全回應小組成員反對。如果提出異議，LLVM 安全回應小組成員應討論此事並嘗試達成共識；如果無法達成共識，則提名只有在獲得 LLVM 安全回應小組三分之二的超級多數票時才能成功。

接受成員資格

在新 LLVM 安全回應小組成員資格最終確定之前，成功的被提名人應接受成員資格並同意遵守此安全策略，特別是以下 LLVM 安全回應小組成員的特權和責任。

保持成員資格有效

  • 至少每六個月，LLVM 安全回應小組會應用上述標準。成員列表會據此進行修剪。

  • 任何 LLVM 安全回應小組成員都可以要求在接下來的五個工作日內應用這些標準。

  • 如果 LLVM 安全回應小組成員的行為不符合本策略的文字和精神，則可以透過成員的多數票撤銷其 LLVM 安全回應小組成員資格，不包括正在考慮撤銷的人員。在成員要求進行撤銷投票後，投票將開放五個工作日。

  • 緊急暫停：如果 LLVM 安全回應小組成員公然無視 LLVM 安全策略，則可以應任何兩名成員的要求暫時暫停其成員資格。在這種情況下，請求成員應將違規行為的描述通知 LLVM 安全回應小組。此時，成員資格將暫時暫停五個工作日，等待永久撤銷投票的結果。

  • LLVM 理事會可以從 LLVM 安全回應小組中移除任何成員。

透明度報告

每年，LLVM 安全回應小組都必須發布透明度報告。本報告的目的是透過總結去年已公開的揭露資訊，讓社群了解情況。它應包含所有公開揭露資訊的列表，以及修復問題所需時間、禁運期長度等統計數據。

透明度報告發布於 LLVM 安全小組透明度報告。

LLVM 安全回應小組成員的特權和責任

存取權限

LLVM 安全回應小組成員將訂閱私人的 討論媒介。它將用於安全問題的技術討論，以及關於揭露時間表和成員資格等事項的流程討論。成員可以存取所有安全問題。

保密性

LLVM 安全回應小組成員應將與小組分享的 LLVM 安全問題資訊視為機密，直到公開揭露為止

  • 成員不應向非成員揭露安全問題資訊，除非兩位成員都受僱於同一家基於 LLVM 產品的供應商，在這種情況下，資訊可以在該組織內按需知情原則共享，並像機密資訊一樣在該組織內處理。

  • 如果 LLVM 安全回應小組同意，指定的成員可以與非基於 LLVM 產品的供應商共享問題，如果其產品也受到相同問題的影響。應要求非 LLVM 供應商尊重問題的禁運日期，並且不要在組織內超出按需知情人員的範圍共享資訊。

  • 如果 LLVM 安全回應小組同意，可以引入關鍵專家來協助解決特定問題。應要求關鍵專家尊重問題的禁運日期，並且不要共享資訊。

揭露

依照以下流程，LLVM 安全回應小組決定每個安全問題的公開揭露禁運日期。如果所有計劃發布修復程式的供應商都已完成，且報告者不反對，則可以提前解除禁運。

協作

LLVM 安全回應小組成員應

  • 及時分享他們意識到的任何 LLVM 漏洞。

  • 自願推動問題向前發展。

  • 協助評估傳入問題的嚴重性。

  • 協助撰寫和審查解決安全問題的修補程式。

  • 參與成員提名和移除流程。

討論媒介

用於託管 LLVM 安全回應小組討論的媒介是安全敏感的。因此，它應在可以滿足我們安全期望的基礎架構上運行。

我們使用 GitHub 的機制私下報告安全漏洞，以進行安全討論

  • 提交安全問題。

  • 討論 LLVM 的安全改進。

我們偶爾也需要討論 LLVM 安全回應小組本身的後勤事宜

  • 提名新成員。

  • 提議移除成員。

  • 建議政策變更。

我們經常在公開場合進行這些討論，在我們的 每月公開同步電話會議 和 Discourse 論壇上。對於內部或機密討論，我們也使用私人郵件列表。

流程

以下流程在討論媒介上針對每個報告的問題發生

  • 安全問題報告者（不一定是 LLVM 貢獻者）報告問題。

  • 在兩個工作日內，LLVM 安全回應小組的一名成員負責推動問題達成可接受的解決方案。這位負責人不需要對每個問題都是同一個人。此人可以自我提名。

  • LLVM 安全回應小組成員討論問題在哪些情況下（如果有的話）與安全相關，並確定它是否是安全問題。

  • 協商公開揭露的禁運日期，預設最短時限為九十天。

  • LLVM 安全回應小組成員可以建議將關鍵專家拉入特定問題的討論。除非其他 LLVM 安全回應小組成員反對，否則可以拉入關鍵專家。

  • 撰寫和審查修補程式。

  • 將安全修補程式從最新版本向後移植到舊版本並不總是可行。是否應進行此類向後移植，以及向後移植到多遠的版本，由 LLVM 安全回應小組決定。

  • LLVM 安全回應小組找出如何調整 LLVM 專案自身的發行版本以及各個供應商的發行版本的時間，以便同時修補問題。

  • 禁運日期可以在 LLVM 安全回應小組的酌情決定下延遲或提前。

  • 問題負責人從 MITRE 取得 CVE 條目。

  • 一旦禁運期結束，修補程式將根據 LLVM 的常規程式碼審查流程公開發布。

  • 所有安全問題（以及提名/移除討論）在大約修復程式碼登陸 LLVM 儲存庫後的十四週內公開。應採取預防措施，避免揭露報告中包含的特別敏感資料（例如使用者名稱和密碼對）。

政策變更

LLVM 安全策略可以透過 LLVM 安全回應小組的多數票更改。此類變更也需要獲得 LLVM 理事會的批准。

什麼被認為是安全問題？

LLVM 專案有大量的程式碼，並非所有程式碼都被認為是安全敏感的。尤其如此，因為 LLVM 被廣泛用於各種情況：存在不同的威脅模型，不受信任的輸入不同，並且 LLVM 運行的環境也各不相同。因此，LLVM 專案認為的安全問題是其成員已簽署協議以安全維護的內容。

隨著此安全流程的成熟，LLVM 社群的成員可以提議將程式碼庫的某一部分指定為安全敏感的（或不再是安全敏感的）。這需要理由，並像任何 RFC 一樣獲得 LLVM 社群的認可。在某些情況下，程式碼庫的某些部分可以作為安全敏感的來處理，但需要大量工作才能達到可管理的階段。LLVM 社群將需要決定是否要投資使程式碼的這些部分可保護，並長期維護這些安全屬性。在所有情況下，都應諮詢 LLVM 安全回應小組，因為他們將回應針對程式碼庫這些部分提交的安全問題。

如果您不確定問題是否在此安全流程的範圍內，請傾向於假設它在範圍內。安全回應小組可能會同意或不同意，並將在其報告中解釋其理由，並透過上述流程更新本文檔。

LLVM 專案目前的安全敏感部分如下。請注意，此列表可能會隨著時間而更改。

  • 目前尚未定義任何項目。請不要因此而阻止您向 LLVM 安全回應小組報告您認為是安全敏感的問題。

LLVM 專案目前被視為非安全敏感的部分如下。請注意，此列表可能會隨著時間而更改。

  • 語言前端，例如 clang，惡意輸入檔案可能會導致不良行為。例如，惡意製作的 C 或 Rust 原始碼檔案可能會導致任意程式碼在 LLVM 中執行。LLVM 的這些部分尚未強化，並且編譯不受信任的程式碼通常還包括運行 make 等工具，這些工具更容易執行惡意操作。