策略

策略为安全和合规团队提供了一种在组织中全局强制执行控制的方法。

安全团队可以确保：

• 安全扫描器在开发团队流水线中得到正确配置并强制执行。
• 所有扫描作业都按原样执行，没有任何更改或修改。
• 根据扫描结果，在合并请求上提供适当的审批。
• 不再检测到的漏洞会自动解决，减少漏洞分类的工作量。

合规团队可以强制执行：

• 所有合并请求都需要多个审批人
• 根据组织要求设置项目，例如启用或锁定合并请求设置或仓库设置。

以下策略类型可用：

• 扫描执行策略。强制执行安全扫描，可以是流水线的一部分，或在指定的时间表上执行。
• 合并请求审批策略。根据扫描结果强制执行项目级设置和审批规则。
• 流水线执行策略。作为项目流水线的一部分强制执行 CI/CD 作业。
  • 定时流水线执行策略（实验性）。跨项目按预定节奏强制执行自定义 CI/CD 作业，与提交活动无关。
• 漏洞管理策略。自动解决默认分支中不再检测到的漏洞。

配置策略范围

policy_scope 关键字

使用 policy_scope 关键字，将策略强制执行范围限定为您指定的那些组、项目、合规框架或其组合。

范围示例

在此示例中，扫描执行策略在每个发布流水线中强制执行 SAST 扫描，适用于应用了 ID 为 2 或 11 的合规框架的所有项目。

