基于 DefectDojo 构建漏洞管理仪表盘：从部署到 CI/CD 集成与执行汇报的四段式工作流

基于 DefectDojo 构建漏洞管理仪表盘：从部署到 CI/CD 集成与执行汇报的四段式工作流

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

DefectDojo 是一个开源的应用程序漏洞管理平台，能够聚合 200+ 安全扫描工具的输出、对重复结果进行去重、跟踪修复进度并提供面向管理层的数据仪表盘。本文将围绕「初始部署与配置 → CI/CD 扫描器集成 → 漏洞分级处置（Triage）→ 执行层汇报」四条核心工作流展开，结合本仓库中 DefectDojo 技能包（技能主文档、API 参考、标准与部署要求、配置模板）及配套 Python 自动化脚本（agent.py、process.py），为你提供一套可复制、可落地的统一漏洞管理方案。读完本文，你将掌握 DefectDojo 的对象层级模型、REST API 调用方式、扫描结果导入与去重、Jira 工单联动、SLA 指标提取与执行汇报的完整链路。

工作流 1：初始部署与配置（Initial Setup and Configuration）

任何仪表盘系统的第一步都是把平台本身架设起来，并完成与业务对齐的基础建模。本工作流覆盖从环境搭建到 API 密钥发放的完整初始化过程。

1.1 克隆仓库并以 Docker Compose 部署

DefectDojo 官方提供 Docker Compose 部署方式，可在几分钟内拉起一套生产模式实例：

# 克隆 DefectDojo 仓库 git clone https://github.com/DefectDojo/django-DefectDojo.git cd django-DefectDojo # 以生产模式启动（官方脚本） ./dc-up-d.sh # 或使用手动 Docker Compose 方式 docker compose up -d # 检查各服务状态 docker compose ps # 从 initializer 容器日志中提取初始管理员密码 docker compose logs initializer 2>&1 | grep "Admin password" # 浏览器访问 http://localhost:8080

说明：以上命令中的仓库地址来自 DefectDojo 官方仓库；本技能包仅负责讲解部署与集成流程，实际克隆时请以官方最新文档为准。

部署硬件基线可参考本技能包中的标准与部署要求，其给出的最小与推荐配置如下：

1.2 配置管理员账号并修改默认密码

首次启动后立即登录初始管理员账号（凭据来自 initializer 日志），强制修改默认密码，并在生产环境中关闭或限制默认开放的调试功能。这是所有后续配置的安全前提。

1.3 按业务单元创建 Product Types

DefectDojo 采用「Product Type → Product → Engagement → Test → Finding」的五层对象模型（详见 SKILL.md）：

Product Type (业务单元) └── Product (应用/服务) └── Engagement (评估/迭代) └── Test (扫描器运行) └── Finding (单个漏洞)

配置模板给出了一套可供直接参考的 Product Type 划分方式：

1.4 为每个应用/服务创建 Product

在 Product Type 之下为每个应用或服务创建 Product 对象。例如「Customer Portal」主站，可归属到「Web Applications」类型下，并关联sla_configuration以启用 SLA 跟踪。

1.5 配置 Jira 集成用于工单管理

Jira 集成是「发现漏洞 → 自动建单 → 关闭自动关单」闭环的核心。配置项包括 Jira 实例地址、认证凭据、默认问题类型以及严重级别到 Jira 优先级的映射（详见 SKILL.md 的 Jira Integration 一节）：

jira_config = { "url": "https://company.atlassian.net", "username": "jira-bot@company.com", "password": "jira_api_token", "default_issue_type": "Bug", "critical_mapping_severity": "Blocker", "high_mapping_severity": "Critical", "medium_mapping_severity": "Major", "low_mapping_severity": "Minor", "finding_text": "**Vulnerability**: {{ finding.title }}\n**Severity**: {{ finding.severity }}\n**CVE**: {{ finding.cve }}\n**Description**: {{ finding.description }}", "accepted_mapping_resolution": "Done", "close_status_key": 6, }

配置模板给出了与之配套的优先级映射速查：Critical → Blocker、High → Critical、Medium → Major、Low → Minor，并支持 DefectDojo 中 finding 关闭后自动关闭对应 Jira 工单（Auto-close）。

1.6 配置 Slack/Teams Webhook 通知

为告警与关键事件（如新出现 Critical 漏洞、SLA 即将违约）配置 Slack 或 Microsoft Teams 的 Webhook 通知，让安全团队无需盯屏即可感知风险变化。

1.7 按严重级别设置 SLA 策略

