GitLab GraphQL API漏洞查询异常求助：无结果/全局ID无效

一、GraphQL返回空漏洞列表的原因 #

1. 查询对象混淆：GitLab的GraphQL中，vulnerabilities（已确认漏洞）和securityReportFindings（安全扫描原始结果）是两个独立对象。你在安全标签页看到的13个条目大概率是扫描结果，但如果直接查询project.vulnerabilities，只会返回已被标记为漏洞的条目——而REST API默认返回的是全量扫描结果，和GraphQL的securityReportFindings对应。
2. 过滤条件限制：
   • vulnerabilities查询默认只返回CONFIRMED/DETECTED状态的条目，若安全标签页包含RESOLVED等其他状态的内容，需要显式指定状态参数，比如state: [DETECTED, CONFIRMED, RESOLVED]。
3. 分页参数缺失：虽然你的条目数量不多，但GraphQL默认返回结果有限，可添加first: 100参数确保拿到全量数据。

二、"不是有效全局ID"报错的原因 #

GitLab GraphQL使用**全局ID（Global ID）**作为对象唯一标识，格式为gid://gitlab/<对象类型>/<数字ID>，比如漏洞的全局ID是gid://gitlab/Vulnerability/191227233。你直接传入REST API返回的纯数字ID，GraphQL无法识别，因此触发报错。

三、适配你目标的解决方案 #

1. 获取SAST结果的正确GraphQL查询 #

如果要获取SAST扫描原始结果，使用securityReportFindings查询：

query GetProjectSASTFindings($projectPath: ID!) {
  project(fullPath: $projectPath) {
    securityReportFindings(reportType: SAST, first: 100) {
      nodes {
        id # 此处为全局ID
        title
        severity
        state
        description
        location {
          filePath
          startLine
        }
      }
    }
  }
}

如果要查询已确认的漏洞，需指定状态范围：

query GetProjectVulnerabilities($projectPath: ID!) {
  project(fullPath: $projectPath) {
    vulnerabilities(state: [DETECTED, CONFIRMED, RESOLVED], first: 100) {
      nodes {
        id
        title
        severity
        state
        finding {
          reportType
        }
      }
    }
  }
}

2. 全局ID处理方法 #

• 若需用数字ID查询漏洞，手动拼接成全局ID格式：gid://gitlab/Vulnerability/191227233后传入。
• 更稳妥的方式是先通过列表查询拿到目标漏洞的全局ID，再进行后续操作，避免手动拼接出错。

3. 同步Jira工单与GitLab漏洞状态 #

• 更新GitLab漏洞状态时，使用全局ID调用updateVulnerability mutation：

mutation UpdateVulnerabilityState($id: ID!, $state: VulnerabilityState!) {
  updateVulnerability(input: {id: $id, state: $state}) {
    vulnerability {
      state
    }
  }
}

• 可通过GitLab webhook监听漏洞状态变化，同步更新对应Jira工单；反之，当Jira工单标记为完成时，调用上述mutation更新GitLab漏洞状态。

内容的提问来源于stack exchange，提问作者Nicolas Haley