---
scan_execution_policy:
- name: 在每个发布流水线中强制执行指定扫描
  description: 此策略为发布分支强制执行 SAST 扫描
  enabled: true
  rules:
  - type: pipeline
    branches:
    - release/*
  actions:
  - scan: sast
  policy_scope:
    compliance_frameworks:
      - id: 2
      - id: 11

在此示例中，扫描执行策略在 ID 为 203 的组中的所有项目（包括所有子组及其项目）的默认分支流水线上强制执行秘密检测和 SAST 扫描，但排除 ID 为 64 的项目。

- name: 在每个默认分支流水线中强制执行指定扫描
  description: 此策略为默认分支强制执行秘密检测和 SAST 扫描
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  - scan: sast
  policy_scope:
    groups:
      including:
        - id: 203
    projects:
      excluding:
        - id: 64

职责分离

职责分离对于成功实施策略至关重要。实施能够满足必要的合规和安全要求，同时允许开发团队实现其目标的策略。

安全和合规团队：

• 应负责定义策略，并与开发团队合作，确保策略满足他们的需求。

开发团队：

• 不应以任何方式禁用、修改或规避策略。

要在组、子组或项目上强制执行安全策略项目，您必须具备以下任一条件：

• 该组、子组或项目的所有者角色。
• 该组、子组或项目中的自定义角色，具有 manage_security_policy_link 权限。

拥有者和具有 manage_security_policy_link 权限的自定义角色遵循组、子组和项目之间的标准层次结构规则：

所需权限

要创建和管理安全策略：

• 对于在组上强制执行的策略：您必须至少拥有该组的维护者角色。
• 对于在项目上强制执行的策略：
  • 您必须是项目所有者。
  • 您必须是具有在该组中创建项目权限的组成员。

策略建议

实施策略时，请考虑以下建议。

分支名称

在策略中指定分支名称时，使用受保护分支的通用类别，例如默认分支或所有受保护分支，而不是单独的分支名称。

只有当指定的分支存在于项目中时，策略才会强制应用于该项目。例如，如果您的策略在 main 分支上强制执行规则，但范围内的某些项目使用 production 作为其默认分支，则该策略不会应用于后者。

推送规则

在 GitLab 17.3 及更早版本中，如果您使用推送规则来验证分支名称，请确保它们允许创建前缀为 update-policy- 的分支。此分支命名前缀在创建或修改安全策略时使用。例如，update-policy-1659094451，其中 1659094451 是时间戳。如果推送规则阻止创建该分支，则会发生以下错误：

分支名称 `update-policy-<时间戳>` 不符合 `<branch_name_regex>` 模式。

在 GitLab 17.4 及更高版本中，安全策略项目被排除在强制执行分支名称验证的推送规则之外。

安全策略项目

为了防止安全策略项目中原本应保持私密的敏感信息泄露，当您将安全策略项目链接到其他项目时：

• 不要在您的安全策略项目中包含敏感内容。
• 在链接私有安全策略项目之前，请审查目标项目的成员列表，确保所有成员都应该能够访问您的策略内容。
• 评估目标项目的可见性设置。
• 使用安全策略管理审计日志来监控项目链接。

这些建议可以防止敏感信息泄露，原因如下：

• 共享可见性：当私有安全项目链接到另一个项目时，有权访问链接项目的安全策略页面的用户可以查看 .gitlab/security-policies/policy.yml 文件的内容。这包括将私有安全策略项目链接到公共项目，这可能使策略内容对任何可以访问公共项目的人可见。
• 访问控制：私有安全项目所链接到的项目的所有成员都可以在策略页面上查看策略文件，即使他们没有访问原始私有仓库的权限。

安全和合规控制

项目维护者可以为项目创建策略，这些策略可能会干扰组策略的执行。为了限制谁可以修改组策略并确保满足合规要求，当您实施关键的安全或合规控制时：

• 使用自定义角色来限制谁可以在项目级别创建或修改流水线执行策略。
• 在您的安全策略项目中为默认分支配置受保护分支，以防止直接推送。
• 在您的安全策略项目中设置合并请求审批规则，要求指定审批人进行审查。
• 监控和审查组策略和项目策略中的所有策略更改。

策略管理

策略页面显示所有可用环境的已部署策略。您可以检查策略的信息（例如，描述或执行状态），并创建和编辑已部署的策略：

1. 在左侧边栏，选择搜索或跳转至并找到您的项目。
2. 选择安全 > 策略。

第一列中的绿色勾号表示策略已启用并在其范围内的所有组和项目上强制执行。灰色勾号表示当前未启用该策略。

策略编辑器

使用策略编辑器来创建、编辑和删除策略：

1. 在左侧边栏，选择搜索或跳转至并找到您的项目。

2. 选择安全 > 策略。

   • 要创建新策略，选择位于策略页面标题中的新建策略。然后您可以选择要创建的策略类型。
   • 要编辑现有策略，请在所选的策略抽屉中选择编辑策略。

   策略编辑器有两种模式：

   • 可视化的规则模式允许您使用规则块和相关控件来构建和预览策略规则。

     

   • YAML 模式允许您以 .yaml 格式输入策略定义，面向专家用户以及规则模式不支持的情况。

     

     您可以互换使用这两种模式，随时在它们之间切换。如果 YAML 资源不正确或包含规则模式不支持的数据，规则模式将自动禁用。如果 YAML 不正确，您必须使用 YAML 模式修复策略，然后规则模式才能再次可用。

3. 选择通过合并请求配置以保存和应用更改。

   策略的 YAML 会进行验证，并显示任何 resulting 错误。

4. 审查并合并 resulting 合并请求。

   如果您是项目所有者，并且没有安全策略项目与此项目关联，则在创建合并请求时会创建一个安全策略项目并将其链接到此项目。

在 policy.yml 中注释 ID

为了简化您的 policy.yml 文件，GitLab 可以在 ID 后自动添加注释，例如项目 ID、组 ID、用户 ID 或合规框架 ID。这些注释帮助用户识别每个 ID 的含义或来源，使 policy.yml 文件更易于理解和维护。

要启用此实验性功能，请在您的安全策略项目的 .gitlab/security-policies/policy.yml 文件的 experiments 部分添加一个 annotate_ids 部分：

experiments:
  annotate_ids:
    enabled: true

启用该选项后，使用 GitLab 策略编辑器 对安全策略的任何更改都会在 policy.yml 文件中的 ID 旁边创建注释。

例如：

# 带注释 ID 的示例 policy.yml
approval_policy:
- name: 您的策略名称
  # ... 其他策略字段 ...
  policy_scope:
    projects:
      including:
      - id: 361 # my-group/my-project
  actions:
  - type: require_approval
    approvals_required: 1
    user_approvers_ids:
    - 75 # jane.doe
    group_approvers_ids:
    - 203 # security-approvers

故障排除

在使用安全策略时，请考虑以下故障排除提示：

• 您不应将安全策略项目同时链接到开发项目以及该开发项目所属的组或子组。这种方式链接会导致合并请求审批策略中的审批规则不应用于开发项目中的合并请求。
• 创建合并请求审批策略时，scan_finding 规则中的数组 severity_levels 和数组 vulnerability_states 都不能为空。对于有效的规则，每个数组至少必须有一个条目。
• 项目所有者可以强制执行该项目的策略，前提是他们还具有在该组中创建项目的权限。不是组成员的项目所有者在添加或编辑策略时可能会遇到限制。如果您无法管理项目的策略，请联系您的组管理员，确保您在组中拥有必要的权限。

如果您仍然遇到问题，可以查看最近报告的错误并提交新的未报告问题。

使用 GraphQL API 重新同步策略

如果您注意到任何策略中的不一致性，例如策略未被强制执行或审批不正确，您可以使用 GraphQL resyncSecurityPolicies 变异手动强制重新同步策略：

mutation {
  resyncSecurityPolicies(input: { fullPath: "group-or-project-path" }) {
    errors
  }
}

将 fullPath 设置为安全策略项目所分配到的项目或组的路径。