合规标准
- 层级:旗舰版
- 提供:GitLab.com、GitLab 自托管、GitLab 专用
您可以使用 GitLab 合规控制 来帮助满足许多合规标准的要求。
合规遵循模板 项目包含一个 JSON 模板库。使用这些模板可以快速采用预定义的合规框架。
FedRAMP 合规要求
FedRAMP(联邦风险与授权管理计划)根据数据泄露对政府运营、资产或个人的潜在影响,将云服务分为三个影响级别:低、中、高。
这些级别对应不同的安全控制和要求集,云服务提供商(CSP)必须满足这些要求和控制才能获得 FedRAMP 授权。针对 FedRAMP 低、FedRAMP 中和 FedRAMP 高合规的控制可用。
FedRAMP Low 合规要求
下表列出了 GitLab 支持 FedRAMP Low 的要求及其对应的控制措施。
你可以使用 fedramp_low_r5.json 模板 为此标准创建合规框架。
| FedRAMP Low 要求 | 说明 | 支持的控制措施 |
|---|---|---|
| CM-5:变更访问限制 | 定义、记录、批准并执行与系统变更相关的物理和逻辑访问限制。 |
|
| CM-6:配置设置 | 建立并记录系统组件的安全配置设置;实施这些设置;根据操作需求识别、记录并批准偏差;并根据组织政策监控和控制配置变更。 |
|
| CM-7:最小功能 | 将系统配置为仅提供组织定义的关键任务必要能力;并禁止或限制使用以下功能、端口、协议、软件和服务:组织定义的禁止或受限功能、系统端口、协议、软件和服务。 |
|
| CM-10:软件使用限制 | 按照合同协议和版权法使用软件及相关文档;跟踪受数量许可保护的软件及相关文档的使用情况以控制复制和分发;并控制和记录点对点文件共享技术的使用,以确保该功能不被用于未经授权的版权作品分发、展示、表演或复制。 |
|
| IA-2(12):接受 PIV 凭证 | 接受并电子验证个人身份验证(PIV)凭证。 |
|
| IA-8(1):接受其他机构的 PIV 凭证 | 接受并电子验证来自其他联邦机构的个人身份验证(PIV)凭证。 |
|
| RA-5:漏洞监控与扫描 | 扫描系统及托管应用程序中的漏洞;使用漏洞扫描工具和技术;分析漏洞扫描报告和结果;修复合法漏洞;并共享漏洞信息。 |
- 依赖项扫描运行中
- 容器扫描运行中
- DAST 运行中
- API 安全运行中
- Fuzz 测试运行中
FedRAMP Moderate 合规要求
下表列出了 GitLab 支持 FedRAMP Moderate 的要求及其对应的控制措施。你可以使用 fedramp_moderate_r5.json 模板 为此标准创建合规框架。
| FedRAMP Moderate 要求 | 描述 | 支持的控制措施 |
|---|---|---|
| AC-5:职责分离 | 将个人职责分开,防止恶意活动无需串通即可发生;记录职责分离情况;并定义系统访问授权以支持职责分离。 |
|
| CM-3:配置变更控制 | 确定受控配置变更的类型;对具有安全/隐私影响的分析进行审查和批准;记录决策;实施已批准的变更;保留记录;监控与变更相关的活动;并通过指定要素协调变更控制的监督。 |
|
| CM-5:变更的访问限制 | 定义、记录、批准并执行与系统变更相关的物理和逻辑访问限制。 |
|
| CM-6:配置设置 | 建立并记录系统组件的安全配置设置;实施这些设置;根据操作需求识别、记录并批准偏差;并根据组织政策监控和控制配置变更。 |
|
| CM-7:最小功能 | 配置系统仅提供组织定义的核心任务能力;禁止或限制使用以下功能、端口、协议、软件和服务:组织定义的禁止或受限功能、系统端口、协议、软件和服务。 |
|
| CM-10: 软件使用限制 | 按照合同协议和版权法使用软件及相关文档;跟踪受数量许可保护的软件及相关文档的使用情况,以控制复制和分发;控制和记录点对点文件共享技术的使用,确保该功能不被用于未经授权的分发、展示、表演或复制受版权保护的作品。 |
|
|---|---|---|
| IA-2(12): 接受PIV凭证 | 接受并电子验证个人身份验证(PIV)凭证。 |
|
| IA-5(7): 禁止嵌入未加密静态认证器 | 确保未加密的静态认证器不嵌入应用程序或其他形式的静态存储中。 |
|
| IA-8(1): 接受其他机构的PIV凭证 | 接受并电子验证来自其他联邦机构的个人身份验证(PIV)凭证。 |
|
| RA-5: 漏洞监控与扫描 | 扫描系统和托管应用程序中的漏洞;使用漏洞扫描工具和技术;分析漏洞扫描报告和结果;修复合法漏洞;分享漏洞信息。 |
|
| SA-11(1): 静态代码分析 | 要求系统、系统组件或系统服务的开发人员使用静态代码分析工具识别常见缺陷,并记录分析结果。 |
|
| SA-11(8): 动态代码分析 | 要求系统、系统组件或系统服务的开发人员使用动态代码分析工具识别常见缺陷,并记录分析结果。 |
|
FedRAMP High 合规要求
下表列出了 GitLab 支持的 FedRAMP High 要求及其对应的控制措施。你可以使用 fedramp_high_r5.json 模板 为此标准创建合规框架。
| FedRAMP High 要求 | 说明 | 支持的控制措施 |
|---|---|---|
| AC-5: 职责分离 | 将个人职责分开以防止恶意活动(无需串通);记录职责分离情况;并定义系统访问授权以支持职责分离。 |
|
| CM-3: 配置变更控制 | 确定受控配置变更的类型;审查并批准带有安全/隐私影响分析的变更;记录决策;实施已批准的变更;保留记录;监控与变更相关的活动;并通过指定要素协调变更控制的监督。 |
|
| CM-3(1): 自动化文档、通知及变更禁止 | 使用自动化机制记录对系统的拟议变更;通知组织定义的审批机构;突出显示在组织规定时间内未收到的变更审批;在收到指定审批前禁止对系统进行变更;并记录对系统的所有变更。 |
|
| CM-5: 变更的访问限制 | 定义、记录、批准并执行与系统变更相关的物理和逻辑访问限制。 |
|
| CM-6: 配置设置 | 建立并记录系统组件的安全配置设置;实施这些设置;根据操作需求识别、记录并批准偏差;并根据组织政策监控和控制配置变更。 |
|
| CM-7: 最小功能集(Least Functionality) | 配置系统以仅提供组织定义的关键任务必需能力;并禁止或限制使用以下功能、端口、协议、软件和服务:组织定义的禁止或限制的功能、系统端口、协议、软件和服务。 |
- 禁止提交者批准合并请求
- 合并请求审批规则防止编辑
- 许可证合规性运行中
- 认证SSO已启用
- 秘密检测运行中
- 认证SSO已启用
- 依赖项扫描运行中
- 容器扫描运行中
- DAST运行中
- API安全运行中
- Fuzz测试运行中
- SAST运行中
- DAST运行中
- Fuzz测试运行中
IRAP合规性要求
IRAP是Infosec注册评估师计划(Infosec Registered Assessors Program)。控制措施适用于IRAP官方、IRAP受保护、IRAP秘密和IRAP绝密级别。
IRAP Official
下表列出了GitLab支持的IRAP官方要求及其对应的控制措施。
你可以使用 irap_official.json 模板 来创建符合此标准的合规框架。
| IRAP Official 要求 | 说明 | 支持的控制措施 |
|---|---|---|
| ISM-0402 应用安全测试 | 在应用程序初始发布及后续版本发布前,需通过静态应用安全测试(SAST)和动态应用安全测试(DAST)全面检测漏洞。 |
|
| ISM-1163 持续监控计划 | 系统需具备持续监控计划,包括:至少每两周对系统进行漏洞扫描;在部署前(包括重大变更部署前)以及之后每年至少一次,对系统进行漏洞评估和渗透测试;分析已识别漏洞以确定其潜在影响;并根据风险、有效性和成本实施缓解措施。 |
|
| ISM-1422 开发、测试和生产环境 | 防止未经授权访问软件的权威来源。 |
|
| ISM-1698 扫描未缓解的漏洞 | 每天至少使用一次漏洞扫描器,识别在线服务中缺失补丁或更新的漏洞。 |
|
| ISM-1700 扫描未缓解的漏洞 | 每两周至少使用一次漏洞扫描器,识别除办公生产力套件、网络浏览器及其扩展、电子邮件客户端、PDF软件和安全产品以外的应用程序中的缺失补丁或更新漏洞。 |
|
| ISM-1701 扫描未缓解的漏洞 | 至少每天使用漏洞扫描器来识别面向互联网的服务器和网络设备的操作系统中的漏洞缺失补丁或更新。 |
- 容器扫描运行中
- DAST扫描运行中
- API安全扫描运行中
- 依赖项扫描运行中
- 容器扫描运行中
- 依赖项扫描运行中
- 容器扫描运行中
- 默认分支受保护
- 秘密检测运行中
IRAP Protected
下表列出了GitLab支持的IRAP Protected要求及其控制措施。
您可以使用 irap_protected.json 模板 为此标准创建合规框架。
| IRAP Protected 要求 | 描述 | 支持的控制 |
|---|---|---|
| ISM-0402 应用安全测试 | 应用在初始发布及后续任何版本发布前,需通过静态应用安全测试(SAST)和动态应用安全测试(DAST)进行全面漏洞测试。 |
|
| ISM-1163 持续监控计划 | 系统需具备持续监控计划,内容包括:至少每两周对系统进行漏洞扫描;在部署前(包括重大变更部署前)以及此后每年至少一次对系统进行漏洞评估和渗透测试;分析已识别漏洞以确定其潜在影响;并根据风险、有效性和成本实施缓解措施。 |
|
| ISM-1422 开发、测试和生产环境 | 防止对软件权威来源的未授权访问。 |
|
| ISM-1698 扫描未缓解的漏洞 | 使用漏洞扫描器至少每日对在线服务中的漏洞进行扫描,以识别缺失的补丁或更新。 |
|
| ISM-1700 扫描未缓解的漏洞 | 使用漏洞扫描器至少每两周对除办公套件、网页浏览器及其扩展、电子邮件客户端、PDF软件和安全产品以外的应用程序中的漏洞进行扫描,以识别缺失的补丁或更新。 |
|
IRAP Secret
下表列出了 GitLab 支持的 IRAP Secret 要求及这些要求的控制措施。
你可以使用 irap_secret.json 模板 为此标准创建合规框架。
| IRAP Secret 要求 | 描述 | 支持的控制 |
|---|---|---|
| ISM-0402 应用安全测试 | 在应用程序首次发布及后续任何版本发布前,需使用静态应用安全测试(SAST)和动态应用安全测试(DAST)对其进行全面漏洞测试。 |
|
| ISM-1163 持续监控计划 | 系统需具备持续监控计划,内容包括:至少每两周对系统进行一次漏洞扫描;在系统部署前(包括重大变更部署前)以及之后每年至少一次进行漏洞评估和渗透测试;分析已识别漏洞以确定其潜在影响;并根据风险、有效性和成本实施缓解措施。 |
|
| ISM-1422 开发、测试和生产环境 | 防止对软件权威来源的未授权访问。 |
|
| ISM-1698 扫描未缓解的漏洞 | 每天至少使用一次漏洞扫描器来识别在线服务中存在的漏洞缺失补丁或更新。 |
|
| ISM-1700 扫描未缓解的漏洞 | 每两周至少使用一次漏洞扫描器来识别除办公套件、网页浏览器及其扩展、电子邮件客户端、PDF 软件和安全产品以外的应用程序中的漏洞缺失补丁或更新。 |
|
IRAP Top Secret
下表列出了GitLab支持的IRAP顶级机密要求及对应控制措施。
你可以使用 irap_top_secret.json 模板 为此标准创建合规框架。
| IRAP Top Secret requirement | Description | Supported controls |
|---|---|---|
| ISM-0402 应用安全测试 | 应用在初始发布及后续版本发布前,需通过静态应用安全测试(SAST)和动态应用安全测试(DAST)全面检测漏洞。 |
|
| ISM-1163 持续监控计划 | 系统需具备持续监控计划,内容包括:至少每两周对系统进行漏洞扫描;在部署前(包括重大变更部署前)以及之后每年至少一次对系统开展漏洞评估和渗透测试;分析已识别漏洞以确定其潜在影响;并根据风险、有效性和成本实施缓解措施。 |
|
| ISM-1422 开发、测试和生产环境 | 防止对软件权威源的非授权访问。 |
|
| ISM-1698 扫描未缓解的漏洞 | 需每日至少使用漏洞扫描器,识别在线服务中漏洞的缺失补丁或更新。 |
|
| ISM-1700 扫描未缓解的漏洞 | 需每两周至少使用漏洞扫描器,识别除办公套件、网页浏览器及其扩展、邮件客户端、PDF软件和安全产品外的应用程序中漏洞的缺失补丁或更新。 |
|
ISMAP合规性要求
信息系统安全管理与评估计划(ISMAP)旨在通过预先评估和注册符合政府安全要求的云服务,确保政府采购的云服务的安全级别,从而促进云服务的顺利引入。
下表列出了GitLab支持的ISMAP要求及其对应的控制措施。您可以使用 ismap.json 模板 为此标准创建合规框架。
| ISMAP 要求 | 描述 | 支持的控制措施 |
|---|---|---|
| 6.1.2 职责分离 | 冲突的职责和责任区域应分离,以减少组织资产被未经授权或无意修改或滥用的机会。 |
|
| 9.3.1 秘密认证信息的使用 | 用户应遵循组织的做法使用秘密认证信息。 |
|
| 9.4.5 程序源代码的访问控制 | 应限制对程序源代码的访问。 |
|
| 12.1.2 变更管理 | 影响信息安全的企业、业务流程、信息处理设施和系统的变更应受控。 |
|
| 12.6.1 技术漏洞的管理 | 应及时获取所使用的信息系统的技术漏洞信息,评估组织对这些漏洞的暴露情况,并采取适当措施解决相关风险。 |
|
| 14.2.1 安全开发政策 | 应制定并应用软件和系统开发的规则,适用于组织内的开发工作。 |
|
| 14.2.8 系统安全性测试 | 开发期间应进行安全功能的测试。 |
|
| 18.1.2 知识产权 | 应实施适当的程序,以确保遵守与知识产权及专有软件产品使用相关的立法、法规和合同要求。 |
|
ISO 27001 合规要求
ISO 27001 是一项国际公认的标准,为实施和管理信息安全管理体系(ISMS)提供了框架。
以下表格列出了 GitLab 支持的 ISO 27001 要求及其对应的控制措施。您可以使用 iso_27001:2022.json 模板 为此标准创建合规框架。
| ISO 27001 要求 | 描述 | 支持的控制措施 |
|---|---|---|
| 5.3 职责分离 | 冲突的职责和责任区域应予以分离。 |
|
| 5.17 身份验证信息 | 身份验证信息的分配和管理应由管理流程控制,包括向人员提供建议关于如何适当处理身份验证信息。 |
|
| 5.18 访问权限 | 应根据组织针对访问控制的特定主题政策和规则,对信息和相关资产的访问权限进行配置、审查、修改和移除。 |
|
| 5.32 知识产权 | 组织应实施适当的程序来保护知识产权。 |
|
| 8.4 源代码访问 | 对源代码、开发工具和软件库的读写访问应妥善管理。 |
|
| 8.8 技术漏洞管理 | 应获取有关使用中的信息系统技术漏洞的信息,评估组织的暴露情况并采取适当措施。 |
|
| 8.28 安全编码 | 应将安全编码原则应用于软件开发。 |
|
| 8.29 开发和验收中的安全测试 | 应在开发生命周期中定义并实施安全测试流程。 |
|
| 8.32 变更管理 | 信息处理设施和信息系统的变更应遵循变更管理流程。 |
|
NIST 合规要求
美国国家标准与技术研究院(NIST)信息技术实验室(ITL)为信息系统提供标准、测量和测试,重点关注互操作性、安全性、可用性和可靠性。这些合规标准涉及在多个领域实施安全和隐私控制,包括:
- 风险管理
- 身份识别与认证
- 事件响应
- 系统与通信保护
针对NIST 800-53、NIST 800-171、NIST SP 800-218和NIST CSF 2.0等合规标准提供了相关控制措施。
NIST 800-53 合规要求
下表列出了 GitLab 支持 NIST 800-53 第 5 版的要求及其控制措施。
你可以使用 nist_800-53_r5 模板 为此标准创建合规框架。
| NIST 800-53 要求 | 说明 | 支持的控制 |
|---|---|---|
| AC-3(2):双重授权 | 对组织定义的特权命令和/或其他组织定义的操作强制执行双重授权。 |
|
| AC-5:职责分离 | 将个人职责分开,以防止未经串通的有害活动;记录职责分离情况;并定义系统访问授权以支持职责分离。 |
|
| AU-9(5):双重授权 | 对组织定义的审计信息的删除或修改强制执行双重授权。 |
|
| CM-3:配置变更控制 | 确定受控配置变更的类型;审查并批准带有安全/隐私影响分析的变更;记录决策;实施已批准的变更;保留记录;监控与变更相关的活动;并通过指定要素协调变更控制的监督。 |
|
| CM-3(1): Automated Documentation, Notification, and Prohibition of Changes | 使用自动化机制记录系统拟议变更;通知组织定义的审批机构;突出显示在组织规定时间内未收到的变更批准;在收到指定批准前禁止对系统进行变更;并记录系统的所有变更。 |
- 至少两个批准
- 作者批准合并请求被禁止
- 提交者批准合并请求被禁止
- 合并请求批准规则防止编辑
- 默认分支受保护
- 至少两个批准
- 作者批准合并请求被禁止
- 提交者批准合并请求被禁止
- 合并请求批准规则防止编辑
- 至少两个批准
- 作者批准合并请求被禁止
- 提交者批准合并请求被禁止
- 合并请求批准规则防止编辑
- 作者批准合并请求被禁止
- 提交者批准合并请求被禁止
- 合并请求批准规则防止编辑
- 默认分支受保护
- 许可证合规运行中
| CP-9(7): 双重授权 | 强制对组织定义的备份信息的删除或销毁执行双重授权。 |
- 至少两个审批
- 禁止作者批准合并请求
- 禁止提交者批准合并请求
- 合并请求审批规则防止编辑
- 身份验证SSO已启用
- 身份验证SSO已启用
- 秘密检测正在运行
- 身份验证SSO已启用
- 身份验证SSO已启用
- 身份验证SSO已启用
- 依赖项扫描正在运行
- 容器扫描正在运行
- DAST正在运行
- API安全正在运行
- 模糊测试正在运行
| SA-11(1): 静态代码分析 | 要求系统的开发者、系统组件或系统服务的开发者使用静态代码分析工具来识别常见缺陷并记录分析结果。 |
- SAST running
- DAST running
- Fuzz testing running
NIST 800-171合规要求
下表列出了GitLab支持的NIST 800-171修订版3 CMMC的要求及对应控制措施。
| NIST 800-171要求 | 描述 | 支持的控制措施 |
|---|---|---|
| 03.01.04 职责分离 | a) 识别需分离职责的个人职责。b) 定义系统访问授权以支持职责分离。 |
|
| 03.04.04 影响分析 | a) 分析系统变更以确定潜在安全影响(变更实施前)。b) 验证系统变更实施后,系统安全要求仍满足。 |
|
| 03.04.05 变更的访问限制 | a) 定义、记录、批准并执行与系统变更相关的物理和逻辑访问限制。 |
|
| 03.04.10 系统组件清单 | a) 开发并记录系统组件清单。b) 审查并更新系统组件清单。c) 安装、移除和系统更新时更新系统组件清单。 |
|
| 03.05.07 密码管理 | b) 用户创建或更新密码时,验证密码未出现在常用、预期或已泄露密码列表中。c) 仅通过加密保护的通道传输密码。d) 以加密保护形式存储密码。 |
|
| 03.11.02 漏洞监控与扫描 | a) 监控并扫描系统漏洞,当发现影响系统的新漏洞时。 c) 更新系统漏洞扫描范围,新漏洞被识别和报告时进行扫描。 |
|
NIST CSF 2.0 合规要求
下表列出了 GitLab 支持的 NIST CSF 要求及对应的要求控制项。
| NIST CSF 2.0 要求 | 说明 | 支持的控制项 |
|---|---|---|
| ID.RA-01 - 身份 - 风险评估:组织需了解网络安全风险对组织、资产和个人造成的影响。 | 资产中的漏洞被识别、验证并记录。 |
|
| ID.RA-07 - 身份 - 风险评估:组织需了解网络安全风险对组织、资产和个人造成的影响。 | 变更和例外情况被管理、评估风险影响、记录并跟踪。 |
|
| PR.AA-05 - 保护 - 身份管理、认证与访问控制:对物理和逻辑资产的访问仅限于授权的用户、服务和硬件,并根据未经授权访问的评估风险进行管理。 | 访问权限、授权和许可在策略中定义、管理、执行和审查,并遵循最小权限原则和职责分离原则。 |
|
| PR.PS-06 - 保护 - 平台安全:物理和虚拟平台的硬件、软件(例如固件、操作系统和应用)和服务的管理符合组织的风险管理策略,以保障其保密性、完整性和可用性。 | 安全软件开发实践被集成,并在整个软件开发生命周期中监控其性能。 |
|
NIST SP 800-218 合规要求
下表列出了 GitLab 支持 NIST SP 800-218 的要求及其对应的控制项。
| NIST SP 800-218 要求 | 说明 | 支持的控制项 |
|---|---|---|
| PO.1.1 定义软件开发的安全要求 | PO.1.1: 识别并记录组织软件开发基础设施和流程的所有安全要求,并长期维护这些要求。 |
|
| PW.4 在可行时重用现有且安全性良好的软件,而非复制功能 | PW.4.1: 获取并维护安全性良好的软件组件(例如,软件库、模块、中间件、框架),这些组件来自商业、开源和其他第三方开发者,供组织的软件使用。PW.4.4: 验证获取的商业、开源以及所有其他第三方软件组件在整个生命周期内是否符合组织定义的要求。 |
|
| PW.5.1 通过遵循安全编码实践来创建源代码 | PW.5.1: 遵循适用于开发语言和环境的安全编码实践,以满足组织的要求。 |
|
| PW.7 审查和/或分析人类可读的代码以识别漏洞并验证符合安全要求 | PW.7.1: 根据组织的规定,确定是否应使用代码审查(人员直接查看代码发现问题)和/或代码分析(使用工具查找代码中的问题,无论是完全自动化方式还是与人员结合)。PW.7.2: 基于组织的安全编码标准执行代码审查和/或代码分析,并在开发团队的工作流或问题跟踪系统中记录和分类所有发现的问题及建议的修复措施。 |
|
| PW.8 测试可执行代码以识别漏洞并验证是否符合安全要求 | PW.8.2:确定测试范围、设计测试、执行测试并记录结果,包括在开发团队的工作流程或问题跟踪系统中记录和分类所有发现的问题及建议的修复措施。 |
|
|---|---|---|
| RV.1 持续识别和确认漏洞 | RV.1.1:从软件采购方、用户和公共来源收集有关软件及所用第三方组件潜在漏洞的信息,并对所有可信报告进行调查。 |
|
PCI DSS v4.0.1 合规要求
PCI DSS 是 PCI 数据安全标准。
下表列出了 GitLab 支持 PCI DSS v4.0.1 的要求及对应控制措施。
你可以使用 pci_dss_v4-0-1.json 模板 为该标准创建合规框架。
| PCI DSS v4.0.1 要求 | 描述 | 支持的控制 |
|---|---|---|
| 6.2 定制和自定义软件以安全方式开发。 | 6.2.3 在发布前审查定制和自定义软件,识别并纠正编码漏洞。确保代码遵循安全编码指南并解决新兴漏洞。实施软件工程方法防止常见软件攻击。 |
|
| 6.5 所有系统组件的变更都得到安全管理。 | 6.5.1 实施对系统组件的变更时,需遵循既定流程,包括:记录原因和描述、进行安全影响分析、获得授权方批准以及测试安全影响。分离生产环境和预生产环境。 6.5.3 预生产环境与生产环境分离,且通过访问控制强制执行这种分离。 6.5.4 生产环境和预生产环境的角色和功能相互分离,以确保责任明确,只有经过审核和批准的变更才能部署。 |
|
| 7.2 对系统组件和数据的访问被适当地定义和分配。 | 7.2.5 所有应用程序和系统账户及其相关访问权限的分配和管理方式如下:基于系统或应用程序运行所需的最低必要权限;访问仅限于明确要求其使用的系统、应用程序或进程。 |
- 启用CI/CD作业令牌范围
- 用户定义的CI/CD变量限制给维护者
- 项目可见性非公开
- 受限构建访问
- 仓库严格权限
7.3.2 访问控制系统配置为基于职位分类和功能强制执行分配给个人、应用程序和系统的权限。 |
- 启用CI/CD作业令牌范围
- 用户定义的CI/CD变量限制给维护者
- 项目可见性非公开
- 受限构建访问
- 仓库严格权限
- 启用Auth SSO
- 组织级别要求MFA
- 贡献者要求MFA
8.4.2 对所有进入CDE的非控制台访问实施MFA。 |
- 启用Auth SSO
- 组织级别要求MFA
- 贡献者要求MFA
| 8.6 应用程序和系统账户及其关联的身份验证因素的使用受到严格管理。 | 8.6.2 用于交互式登录的任何应用程序和系统账户的密码/口令不会硬编码在脚本、配置/属性文件或定制的自定义源代码中。 |
|
|---|---|---|
| 11.3 定期识别、优先级排序并解决外部和内部漏洞。 | 11.3.1 使用经过身份验证的扫描方法执行内部漏洞扫描。及时处理高风险/关键漏洞,并根据风险评估管理其他漏洞。在系统发生重大变更后进行扫描。 11.3.2 通过合格人员执行外部漏洞扫描。及时处理高风险/关键漏洞,并根据风险评估管理其他漏洞。在系统发生重大变更后进行扫描。 |
|
| CC3.4 - COSO 原则 9: 实体识别并评估可能对内部控制体系产生重大影响的变化。 | POF 4: 评估系统和技术的变化——风险识别过程考虑了来自实体系统变化和技术环境变化的变化。POF 6: 评估威胁和漏洞的变化——风险识别过程评估(1)实体系统组件的内部和外部威胁及其漏洞的变化,以及(2)由此产生的风险对实现实体目标的可能性及严重程度的变化。 |
- 依赖扫描运行中
- 容器扫描运行中
- DAST 运行中
- API 安全运行中
- Fuzz 测试运行中
- 默认分支受保护
- 至少两步审批
- 禁止作者批准合并请求
- 禁止提交者批准合并请求
- 合并请求审批规则防止编辑
- 密钥检测运行中