Checkov GitLab SAST 输出格式详解将 IaC 扫描结果接入 GitLab 安全中心与合并请求【免费下载链接】checkovPrevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.项目地址: https://gitcode.com/GitHub_Trending/ch/checkovCheckov 提供的gitlab_sast输出格式遵循 GitLab SAST 报告规范schema 版本 15.0.4让基础设施即代码IaC、容器镜像与开源依赖的扫描结果可以直接呈现在 GitLab 的Security安全标签页和**合并请求Merge Request**中。读完本文你将掌握如何通过-o gitlab_sast生成合规的 SAST 报告、理解报告 JSON 中每个字段的含义与来源并了解其底层实现严重级别映射、三类漏洞的构造逻辑、输出文件落盘机制以及对应的单元测试验证。一、GitLab SAST 输出能做什么Checkov 默认在终端输出 CLI 风格的扫描结果但 GitLab 用户往往希望把安全发现沉淀到 GitLab 平台内部。gitlab_sast输出正是为此设计它把 Checkov 的检查结果check 记录翻译成 GitLab 安全产品体系认可的SAST 报告格式从而在 GitLab 项目的Security安全标签页中集中展示全部合规与漏洞问题在**合并请求Merge Request**中以内联/汇总形式呈现新增问题帮助开发者在代码评审阶段即时发现云配置风险与 GitLab 的漏洞管理、严重级别筛选、策略引擎等安全能力打通。从源码结构看该能力由 checkov/common/output/gitlab_sast.py 中的GitLabSast类负责实现并在 checkov/common/runners/runner_registry.py 中作为标准输出格式被统一调度属于 Checkov 原生支持的一种报告输出无需额外插件。二、快速上手一条命令生成 GitLab SAST 报告在原文档中生成该报告的 CLI 命令非常简单扫描当前目录下的全部 IaC 文件并输出 GitLab SAST 格式checkov -d . -o gitlab_sast命令各部分的含义-d .指定扫描目录为当前目录Checkov 会递归发现其中的 Terraform、CloudFormation、Kubernetes、Dockerfile、Bicep 等 IaC 文件-o gitlab_sast--output选项的值明确要求以 GitLab SAST 格式输出结果。更完整的用法是同时指定输出文件便于后续交给 GitLab 消费checkov -d . -o gitlab_sast --output-file-path gitlab-sast.json从 runner_registry.py 的实现可以看到每种输出格式都有默认的文件名映射其中gitlab_sast对应的默认文件名为results_gitlab_sast.json。也就是说即使不显式指定输出文件名只要设置了--output-file-path输出目录Checkov 也会自动把 GitLab SAST 报告写入该目录下的results_gitlab_sast.json文件。此外-o支持逗号分隔的多个格式例如checkov -d . -o cli,gitlab_sast可以同时保留终端可读的 CLI 摘要和供 GitLab 使用的 SAST 报告。三、输出格式结构一个完整的 GitLab SAST 报告示例原文档给出了一个典型的输出示例。下面完整保留该示例含两条 S3 相关的失败检查以便逐字段解读{ schema: https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/raw/v15.0.4/dist/sast-report-format.json, version: 15.0.4, scan: { start_time: 2023-01-23T22:45:33, end_time: 2023-01-23T22:45:33, analyzer: { id: checkov, name: Checkov, url: https://www.checkov.io/, vendor: { name: Prisma Cloud }, version: 2.2.281 }, scanner: { id: checkov, name: Checkov, url: https://www.checkov.io/, vendor: { name: Prisma Cloud }, version: 2.2.281 }, status: success, type: sast }, vulnerabilities: [ { id: 605d1ad8-da1e-4784-859a-199708846fee, identifiers: [ { name: CKV_AWS_18, type: checkov, url: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/s3_13-enable-logging, value: CKV_AWS_18 } ], links: [ { url: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/s3_13-enable-logging } ], location: { file: main.tf, start_line: 1, end_line: 8 }, name: Ensure the S3 bucket has access logging enabled, description: Further info can be found None, severity: Unknown, solution: Further info can be found None }, { id: 1fe876c4-db57-4785-867e-ab1415250382, identifiers: [ { name: CKV2_AWS_6, type: checkov, url: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/s3-bucket-should-have-public-access-blocks-defaults-to-false-if-the-public-access-block-is-not-attached, value: CKV2_AWS_6 } ], links: [ { url: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/s3-bucket-should-have-public-access-blocks-defaults-to-false-if-the-public-access-block-is-not-attached } ], location: { file: main.tf, start_line: 1, end_line: 8 }, name: Ensure that S3 bucket has a Public Access block, description: Further info can be found None, severity: Unknown, solution: Further info can be found None } ] }3.1 顶层字段字段值含义schemaSAST 报告 JSON Schema 地址声明本报告遵循 GitLab 安全报告规范的 15.0.4 版本GitLab 据此校验与解析报告version15.0.4报告格式的 schema 版本号与schema字段保持一致scan对象本次扫描的元信息包括时间、分析器、扫描器与状态vulnerabilities数组扫描发现的所有问题check 记录列表对应到源码顶层结构由GitLabSast.create_sast_json()构建见 gitlab_sast.pyschema与version是硬编码常量scan由_create_scan()生成vulnerabilities由_create_vulnerabilities()汇总。3.2 scan 对象start_time/end_time扫描起止时间格式为YYYY-MM-DDTHH:MM:SS。从源码看当前实现使用 UTC 时间生成且起止时间取同一时刻源码注释也标注了需要在后续阶段完善因此报告中的时间窗口仅作标识用途analyzer/scanner分析器与扫描器信息。Checkov 同时扮演这两个角色二者内容一致id与name均为checkovvendor为 Bridgecrew/Prisma Cloudversion来自 checkov/version.py 的版本常量即当前安装的 Checkov 版本status固定为success表示扫描流程正常完成type固定为sast声明这是 SAST 类型的报告。3.3 vulnerabilities 数组中的单个条目以CKV_AWS_18确保 S3 桶启用访问日志为例字段含义数据来源id该问题的唯一标识UUID源码中使用uuid4()随机生成每次输出不同identifiers问题标识符列表type为checkovname与value均为 Checkov 检查 ID如CKV_AWS_18、CKV2_AWS_6Record.check_idlinks相关的参考链接策略文档等Record.guideline仅当其为合法 URL 时才生成location问题定位file为相对仓库根目录的文件路径start_line/end_line为问题代码起止行号Record.repo_file_path、Record.file_line_rangename检查名称人类可读的违规描述Record.check_namedescription问题描述格式为Further info can be found {guideline}Record.guidelineseverity严重级别见下文映射规则Record.severitysolution修复建议/指引Record.guideline四、严重级别映射规则GitLab SAST 报告使用Critical / High / Medium / Low / Info五档严重级别而 Checkov 内部的严重级别体系与之并不完全相同因此 gitlab_sast.py 定义了一张显式的映射表DEFAULT_SEVERITY_GITLAB_LEVEL Unknown SEVERITY_TO_GITLAB_LEVEL { critical: Critical, high: High, medium: Medium, low: Low, none: Info, }映射逻辑为取Record.severity的枚举名并转小写后查表如果某一严重级别不在映射表内例如 Checkov 中部分策略没有显式标注严重度则统一回退为默认值Unknown——这也是原文档示例中两条 S3 检查severity均为Unknown的原因这两个检查在测试场景下未配置显式严重级别。从上文示例与测试用例 test_gitlab_sast_report.py 都可以看到severity: Unknown的输出。五、三类漏洞的构造逻辑IaC 检查、CVE 与许可证GitLabSast._create_vulnerabilities()会根据报告类型report.check_type走不同的构造分支见 gitlab_sast.pyIaC 检查默认分支非 SCA 类型的报告Terraform、CloudFormation、Kubernetes、Bicep、ARM、Dockerfile 等每条失败的 check 记录都会调用_create_iac_vulnerability()生成第三节展示的完整漏洞条目包含location.file、start_line/end_line、identifiers、links、severity、description、solution等字段CVE 漏洞SCA 报告检查 ID 以BC_VUL或CKV_CVE开头调用_create_cve_vulnerability()其identifiers.type为cvevalue为 CVE 编号如CVE-2019-19844description取自vulnerability_details.descriptionsolution取自vulnerability_details.status通常描述在哪个版本中修复location只带文件路径、不含行号许可证问题SCA 报告检查 ID 以BC_LIC开头调用_create_license_vulnerability()其identifiers.type为licensedescription形如Package {package_name}{package_version} has license {license}用于提示某个依赖包引入了特定许可证。其中SCA 报告的判定来自 checkov/common/output/cyclonedx_consts.py 中的常量SCA_CHECKTYPES (CheckType.SCA_PACKAGE, CheckType.SCA_IMAGE)即开源软件包扫描与容器镜像扫描两类报告。而Record上承载的short_description、vulnerability_details、file_line_range、guideline等属性定义在 checkov/common/output/record.py是上述三类漏洞字段的数据源头。六、底层调用链从-o gitlab_sast到报告文件在 checkov/common/runners/runner_registry.py 中可以看到完整的处理流程扫描开始前gitlab_sast被注册为合法输出格式L73并随其他格式一起解析命令行参数各框架 runner 完成扫描后print_reports()遍历所有非空报告凡是config.output包含gitlab_sast就把该报告追加进gitlab_reports列表L433-L434汇总阶段用GitLabSast(reportsgitlab_reports)实例化并调用create_sast_json()生成完整 JSONL592-L601若输出目标是控制台则以 4 空格缩进打印gl_sast.sast_json当指定了--output-file-path时data_outputs[gitlab_sast]中的 JSON 字符串会被写入默认文件名results_gitlab_sast.jsonL628。这段实现也说明一个特性GitLab SAST 报告会聚合所有启用框架Terraform、Kubernetes、Dockerfile、SCA 等的失败检查因此一个项目中同时存在 IaC 违规、镜像 CVE 和依赖许可证问题时会合并到同一份报告中并按上述三类逻辑分别渲染。七、如何接入 GitLab原文档明确指出该输出的价值在于直接与 GitLab 的 Security 标签页和合并请求集成。实践上的一般做法是在 GitLab CI 流水线中加入 Checkov 扫描步骤运行上文命令生成gitlab_sast报告或使用--output-file-path指定落盘位置将生成的results_gitlab_sast.json或自定义路径的报告文件作为 GitLab 安全报告工件上传GitLab 根据报告中的schema/version完成解析后问题会出现在流水线对应的 Security 标签页中并在后续合并请求中持续跟踪。仓库的 kubernetes/checkov-job.yaml 提供了一份在 Kubernetes 集群中以 Job 方式运行 Checkov 的参考清单可作为将扫描器部署进 CI/CD 环境的补充参考。需要说明的是Checkov 只负责生成符合规范的 SAST 报告文件具体的流水线编排方式如 GitLab CI 的report关键字用法取决于你所在项目的 GitLab 配置。八、测试验证报告结构有单元测试保障gitlab_sast输出的正确性由 tests/common/output/test_gitlab_sast_report.py 覆盖其中test_iac_output使用真实 Terraform runner 扫描测试夹具main.tf仅运行CKV2_AWS_6与CKV_AWS_18两个检查随后断言schema、version、scan各字段值并验证vulnerabilities中两条 IaC 漏洞的identifiers、location、severity均为Unknown等内容——这正是原文档示例 JSON 的测试来源test_sca_package_output构造带 CVE 详情vulnerability_details的 SCA 记录验证 CVE 类型漏洞条目的字段渲染其余用例继续覆盖许可证记录、以及存在/不存在有效 guideline 链接时的links/identifiers.url行为。如果你需要修改或扩展 GitLab SAST 输出运行pytest tests/common/output/test_gitlab_sast_report.py即可快速回归验证。九、使用注意事项动态字段vulnerabilities[].id每次扫描由uuid4()重新生成报告间的 ID 不具备稳定性start_time/end_time目前取同一时刻仅作元信息guideline 为空时description与solution会显示为Further info can be found None如原文档示例所示且links与identifiers.url不会出现——这是源码中valid_url()校验的结果severity 兜底未配置严重级别的检查统一输出为Unknown如需更精确的分级可在策略配置中显式声明严重度SCA 报告的漏洞定位CVE 与许可证条目只有location.file而没有行号这是由Record数据的属性决定的解析端需兼容该差异。十、小结gitlab_sast输出让 Checkov 的 IaC 合规检查、镜像 CVE 与依赖许可证发现能够无缝进入 GitLab 的安全工作流。通过checkov -d . -o gitlab_sast一行命令即可获得符合 GitLab SAST 15.0.4 规范的报告其字段语义、严重级别映射、三类漏洞构造逻辑与文件落盘机制均有 gitlab_sast.py、runner_registry.py 及对应的单元测试作为实现依据便于二次开发与排查问题。关于报告格式中更多元素与属性的权威定义可参考 GitLab 官方维护的 SAST 报告 JSON Schema即报告schema字段指向的 v15.0.4 规范文件。【免费下载链接】checkovPrevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.项目地址: https://gitcode.com/GitHub_Trending/ch/checkov创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Checkov GitLab SAST 输出格式详解：将 IaC 扫描结果接入 GitLab 安全中心与合并请求
Checkov GitLab SAST 输出格式详解将 IaC 扫描结果接入 GitLab 安全中心与合并请求【免费下载链接】checkovPrevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.项目地址: https://gitcode.com/GitHub_Trending/ch/checkovCheckov 提供的gitlab_sast输出格式遵循 GitLab SAST 报告规范schema 版本 15.0.4让基础设施即代码IaC、容器镜像与开源依赖的扫描结果可以直接呈现在 GitLab 的Security安全标签页和**合并请求Merge Request**中。读完本文你将掌握如何通过-o gitlab_sast生成合规的 SAST 报告、理解报告 JSON 中每个字段的含义与来源并了解其底层实现严重级别映射、三类漏洞的构造逻辑、输出文件落盘机制以及对应的单元测试验证。一、GitLab SAST 输出能做什么Checkov 默认在终端输出 CLI 风格的扫描结果但 GitLab 用户往往希望把安全发现沉淀到 GitLab 平台内部。gitlab_sast输出正是为此设计它把 Checkov 的检查结果check 记录翻译成 GitLab 安全产品体系认可的SAST 报告格式从而在 GitLab 项目的Security安全标签页中集中展示全部合规与漏洞问题在**合并请求Merge Request**中以内联/汇总形式呈现新增问题帮助开发者在代码评审阶段即时发现云配置风险与 GitLab 的漏洞管理、严重级别筛选、策略引擎等安全能力打通。从源码结构看该能力由 checkov/common/output/gitlab_sast.py 中的GitLabSast类负责实现并在 checkov/common/runners/runner_registry.py 中作为标准输出格式被统一调度属于 Checkov 原生支持的一种报告输出无需额外插件。二、快速上手一条命令生成 GitLab SAST 报告在原文档中生成该报告的 CLI 命令非常简单扫描当前目录下的全部 IaC 文件并输出 GitLab SAST 格式checkov -d . -o gitlab_sast命令各部分的含义-d .指定扫描目录为当前目录Checkov 会递归发现其中的 Terraform、CloudFormation、Kubernetes、Dockerfile、Bicep 等 IaC 文件-o gitlab_sast--output选项的值明确要求以 GitLab SAST 格式输出结果。更完整的用法是同时指定输出文件便于后续交给 GitLab 消费checkov -d . -o gitlab_sast --output-file-path gitlab-sast.json从 runner_registry.py 的实现可以看到每种输出格式都有默认的文件名映射其中gitlab_sast对应的默认文件名为results_gitlab_sast.json。也就是说即使不显式指定输出文件名只要设置了--output-file-path输出目录Checkov 也会自动把 GitLab SAST 报告写入该目录下的results_gitlab_sast.json文件。此外-o支持逗号分隔的多个格式例如checkov -d . -o cli,gitlab_sast可以同时保留终端可读的 CLI 摘要和供 GitLab 使用的 SAST 报告。三、输出格式结构一个完整的 GitLab SAST 报告示例原文档给出了一个典型的输出示例。下面完整保留该示例含两条 S3 相关的失败检查以便逐字段解读{ schema: https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/raw/v15.0.4/dist/sast-report-format.json, version: 15.0.4, scan: { start_time: 2023-01-23T22:45:33, end_time: 2023-01-23T22:45:33, analyzer: { id: checkov, name: Checkov, url: https://www.checkov.io/, vendor: { name: Prisma Cloud }, version: 2.2.281 }, scanner: { id: checkov, name: Checkov, url: https://www.checkov.io/, vendor: { name: Prisma Cloud }, version: 2.2.281 }, status: success, type: sast }, vulnerabilities: [ { id: 605d1ad8-da1e-4784-859a-199708846fee, identifiers: [ { name: CKV_AWS_18, type: checkov, url: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/s3_13-enable-logging, value: CKV_AWS_18 } ], links: [ { url: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/s3_13-enable-logging } ], location: { file: main.tf, start_line: 1, end_line: 8 }, name: Ensure the S3 bucket has access logging enabled, description: Further info can be found None, severity: Unknown, solution: Further info can be found None }, { id: 1fe876c4-db57-4785-867e-ab1415250382, identifiers: [ { name: CKV2_AWS_6, type: checkov, url: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/s3-bucket-should-have-public-access-blocks-defaults-to-false-if-the-public-access-block-is-not-attached, value: CKV2_AWS_6 } ], links: [ { url: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/s3-bucket-should-have-public-access-blocks-defaults-to-false-if-the-public-access-block-is-not-attached } ], location: { file: main.tf, start_line: 1, end_line: 8 }, name: Ensure that S3 bucket has a Public Access block, description: Further info can be found None, severity: Unknown, solution: Further info can be found None } ] }3.1 顶层字段字段值含义schemaSAST 报告 JSON Schema 地址声明本报告遵循 GitLab 安全报告规范的 15.0.4 版本GitLab 据此校验与解析报告version15.0.4报告格式的 schema 版本号与schema字段保持一致scan对象本次扫描的元信息包括时间、分析器、扫描器与状态vulnerabilities数组扫描发现的所有问题check 记录列表对应到源码顶层结构由GitLabSast.create_sast_json()构建见 gitlab_sast.pyschema与version是硬编码常量scan由_create_scan()生成vulnerabilities由_create_vulnerabilities()汇总。3.2 scan 对象start_time/end_time扫描起止时间格式为YYYY-MM-DDTHH:MM:SS。从源码看当前实现使用 UTC 时间生成且起止时间取同一时刻源码注释也标注了需要在后续阶段完善因此报告中的时间窗口仅作标识用途analyzer/scanner分析器与扫描器信息。Checkov 同时扮演这两个角色二者内容一致id与name均为checkovvendor为 Bridgecrew/Prisma Cloudversion来自 checkov/version.py 的版本常量即当前安装的 Checkov 版本status固定为success表示扫描流程正常完成type固定为sast声明这是 SAST 类型的报告。3.3 vulnerabilities 数组中的单个条目以CKV_AWS_18确保 S3 桶启用访问日志为例字段含义数据来源id该问题的唯一标识UUID源码中使用uuid4()随机生成每次输出不同identifiers问题标识符列表type为checkovname与value均为 Checkov 检查 ID如CKV_AWS_18、CKV2_AWS_6Record.check_idlinks相关的参考链接策略文档等Record.guideline仅当其为合法 URL 时才生成location问题定位file为相对仓库根目录的文件路径start_line/end_line为问题代码起止行号Record.repo_file_path、Record.file_line_rangename检查名称人类可读的违规描述Record.check_namedescription问题描述格式为Further info can be found {guideline}Record.guidelineseverity严重级别见下文映射规则Record.severitysolution修复建议/指引Record.guideline四、严重级别映射规则GitLab SAST 报告使用Critical / High / Medium / Low / Info五档严重级别而 Checkov 内部的严重级别体系与之并不完全相同因此 gitlab_sast.py 定义了一张显式的映射表DEFAULT_SEVERITY_GITLAB_LEVEL Unknown SEVERITY_TO_GITLAB_LEVEL { critical: Critical, high: High, medium: Medium, low: Low, none: Info, }映射逻辑为取Record.severity的枚举名并转小写后查表如果某一严重级别不在映射表内例如 Checkov 中部分策略没有显式标注严重度则统一回退为默认值Unknown——这也是原文档示例中两条 S3 检查severity均为Unknown的原因这两个检查在测试场景下未配置显式严重级别。从上文示例与测试用例 test_gitlab_sast_report.py 都可以看到severity: Unknown的输出。五、三类漏洞的构造逻辑IaC 检查、CVE 与许可证GitLabSast._create_vulnerabilities()会根据报告类型report.check_type走不同的构造分支见 gitlab_sast.pyIaC 检查默认分支非 SCA 类型的报告Terraform、CloudFormation、Kubernetes、Bicep、ARM、Dockerfile 等每条失败的 check 记录都会调用_create_iac_vulnerability()生成第三节展示的完整漏洞条目包含location.file、start_line/end_line、identifiers、links、severity、description、solution等字段CVE 漏洞SCA 报告检查 ID 以BC_VUL或CKV_CVE开头调用_create_cve_vulnerability()其identifiers.type为cvevalue为 CVE 编号如CVE-2019-19844description取自vulnerability_details.descriptionsolution取自vulnerability_details.status通常描述在哪个版本中修复location只带文件路径、不含行号许可证问题SCA 报告检查 ID 以BC_LIC开头调用_create_license_vulnerability()其identifiers.type为licensedescription形如Package {package_name}{package_version} has license {license}用于提示某个依赖包引入了特定许可证。其中SCA 报告的判定来自 checkov/common/output/cyclonedx_consts.py 中的常量SCA_CHECKTYPES (CheckType.SCA_PACKAGE, CheckType.SCA_IMAGE)即开源软件包扫描与容器镜像扫描两类报告。而Record上承载的short_description、vulnerability_details、file_line_range、guideline等属性定义在 checkov/common/output/record.py是上述三类漏洞字段的数据源头。六、底层调用链从-o gitlab_sast到报告文件在 checkov/common/runners/runner_registry.py 中可以看到完整的处理流程扫描开始前gitlab_sast被注册为合法输出格式L73并随其他格式一起解析命令行参数各框架 runner 完成扫描后print_reports()遍历所有非空报告凡是config.output包含gitlab_sast就把该报告追加进gitlab_reports列表L433-L434汇总阶段用GitLabSast(reportsgitlab_reports)实例化并调用create_sast_json()生成完整 JSONL592-L601若输出目标是控制台则以 4 空格缩进打印gl_sast.sast_json当指定了--output-file-path时data_outputs[gitlab_sast]中的 JSON 字符串会被写入默认文件名results_gitlab_sast.jsonL628。这段实现也说明一个特性GitLab SAST 报告会聚合所有启用框架Terraform、Kubernetes、Dockerfile、SCA 等的失败检查因此一个项目中同时存在 IaC 违规、镜像 CVE 和依赖许可证问题时会合并到同一份报告中并按上述三类逻辑分别渲染。七、如何接入 GitLab原文档明确指出该输出的价值在于直接与 GitLab 的 Security 标签页和合并请求集成。实践上的一般做法是在 GitLab CI 流水线中加入 Checkov 扫描步骤运行上文命令生成gitlab_sast报告或使用--output-file-path指定落盘位置将生成的results_gitlab_sast.json或自定义路径的报告文件作为 GitLab 安全报告工件上传GitLab 根据报告中的schema/version完成解析后问题会出现在流水线对应的 Security 标签页中并在后续合并请求中持续跟踪。仓库的 kubernetes/checkov-job.yaml 提供了一份在 Kubernetes 集群中以 Job 方式运行 Checkov 的参考清单可作为将扫描器部署进 CI/CD 环境的补充参考。需要说明的是Checkov 只负责生成符合规范的 SAST 报告文件具体的流水线编排方式如 GitLab CI 的report关键字用法取决于你所在项目的 GitLab 配置。八、测试验证报告结构有单元测试保障gitlab_sast输出的正确性由 tests/common/output/test_gitlab_sast_report.py 覆盖其中test_iac_output使用真实 Terraform runner 扫描测试夹具main.tf仅运行CKV2_AWS_6与CKV_AWS_18两个检查随后断言schema、version、scan各字段值并验证vulnerabilities中两条 IaC 漏洞的identifiers、location、severity均为Unknown等内容——这正是原文档示例 JSON 的测试来源test_sca_package_output构造带 CVE 详情vulnerability_details的 SCA 记录验证 CVE 类型漏洞条目的字段渲染其余用例继续覆盖许可证记录、以及存在/不存在有效 guideline 链接时的links/identifiers.url行为。如果你需要修改或扩展 GitLab SAST 输出运行pytest tests/common/output/test_gitlab_sast_report.py即可快速回归验证。九、使用注意事项动态字段vulnerabilities[].id每次扫描由uuid4()重新生成报告间的 ID 不具备稳定性start_time/end_time目前取同一时刻仅作元信息guideline 为空时description与solution会显示为Further info can be found None如原文档示例所示且links与identifiers.url不会出现——这是源码中valid_url()校验的结果severity 兜底未配置严重级别的检查统一输出为Unknown如需更精确的分级可在策略配置中显式声明严重度SCA 报告的漏洞定位CVE 与许可证条目只有location.file而没有行号这是由Record数据的属性决定的解析端需兼容该差异。十、小结gitlab_sast输出让 Checkov 的 IaC 合规检查、镜像 CVE 与依赖许可证发现能够无缝进入 GitLab 的安全工作流。通过checkov -d . -o gitlab_sast一行命令即可获得符合 GitLab SAST 15.0.4 规范的报告其字段语义、严重级别映射、三类漏洞构造逻辑与文件落盘机制均有 gitlab_sast.py、runner_registry.py 及对应的单元测试作为实现依据便于二次开发与排查问题。关于报告格式中更多元素与属性的权威定义可参考 GitLab 官方维护的 SAST 报告 JSON Schema即报告schema字段指向的 v15.0.4 规范文件。【免费下载链接】checkovPrevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.项目地址: https://gitcode.com/GitHub_Trending/ch/checkov创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考