LLVM 安全响应小组¶
LLVM 安全响应小组有以下目标
允许 LLVM 贡献者和安全研究人员向 LLVM 社区成员披露影响 LLVM 项目的安全相关问题。
组织针对所述问题的修复、代码审查和发布管理。
允许分发商在广泛传播漏洞或缓解措施缺陷之前，有时间调查和部署修复程序。
确保及时通知和发布给打包和分发基于 LLVM 的工具链和项目的供应商。
通过 CVE 流程，确保及时通知那些编译代码对安全敏感的基于 LLVM 的工具链的用户。
注意：这些目标确保及时采取行动，在报告问题时提供披露时间，并尊重供应商/打包商/用户的约束。
LLVM 安全响应小组是私有的。它由受信任的 LLVM 贡献者组成。在问题被调查期间，其讨论仅限于 LLVM 安全响应小组（加上问题报告者和关键专家）。在问题公开后，小组关于该问题的全部讨论也将公开。
如何报告安全问题？¶
要在任何 LLVM 项目中报告安全问题，请使用 github 上 llvm/llvm-security-repo 仓库 “Security” 选项卡下的 报告漏洞 功能。
我们的目标是在您首次联系后的两个工作日内确认您的报告。如果您在那时没有收到任何回复，您可以通过在 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 等实用程序，这些实用程序更容易执行恶意操作。