GitLab合并请求中自定义container_scanning报告无法显示求助

• 严格核对报告JSON格式规范
  必须完全匹配GitLab Container Scanning的官方格式要求，重点检查这些必填项：

  • 根字段category必须是container_scanning
  • 每个漏洞条目必须包含name、message、severity（仅允许Critical/High/Medium/Low/Unknown/Info）、scanner（含id和name）、location（需包含镜像相关字段如image、依赖的package和version）
  • 对比官方示例结构逐字段校验，尤其是identifiers等嵌套结构的格式，不能有语法错误（比如多余逗号、缺失引号）

• 验证工件上传配置正确性

  • 检查.gitlab-ci.yml中的artifacts配置，确保路径完全正确，示例如下：

    artifacts:
      reports:
        container_scanning: custom_report.json
    

  • 查看Job执行日志，确认Uploading artifacts...环节成功上传了目标JSON文件，若文件生成在子目录，需写全路径（如./build/custom_report.json）

• 确认GitLab版本兼容性
  自定义Container Scanning报告的支持是从GitLab 13.0开始的，若使用自托管实例，先核对版本是否达标；GitLab.com用户确保使用的是最新共享Runner，旧版本Runner可能不兼容新报告格式

• 检查MR展示的触发条件
  GitLab仅展示当前分支相对于目标分支新增的漏洞，若报告中所有漏洞在目标分支已存在，MR界面不会显示。可以临时在报告中添加一个测试漏洞，验证是否能正常展示；同时检查项目安全设置中是否过滤了对应 severity 的漏洞（比如默认可能隐藏Info级）

• 排查日志中的解析错误

  • 在Job日志中搜索container_scanning关键词，查看是否有Invalid JSON、Missing required field等解析失败的提示
  • 自托管实例可查看gitlab-rails/log/application.log，定位报告解析环节的异常信息

• 对比Code Quality配置找差异
  既然Code Quality报告正常，对比两者的配置细节：

  • 检查文件生成路径、权限是否一致，避免Container Scanning报告文件因权限问题无法被读取
  • 核对两份报告的编码（需均为UTF-8）、JSON语法严谨性，排除格式层面的隐性差异

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