feat: add vulnerability management platform service adapter - #385
feat: add vulnerability management platform service adapter#385dongyueyan127-dot wants to merge 18 commits into
Conversation
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次 PR 新增了一个漏洞管控平台（Vulnerability Platform）的 OctoBus Service 适配器示例，包含：
整体为模板/示例代码，核心接口定义完整，但 |
![monkeyscan[bot]](https://avatars.githubusercontent.com/u/231811742?s=60&v=4){kind=small}
|
缺少实际测试的证据 |
Service L2 自动检查结果：l2:blocked
L2 只验证包结构、mock 测试、80% line/branch/function coverage、打包、构建和 OctoBus smoke 链路；真实设备兼容性仍需人工检查作者提供的脱敏证据。 |
97104fd to
30e67ac
Compare
|
已补齐可复现测试证据（PR head:
已迁移到 |
30e67ac to
8859f31
Compare
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次变更为新增一个 OctoBus 服务适配器，用于对接第三方"漏洞管理平台 3.2.0"。新增内容主要包括：config/secret JSON schema、service.json、proto 定义（3 个 service、16 个 RPC）、README；核心实现 src/client.js（PlatformClient，负责 REST 调用、token 获取/缓存、TLS 处理与 gRPC 错误映射）、src/token-generator.js（调用 vendor vms-auth-sdk JAR 生成签名 token）、src/vulnplatform-vuln.js（16 个 RPC handler 到 REST 端点的映射）；以及注册文件（services/package.json、bin/octobus-tentacles.js、bin/vulnplatform-vuln.js）和单元/冒烟测试。 关键设计：支持 apiToken 直配或 appId/key/account + 本地 JAR 两种认证方式，后者通过 /api/login2 换取 bearer token 并缓存 25 分钟、对并发登录做请求合并；错误映射为 401/403/404 分别对应 UNAUTHENTICATED/PERMISSION_DENIED/NOT_FOUND，其余 4xx 归 FAILED_PRECONDITION，5xx/网络错误归 UNAVAILABLE，超时归 DEADLINE_EXCEEDED；skipTlsVerify 通过本地 undici dispatcher 实现，不改变进程级 TLS 策略；错误消息刻意不包含上游响应体与密钥。 总体评估：代码结构清晰，安全防御（不泄漏密钥/响应体、并发合并、TLS 隔离）与测试覆盖较好。主要风险集中在认证/缓存生命周期与密钥处理：1) vendor key 作为命令行参数传给 java 子进程，本机其他进程可通过 ps//proc 读取；2) 上游返回 401 时不会使 token 缓存失效，token 被吊销后最长 25 分钟持续鉴权失败；3) loginCache 条目永不回收，多租户场景存在内存增长与过期 token 长期驻留；4) HTTP 429 被映射为 FAILED_PRECONDITION，语义不当且丢失可重试语义。 |
|
维护者深修更新（head |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次变更对 vulnplatform 客户端做 token 生命周期与限流映射加固，共修改 2 个文件（src/client.js 与对应测试）。 核心改动：
测试补充了 429→RESOURCE_EXHAUSTED 映射断言以及"401 驱逐被吊销 token"的行为断言，覆盖了本次新增行为。 整体评估：变更方向正确、范围聚焦，修复了两个历史缺陷并缓解了第三个。未发现由本次改动引入的高置信度严重 bug。已提交 1 条低严重度发现：loginCache 仍为无容量上限的模块级 Map，多租户长运行场景下未复用凭证与不再访问的过期条目会永久驻留内存，建议增加有界回收机制。 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次变更（services/vulnplatform__vulnerability-management_v3-2-0/src/client.js，+6/-0）为模块级 loginCache 增加容量上限 MAX_LOGIN_CACHE_ENTRIES = 256，并在成功登录写入缓存前按 Map 插入顺序（FIFO）逐出最旧条目直至容量低于上限。 评估结论：
未发现由本次变更引入的高置信度正确性、安全性或可靠性缺陷，无新增 finding 提交。附带非阻塞观察：FIFO 逐出在超过 256 个凭证组合时会逐出仍有效的 token 并触发重新登录，属有界缓存的预期取舍；逐出仅发生在成功登录路径，缓存中仍可能驻留已过期条目，但总量受 256 硬限制。 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次变更移除了 vulnplatform 服务的 vendor JAR 令牌生成能力（删除 token-generator.js；secret.schema.json 收紧为仅允许 apiToken；config.schema.json 移除 tokenJarPath；client.js 删除 appId/key/account 登录流程；README 与测试同步清理），目的是避免把 vendor 密钥暴露在进程命令行参数中，属安全加固，整体方向正确。 主要问题：client.js 的 bearerToken() 重构不彻底，留下不可达死代码——首行 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次变更仅涉及一个文件：services/vulnplatform__vulnerability-management_v3-2-0/config.schema.json，改动为删除 JSON Schema 中 properties 对象末尾（skipTlsVerify 属性对象闭合花括号之后）的一个尾随逗号（trailing comma）。 评估：
结论：无需要上报的问题。 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次变更从 PlatformClient 中移除了 bearer token 的内存缓存机制（TOKEN_TTL_MS / MAX_LOGIN_CACHE_ENTRIES / loginCache / loginRequests / loginCacheKey），并删除了 request() 中 401 时按缓存键失效的死分支。旧代码因首行 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次变更仅修改 services/vulnplatform__vulnerability-management_v3-2-0/src/client.js 的 bearerToken() 方法：删除了一行冗余的提前返回 行为分析：删除后逻辑为——apiToken 经 text() 归一化后为空则抛 FAILED_PRECONDITION，否则返回配置的 token。与删除前完全一致（此前该提前返回使末尾 该改动同时化解了历史发现 9366bc24（bearerToken() 尾部 return 不可达的死代码问题）；历史发现 879bd757 所指的登录缓存死代码与 README 不一致问题，也已被前序提交（d5f41bc 移除过时的 bearer token 缓存）彻底清除，当前文件已不存在相关缓存代码。 整体评估：改动安全且属于纯清理，无需要提交的 actionable finding。 |
a4f6007 to
7d30802
Compare
|
PR Title: feat: add vulnerability management platform servic... Commit: 该 PR 新增 "Vulnerability Management Platform 3.2.0" 的 OctoBus 服务集成，共 15 个文件。核心内容：vulnerability.proto 定义 16 个 RPC（VulnerabilityService 7 个、AssetService 6 个、IntelligenceService 3 个），src/client.js 实现基于 undici/fetch 的 HTTP 客户端，src/vulnplatform-vuln.js 将 16 个 RPC 映射到平台 REST 端点，src/service.js 通过 defineService 导出服务。同时新增配置/密钥 schema、bin 入口、README、单测与 smoke 测试，并更新根 package.json 与 octobus-tentacles.js 注册。 整体设计质量较高：HTTP 状态码到 gRPC 错误的映射完整（401/403/404/429/4xx/5xx/超时分别映射），错误信息不包含上游响应体（避免泄露敏感信息）；skipTlsVerify 通过局部 undici dispatcher 实现且不改变进程级 TLS 策略；proto 方法名与 handler 一一对应；测试覆盖了错误映射、配置校验、TLS 隔离、mapper 等关键路径。 发现两个低风险问题：(1) CreateVulnerability/CreateStandardVulnerability 的 handler 将 proto int64 的返回 ID 用 Number() 强转，存在大整数精度丢失风险（与列表响应的透传行为不一致）；(2) apiBaseUrl 校验明确允许 http 协议，配置为 http 时 bearer token 将明文传输。两者均为本变更引入/暴露，建议在提交前加固。 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次变更围绕两个目标：(1) 强制 API base URL 使用 HTTPS，防止平台签发的 bearer token 通过明文 HTTP 传输被嗅探；(2) 修复 CreateVulnerability / CreateStandardVulnerability 响应中 int64 标识符因 Number() 转换导致的精度丢失。 具体改动：src/client.js 的 endpoint() 校验从接受 http:/https: 收紧为仅接受 https:，并更新错误文案；config.schema.json 为 apiBaseUrl 增加 ^https:// pattern，与运行时校验形成双重约束；src/vulnplatform-vuln.js 移除 vulId / standardVulId 的 Number() 包装，直接透传上游值以保留 int64（字符串形式）精度；测试新增 int64 精度保留用例和 http 拒绝用例；README 更新了 HTTPS 要求说明。 关键设计决策：运行时校验（endpoint）+ schema pattern 双重保障；skipTlsVerify 仅针对自签名证书场景，仍需 https: 协议，不削弱进程级 TLS 策略。int64 透传符合 protobuf JSON 中 64 位整数以字符串表示的约定，是正确性修复。 整体评估：变更方向正确、实现简洁、测试覆盖了新增行为（int64 字符串保留、http:// 拒绝），并解决了既有的历史安全发现（apiBaseUrl 允许 http 导致 token 明文传输）。仅存在边际级别的 schema/运行时校验一致性差异（如 schema 允许含内嵌凭据的 https URL、大小写方案差异），均由运行时校验兜底，不构成可操作的高置信问题。未发现需要报告的新增缺陷。 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本变更放宽了 Vulnerability Management Platform 适配器的 apiBaseUrl 校验：在原先“必须 HTTPS”的基础上，额外允许对回环地址（localhost / 127.0.0.1 / [::1]）使用明文 HTTP，以便本地测试端点使用；非回环的明文 HTTP 仍被拒绝，且仍禁止 URL 内嵌凭据。改动同时更新了 config.schema.json 的 pattern、错误提示、README 说明，并新增了相应测试。运行时校验（client.js 的 endpoint()）基于 WHATWG URL 解析后的 protocol/hostname 做白名单判断，逻辑严谨，未发现可绕过的路径；测试覆盖了允许/拒绝的关键分支。总体评估：实现扎实、安全边界清晰，无高危缺陷。仅有两处低危改进空间：(1) schema 正则与运行时校验构成两套重复且已出现细微分歧的安全白名单（大小写敏感差异、schema 的 https 分支仍可放行内嵌凭据、缺少对 schema pattern 的测试），存在未来漂移风险；(2) 以主机名 localhost 作为回环信任依据而未在校验时解析确认其指向回环网段，属于纵深防御层面的小缺口。 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次变更是一组面向传输安全加固的改动：1) src/client.js 的 endpoint() 从明文 HTTP 回环例外中移除 localhost 与无括号的 ::1（后者在 WHATWG URL 序列化下本就永不匹配，属冗余），仅保留字面量 127.0.0.1 与 [::1]；运行时同时通过 url.username/password 拒绝内嵌凭据，且校验在 PlatformClient 构造期即抛 FAILED_PRECONDITION，不会发出任何请求。2) config.schema.json 删除 apiBaseUrl 的 URL pattern，将 HTTPS/回环/凭据约束完全下放到运行时，并在 description 中同步说明。3) 测试与 README 相应更新，新增 localhost 被拒与内嵌凭据被拒的断言，127.0.0.1/[::1] 的放行用例保留。整体评估：核心改动正确，此前的历史发现（信任 localhost 主机名作为回环依据）已被本次变更消除——localhost 现在一律要求 HTTPS；未发现绕过运行时校验的路径（URL 解析器规范化后 hostname 精确匹配，凭据、DNS 重绑定、非常规 IPv4 写法等均不会产生非回环放行）。唯一值得关注的弱化点是 schema 层校验的移除：任何仅依赖 config.schema.json 做配置预检的环节将不再能提前拦截明文 HTTP 非回环或内嵌凭据 URL，错误推迟到运行时暴露；该点已作为低严重度安全发现提交。 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本变更在 config.schema.json 的 apiBaseUrl 上重新加入了传输安全校验 pattern（强制 HTTPS，或仅放行 127.0.0.1/[::1] 字面回环地址的 HTTP，并拒绝内嵌凭据），同时在测试中从 schema 读取该 pattern 并与 client.js endpoint() 运行时校验做一致性断言。整体方向正确，修复了此前删除 pattern 导致的 schema 层提前校验回退（对应历史发现）；运行时 endpoint() 仍是最终安全底线，未发现凭据或明文 HTTP 绕过，安全属性（拒绝明文非回环、拒绝内嵌凭据）在 schema 层与运行时保持一致。发现一个低严重度的功能正确性偏差：该正则与 WHATWG URL 解析的规范化行为不一致，导致部分运行时合法接受的配置会被 schema 层误拒绝（例如大写 scheme 的 HTTPS://host、http://[0:0:0:0:0:0:0:1]:19001 全写形式回环 IPv6）。该偏差方向是过度限制而非放宽，不影响安全底线，但会造成 schema 层（配置 UI/CI 预检）与运行时行为不一致，且新增测试的固定样例恰好未覆盖这些偏差方向。 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次改动仅涉及 vulnplatform 服务的客户端 URL 校验与其测试。client.js 中 endpoint() 的校验逻辑被重写：从"基于 new URL() 规范化后的 url.protocol / url.hostname 判断"改为"对原始字符串做字面匹配"（raw.startsWith("https://") + 针对原始 raw 的正则），目的是与 config.schema.json 中预先存在的 pattern 对齐（该 pattern 要求 scheme 小写、回环 HTTP 仅接受字面 127.0.0.1 与 [::1]）。测试文件新增了 3 个被拒绝用例：HTTPS://...、HTTP://127.0.0.1:19001、http://[0:0:0:0:0:0:0:1]:19001。 总体评估：新校验在安全方向上仍然成立（HTTP 仅限回环、拒绝内嵌凭据、HTTPS 放开主机名，未发现可被绕过的 SSRF/凭据泄漏路径）。但改用原始字符串字面匹配引入了两处过度收紧的行为回归：1) scheme 大小写敏感，拒绝 RFC 3986 规定的合法 URL（HTTPS:// 与 HTTP:// 形式），而 new URL() 与 fetch 均会将其规范化为小写，旧代码可接受；2) 拒绝完整形式 IPv6 回环地址 [0:0:0:0:0:0:0:1]（等价于 [::1]），与"HTTP 仅允许回环"的策略本意相悖。两处回归均被新增测试固化为期望行为。建议基于规范化的 url.protocol / url.hostname 做校验，而非对原始字符串做字面匹配。 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次变更放宽了 Vulnerability Management Platform 服务 apiBaseUrl 的 URL 校验，目标是「接受规范化/大小写不敏感的 URL 形式」，并修复此前拒绝 HTTPS://（大写 scheme）与完整形式 IPv6 回环地址 http://[0:0:0:0:0:0:0:1] 的过严回归。 变更内容：
总体方向合理，修复了过严回归。但发现一处 schema 与运行时校验不一致：运行时改用规范化 hostname / protocol 后，会额外接受 schema 仍然拒绝的非字面回环地址（如 http://0x7f000001、http://127.1、http://2130706433）以及缺少 // 的非规范 scheme 形式（https:example.com、http:127.0.0.1）。这些输入能通过 endpoint() 却无法通过 config.schema.json 的 pattern，运行时门禁比文档化的配置契约（literal 127.0.0.1 and [::1]）更宽松。虽然目标主机仍是回环、无 SSRF 逃逸，但属于纵深防御与审计一致性的回归，建议让运行时与 schema 采用同一套字面形式约束并补充边界回归测试。 |
| const raw = text(value).replace(/\/+$/, ""); | ||
| try { | ||
| const url = new URL(raw); | ||
| const secureHTTPS = url.protocol === "https:"; |
There was a problem hiding this comment.
运行时 endpoint() 校验比 config.schema.json 更宽松，接受 schema 拒绝的非字面回环地址与非规范 scheme 形式
secureHTTPS 由原来的 raw.startsWith("https://") && url.protocol === "https:" 改为仅检查 url.protocol === "https:"；loopbackHTTP 由对原始串的字面正则（^http://(?:127.0.0.1|[::1])...）改为比较 URL 规范化后的 hostname。WHATWG URL 会做主机名/地址规范化：http://0x7f000001、http://127.1、http://2130706433 的 hostname 均规范化为 "127.0.0.1"，http://[::0:1] 规范化为 "[::1]"，https:example.com、https:/example.com 也会被 new URL() 规范化为 https://example.com/。因此这些输入现在都能通过客户端运行时校验。但 config.schema.json 的 pattern 仍只接受字面的 127.0.0.1 与特定 IPv6 回环文本形式，且要求 scheme:// 前缀，导致 schema 拒绝而运行时接受的校验分歧。当配置绕过 schema（例如以编程方式构造 PlatformClient）时，运行时门禁会接受混淆形式的回环 HTTP 地址，削弱 config.schema.json 描述中“HTTP 仅允许字面 127.0.0.1 和 [::1] 测试端点”这一文档化策略。目标主机仍为回环、无 SSRF 逃逸，但这是纵深防御与校验一致性/可审计性方面的回归。
Problem code:
Changed code at services/vulnplatform__vulnerability-management_v3-2-0/src/client.js:40-41
Recommendation:
让运行时与 schema 采用同一套字面形式约束：secureHTTPS 需同时满足 /^https:///i（大小写不敏感的字面 scheme:// 前缀），loopbackHTTP 需同时满足「原始串 authority 为字面 127.0.0.1 或带方括号的 IPv6 字面量」与「规范化 hostname 为回环」。同时补充针对 http://0x7f000001、http://127.1、http://2130706433、https:example.com 等边界输入的回归测试，固定 schema 与运行时行为一致（或明确统一策略后同步修改 schema）。
Suggested diff:
--- a/services/vulnplatform__vulnerability-management_v3-2-0/src/client.js
+++ b/services/vulnplatform__vulnerability-management_v3-2-0/src/client.js
@@ -38,7 +38,10 @@ function endpoint(value) {
const raw = text(value).replace(/\/+$/, "");
try {
const url = new URL(raw);
- const secureHTTPS = url.protocol === "https:";
- const loopbackHTTP = url.protocol === "http:" && (url.hostname === "127.0.0.1" || url.hostname === "[::1]");
+ const secureHTTPS = url.protocol === "https:" && /^https:\/\//i.test(raw);
+ const loopbackHTTP =
+ url.protocol === "http:" &&
+ /^http:\/\/(?:127\.0\.0\.1|\[[^\]]*\])(?::[0-9]+)?(?:[/?#]|$)/i.test(raw) &&
+ (url.hostname === "127.0.0.1" || url.hostname === "[::1]");
if ((!secureHTTPS && !loopbackHTTP) || url.username || url.password) throw new Error("unsupported URL");
return raw;
} catch {
|
PR Title: feat: add vulnerability management platform servic... Commit: 本 PR 收紧了 vulnplatform 客户端 endpoint() 的 URL 校验规则：1) HTTPS 分支现在要求原始字符串以字面 |
|
PR Title: feat: add vulnerability management platform servic... Commit: 本次变更收紧 vulnplatform 客户端 endpoint() 对 HTTPS URL 的校验。原先 secureHTTPS 仅检查 url.protocol === "https:" 且 raw 以 https:// 开头，导致 WHATWG URL 可解析但主机名为空的畸形形式（https:///path、https://:8443/path 等）被误判为安全 URL 并通过校验。改动后增加 /^https://[^/]/ 正则（要求 // 后紧跟非 / 字符）与 Boolean(url.hostname)（要求解析出非空主机名）两个条件，彻底关闭空主机 HTTPS 形式。测试新增 "https://"（经尾斜杠剥离后 new URL 解析失败）、"https:///path"（[^/] 拒绝）、"https://:8443/path"（主机名为空拒绝）三个被拒用例，并与 config.schema.json 的 pattern 断言保持一致。 核对结论：
|
4 participants
Summary
Add a new OctoBus Service adapter for the Vulnerability Management Platform (v3.2.0).
Changes
New Service:
examples/vulnplatform-vuln/proto/vulnerability.proto — 3 gRPC services, 16 methods:
VulnerabilityService: List, Create, Update, Delete, Timeline, Types, GraphQL queryAssetService: List groups, IP/Web/Repo/Component/Container assetsIntelligenceService: List, Create, Delete standard vulnerabilitieslib/token-generator.js — Token generation via Java subprocess calling
vms-auth-sdk-2.1.0.jarlib/platform-client.js — Full API client with login, token caching (25min), and all platform API methods
bin/vulnplatform-vuln.js — OctoBus handler with data transformation (snake_case ↔ camelCase)
service.json, package.json, secret.schema.json, README.md — Configuration and documentation
Authentication Flow
appId+dateTime+key+account)/api/login2with token to get Bearer tokenNotes
vms-auth-sdk-2.1.0.jarfrom the vendor for token generation