SLA（服务等级协议）是量化修复效率的核心。参考 配置模板 的 SLA 配置表：

SLA 期限可在 API 查询中通过sla_breached=true参数直接筛出违约项，用于驱动后续的执行汇报（见工作流 4）。

1.8 为扫描器集成创建 API 密钥

DefectDojo 使用基于 Token 的认证（参见 API 参考）：

curl -H "Authorization: Token $DEFECTDOJO_TOKEN" \ "http://localhost:8080/api/v2/findings/"

为每个接入方（CI/CD 流水线、本地扫描脚本、报告工具）单独发放最小权限的 API Key，便于审计与吊销。

环境变量基线（部署阶段）

部署阶段需要在docker-compose.yml中预设如下关键环境变量（见 SKILL.md）：

DD_DATABASE_ENGINE=django.db.backends.postgresql DD_DATABASE_HOST=postgres DD_DATABASE_PORT=5432 DD_DATABASE_NAME=defectdojo DD_DATABASE_USER=defectdojo DD_DATABASE_PASSWORD=<secure_password> DD_ALLOWED_HOSTS=* DD_SECRET_KEY=<random_64_char_key> DD_CREDENTIAL_AES_256_KEY=<random_128_bit_key> DD_SOCIAL_AUTH_GOOGLE_OAUTH2_ENABLED=True

其中DD_SECRET_KEY与DD_CREDENTIAL_AES_256_KEY必须使用强随机值，前者保护会话与签名，后者用于加密存储的凭据，切勿使用默认值上生产。

工作流 2：CI/CD 扫描器集成（CI/CD Scanner Integration）

第二工作流解决「扫描结果如何自动进入仪表盘」的问题。核心思路是：在流水线中加入扫描步骤 → 上传结果 → 由 DefectDojo 负责去重与联动。

2.1 在 CI/CD 流水线中加入扫描步骤

支持 GitHub Actions、GitLab CI、Jenkins 等主流流水线。以 GitHub Actions 为例，本技能包在 SKILL.md 中给出了完整的.github/workflows/security-scan.yml：

name: Security Scan on: [push] jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Semgrep run: | pip install semgrep semgrep --config auto --json -o semgrep_results.json . - name: Upload to DefectDojo run: | curl -X POST "${{ secrets.DD_URL }}/api/v2/reimport-scan/" \ -H "Authorization: Token ${{ secrets.DD_API_KEY }}" \ -F "scan_type=Semgrep JSON Report" \ -F "file=@semgrep_results.json" \ -F "product_name=${{ github.event.repository.name }}" \ -F "engagement_name=CI/CD" \ -F "auto_create_context=true"

auto_create_context=true表示若 Product / Engagement 尚不存在则自动创建，极大降低了流水线接入成本。

2.2 运行安全扫描器（Semgrep、Trivy、ZAP 等）

在流水线中按需执行 SAST（Semgrep）、容器扫描（Trivy）、DAST（OWASP ZAP）等工具，并导出为 DefectDojo 支持的格式。各主流扫描器的scan_type取值见 API 参考：

完整解析器清单（含 Nessus、Qualys、Burp、ZAP、Trivy、Semgrep、SonarQube、Snyk、Checkov 等 200+ 解析器）可参考标准与部署要求。

2.3 通过 reimport-scan API 上传扫描结果

除import-scan/外，增量场景应使用reimport-scan/：它允许对同一 Test 反复上传新结果，而不是每次生成全新 Test。本技能包在 SKILL.md 中给出了 Nessus、ZAP、Trivy 三种典型上传命令：

# 上传 Nessus 扫描结果 curl -X POST "${DD_URL}/reimport-scan/" \ -H "Authorization: Token ${API_KEY}" \ -F "scan_type=Nessus Scan" \ -F "file=@nessus_report.csv" \ -F "product_name=Customer Portal" \ -F "engagement_name=Q1 2024 Security Assessment" \ -F "auto_create_context=true" \ -F "deduplication_on_engagement=true" # 上传 OWASP ZAP 结果 curl -X POST "${DD_URL}/reimport-scan/" \ -H "Authorization: Token ${API_KEY}" \ -F "scan_type=ZAP Scan" \ -F "file=@zap_report.xml" \ -F "product_name=Customer Portal" \ -F "engagement_name=Q1 2024 Security Assessment" \ -F "auto_create_context=true" # 上传 Trivy 容器扫描结果 curl -X POST "${DD_URL}/reimport-scan/" \ -H "Authorization: Token ${API_KEY}" \ -F "scan_type=Trivy Scan" \ -F "file=@trivy_results.json" \ -F "product_name=Customer Portal" \ -F "engagement_name=Q1 2024 Security Assessment" \ -F "auto_create_context=true"

