Activepieces Dependabot 告警治理实战从告警去重到证明无破坏的依赖升级全流程【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces本篇指南围绕 Activepieces 仓库内置的triage-dependabot-alerts技能.agents/skills/triage-dependabot-alerts/SKILL.md展开系统讲解如何对 GitHub Dependabot 依赖漏洞告警做端到端处置确定性拉取开放告警、按(package, advisory)去重、用 lockfile 权威清点实际安装版本、逐包确认漏洞 API 是否真实被使用并在用户批准后以构建 测试全部通过为前提提出非破坏性的版本升级 PR。读完本文你将掌握一套可复制的、面向大型 monorepo 的依赖漏洞分诊方法论以及 bun Turborepo 工程下的安全升级实操细节。适用范围何时使用本技能何时交给姊妹技能该技能面向的是Dependabot 依赖告警/repos/{owner}/{repo}/dependabot/alerts处理对象是已经公开的依赖 CVE因此修复可以直接走普通 PR不需要走私有 fork 流程。与之互补的是 .agents/skills/triage-security-advisories/SKILL.md它负责 Security 标签页中人工提交的私有安全公告需要对照 SECURITY.md 做范围检查修复必须走security/ghsa-id私有分支。两个技能共享同一个.security-triage/工作区本技能写入的汇总文件命名为DEPENDABOT-TRIAGE-SUMMARY.md与公告技能使用的TRIAGE-SUMMARY.md区分开避免互相覆盖。隐私约定Dependabot 数据比私有公告敏感度低但工作区必须保持一致所有产物拉取的 JSON、每包报告、汇总文件一律写入.security-triage/该目录在仓库根目录的 .gitignore 中已被显式忽略# security advisory triage artifacts (PRIVATE/embargoed advisory content — never commit).security-triage/任何分诊产物都不得提交。Step 1 — 确定性拉取开放告警先用 GitHub CLI 拉取所有stateopen的 Dependabot 告警并落盘mkdir -p .security-triage gh api -H Accept: application/vnd.githubjson /repos/activepieces/activepieces/dependabot/alerts?stateopen --paginate .security-triage/dependabot.json分页数组必须合并gh api --paginate每次分页会输出一个独立的 JSON 数组[...]\n[...]拼接直接交给jq会解析失败。必须用jq -s add合并成单个数组jq -s add .security-triage/dependabot.json .tmp mv .tmp .security-triage/dependabot.json校验返回的是真实数据而非错误对象403/404 的响应体形如{message, documentation_url, status}此时jq length会返回3看起来像3 条告警极具迷惑性。必须显式断言顶层是数组jq -e typearray .security-triage/dependabot.json /dev/null \ || echo Not an array — Dependabot fetch failed (likely token scope). Stopping.Token scope先拉取失败再补不要预先做 scope 检查——实践表明仅reposcope 就能返回完整告警列表直接尝试拉取即可。只有返回 403/404 或非数组时才需要补security_eventsscopeweb-OAuth 登录gho_tokengh auth refresh -s security_events经典 PATgh auth refresh无法为 PAT 追加 scope需要重新签发包含reposecurity_events的 token再用gh auth login --with-token登录后重试。直到 fetch 返回数组之前停止后续流程。Step 2 — 去重再验证使用情况大型 backlog数百条告警去重后会坍缩成很小的去重漏洞集合同一个 CVE 会针对每个声明了该包的 manifest各报一条而单一提升hoistedlockfile 的 monorepo 实际只安装一份副本。分诊的单位是去重后的漏洞不是原始告警。按 (package, advisory) 去重# distinct (package, advisory) — the real triage unit jq -r group_by(.security_advisory.ghsa_id | .dependency.package.name) | map({pkg:.[0].dependency.package.name, sev:.[0].security_advisory.severity, ghsa:.[0].security_advisory.ghsa_id, n:length}) | .[] | \(.sev)\t\(.pkg)\t\(.ghsa)\tx\(.n) .security-triage/dependabot.json | sort默认只聚焦critical high如需 medium/low 先询问用户——超长 backlog 很少值得全量分诊。后续流程按包分组推进一次升级通常能清掉该包在所有 manifest 上的全部告警。读取每条公告的完整受影响区间而不是只读第一条每条公告的security_advisory.vulnerabilities[]针对每个受影响的大版本线各有一条记录。例如form-data同时修补2.5.6和4.0.0,4.0.6undici对 6.x / 7.x / 8.x 分别给出修补版本6.27这种范围没有下界还覆盖 5.x。只取vulnerabilities[0]会静默低估暴露面必须全部取出jq -r .[] | select(.security_advisory.ghsa_idGHSA) | .security_advisory.vulnerabilities[] | range\(.vulnerable_version_range) patched\(.first_patched_version.identifier // none) \ .security-triage/dependabot.json | sort -u在主线程清点 lockfile不要相信子代理的记忆在派发子代理之前直接从 bun.lock 列出每个包的所有已安装副本这是权威事实子代理经常漏数重复的传递依赖副本实践中两个子代理都只报告了 1 个副本而 lockfile 里实际有 3 个grep -oE pkg[0-9][^]* bun.lock | sort -u # every installed version, incl. transitive dupes每包或每去重公告一个子代理每个子代理确认该告警对本仓库是否真实成立确认包确实是依赖直接或传递以及由哪些 manifest 声明grep manifest 时要忽略node_modules/**路径确认具体的易受攻击 API / 代码路径确实被 import 并被调用——而不是只存在于传递依赖或死代码中是否受影响必须以 lockfile 为准从 lockfile 读实际安装版本与公告的受影响区间比对。落在区间内就是受影响的即使版本号看起来很新。对于有多条公告的包≥ 某条公告的 first-patched 版本不代表安全——另一条公告可能要求更高的修补版本例如form-data4.0.4 清掉了4.0.4的公告但依然受4.0.6公告影响。LLM 对安装版本的猜测不可靠必须查 lockfile记录first patched version并确认是否存在任何修复版本评估真实暴露面攻击者输入可达还是仅开发/构建期。包管理器根据仓库packageManager字段和存在的 lockfile 判断bun.lock→ bunpackage-lock.json→ npmpnpm-lock.yaml→ pnpmyarn.lock→ yarn。本仓库是bun——根目录 package.json 明确声明packageManager: bun1.4.0Step 4 需使用对应的 bun 工具链。每个包/公告输出一个裁决裁决含义AFFECTED易受攻击的路径确实被使用NOT_AFFECTED依赖存在但易受攻击的 API 未被使用NO_FIX_YET任何地方都不存在已修补版本DEV_ONLY仅构建/测试期受影响Step 3 — 输出评审就绪的报告每个受影响包生成一份 markdown 文件路径为.security-triage/reports/dependabot-package.md不是每条告警一份那样无法扩展。每份报告包含该包的公告 受影响区间、来自 lockfile 的已安装版本、first patched version、使用裁决 调用点、严重级别、组成该包的告警 ID 列表、以及升级建议。随后写合并汇总.security-triage/DEPENDABOT-TRIAGE-SUMMARY.md这是用户真正评审的产物注意与公告技能的TRIAGE-SUMMARY.md区分不要覆盖它内容包括裁决统计AFFECTED / NOT_AFFECTED / NO_FIX_YET / DEV_ONLY 各多少按严重级别 裁决分组的表格包、严重级别、已安装 → 修复版本、裁决、可达性、告警数共享依赖模式一次升级解决多条告警或多条告警共享同一 manifest。在聊天中呈现头条裁决时按攻击者最易达的顺序排列DEV_ONLY发现单独分组呈现——开发环境测试运行器里的 critical CVSS 不应埋没生产代码中攻击者可达的 high。Step 4 — 批准后修复升级必须被证明无破坏只有用户选定要修复的包之后才进入本步。单一 lockfile → 单批 PR在共享单一 lockfilebun/npm/pnpm的 monorepo 中按包开分支会在 lockfile 上互相冲突。必须把所有获批的包放进一个隔离的 git worktree开一个PR——绝不能每包一个 worktree/PR。为整批创建一个隔离的 git worktree主工作树保持不动把每个依赖升级到能清掉其全部公告的 first patched versionbun改 pin 的范围 bun install。本仓库的直接依赖通常是精确 pin因此要在每个声明了该包的 manifest 中同步升级——对精确 pin 使用 find sed 全量替换是合适的做法find … -not -path */node_modules/* -exec sed -i s/pkg: old/pkg: new/ {} \;小心处理升级后残留的重复副本——这是升级最容易出错的地方。升级后重跑 Step 2 的清点。对每个仍易受攻击的副本同一大版本线、属于我们自己依赖树→ 用扁平的resolutions/overrides条目 pin 住如axios: 1.16.0。bun 只认扁平 key——superagent/form-data: x这类带作用域的 key 会被静默忽略所以扁平 pin 才能强制所有副本。本仓库 package.json 的resolutions字段rollup、axios、nanoid就是这一机制的现成实例跨越第三方 SDK 内部的大版本线如superagent内的form-data2.x、vendor client 内的undici5.x→不要强行升级。仓库测试不会覆盖该 SDK 的代码路径强行跨大版本无法被证明无破坏。保留它并在包报告 PR body 中记录为残留风险哪个副本、哪条公告、为何不强升。修复攻击者可达的直接依赖是底线SDK 内部的传递副本等 SDK 自行更新用清点 grep 确认最终依赖树。给 semver 跳变分类minor/patch 升级并非自动安全——库可能在 minor 版本收紧 TypeScript 类型导致构建失败实践中samlify2.10→2.13 的 minor 升级因收窄参数类型破坏了tsc。major 标记为最高风险但任何低风险升级都不能跳过构建验证阅读依赖从当前版本到目标版本之间的 changelog / release notes查找破坏性变更全仓库 grep 该依赖 API 的每个使用点逐一对照新版本检查任何需要的代码改动如适配收紧的类型必须放进同一个PR跑 typecheck build lint 受影响包的测试npx turbo run build lint test --filterpkg … # 每个受影响包一个 --filterTurborepo 的build/lint/test/typecheck任务定义见 turbo.json其中test任务依赖build确保依赖图顺序正确故障分诊——不要默认是升级造成的测试失败时先在 baseHEAD树上重跑再归因于升级。陈旧测试和依赖网络的集成测试与依赖版本无关地失败。只有base 上绿、升级后红的测试才归你修在有版本的内部包packages/core/shared、packages/server/utils内部升级依赖会触发仓库的版本升级规则——这些包也要做 patch 版本升级每分支一次不是每次编辑一次只有 build/lint/tests 全部通过或唯一失败已被第 8 步证明是预先存在的/环境性的才提 PR否则报告确切的破坏点与备选方案pin、仅 patch 升级、或所需代码改动失败则丢弃 worktree。NO_FIX_YET 包不升 PR产出风险接受书没有已修补版本的包不生成升级 PR改为在包报告中产出风险接受/缓解说明它在哪里可达、现有 sandboxing 情况、以及选项附理由地接受残余风险、用patch-package/bun patch 本地修补、或替换该库。如果唯一可用的修复来自外部源例如 SheetJS 从 npm 换到 CDN tarball要标记self-hosting 规则构建期依赖第三方 CDN 的安装方式可能破坏零配置自托管需要交由维护者决策。依赖 CVE 是公开的走普通 PR 即可无需私有 fork 流程。修补范围保持克制——不要夹带无关升级。仓库侧的证据与配套工具包管理器与 monorepo 结构package.json 声明bun1.4.0workspaces覆盖packages/cli、packages/core/*、packages/server/*、packages/web以及数百个packages/pieces/community/*包——这正是一个 CVE 报多条告警、但一次升级清一片的典型场景构建矩阵turbo.json 定义了builddependsOn: [^build]、lint、test、typecheck等任务第 4 步的npx turbo run build lint test --filterpkg与之一一对应SLA 与状态桶tools/scripts/security/sla-report.ts 内置了 severity → 修复时限critical 7 天 / high 30 天 / medium 90 天 / low best-effort与 DUE_SOON 阈值2 / 7 / 14 天状态桶为BREACHED → DUE_SOON → ON_TRACK → BEST_EFFORT → NEEDS_TRIAGE。虽然该脚本默认同时支持advisory与dependabot两种数据源normalizeDependabot处理 Dependabot 告警行结构本技能的主流程是手动的 jq 流水线 子代理验证SLA 脚本可作为公告侧triage-security-advisories技能的配套根目录 package.json 也暴露了security:sla脚本入口工作区隔离.gitignore 确认.security-triage/已被忽略任何分诊产物都不会进入提交历史。与相邻技能的分工.agents/skills/triage-security-advisories/SKILL.md处理 Security 标签页人工报告的私有公告需对照 SECURITY.md 做范围检查修复走私有 fork 的security/ghsa-id分支与本文的公开依赖 CVE 流程严格区分.agents/skills/triage-image-cves/SKILL.md负责容器镜像层面的 CVE 分诊与本文的依赖告警互为补充。三者共享.security-triage/工作区与绝不提交产物的隐私规则但各写各的汇总文件避免互相覆盖。输出物清单一次完整的 Dependabot 分诊结束后所有产物落在.security-triage/gitignoreddependabot.json—— 拉取并合并校验后的原始告警数据DEPENDABOT-TRIAGE-SUMMARY.md—— 供用户评审的合并汇总裁决统计 表格 共享依赖模式reports/dependabot-package.md—— 每个受影响包一份的详细报告。整个流程的核心纪律可以浓缩为三点以去重后的漏洞为单位分诊而不是原始告警、以 lockfile 为权威事实而不是 LLM 记忆、以构建 测试通过为升级门槛而不是版本号新旧。这套方法论让数百条告警的 backlog 变成可评审、可决策、可追溯的少量真实风险项。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Activepieces Dependabot 告警治理实战：从告警去重到“证明无破坏“的依赖升级全流程
Activepieces Dependabot 告警治理实战从告警去重到证明无破坏的依赖升级全流程【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces本篇指南围绕 Activepieces 仓库内置的triage-dependabot-alerts技能.agents/skills/triage-dependabot-alerts/SKILL.md展开系统讲解如何对 GitHub Dependabot 依赖漏洞告警做端到端处置确定性拉取开放告警、按(package, advisory)去重、用 lockfile 权威清点实际安装版本、逐包确认漏洞 API 是否真实被使用并在用户批准后以构建 测试全部通过为前提提出非破坏性的版本升级 PR。读完本文你将掌握一套可复制的、面向大型 monorepo 的依赖漏洞分诊方法论以及 bun Turborepo 工程下的安全升级实操细节。适用范围何时使用本技能何时交给姊妹技能该技能面向的是Dependabot 依赖告警/repos/{owner}/{repo}/dependabot/alerts处理对象是已经公开的依赖 CVE因此修复可以直接走普通 PR不需要走私有 fork 流程。与之互补的是 .agents/skills/triage-security-advisories/SKILL.md它负责 Security 标签页中人工提交的私有安全公告需要对照 SECURITY.md 做范围检查修复必须走security/ghsa-id私有分支。两个技能共享同一个.security-triage/工作区本技能写入的汇总文件命名为DEPENDABOT-TRIAGE-SUMMARY.md与公告技能使用的TRIAGE-SUMMARY.md区分开避免互相覆盖。隐私约定Dependabot 数据比私有公告敏感度低但工作区必须保持一致所有产物拉取的 JSON、每包报告、汇总文件一律写入.security-triage/该目录在仓库根目录的 .gitignore 中已被显式忽略# security advisory triage artifacts (PRIVATE/embargoed advisory content — never commit).security-triage/任何分诊产物都不得提交。Step 1 — 确定性拉取开放告警先用 GitHub CLI 拉取所有stateopen的 Dependabot 告警并落盘mkdir -p .security-triage gh api -H Accept: application/vnd.githubjson /repos/activepieces/activepieces/dependabot/alerts?stateopen --paginate .security-triage/dependabot.json分页数组必须合并gh api --paginate每次分页会输出一个独立的 JSON 数组[...]\n[...]拼接直接交给jq会解析失败。必须用jq -s add合并成单个数组jq -s add .security-triage/dependabot.json .tmp mv .tmp .security-triage/dependabot.json校验返回的是真实数据而非错误对象403/404 的响应体形如{message, documentation_url, status}此时jq length会返回3看起来像3 条告警极具迷惑性。必须显式断言顶层是数组jq -e typearray .security-triage/dependabot.json /dev/null \ || echo Not an array — Dependabot fetch failed (likely token scope). Stopping.Token scope先拉取失败再补不要预先做 scope 检查——实践表明仅reposcope 就能返回完整告警列表直接尝试拉取即可。只有返回 403/404 或非数组时才需要补security_eventsscopeweb-OAuth 登录gho_tokengh auth refresh -s security_events经典 PATgh auth refresh无法为 PAT 追加 scope需要重新签发包含reposecurity_events的 token再用gh auth login --with-token登录后重试。直到 fetch 返回数组之前停止后续流程。Step 2 — 去重再验证使用情况大型 backlog数百条告警去重后会坍缩成很小的去重漏洞集合同一个 CVE 会针对每个声明了该包的 manifest各报一条而单一提升hoistedlockfile 的 monorepo 实际只安装一份副本。分诊的单位是去重后的漏洞不是原始告警。按 (package, advisory) 去重# distinct (package, advisory) — the real triage unit jq -r group_by(.security_advisory.ghsa_id | .dependency.package.name) | map({pkg:.[0].dependency.package.name, sev:.[0].security_advisory.severity, ghsa:.[0].security_advisory.ghsa_id, n:length}) | .[] | \(.sev)\t\(.pkg)\t\(.ghsa)\tx\(.n) .security-triage/dependabot.json | sort默认只聚焦critical high如需 medium/low 先询问用户——超长 backlog 很少值得全量分诊。后续流程按包分组推进一次升级通常能清掉该包在所有 manifest 上的全部告警。读取每条公告的完整受影响区间而不是只读第一条每条公告的security_advisory.vulnerabilities[]针对每个受影响的大版本线各有一条记录。例如form-data同时修补2.5.6和4.0.0,4.0.6undici对 6.x / 7.x / 8.x 分别给出修补版本6.27这种范围没有下界还覆盖 5.x。只取vulnerabilities[0]会静默低估暴露面必须全部取出jq -r .[] | select(.security_advisory.ghsa_idGHSA) | .security_advisory.vulnerabilities[] | range\(.vulnerable_version_range) patched\(.first_patched_version.identifier // none) \ .security-triage/dependabot.json | sort -u在主线程清点 lockfile不要相信子代理的记忆在派发子代理之前直接从 bun.lock 列出每个包的所有已安装副本这是权威事实子代理经常漏数重复的传递依赖副本实践中两个子代理都只报告了 1 个副本而 lockfile 里实际有 3 个grep -oE pkg[0-9][^]* bun.lock | sort -u # every installed version, incl. transitive dupes每包或每去重公告一个子代理每个子代理确认该告警对本仓库是否真实成立确认包确实是依赖直接或传递以及由哪些 manifest 声明grep manifest 时要忽略node_modules/**路径确认具体的易受攻击 API / 代码路径确实被 import 并被调用——而不是只存在于传递依赖或死代码中是否受影响必须以 lockfile 为准从 lockfile 读实际安装版本与公告的受影响区间比对。落在区间内就是受影响的即使版本号看起来很新。对于有多条公告的包≥ 某条公告的 first-patched 版本不代表安全——另一条公告可能要求更高的修补版本例如form-data4.0.4 清掉了4.0.4的公告但依然受4.0.6公告影响。LLM 对安装版本的猜测不可靠必须查 lockfile记录first patched version并确认是否存在任何修复版本评估真实暴露面攻击者输入可达还是仅开发/构建期。包管理器根据仓库packageManager字段和存在的 lockfile 判断bun.lock→ bunpackage-lock.json→ npmpnpm-lock.yaml→ pnpmyarn.lock→ yarn。本仓库是bun——根目录 package.json 明确声明packageManager: bun1.4.0Step 4 需使用对应的 bun 工具链。每个包/公告输出一个裁决裁决含义AFFECTED易受攻击的路径确实被使用NOT_AFFECTED依赖存在但易受攻击的 API 未被使用NO_FIX_YET任何地方都不存在已修补版本DEV_ONLY仅构建/测试期受影响Step 3 — 输出评审就绪的报告每个受影响包生成一份 markdown 文件路径为.security-triage/reports/dependabot-package.md不是每条告警一份那样无法扩展。每份报告包含该包的公告 受影响区间、来自 lockfile 的已安装版本、first patched version、使用裁决 调用点、严重级别、组成该包的告警 ID 列表、以及升级建议。随后写合并汇总.security-triage/DEPENDABOT-TRIAGE-SUMMARY.md这是用户真正评审的产物注意与公告技能的TRIAGE-SUMMARY.md区分不要覆盖它内容包括裁决统计AFFECTED / NOT_AFFECTED / NO_FIX_YET / DEV_ONLY 各多少按严重级别 裁决分组的表格包、严重级别、已安装 → 修复版本、裁决、可达性、告警数共享依赖模式一次升级解决多条告警或多条告警共享同一 manifest。在聊天中呈现头条裁决时按攻击者最易达的顺序排列DEV_ONLY发现单独分组呈现——开发环境测试运行器里的 critical CVSS 不应埋没生产代码中攻击者可达的 high。Step 4 — 批准后修复升级必须被证明无破坏只有用户选定要修复的包之后才进入本步。单一 lockfile → 单批 PR在共享单一 lockfilebun/npm/pnpm的 monorepo 中按包开分支会在 lockfile 上互相冲突。必须把所有获批的包放进一个隔离的 git worktree开一个PR——绝不能每包一个 worktree/PR。为整批创建一个隔离的 git worktree主工作树保持不动把每个依赖升级到能清掉其全部公告的 first patched versionbun改 pin 的范围 bun install。本仓库的直接依赖通常是精确 pin因此要在每个声明了该包的 manifest 中同步升级——对精确 pin 使用 find sed 全量替换是合适的做法find … -not -path */node_modules/* -exec sed -i s/pkg: old/pkg: new/ {} \;小心处理升级后残留的重复副本——这是升级最容易出错的地方。升级后重跑 Step 2 的清点。对每个仍易受攻击的副本同一大版本线、属于我们自己依赖树→ 用扁平的resolutions/overrides条目 pin 住如axios: 1.16.0。bun 只认扁平 key——superagent/form-data: x这类带作用域的 key 会被静默忽略所以扁平 pin 才能强制所有副本。本仓库 package.json 的resolutions字段rollup、axios、nanoid就是这一机制的现成实例跨越第三方 SDK 内部的大版本线如superagent内的form-data2.x、vendor client 内的undici5.x→不要强行升级。仓库测试不会覆盖该 SDK 的代码路径强行跨大版本无法被证明无破坏。保留它并在包报告 PR body 中记录为残留风险哪个副本、哪条公告、为何不强升。修复攻击者可达的直接依赖是底线SDK 内部的传递副本等 SDK 自行更新用清点 grep 确认最终依赖树。给 semver 跳变分类minor/patch 升级并非自动安全——库可能在 minor 版本收紧 TypeScript 类型导致构建失败实践中samlify2.10→2.13 的 minor 升级因收窄参数类型破坏了tsc。major 标记为最高风险但任何低风险升级都不能跳过构建验证阅读依赖从当前版本到目标版本之间的 changelog / release notes查找破坏性变更全仓库 grep 该依赖 API 的每个使用点逐一对照新版本检查任何需要的代码改动如适配收紧的类型必须放进同一个PR跑 typecheck build lint 受影响包的测试npx turbo run build lint test --filterpkg … # 每个受影响包一个 --filterTurborepo 的build/lint/test/typecheck任务定义见 turbo.json其中test任务依赖build确保依赖图顺序正确故障分诊——不要默认是升级造成的测试失败时先在 baseHEAD树上重跑再归因于升级。陈旧测试和依赖网络的集成测试与依赖版本无关地失败。只有base 上绿、升级后红的测试才归你修在有版本的内部包packages/core/shared、packages/server/utils内部升级依赖会触发仓库的版本升级规则——这些包也要做 patch 版本升级每分支一次不是每次编辑一次只有 build/lint/tests 全部通过或唯一失败已被第 8 步证明是预先存在的/环境性的才提 PR否则报告确切的破坏点与备选方案pin、仅 patch 升级、或所需代码改动失败则丢弃 worktree。NO_FIX_YET 包不升 PR产出风险接受书没有已修补版本的包不生成升级 PR改为在包报告中产出风险接受/缓解说明它在哪里可达、现有 sandboxing 情况、以及选项附理由地接受残余风险、用patch-package/bun patch 本地修补、或替换该库。如果唯一可用的修复来自外部源例如 SheetJS 从 npm 换到 CDN tarball要标记self-hosting 规则构建期依赖第三方 CDN 的安装方式可能破坏零配置自托管需要交由维护者决策。依赖 CVE 是公开的走普通 PR 即可无需私有 fork 流程。修补范围保持克制——不要夹带无关升级。仓库侧的证据与配套工具包管理器与 monorepo 结构package.json 声明bun1.4.0workspaces覆盖packages/cli、packages/core/*、packages/server/*、packages/web以及数百个packages/pieces/community/*包——这正是一个 CVE 报多条告警、但一次升级清一片的典型场景构建矩阵turbo.json 定义了builddependsOn: [^build]、lint、test、typecheck等任务第 4 步的npx turbo run build lint test --filterpkg与之一一对应SLA 与状态桶tools/scripts/security/sla-report.ts 内置了 severity → 修复时限critical 7 天 / high 30 天 / medium 90 天 / low best-effort与 DUE_SOON 阈值2 / 7 / 14 天状态桶为BREACHED → DUE_SOON → ON_TRACK → BEST_EFFORT → NEEDS_TRIAGE。虽然该脚本默认同时支持advisory与dependabot两种数据源normalizeDependabot处理 Dependabot 告警行结构本技能的主流程是手动的 jq 流水线 子代理验证SLA 脚本可作为公告侧triage-security-advisories技能的配套根目录 package.json 也暴露了security:sla脚本入口工作区隔离.gitignore 确认.security-triage/已被忽略任何分诊产物都不会进入提交历史。与相邻技能的分工.agents/skills/triage-security-advisories/SKILL.md处理 Security 标签页人工报告的私有公告需对照 SECURITY.md 做范围检查修复走私有 fork 的security/ghsa-id分支与本文的公开依赖 CVE 流程严格区分.agents/skills/triage-image-cves/SKILL.md负责容器镜像层面的 CVE 分诊与本文的依赖告警互为补充。三者共享.security-triage/工作区与绝不提交产物的隐私规则但各写各的汇总文件避免互相覆盖。输出物清单一次完整的 Dependabot 分诊结束后所有产物落在.security-triage/gitignoreddependabot.json—— 拉取并合并校验后的原始告警数据DEPENDABOT-TRIAGE-SUMMARY.md—— 供用户评审的合并汇总裁决统计 表格 共享依赖模式reports/dependabot-package.md—— 每个受影响包一份的详细报告。整个流程的核心纪律可以浓缩为三点以去重后的漏洞为单位分诊而不是原始告警、以 lockfile 为权威事实而不是 LLM 记忆、以构建 测试通过为升级门槛而不是版本号新旧。这套方法论让数百条告警的 backlog 变成可评审、可决策、可追溯的少量真实风险项。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考