概述
Argon(现在是Aqua Security的一部分)与互联网安全中心(CIS)接洽，商量开发软件供应链安全的CIS Benchmark。CIS 多年来开发并发布了涵盖广泛的安全配置指南(即CIS Benchmark)，但生成软件供应链安全基准的概念提出了一系列新的问题。开发现代软件通常使用各种各样的技术平台，那么应该包括哪些平台呢?我们如何确保不同平台安全建议的一致性?
我们决定，与其一开始就潜心创建一个特定的基准，不如首先创建通用指南集，作为更具体指南的母版。因此，《CIS软件供应链安全指南》应时而生。本指南的出版希望从全球征求反馈意见，这将有助于确保未来的特定平台指南(CIS Benchamrk)更加准确和客户需求相关。
指南覆盖软件供应链阶段，如下图所示，从贡献者添加代码开始，到应用交付给客户。
该指南目前分为五大类，包含100多条建议：
1 源代码：对组织开发的应用程序，源代码管理的安全建议
-
软件供应链的第一阶段，对其他过程而言，这是唯一的正确来源。因此，需要保护它不受代码本身、漏洞、错误配置、可能存在的敏感信息、存储它的平台的影响。
2 构建管道：管理和保证构建管道组件安全的安全建议
-
构建组件包括构建管道（一组指令，专门作用于源代码的初始文件，并在其上运行一系列任务，以输出最终的工件）、管道所运行的环境、管道的管理和执行等等。供应链攻击越来越多地针对软件供应链的第二阶段(如Codecov攻击或SolarWinds)。
3 依赖项：管理软件构建和发布过程中各种依赖项的安全建议
-
依赖项是软件供应链的重要组成部分，包括任何进入应用程序代码或被构建管道本身使用的东西。他们通常由第三方开发人员编写，可能容易受到某些攻击(例如，log4j攻击)。
4 工件：管理构建管道生成工件的安全建议，以及应用程序在构建过程本身中使用的工件。
-
工件是软件的打包版本。它们存储在包注册中心(或构件管理器)，并要求从它们被创建的那一刻起，到复制和更新它们的时间内一直保证安全，直到将它们部署到相关的环境。
5 部署：管理应用程序部署过程、配置和附带文件的安全建议
-
这是软件供应链的最后阶段。之后，客户端已经使用应用程序，并且正在生产环境中运行。确保将软件安全地交付到客户端非常重要。
指南的总体愿景和CIS Benchmark的最终目的，是支持重要的新兴标准，如软件工件的供应链水平(supply-chain levels for software Arifacts，SLSA)和更新框架(The Update Framework，TUF)，对本基准所支持平台的设置和审计配置，提供基本建议。
通过发布《CIS软件供应链安全指南》，CIS和Aqua Security希望搭对搭建特定开发平台基准指南感兴趣的充满活力的社区。以CIS人所共知的协作和共识态度，呼吁使用这种平台开发或工作的主题专家(subject matter expert，sme)的帮助。
到目前为止，该指南已经被来自Aqua Security、CIS、 Microsoft、PayPal,、Red Hat、CyberArk,、Axonius等的主题专家审查。通过发布当前的工作，CIS和Aqua Security希望有更多的中小企业参与到这个项目中做出贡献，为所有人带来好处。
目标受众
本CIS指南适用于通过自动化构建和部署软件更新DevOps管道，计划部署、评估或保护解决方案的DevOps和应用程序安全管理员、安全专家、审核员、帮助台和平台部署人员。
共识指南
本指南是通过由主题专家组成的全球社区使用协商一致审查程序制定的。该过程将实际经验与数据为基础的信息相结合，以创建特定技术的指导，来帮助用户保护其安全环境。协商意见的参与者提供了来自不同背景的观点，包括咨询、软件开发、审计和合规、安全研究、运营、政府和法律。
致谢
本指南举例说明了一个由用户、供应商和主题专家组成的社区，通过共识协作来完成任务。CIS 社区感谢整个共识团队，特别表彰以下对本指南制定做出重大贡献的个人：
作者
Eylam Milner, Aqua Security
Resheet Kosef, Aqua Security
贡献者
Yossi Weizman, Microsoft
Erez Dasa, PayPal
Michael Kotelnikov, Red Hat
Moshik Barak, CyberArk
Ofir Shapira, Axonius
Mor Weinberger, Aqua Security
Yakir Kadkoda, Aqua Security
Randy Mowen, Center for Internet Security
Stephen Keller, Center for Internet Security
Phil White, Center for Internet Security
Andrew Dannenberger, Center for Internet Security
Kari Byrd, Independent Consultant
Ori Zerah, Aqua Security
Lucas Aides, Aqua Security
Marina Segal, Sysdig
1 源代码
本节包含对组织开发的任何应用程序源代码正确管理的安全建议。这是软件供应链的第一阶段，并被认为是流程其余部分的唯一真相来源。
保护源代码本身以及管理源代码平台的安全至关重要，都是为了保证软件版本的完整性。从提交变更的开发人员，到其中可能存在的敏感数据或漏洞，再到其最终存储的源代码管理平台，为了保证每次软件更新的安全，源代码的完整性非常重要。
1.1 代码变更
本节包含对代码变更以及应该如何完成的安全建议。它包含了保护应用程序代码主分支的建议。这是最重要的分支，因为它包含被交付给客户的实际代码。为了保证软件安全，应该保护它不受任何错误或恶意行为的伤害。
1.1.1 确保在版本控制平台中跟踪任何代码变更
描述
在版本控制平台中管理所有代码项目。
说明
版本控制平台跟踪代码的每一次修改。他们代表了代码安全性的基石，同时也允许工程团队内部更好的代码协作。通过细粒度访问管理、变更追踪和代码编辑的密钥签名，版本控制平台是确保软件供应链安全的第一步。
审计
确保组织开发的每个微服务或应用程序的所有代码活动都通过版本控制平台进行管理。
将现有的代码项目上传到专门的版本控制平台，并对于每个可能做出贡献或需要访问它的活跃团队成员创建标识。
1.1.2 确保对代码的任何更改都可以追溯到其关联的任务
描述
使用任务管理系统追溯任意代码到其所关联的任务。
说明
跟踪每段代码到其所关联任务的能力简化了敏捷和DevOps过程，实现支持任何代码变更的透明性。这允许更快地修复bug和安全问题，同时也使得将未经授权的代码变更推送到敏感项目变得更加困难。此外，使用任务管理系统简化了合规的实现，因为它更容易跟踪每个监管要求。
审计
确保每次代码变更都可以追溯到任务管理系统中的原始任务。
补救措施
每次代码变更开始，使用任务管理系统来管理任务。无论是新功能、bug修复还是安全修复，所有这些都应该来自于组织任务管理系统中的专用任务(票证)。这些任务也应该以一种容易遵循的方式链接到代码变更自身：从代码到任务，从任务返回到代码。
1.1.3 确保任何代码变更都得到两个经过强认证用户的批准(自动化)
描述
确保每次代码变更都由与代码变更相关团队的两个经过强认证的授权者审查和批准。
说明
为了防止恶意或未经授权的代码更改，第一层保护是代码审查流程。这个流程涉及到工程师团队评审彼此的代码，检查错误、优化和通用知识共享。有了适当的同行评审，组织就可以在发布过程的早期检测到不需要的代码变更。为了帮助促进代码评审，公司应该使用自动化来验证，每次代码变更在被推入代码库之前至少已经被两个团队成员评审和批准。这些团队成员应该来自与代码变更相关的团队，因此这将是一次有意义的评审。
注:为了强制代码评审要求，必须对至少两个评审人员进行验证。这将确保新代码在收到两个独立的批准之前不能被推入代码库。
审计
对于正在使用的每个代码存储库，将新代码推入代码库之前，需要来自特定代码库团队的两次验证批准。
补救措施
一个组织可以通过设置保护规则来保护特定的代码分支，例如“主”分支，它通常是部署到生产环境中的版本。这些规则保护您的代码库免受不需要的或未经授权的更改。您可以为该分支的任何代码变更设置需求，从而指定批准更改所需的最少审查员数量。
1.1.4 当对代码进行更新时，确保取消先前的批准
描述
确保代码提议更新时，丢弃先前的批准，需要新的批准。
说明
当建议更改代码时，需要一个批准过程。通过这个批准过程，仍然可以对原来的建议进行修改。这意味着即使组织实施了审查政策，恶意代码仍可以找到进入代码的方法。为了确保这一切不可能发生，当建议进行更改时，必须拒绝过时的批准。
注:如果新的代码变更提到日程，所有以前接受的代码更改建议必须被拒绝。
审计
对于正在使用的每个代码库，验证每个更新的代码建议，拒绝之前得到的批准。
补救措施
对于正在使用的每个代码库，组织范围内强制实行策略，如果建议得到更新，取消代码变更的已有的批准建议。
1.1.5 确保对能够取消代码变更检查的人，加强限制
描述
应该只允许可信的用户取消代码变更审查。
说明
取消代码变更审查允许用户合并新的代码更改，不需要经过标准的审批程序。控制谁可以执行此操作将防止恶意行为者简单地取消代码变更所需的审查，并将恶意或没有满足功能的代码合并到代码库中。
注：自从最后一次检查，代码变更方案更新，没有人批准检查。一般的合作人员将无法合并他们的代码变更，直到具有“取消审查”能力的人能取消开放审查。不允许取消代码变更的用户将无法这么做，因此也无法放弃标准审批流程。
审计
对于正在使用的每个代码库，确保只允许受信任的用户取消代码变更检查。
补救措施
对于正在使用的每个代码库，不要批准取消代码检查，除非真的有必要。如果是强制性的，请仔细选择你信任并有能力取消代码变更检查个人或小组。
1.1.6 确保为特别敏感的代码或配置设置代码所有者
描述
代码所有者是可信任的用户，他们负责审查和管理重要的代码或配置。建议组织为每个极其敏感的代码或配置设置代码所有者。
说明
通过验证受信任的用户将注意到并检查每一次编辑，配置代码所有者来保护数据，从而防止潜在的不需要的或恶意的更改损害敏感代码或配置。
注：代码所有者用户将收到发生在代码中的每一个更改的通知，并随后自动添加为拉取请求的检查者。
审计
对于正在使用的每个代码库，确保为敏感代码或配置设置了代码所有者。
补救措施
对于使用中的每个代码库，识别特别敏感的代码和配置部分，并将可信用户设置为其代码所有者。
1.1.7 确保当更改影响到其拥有的代码时，需要代码所有者的评审
描述
保证受信任的代码所有者，在他们各自拥有代码区域中，被要求评审和批准任何代码变更计划，
说明
配置代码所有者确保没有代码、特别是可能被证明是恶意的代码，会溜进代码库的源代码或配置文件中。这允许组织标记代码库中特别敏感或更容易受到攻击的区域。它还可以强制为这些区域所有者指定的特定个人作为所有者进行强制审查，以便他们事先过滤掉未经授权或不想要的变更。
注：如果一个组织强制执行基于代码所有者的审查，在特定的、可信的个人批准之前，一些代码变更建议将不能合并到代码库中。
审计
对于正在使用的每个代码库，验证代码所有者需要审查与他们所拥有的领域相关的所有代码变更建议。
补救措施
对于每个正在使用的代码库，为每个与他们拥有的代码相关的变更建议配置代码所有者需要的批准。
1.1.8 确保定期检查和移除不活动的分支
描述
跟踪那些长时间不活动的代码分支，并定期移除它们。
说明
长期处于不活动状态(即没有引入新的变更)的Git分支正在扩大恶意代码注入、敏感数据泄漏和CI管道被利用的攻击面。它们可能包含过时的依赖关系，这可能使它们非常脆弱。它们更有可能被不恰当地管理，并且可能被组织的大量成员访问。
注：删除不活动的Git分支意味着它们包含的任何代码变更将会被一起删除，因此在审计不活动Git分支后，过去完成的工作可能再也无法访问。
审计
对于正在使用的每个代码库，验证所有现有Git分支都是活动的，或者在指定的时间段内还没有检查是否处于不活动状态。
补救措施
对于正在使用的每个代码库，检查现有的Git分支，并删除那些在规定的时间内未激活的分支。
1.1.9 在合并新代码之前确保所有检查都已通过
描述
在代码变更请求合并到代码库之前，必须成功通过所有预定义检查。
说明
在代码变更的手动检查之上，代码保护应该包含一组验证每个更改的规定检查。组织应该执行这些状态检查，以便只有在所有检查都成功通过的情况下才能引入变更。为了将新代码合并到项目中，这组检查条件在质量、稳定性和安全条件方面必须得到绝对满足。
注：所有检查都未成功通过的代码更改将不能被推入特定代码库。
审计
确保对于每个正在使用的代码库，在允许任何代码变更建议合并之前，都需要通过状态检查。
补救措施
配置每个代码库，要求在允许合并新代码之前通过所有状态检查。
1.1.10 确保打开的Git分支是最新的，然后才可以合并到代码库
描述
组织应该确保每一次建议的代码变改与它的原始代码库的现有状态完全同步，然后才允许合并。
说明
Git分支很容易过时，因为原始代码存储库一直在被编辑。这意味着，在单独代码分支上工作的工程师可能会意外地包含过时的代码，存在可能已经被修复的潜在安全问题，从而在合并他们自己的更改时，覆盖了这些安全问题的潜在解决方案。
注：如果执行，过时的分支没有包含任何最近的更改，将无法合并到它们的原始代码库中。
审计
对于正在使用的每个代码库，允许合并之前必须验证分支已更新。
补救措施
对于正在使用的每个代码库，执行一个策略，只允许合并打开的分支，如果它们保持原始库的最新更改。
1.1.11 在允许代码变更合并之前，确保所有打开的注释都被解决了
描述
组织应该执行一个策略，在代码变更合并之前，“没有打开的注释”。
说明
在一个代码变更提议中，审查员可以留下包含他们的问题和建议的注释。这些注释还可能包括潜在的错误和安全问题。要求在合并之前，代码变更建议内的所有注释得到解决。可以确保在将新的代码变更引入代码库之前，适当地处理或确认每个关注事项。
注：包含开放注释的代码变更建议将不能合并到代码库中。
审计
对于正在使用的每个代码库，验证每个合并的代码变更不包含打开的、尚未处理的注释。
补救措施
对于正在使用的每个代码库，在相关的代码更改可以合并之前，需要解决打开的注释。
1.1.12 确保在合并前对新变更的提交进行签名验证
描述
确保在合并之前，每次拉取请求中的提交得到签名和验证。
说明
签名提交，或要求签署提交，让其他用户对特定代码变更的来源有信心。它确保更改的作者不被隐藏，并由版本控制系统验证，因此更改来自可信的源。
注：未带签名提交的拉取请求不能合并。
审计
保证对于每个分支，特别是主分支，通过分支保护规则，只有签名提交可以合并。
补救措施
对于每个正在使用的代码库，强制要求签名提交的分支保护规则，并确保只有签名提交能够合并。
1.1.13 确保必须是线性历史
描述
线性历史指Git的提交历史，所有的提交都是按时间顺序排列的，一个接一个。如果通过rebase merge(重新排列提交历史)或squash merge(将所有提交压缩为一个)合并一个拉取请求，就会存在这样的历史记录。合并拉取请求时，要求使用rebase合并或squash合并，保证要求线性历史。
说明
强制线性历史产生了一个清晰的活动记录，因此它提供了特定的优势：它更容易遵循，更容易恢复更改，更容易发现bug。
注：除非通过squash或rebase merge，拉取请求不能被合并。
审计
对于使用的每个存储库，确保必须是线性历史和/或只允许squash 合并和rebase 合并。
补救措施
对于每个正在使用的代码库，要求线性历史记录和/或只允许rebase合并和squash合并。
1.1.14 确保管理员遵守分支保护规则
描述
保证管理员遵守分支保护规则
说明
管理员默认不受任何分支保护规则的影响。这意味着这些特权用户(在代码库和组织级别上)不受旨在防止不受信任的代码插入(包括恶意代码)的保护。这是非常重要的，因为管理员帐户的特权角色，他们经常是账户劫持的目标。
注：管理员用户如果不遵守已有的分支保护规则，将不能直接将代码推送到受保护的分支。
审计
对于每个正在使用的代码库，验证分支保护规则也适用于管理员帐户。
补救措施
对于每个正在使用的代码库，对管理员账户强制分支保护规则。
1.1.15 确保仅限于特定的个人或团队推送或合并新代码
描述
确保只有可信的用户才能推送或合并新代码到受保护的分支。
说明
要求只有受信任的用户可以推送或合并新的变更，降低了未经验证代码、特别是恶意代码的风险，通过减少有能力这样做的受信任用户的数量保护分支。
注：只有管理员和信任用户可以推送或合并到受保护的分支。
审计
对于正在使用的每个代码存储库，确保只有可信和负责任的用户可以推送或合并新代码。
补救措施
对于正在使用的每个代码存储库，只允许可信和负责任的用户推送或合并新代码。
1.1.16 确保拒绝强制推送代码到分支
描述
“强制推送”选项允许具有“推送”权限的用户在没有拉取请求的情况下，直接将他们的更改强制推送到分支，因此应该禁用。
说明
“强制推送”选项允许用户用自己的代码覆盖现有的代码。这可能导致有意或无意的数据丢失，以及恶意代码的数据感染。禁用“强制推送”选项将禁止用户将更改强制推送到主分支，这最终将阻止恶意代码进入源代码。
注：用户不能对受保护的分支进行“强制推送”。
审计
对于正在使用的每个代码存储库，验证没有人可以“强制推送”代码。
补救措施
对于每个正在使用的存储库，阻止“强制推送”代码的选项
1.1.17 确保拒绝分支删除
描述
确保只有推送访问权限的用户无法删除受保护的分支。
说明
当启用删除受保护的分支时，任何只要对代码存储库具有推送访问权限的用户都可以删除分支。这可能是潜在的危险，因为一个简单的人为错误或黑客账户如果删除分支，可能导致数据丢失。因此，通过拒绝删除受保护的分支来防止此类事件是至关重要的。
注：受保护的分支不能被删除。
审计
对于正在使用的每个存储库，验证受保护的分支不能被删除。
补救措施
对于每个正在使用的存储库，通过分支保护规则阻禁止删除受保护分支的选项
1.1.18 确保自动化扫描任何代码合并风险
描述
确保每个拉取请求都需要进行风险扫描。
说明
扫描拉请求检测风险允许检测早期脆弱的代码和/或依赖关系，并帮助缓解潜在的恶意代码。
审计
对于正在使用的每个代码库，确保必须扫描每个拉取请求的风险。
补救措施
对于正在使用的每个代码库，在每个拉取请求上强制执行风险扫描。
1.1.19 确保对分支保护规则的变更进行审计
描述
确保对分支保护规则的变更进行审计
说明
在每个代码库上都要配置分支保护规则。唯一可以更改这些规则的用户是管理员。在由于管理员的人为错误而对管理员帐户进行攻击的情况下，可以禁用保护规则，从而降低源代码的保密性。重要的是要跟踪和审计这些变化，以尽快防止潜在的事件。
审计
确保有一个跟踪系统，记录分支保护规则(webhook等)的更改。
补救措施
使用、维护或创建跟踪系统来跟踪分支保护规则的变化(webhook等)。
1.2 代码库管理
本节包含关于正确管理代码库的安全建议。代码库是存储和组织应用程序代码的地方。重要的是要保持组织和维护代码库，以避免数据丢失、数据盗窃和其他可能在代码库维护不好时不知不觉受到的攻击。本节的建议是代码库管理的设置指南。
1.2.1 确保所有公共代码库都包含SECURITY.md 文件
描述
SECURITY.md文件是一个安全策略文件，提供了项目中报告安全漏洞的指令。当有人在特定项目中创建一个问题时，将随后显示一个到SECURITY.md文件的链接。
说明
SECURITY.md文件为用户提供重要的安全信息。它还可以在项目维护中发挥重要作用，鼓励用户提前考虑如何正确处理潜在的安全问题、更新和一般安全实践。
审计
对于正在使用的每个代码库，在文档或代码库的根目录中验证它是否具有SECURITY.md文件
补救措施
对于正在使用的每个代码库，创建一个SECURITY.md文件，保存在文档或代码库的根目录中。
1.2.2 确保仅限于特定的成员能创建代码库
描述
仅限信任的用户和团队有能力创建代码库。
说明
建议将代码库创建限制为可信任的用户和团队，以保持组织的正确结构，跟踪更少的条目，防止模仿，并避免版本控制系统超载。它将允许管理员更容易地跟踪源代码和管理功能，因为他们将有更少的代码库要跟踪。检测潜在攻击的过程也变得更加简单，因为跟踪源代码越容易，就越容易检测到其中的恶意行为。此外，成员创建公共代码库并对外共享组织数据的可能性显著降低。
注：特定用户不允许创建代码库。
审计
验证只允许可信的用户和团队创建代码库。
补救措施
将代码库的创建限制为仅可信任的用户和团队。
1.2.3 确保库的删除仅限于特定用户
描述
确保只有有限数量的受信任用户可以删除代码库。
说明
限制删除代码库的能力可以保护组织避免有意或无意的数据丢失。这确保了用户不能删除存储库或造成其他潜在的损害——无论是由于意外还是由于他们的账户被黑客攻击——除非他们拥有正确的特权。
注：某些用户不允许删除代码库。
审计
验证确认只有有限数量的受信任用户可以删除代码库。
补救措施
部分可信和负责用户可以删除代码库。
1.2.4 确保仅限于特定用户删除问题（issue）
描述
确保只有可信和负责的用户可以删除问题。
说明
问题是一种跟踪代码库中发生的事情的方法，例如设置新的里程碑或请求紧急修复。删除问题不是一个良性的活动，因为它可能会破坏开发工作流或试图隐藏恶意行为。正因为如此，它应该受到限制，只有值得信任和负责任的用户才允许使用。
注：某些用户不允许删除问题。
审计
验证只有受信任和负责任的用户才能删除问题。
补救措施
措施限制只对少数信任和负责的用户删除问题。
1.2.5 确保所有代码的拷贝(分支)都被跟踪和解释
描述
跟踪每一个代码分支并确保它被解释。
说明
分支是一个存储库的副本。除了作为普通的副本之外，任何对原始代码库本身的更新都可以在特定条件下由分支拉取和反映。大量的代码库副本(分叉)变得难以管理和正确地保护。新的和敏感的变更通常可以被推入关键的代码库，而开发人员不知道同一代码库的更新副本。如果这样做没有限制，那么建议根据需要跟踪并删除组织代码库的副本。
注：完全禁用分叉可能会减慢开发过程，因为为了分叉一个代码库，有必要采取更多的操作。
审计
是否定期跟踪和检查分叉。
补救措施
措施跟踪分叉并定期检查。
1.2.6 确保跟踪所有代码项目可见性状态的变化
描述
确保跟踪项目可见性的每一次变更
说明
项目的可见性决定了谁可以访问和/或分叉项目：任何人、指定的用户、或者只有组织的成员。如果一个私人项目被公开，这可能指向一个潜在的攻击，最终可能导致数据丢失，敏感信息泄漏，最终导致供应链攻击。为了防止此类事件的发生，跟踪这些变化是至关重要的。
审计
确保跟踪和调查项目可见性的每一个变化。
补救措施
跟踪项目可见性的每一个变化，并调查是否发生了可疑的行为。
1.2.7 确保定期检查和归档不活跃的代码库
描述
跟踪不活跃的代码库，定期移除。
说明
不活跃的代码库(即在很长一段时间内没有引入新的变更)会扩大潜在攻击面或数据泄漏面。这些代码库更容易受到不恰当的管理，因此可能被组织中的许多用户访问。
注：Bug修复和必要变更的部署对于归档代码库来说可能是复杂的。
审计
验证组织中的所有代码库都是活跃的，那些不活跃的将被审查或存档。
补救措施
检查所有不活跃的代码库并定期存档
1.3 贡献访问
本节包括管理对应用程序代码访问的安全建议。这包括管理内部和外部访问、管理员帐户、权限、识别方法等。保护这些项目对软件安全非常重要，因为对访问的每一个安全约束都是攻击的障碍。
本节区分普通用户帐户和管理员帐户。重要的是要理解，由于管理帐户的高权限，它应该只用于管理工作，而不是日常任务。
1.3.1 确保定期检查和移除不活跃的用户
描述
跟踪不活跃的用户账户，并定期移除他们。
说明
长期处于不活跃状态的用户账户正在扩大攻击面。拥有高级特权的不活跃用户尤其值得关注，因为这些账户更有可能成为攻击者的目标。如果这样的攻击被证明是成功的，这可能会允许访问组织的大部分内容。建议尽快删除它们，以防止这种情况的发生。
审计
对于正在使用的每个代码库，验证所有用户账户都是活跃的。
补救措施
对于每个正在使用的代码库，检查不活动的用户账户(离开组织的成员等)并删除它们。
1.3.2 确保仅限于特定成员创建团队
描述
仅限可信任的和特定的用户有能力创建团队。
说明
创建新团队的能力应该限制到特定的成员，以保持组织的有序，并确保用户处于只能访问所需内容的最低权限级别。团队通常从其父团队继承权限；因此，如果基本权限限制较少，并且任何用户都有能力创建一个团队，则可能会出现权限杠杆，即某些数据可以提供给不应该访问它的用户。这种情况可能会导致攻击者创建影子团队。限制团队的创建也会减少组织结构中的额外混乱，从而更容易跟踪变化和异常。
注：只有特定的用户才能创建新的团队。
审计
对于每个组织，确保团队创建仅限于特定的、可信的用户。
补救措施
对于每个组织，限制特定的、受信任的用户创建团队。
1.3.3 确保为组织设置了最低数量的管理员
描述
确保组织有最低数量的管理员。
说明
组织管理员拥有最高级别的权限，包括添加/删除合作者、创建或删除存储库、更改分支保护策略，以及转换为公共可访问的代码库的能力。由于组织的访问权限被授予管理员，强烈建议尽可能减少管理员账户的数量。
审计
组织中设置最小数量的管理员。
补救措施
设置组织中管理员的最小数量。
1.3.4 确保新代码的贡献者需要多因素身份验证(MFA)
描述
要求组织外部的合作者在向源代码管理平台进行身份验证时，除了标准的用户名和密码外，还需要使用多因素身份验证(MFA)。
说明
默认情况下，每个用户在系统内只通过密码进行身份验证。然而，如果用户的密码被泄露，用户帐户和他们访问的每个存储库都有数据丢失、恶意代码提交和数据被盗的危险。因此，建议每个用户启用多因素身份验证。这增加了一层额外的保护，即使用户的密码被泄露，以确保账户仍然安全。
注：未启用“多因素身份验证”的成员不能为项目做贡献。在贡献任何代码之前，他们必须启用多因素身份验证
审计
对于使用的每个代码库，验证对参与者实施了多因素身份验证，并且这是身份验证的唯一方法。
补救措施
对于使用的每个代码库，强制对参与者实施了多因素身份验证，并且这是身份验证的唯一方法。
1.3.5 确保组织要求成员使用多因素身份验证(MFA)
描述
要求组织成员在向源代码管理平台进行身份验证时，除了使用标准的用户名和密码外，还使用多因素身份验证(MFA)。
说明
默认情况下，每个用户在系统内只通过密码进行身份验证。然而，如果用户的密码被泄露，用户帐户和他们访问的每个存储库都有数据丢失、恶意代码提交和数据被盗的危险。因此，建议每个用户启用多因素身份验证。这增加了一层额外的保护，以确保帐户仍然安全，即使用户的密码被泄露。
注：如果成员没有启用多因素身份验证，则可以从组织中删除成员。如果是这种情况，建议发出邀请以恢复用户的访问权限和以前的特权。他们必须启用多因素身份验证才能接受邀请。
审计
对于您的源代码管理平台中存在的每一个组织，验证实施了多因素身份认证，并且这是认证的唯一方法。
补救措施
使用内置设置，以确保对组织的每个成员实施多因素身份认证。
1.3.6 确保要求使用公司批准的电子邮件邀请新成员加入组织
描述
现有成员可以邀请新成员加入；然而，必须使用他们公司批准的电子邮件邀请新会员。
说明
确保组织的新成员拥有公司批准的电子邮件，可以防止组织现有成员随意邀请新用户加入。如果没有这种验证，他们可以邀请任何正在使用组织的版本控制系统或拥有活跃电子邮件帐户的人，从而允许外部用户(和潜在的威胁者)轻松获得访问公司私有代码和资源的权限。这种做法将减少在邀请新成员时出现人为错误或拼写错误的机会。
注：现有会员将不能邀请没有公司批准的电子邮件地址的新用户。
审计
对于使用的每个组织，验证每个邀请的电子邮件地址是公司批准的。
补救措施
对于每个组织，只允许邀请具有公司批准的电子邮件的用户。如果一个用户在没有公司批准的邮件的情况下被邀请，取消邀请并调查他们被邀请的原因。
1.3.7 确保每个代码库设置两个管理员
描述
确保每个代码库有两个管理员权限的用户。
说明
代码库管理员对该代码库具有最高权限。这些功能包括添加/删除协作者，更改分支保护策略，以及转换为公共可访问的代码库。由于授予代码库管理员的自由访问权，因此强烈建议只有两个贡献者担任此角色。
注：从代码库中删除管理用户将导致他们失去对该代码库的高级访问权限。
审计
对于正在使用的每个代码库，验证有两个管理员。
补救措施
对于每个正在使用的代码库，设置两个管理员。
1.3.8 确保为代码库设置严格的基本权限
描述
基本权限定义了自动授予所有组织成员的权限级别。为组织中的所有代码库(包括新代码库)定义严格的基本访问权限。
说明
定义严格的基本权限是每个基于角色的访问控制(RBAC)系统的最佳实践。如果基本权限很高——例如“写”权限——组织的每个成员对组织中的每个存储库都有“写”权限。不管用户可能需要什么特定的权限，这通常在组织代码库之间是不同的，这都是适用的。权限越高，发生错误代码提交或数据泄露等事件的风险就越高。因此，建议将基本权限设置为尽可能严格的级别。
注： 用户可能无法访问组织存储库或执行某些操作，如提交。这些特定的权限应该根据需要分别授予每个用户或团队。
审计
验证为组织代码库设置了严格的基本权限—“None”或“Read”。
补救措施
为组织代码库设置严格的基本权限—要么“None”，要么“Read”。
1.3.9 确保使用“已验证”标识确认组织的身份。
描述
证实组织拥有的域，具有“已验证”标识
说明
验证组织的域为开发人员提供了一个保证，即给定的域确实是公共组织的官方所属。攻击者可以假装是一个组织，通过伪造/欺骗的域名窃取信息；因此，“认证”标识的使用在开发人员和开源社区之间灌输了更多的信心和信任。
审计
确保组织的名称旁边有一个“认证”标识。
补救措施
验证组织的域，并在其名称旁边添加“已验证”标识。
1.3.10 确保源代码管理(SCM)的电子邮件通知被限制到已验证的域
描述
限制组织的源代码管理(SCM)的电子邮件通知仅被批准的域。
说明
合理限制源代码管理邮件通知到经过验证的域只能防止数据泄露，因为个人邮件和定制域更容易通过DNS劫持或密码泄露的方式接管帐户。
注：只有获得批准的电子邮件的成员才能收到源代码管理通知。
审计
保证源代码管理电子邮件通知仅限于被批准的域。
补救措施
源代码管理电子邮件通知只限制在批准的域。
1.3.11 确保组织提供SSH证书
描述
作为一个组织，成为SSH证书颁发机构(CA)，并提供访问代码库的SSH密钥。
说明
有两种方法可以远程使用源代码管理：通过HTTPS，它需要通过用户/密码进行身份验证，或者通过SSH，它需要使用SSH密钥。SSH认证在安全性方面更好；但是，密钥的创建和分发必须以安全的方式进行。这可以通过实施SSH证书来实现，该证书用于验证服务器的身份。如果开发人员的密钥不能通过SSH证书颁发机构(CA)服务器进行验证，则开发人员将无法连接到Git服务器。在组织中，如果定义并使用CA，则可以验证用于身份验证的SSH证书签名。这确保了只有经过验证的开发人员才能访问组织代码库，因为他们的SSH密钥将是由CA证书签名的唯一密钥。这降低了误用和恶意代码提交的风险。
注：拥有未验证密钥的成员将无法克隆组织代码库。签名、认证和验证也可能减慢开发过程。
审计
验证组织是否拥有SSH证书颁发机构服务器，并提供用于签名密钥的SSH证书。
补救措施
部署一个SSH证书颁发机构服务器，并将其配置为提供用于签名密钥的SSH证书。
1.3.12 确保基于IP地址的Git访问限制
描述
通过允许访问的IP地址列表来实现基于IP地址限制的Git访问。
说明
只允许从特定的IP地址访问Git代码库(源代码)增加了另一层限制，并降低了未经授权连接到组织资产的风险。这将阻止攻击者访问源代码管理(SCM)，因为他们首先需要知道允许的IP地址才能访问这些地址。
注：只有白名单IP地址的成员才能访问组织的Git代码库。
审计
对于正在使用的每个存储库，确保只有IP 白名单允许访问，并且禁止所有其他IP访问。
补救措施
创建IP 访问白名单，禁止所有其他IP访问源代码。
1.3.13 确保异常代码行为被跟踪
描述
跟踪代码异常。
说明
仔细分析组织内的任何代码异常。例如，代码异常可能是在工作时间之外进行的推送。这样的代码推送更有可能是攻击的结果，因为组织的大多数成员(如果不是所有成员的话)可能都不在办公室。另一个例子是某个活动超过了特定用户的平均活动。跟踪和审计此类行为可以创建额外的安全层，并有助于早期发现潜在的攻击。
审计
对于每个正在使用的代码库，确保及时调查与组织相关的代码异常。
补救措施
对于正在使用的每个代码库，跟踪和调查异常的代码行为和活动。
1.4 第三方
本节包括在代码库中使用第三方应用程序的安全建议。
应用程序通常是改进组织工作流程的自动化集成，例如，OAuth应用程序或Github应用程序。这些应用程序是由第三方开发人员编写的，因此在使用前应该仔细检查。监控它们的使用和权限是很重要，因为未使用的应用程序或不必要的高权限会扩大攻击面。
1.4.1 确保每个已安装的应用程序都需要管理员批准
描述
确保安装应用程序时需要管理员批准。
说明
应用程序是典型的自动化集成，它改进了组织的工作流。它们是由第三方开发人员编写的，因此在使用之前应该进行验证，以防它们是恶意的或不可信任的。因为管理员应该是组织中最合格和最受信任的成员，所以他们应该审查正在安装的应用程序，并决定它们是否既可信又必要。
注：未经管理员批准，应用程序不能被安装。
审计
验证只在收到管理员批准后安装应用程序。
补救措施
每个安装的应用程序都需要管理员批准。
1.4.2 确保过时的应用程序被审查，不活跃的应用程序被删除
描述
确保过时的(不活跃的)应用程序被审查，并在不再使用时删除。
说明
长期处于不活跃状态的应用程序正在扩大数据泄漏的攻击面。它们更有可能被不恰当地管理，并且可能被第三方开发人员作为收集它们的组织或安装在代码库内部数据的工具访问。尽快删除这些不活跃的应用程序非常重要。
审计
验证组织中所有的应用程序都被经常使用，并删除那些不再使用的应用程序。
补救措施
检查所有过时的应用程序，并定期删除它们。
1.4.3 确保授予每个已安装应用程序的访问权限限制在所需的最低权限级别
描述
确保已安装应用程序的许可，被限制在所需最低权限
说明
应用程序是典型的自动化集成，可以改进组织的工作流程。它们是由第三方开发人员编写的，因此在使用之前应该仔细检查。建议使用“最小权限原则”，授予应用程序所需的最低级别的权限。这可以防止潜在恶意应用程序(具有不必要的高级权限)泄漏数据或修改源代码带来的危害。
审计
验证每个安装的应用程序具有所需的最小权限。
补救措施
通过“最小权限原则”授予应用程序权限，这意味着所需的尽可能低的权限。
1.5 代码风险
本节包括对许多安全代码扫描器的建议。这包括，例如，寻找硬编码的加密凭证，易受攻击的常见错误配置或限制性软件许可。因为一个应用程序代码有很多组件，扫描每一个可能导致攻击的部分是很重要的，从加密凭证到软件许可协议。
1.5.1 确保扫描器在适当的地方识别和防止代码中的敏感数据
描述
检测和防止代码中的敏感数据，如机密的身份证号，密码等。
说明
在源代码中存在敏感信息，很容易遭到攻击者恶意使用。为了避免这种情况，指定扫描器来识别和防止代码中敏感数据的存在。
审计
对于正在使用的每个代码库，验证扫描器设置为识别和防止代码中的敏感数据。
补救措施
对于正在使用的每个代码库，指定扫描器来识别和防止代码中的敏感数据。
1.5.2确保扫描器就位，以保护持续集成(CI)管道指令
描述
检测和防止持续集成(CI)管道中的错误配置和不安全指令。
说明
合理检测和修复持续集成(CI)管道中的错误配置或不安全指令，降低了通过持续集成(CI)管道或对CI管道进行成功攻击的风险。管道越安全，潜在的敏感数据暴露、部署被破坏、外部访问被错误地授予持续集成(CI)基础设施或源代码的风险就越小。
审计
对于每个持续集成(CI)管道，验证扫描器设置为识别和防止错误配置和不安全的指令。
补救措施
对于每一个持续集成(CI)管道，设置扫描器以识别和防止错误配置和不安全的指令。
1.5.3 确保扫描器就位，以保护基础设施作为代码(IaC)的指令
描述
检测和阻止在基础设施即代码（IaC）文件中的错误配置和不安全指令，如Terraform文件。
说明
检测和修复基础设施即代码（IaC ，Infrastructureas Code)文件中的错误配置和/或不安全指令，降低了数据泄漏或数据被盗的风险。为了防止部署、暴露的资产或不正确配置的连带问题，保护Iac指令很重要，这些问题最终会导致更容易的攻击和窃取组织数据的方法。
审计
对于每个IaC指令文件，验证扫描器设置为识别和防止错误配置和不安全指令。
补救措施
对于每个IaC指令文件，设置扫描器来识别和防止错误配置和不安全的指令。
1.5.4 确保扫描器就位，扫描代码漏洞
描述
检测和阻止代码中已知的开源代码漏洞
说明
开源代码块在开发的软件中被大量使用。这有自己的优势，但也有风险。因为代码对所有人开放，攻击者可以发布或添加恶意代码到这些开放源码代码块，或利用他们的知识找到现有代码中的漏洞。通过软件成分分析（SCA）检测和修复此类代码漏洞可以防止不安全的缺陷进入生产环境。它为开发人员提供了在将源代码部署到生产环境之前保护源代码的另一个机会，在生产环境中，源代码更容易暴露，更容易受到攻击。
审计
对于正在使用的每个代码库，验证扫描器设置为识别和防止代码漏洞。
补救措施
对于正在使用的每个代码库，设置将识别和防止代码漏洞的扫描器。
1.5.5 确保已使用包中的开源漏洞的扫描器已经到位
描述
检测、阻止和监控正在使用的包中已知的开源软件漏洞，
说明
开源漏洞可能在人们开始使用一个包之前就已经存在了，但是随着时间的推移，它们也会被发现。每隔一段时间就会公布新的攻击和漏洞。重要的是要跟踪这些，并监视使用的依赖项是否受到最近的漏洞的影响。检测和修复这些包的漏洞减少了使用这些包已部署和正在运行的应用程序的攻击面。它防止安全缺陷到达生产环境，从而最终导致安全漏洞。
审计
对于正在使用的每个代码库，验证扫描器设置为监视、识别和防止包中的开源代码漏洞。
补救措施
对于正在使用的每个代码库，设置扫描器将监视、识别和防止包中的开源代码漏洞。
1.5.6 确保在使用的包中对开源许可证问题进行扫描
描述
在已用的依赖中检测开源许可证并修复他们
说明
软件许可证是一种法律文件，它在软件公司或开发者和用户之间建立了几个关键条件，以便允许软件的使用。软件许可证有可能产生代码依赖关系。不遵守软件许可的条件也会导致诉讼。当使用带有软件许可证的包时，特别是商业许可证(这是最宽松的)，为了避免诉讼，验证许可证允许的内容是很重要的。
审计
对于使用的每个包，确保设置了扫描器来识别开源许可证问题。
补救措施
对于正在使用的每个包，指定扫描器来识别开源许可证问题并修复它们。
（完）
原文始发于微信公众号（安全行者老霍）：CIS软件供应链安全指南v1.0（上）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论