配套的通用 CI/CD 上传片段（来自配置模板）将DD_URL、DD_API_KEY从流水线密钥注入，并通过SCAN_TYPE、SCAN_FILE、PRODUCT_NAME变量实现一次编写、处处复用：

- name: Upload scan results to DefectDojo env: DD_URL: ${{ secrets.DEFECTDOJO_URL }} DD_API_KEY: ${{ secrets.DEFECTDOJO_API_KEY }} run: | curl -X POST "${DD_URL}/api/v2/reimport-scan/" \ -H "Authorization: Token ${DD_API_KEY}" \ -F "scan_type=${SCAN_TYPE}" \ -F "file=@${SCAN_FILE}" \ -F "product_name=${PRODUCT_NAME}" \ -F "auto_create_context=true" \ -F "close_old_findings=true"

close_old_findings=true让已修复的漏洞在下次扫描上传时自动关闭，保持仪表盘数据实时反映现状。

2.4 自动去重（Deduplication）

DefectDojo 的核心价值之一是去重：同一漏洞在多次扫描、多个工具间重复出现时，平台会依据配置的哈希算法与去重作用域，将新结果与既有数据比对并合并，避免工单爆炸。deduplication_on_engagement=true将去重范围限定在单个 Engagement 内，是 CI/CD 场景最常用的设置。

2.5 新发现触发 Jira 工单创建

去重后真正的新发现会自动（或经配置的规则）触发 Jira 工单创建，工单内容由finding_text模板渲染，包含标题、严重级别、CVE 与描述（见工作流 1 的 Jira 配置）。

2.6 已关闭漏洞自动关闭关联 Jira 工单

当 DefectDojo 中 finding 被关闭（例如下次扫描确认修复），配置了 Auto-close 后对应的 Jira 工单会同步关闭，形成「扫描 → 建单 → 修复 → 复扫 → 关单」的自动化闭环。

2.7 流水线依据漏洞严重级别返回 pass/fail 状态

流水线末尾可根据本次上传产生的 Critical/High 数量决定门禁：存在高危漏洞则失败阻断发布，否则通过。该策略将漏洞管理前移到开发阶段，落实 DevSecOps 理念。

工作流 3：漏洞分级处置（Vulnerability Triage）

第三工作流描述安全分析师在 DefectDojo 仪表盘中的人工研判与处置过程。

3.1 分析师在仪表盘中审阅新发现

每日或按事件驱动的第一动作是：打开 DefectDojo 仪表盘，按严重级别、产品、Engagement 过滤查看新发现的 findings。

3.2 逐条验证、定级并设置风险接受状态

对每条 finding 执行三步动作：验证（verify）其真实性、核定严重级别（severity）、设置风险接受（risk acceptance）状态。查询时可通过 API 参考 中的参数组合精准定位待处理项：

3.3 有效漏洞：推送 Jira 跟踪修复

验证为真实漏洞的 finding，推送至 Jira 进行修复跟踪；修复完成后由复扫自动关闭（见工作流 2.6）。

3.4 误报：标记为 false positive 并附理由

确认为误报的 finding，标记为false positive并填写判断依据，防止后续扫描重复报出、占用分析师时间。

3.5 风险接受：记录补偿性控制并设置到期时间

确实无法在短期修复、但可接受的漏洞，走风险接受流程：记录补偿性控制措施（compensating controls）并设置接受到期时间（expiration）。到期后自动重新激活提醒，避免风险被无限期搁置。

3.6 通过 DefectDojo 指标跟踪修复进度

所有 triage 动作都会反映到平台指标中，包括各严重级别存量、新增/关闭速率、SLA 违约数等，为下一工作流的汇报提供数据源。

工作流 4：执行层汇报（Executive Reporting）

第四工作流将平台数据转化为管理层可决策的报表与指标。

4.1 通过 DefectDojo API 拉取报告周期内的指标

SKILL.md 给出了三条核心指标查询示例：

# 按严重级别统计活跃 finding 数量 resp = requests.get(f"{DD_URL}/findings/?limit=0&active=true", headers=HEADERS) findings = resp.json() # 统计 SLA 违约数量 resp = requests.get(f"{DD_URL}/findings/?limit=0&active=true&sla_breached=true", headers=HEADERS) # 获取产品级指标 resp = requests.get(f"{DD_URL}/products/{product_id}/", headers=HEADERS) product_data = resp.json()

