LLVM 安全小组¶
LLVM 安全小组有以下目标
允许 LLVM 贡献者和安全研究人员向 LLVM 社区成员披露影响 LLVM 项目的安全相关问题。
组织针对这些问题的修复、代码审查和发布管理。
在广泛传播漏洞或缓解措施不足之前，允许发行版有时间调查和部署修复程序。
确保及时通知并发布给打包和分发基于 LLVM 的工具链和项目的供应商。
通过 CVE 流程，确保及时通知使用基于 LLVM 的工具链且其编译代码对安全性敏感的用户。
努力随着时间的推移提高安全性，例如在修复问题后添加额外的测试、模糊测试和加固。
注意：这些目标确保了及时的行动，在报告问题时提供了披露时间，并尊重供应商/打包者/用户的限制。
LLVM 安全小组是私密的。它由值得信赖的 LLVM 贡献者组成。在调查问题期间，其讨论内容仅限于安全小组（加上问题报告人和关键专家）。在问题公开后，该小组与该问题相关的全部讨论内容也将公开。
如何报告安全问题？¶
要报告任何 LLVM 项目中的安全问题，请使用 github 上 报告漏洞 功能，该功能位于 llvm/llvm-security-repo 代码库的“安全”选项卡下。
我们力争在您首次联系后的两个工作日内确认您的报告。如果您在那之前没有收到任何回复，您可以通过在 Discourse 论坛 上发帖请求与 LLVM 安全小组的某人联系来升级问题。**升级邮件列表是公开的**：在上面发帖时，避免讨论或提及具体问题。
小组构成¶
安全小组成员¶
小组成员代表了社区的广泛横截面，并满足以下纳入标准。列表格式为* ${full_name} (${affiliation}) [${github_username}]。如果某个人的 github 用户名不可用，则括号将为空。
Ahmed Bougacha (Apple) [@ahmedbougacha]
Andy Kaylor (Intel) [@andykaylor]
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]
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 安全小组成员）提名。提名应说明提名人是以个人、研究人员还是供应商联系人的身份提名。它应该清楚地描述提名的理由。
目前，提名通常使用 github 拉取请求提出、讨论和投票。 此处提供了一个提名示例。使用拉取请求有助于使成员资格讨论保持公开、透明，并以多种方式方便 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 项目自己的发布以及各个供应商的发布，以便同时修补问题。
安全小组可自行决定延迟或提前禁运日期。
问题负责人从MITRE获取 CVE 条目。
一旦禁运期结束，补丁将根据 LLVM 通常的代码审查流程公开发布。
所有安全问题（以及提名/移除讨论）将在修复程序进入 LLVM 代码库的大约十四周内公开。应采取预防措施，避免泄露报告中包含的特别敏感数据（例如用户名和密码对）。
政策变更¶
LLVM 安全政策可以通过 LLVM 安全小组的多数投票进行修改。此类变更也需要 LLVM 董事会批准。
什么是安全问题？¶
LLVM 项目有大量的代码，并非所有代码都被认为是安全敏感的。这尤其如此，因为 LLVM 在各种情况下使用：威胁模型不同，不受信任的输入不同，LLVM 运行的环境也各不相同。因此，LLVM 项目认为的安全问题是其成员已注册以安全维护的内容。
随着此安全流程的成熟，LLVM 社区成员可以提议将代码库的一部分指定为安全敏感的（或不再是安全敏感的）。这需要有理由，并需要像任何 RFC 一样得到 LLVM 社区的认可。在某些情况下，代码库的部分可以作为安全敏感的处理，但需要大量工作才能达到可管理的阶段。LLVM 社区需要决定是否希望投资于使这些代码部分可安全保护，并随着时间的推移保持这些安全属性。在所有情况下，都应咨询 LLVM 安全小组，因为他们将对针对这些代码部分提交的安全问题做出回应。
如果您不确定某个问题是否在此安全流程范围内，请倾向于假设它在范围内。安全小组可能会同意或不同意，并将在报告中解释其理由，并通过上述流程更新本文档。
LLVM 项目目前的安全敏感部分如下。请注意，此列表可能会随着时间的推移而改变。
目前没有定义。请不要因此而阻止您向安全小组报告您认为是安全敏感的问题。
LLVM 项目当前被视为非安全敏感的部分如下。请注意，此列表可能会随着时间的推移而改变。
语言前端，例如 clang，恶意输入文件可能导致不良行为。例如，恶意制作的 C 或 Rust 源文件可能导致 LLVM 中执行任意代码。LLVM 的这些部分尚未得到强化，编译不受信任的代码通常还包括运行make等实用程序，这些实用程序更容易执行恶意操作。