limit=0表示一次返回全部结果，适合统计场景；active=true过滤掉已关闭项，sla_breached=true直接圈出违约项。

4.2 计算核心指标：总量、新增 vs 关闭、SLA 达标率

在拉取原始数据后，汇总计算：

• 总发现量（total findings）：当前活跃漏洞总数；
• 新增 vs 关闭（new vs closed）：周期内开单与关单的对比，反映修复吞吐；
• SLA 达标率（SLA compliance rate）：在 SLA 时限内完成修复的占比。

4.3 生成产品级与业务单元级汇总

利用 Product Type（业务单元）→ Product（产品）的层级结构，按不同粒度出具汇总：既能看「Web 应用组合」整体风险，也能下钻到「Customer Portal」单产品明细。

4.4 按严重级别跟踪平均修复时长（MTTR）

统计 Critical / High / Medium / Low 各级别的平均修复时长（mean time to remediate），用于识别修复流程瓶颈。

4.5 导出仪表盘数据用于高管演示

将上述指标整理为报表导出，供高管演示与月度/季度安全评审使用。

源码级支撑：用 Python 客户端自动化指标计算

本技能包在 scripts/agent.py 中实现了DefectDojoClient，封装了 findings/products/engagements 查询与扫描导入，并内置build_dashboard_data()指标聚合逻辑：按严重级别计数、按产品分布、计算平均漏洞年龄与 SLA 达标率。其内部按Critical / High / Medium / Low / Info五档循环统计，与 api-reference.md 的DefectDojoClient设计一脉相承：

import requests class DefectDojoClient: def __init__(self, url, token): self.url = url.rstrip("/") self.headers = {"Authorization": "Token " + token} def get_findings(self, **params): return requests.get( f"{self.url}/api/v2/findings/", headers=self.headers, params=params ).json()

另一脚本 scripts/process.py 则面向全流程编排：通过环境变量DD_URL/DD_API_KEY初始化，提供create_product_type、create_product、create_engagement、import_scan、get_findings、get_metrics、generate_dashboard_report等函数，覆盖「搭建对象层级 → 导入扫描 → 拉取指标 → 生成仪表盘报告」的完整链路，其中import_scan默认开启auto_create_context、deduplication_on_engagement与close_old_findings，与工作流 2 的命令行参数保持一致。从源码结构看，这两个脚本可以直接作为 Agent 调用或定时任务执行，将工作流 1–4 的重复操作固化为代码。

合规映射与适用前提

DefectDojo 的集中化漏洞跟踪能力与多项合规要求对齐（见 standards.md）：

• NIST SP 800-53 Rev 5 RA-5（漏洞监测与扫描）：集中化漏洞跟踪正是 RA-5 的落地支撑；
• OWASP ASVS：DefectDojo 使用 OWASP 分类法对 finding 归类；
• PCI DSS v4.0 要求 6：通过跟踪应用安全发现支撑 PCI 合规。

本技能包（SKILL.md 的 frontmatter）将该场景映射至 NIST CSF 的 ID.RA-01（识别资产漏洞）、ID.RA-02（接收威胁与漏洞情报）、ID.IM-02（改进监控能力）与 ID.RA-06（评估漏洞风险），以及 MITRE ATT&CK 的 T1190（面向公网应用利用）、T1203（客户端利用）、T1068（利用提权）。

需要说明的适用前提：文中命令与脚本均面向 DefectDojo REST API v2 设计；部署与scan_type取值以所用 DefectDojo 版本实际支持情况为准（如 API 参考中列出SARIF、Nuclei Scan等常用值），部分扫描器的解析器在不同版本间可能有差异，接入新扫描器前建议先核对目标版本支持的解析器清单。整套工作流最适合已具备 Docker 环境、希望以低成本统一多工具扫描输出并建立可量化漏洞治理闭环的团队。

小结

四个工作流环环相扣：工作流 1完成平台部署、对象建模、Jira/Slack 联动与 SLA 基线；工作流 2将扫描结果自动注入仪表盘并完成去重、建单与门禁判定；工作流 3由分析师完成验证、定级、误报/风险接受处置；工作流 4将存量数据转化为 MTTR、SLA 达标率等执行层指标。配合本技能包提供的 配置模板、API 参考 与 Python 自动化脚本，即可从零搭建一套「扫描即入库、漏洞可跟踪、风险可量化、汇报一键出」的集中化漏洞管理仪表盘。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills