平台雷达PLFM_RADAR：资产发现、SBOM审计与运行态异常检测实战

说实话，这两年“平台工程”火得一塌糊涂，但我见过太多团队把精力全砸在给开发者建门户、抽公共组件上，却连自己平台里到底跑了哪些服务、每个服务用了哪些第三方依赖、有没有密钥被误提交到仓库，都答不上来。这就像你住在一栋自己盖的楼里，却不知道墙里埋了多少根水管、哪根已经锈透了。我们内部代号为 PLFM_RADAR 的系统，就是为解决这个问题做的——它是一台持续运转的“平台雷达”，负责把平台自身的资产、依赖、敏感信息与运行异常全部“照”出来。这篇文章想把我们踩过的坑、想明白的原理、沉淀下来的配置，完整分享给同样在维护业务平台或基础设施的工程师。

PLFM_RADAR 这名字拆开看就是 Platform Radar，平台雷达。它适合谁？适合那些服务数量超过五十个、环境越来越复杂、每次安全检查都要靠人工拉 Excel 的团队。也适合刚准备开始做资产盘点、安全合规、供应链风险治理，但不知道从哪里下手的同学。如果你已经上了比较成熟的扫描工具，那这篇文章里的架构思路、告警分级和踩坑记录，同样有参考价值。

在开始之前先给你一个结论：PLFM_RADAR 的价值不在某一次扫描能发现多少问题，而在于它能把“平台动态”变成一条持续更新的基线，再拿每一次新扫描的结果和基线做对比，发现增量偏差。这个思路贯穿了整体设计和所有模块的实现，也是我建议你参考它时最应该先理解的一点。

1. 为什么需要一台“平台雷达”：拆解核心痛点与设计目标

1.1 从资产清单失控说起

PLFM_RADAR 这个项目最初的触发点，并不像很多安全产品那样来自一次攻击事件，而是来自一个特别尴尬的会议。当时业务方问我们：生产环境一共多少个对外服务？每个服务的域名、端口、数据库实例都是什么？结果在场的六个人给出了五个不完全一样的答案，因为维护者手里的 Excel、CMDB 系统、云厂商控制台里的数据各差了一截。

这个问题非常典型：当平台演进到一定规模后，资产生命周期变得极短，今天用容器编排平台拉起一个新服务只要几分钟，明天下线一个老服务也可能只是一条指令的事。靠人工更新 CMDB 早就跟不上节奏了，更不用说那些临时用于联调、压测、灰度验证的资源，用完没有回收，悄悄地躺在某个角落继续产生费用、暴露端口。PLFM_RADAR 要解决的第一个问题，就是让资产清单与真实环境自动对齐。

你可能觉得，一个普通的网络扫描器不就能扫出来吗？确实，端口扫描、子域名枚举都能做。但平台雷达需要的不只是“扫出来”，而是要把扫描结果和已知资产做交叉比对，识别出新增、变更、消失三类状态，这样团队才知道哪些是计划内的变化，哪些是需要警惕的“陌生资产”。

1.2 设计目标：扫描、感知、盯异常

命名成 RADAR，有意识的联想是“雷达一直在转，而不是照一张照片”。我们最终确定的产品形态包含三条核心能力线：

第一是持续盘点，也就是定期的资产发现与指纹识别，回答“平台现在长什么样”；第二是脆弱性感知，包括第三方依赖漏洞、容器镜像问题、敏感信息泄漏，回答“当前状态有没有已知风险”；第三是异常行为探测，比如非预期端口开放、可疑的进程启动、容器突然和陌生域名通信，回答“有没有超出预期的运行时行为”。

这三条能力线的共性，是都依赖“持续对照基线”的雷达原理。比如一个服务今天开了 8080 端口，这是它的业务端口，雷达会记录成正常端口；但明天它额外多了 6379 端口，雷达就能立刻标成可疑事件，因为 Redis 不应该暴露在这个服务的公网入口上。静态扫描只能发现“开了 6379”，而雷达能告诉你“这个变化不合常理”。这种基于时间维度的偏差检测，是我们在设计每一个子模块时都刻意坚持的。

2. 整体架构与关键选型：看清雷达是怎么运转的

2.1 四层架构：采集、处理、存储、告警

PLFM_RADAR 整体上分成了四层：采集层、处理层、存储层、告警与展示层。这个分层没有刻意去追求微服务复杂度，而是从数据流自然长出来的：数据从多个来源进入，经过清洗和规则判断，变为可查询的结构化记录，最终通过告警通道触达责任人。

采集层包含三类东西：第一类是二进制采集代理，我们用 Go 写了一个很轻量的 agent，部署在各台主机和容器节点上，负责收集进程列表、网络连接、端口监听这些操作系统层面的数据；第二类是平台侧扫描器，比如用来做子域名枚举、Git 仓库密钥扫描、镜像与依赖漏洞扫描的任务型组件，它们不需要常驻业务节点，按调度计划拉起即可；第三类是外部数据接口，包括云厂商资源列表、内部 DNS 记录、容器编排平台 API，这些都是获取“权威资产列表”的重要数据源。

处理层最核心的是一个规则引擎和一套任务调度器。任务调度器管的是“什么时候跑哪个扫描任务”，规则引擎负责把采集到的数据变成有语义的事件。比如采集代理上报了一条“本地进程访问了某个外部 IP”，规则引擎要结合威胁情报、历史基线、所属服务上下文来判断，这到底是正常业务调用还是可疑行为。

存储层我们是分了两类数据：关系型数据库存资产元数据、扫描任务状态、告警记录；Elasticsearch 存扫描原始结果和事件日志，方便做全文检索和聚合分析。这两类数据的使用场景差别很大，混在一起会互相拖累性能。告警与展示层则是通过 Webhook 推到即时通讯工具的告警机器人，同时在 Grafana 上做资产趋势大盘。

2.2 为什么不用单一 Agent，而是“Agent 加平台侧扫描”混搭

这是我被问得最多的问题：既然每台机器上都能装 agent，为什么不干脆全让 agent 干活？答案是成本和权限的平衡。

二进制 agent 适合做“需要持续观察”的数据收集，比如进程、端口、网络连接的变化，这类信息必须实时或准实时地暴露出来，才能支撑偏差检测。但 agent 不适合做重扫描，比如对一个几十 GB 的仓库跑一次完整密钥历史扫描，或者对镜像层做漏洞检索，这种任务计算量大、持续时间长，放在每台业务节点上会很干扰正常业务，更应该由平台侧专门的扫描器集群来执行。

混搭的另一个原因是权限模型更干净。业务团队不希望平台雷达的 agent 拥有读取任意代码仓库的权限，这在合规上也说不过去。所以代码仓库扫描、依赖项审计这类任务放在平台侧，由独立服务账号执行，并保留审计日志。两部分数据最终在存储层汇合，以资产 IP 或服务名作为关联键。

3. 核心功能拆解：雷达到底扫什么，怎么扫

3.1 资产清单发现：不只是 IP 和域名

资产清单发现是整个系统的基础，基础到很多人会低估它。PLFM_RADAR 里资产发现的数据源大概有五种：云厂商资源 API、内网 DNS 区域传送与枚举、容器编排平台 API、TLS 证书中的 CN/SAN 字段、网络层主动探测。这五种源各有侧重，互为补充。

云厂商资源 API 能给出最权威的虚拟机和负载均衡列表，但它不知道哪个 IP 对应哪个业务域；DNS 枚举可以发现大量不在 CMDB 里的子域名，因为很多开发环境会随手加一条 DNS 记录；容器编排平台 API 能看到工作负载的暴露方式，比如哪些 Service 把端口映射到了节点；TLS 证书则是一个“被动指纹库”，通过证书名称能反推资产的业务归属。主动探测放在最后，它只用来兜底，避免漏掉那些没有任何已知元数据、却真实存在监听端口的“影子资产”。

在实现上，我们把五种来源的数据合入一张assets表，每条资产记录都带来源标签和首次发现时间。调度器周期性执行一次“全量发现”，然后把结果和上一次快照做差集计算，产出asset_added、asset_changed、asset_removed三类事件。这里有个特别容易踩坑的细节：直接比对 IP 列表会误报频繁，因为云环境的公网 IP 经常会因重建而变化。我们选择以“域名加服务名”作为稳定标识，IP 只作为属性字段，这样才把误报降到能看的水平。

# 资产差异计算的核心思路（伪代码） old_assets = load_previous_snapshot() new_assets = load_current_snapshot() key_func = lambda asset: asset["service_name"] + "/" + asset["domain"] diff_set = compute_diff(old_assets, new_assets, key=key_func) for series in diff_set["removed"]: create_event("asset_removed", series, severity="info") for series in diff_set["added"]: create_event("asset_added", series, severity="info") for series in diff_set["changed"]: create_event("asset_changed", series, severity="warning")

实际过程中，asset_changed的判定要小心。我们规定只有“监听端口集合变化、对外开放方式变化、部署地域变化”这类有安全语义的变更才算changed；像镜像 tag 从 v1.0 变成 v1.1 这种更新频率较高的字段，不算资产变更，避免把雷达变成一台噪音制造机。

3.2 依赖与 SBOM 审计：把漏洞找在发布之前

供应链安全是最近几年安全圈最热的话题，PLFM_RADAR 在这块做的不是简单的“用 Trivy 扫一遍镜像”，而是把 SBOM（软件物料清单）的理念向前推了一步，把漏洞卡点推进到 CI 阶段，同时又在夜间任务里做全量补充扫描。

我们的做法分三步。第一步，在构建流水线里生成 SBOM。如果你的项目是 Go 写的，可以用syft或trivy fs --format cyclonedx直接把文件系统、镜像里的依赖列表提取成标准格式。第二步，把 SBOM 提交到平台侧，由 PLFM_RADAR 的漏洞匹配服务去比对漏洞库，这里我们同时用了本地漏洞库和在线漏洞服务，在线服务的优势是响应更快，零日漏洞披露后几小时就能同步，本地库的优势是内网环境下稳定可控。第三步，给 CI 设置一个“失败阈值”。如果发现高危及以上漏洞，并且没有已接受的风险记录，构建直接失败。

很多团队会说“这样会不会太严格，导致发布被阻塞”。所以我们在做准入规则时留了两个后门：一是只对生产发布分支强制执行，二是允许安全团队在漏洞数据库里维护“已确认不影响本平台”的例外清单。比如某个漏洞虽然 CVSS 评分很高，但攻击路径依赖特定的运行方式，而我们的环境中根本不具备该条件，这种情况就可以走例外流程。

# 在 CI 中生成 SBOM 并上传（示意） trivy fs --format cyclonedx --output sbom.json . curl -X POST https://radar.internal/api/v1/sbom \ -H "Authorization: Bearer $RADAR_TOKEN" \ -F "service=payment-api" \ -F "env=prod" \ -F "file=@sbom.json"

这里我必须提醒一句：SBOM 的版本匹配特别容易出问题。很多项目直接拉取依赖包最新版去做哈希匹配，但同一份代码在不同时间构建，依赖的补丁版本可能悄悄升级过。如果平台侧的基线库没有跟着更新，你再拿旧 SBOM 去对漏洞库，全是无效记录。所以我们的做法是生成 SBOM 时把精确版本号、commit hash、构建时间都带上，并且每天晚上定时清理七天前的临时构建产物。

3.3 敏感信息巡检：密钥泄漏的亡羊补牢

密钥泄漏这个议题，几乎每个团队都遇到过几次。代码仓库里躺着 AWS Access Key、数据库密码、内部网关密钥的明文记录，时间越久越难清理。PLFM_RADAR 的敏感信息巡检模块，没有自己造轮子，而是在 Gitleaks 规则基础上做了两层增强。

第一层增强是规则库裁剪与本地化。Gitleaks 自带数百条规则，覆盖面很广，但默认规则对我们的场景会产生大量误报。比如它默认会匹配 AWS AKIA 开头的密钥，但我们有很多测试代码里本来就写了 fake 前缀的示例，需要改成白名单匹配。更关键的是我们加了自己的内部规则：基于公司内部密钥格式和常见配置文件名去扫描，比如特定配置中心的 Token 前缀，这类内部格式只有自己知道，通用工具扫不到。

第二层增强是扫描范围管理。我们启用了三档扫描：全量历史扫描（只在仓库首次接入和季度核查时跑）、增量扫描（每次 push 后跑变更文件）、定时扫描（每晚扫最近七天变更的分支）。全量历史扫描很费时间，一个中型仓库可能要跑二十分钟，所以不能做成常规任务，增量扫描才是日常主力。

# 基于 Gitleaks 的增量扫描示例 gitleaks detect --source . --log-opts="--since=7d" --report-format=json --report-path=leaks.json # 或者在 CI 中针对 MR 变更内容扫描 gitleaks detect --source . --log-opts="origin/main...HEAD"

处理敏感信息告警时，我们内部有一条铁律：检查到真实密钥，立即通知安全负责人，并且要求在一个小时内轮换密钥。轮换完成后，还要回到仓库历史里把密钥从所有历史 commit 中抹除，否则攻击者依然可以从旧版本代码里找到它。很多团队只在最新代码里把密钥删了，历史 commit 里还留着，这等于白干。

3.4 运行态异常探测：雷达不只是“静态扫描仪”

如果说前面几个模块都偏向“静态”，那运行态异常探测才是让 PLFM_RADAR 真正有“雷达”感觉的部分。部署在各节点上的 agent 会持续采集进程列表、监听端口、主动外连目标、关键文件变化，然后送到规则引擎做实时分析。

规则引擎的核心是一批“基线化”的模型。具体做法是：生产环境跑稳定一段时间后，agent 把每个服务在一周内的端口、进程、连接数做统计，形成“正常区间”。这个区间不是死的，而是动态更新的，但要加阻尼，防止恶意行为快速污染基线。在动态基线上，我们叠加了少量专家规则，比如：某个服务突然监听了数据库端口、某个服务尝试连接外部矿池域名、某个容器里出现了明文脚本调用内部接口，这些规则命中后直接产生高危告警。

我简单写一个规则示例的思路，用伪代码表示：

def check_service_ports(service_id, current_ports, baseline_ports): unexpected_ports = set(current_ports) - set(baseline_ports) sensitive_ports = {6379, 3306, 9200, 27017} # redis/mysql/es/mongo if unexpected_ports & sensitive_ports: return Alert( severity="high", message=f"{service_id} opened sensitive port(s): {unexpected_ports & sensitive_ports}", ) return None

运行态异常这块，最大的挑战是告警收敛。第一周我们接到的告警里有三分之一是业务方合法的“临时运维操作”，比如压测时短时间提高了连接数、排查问题时临时开启了tcpdump抓包。后来加入了“维护窗口”机制，业务方可以提前在雷达系统里创建一个时间窗口，标注“本时段将执行压测/变更”，窗口期间的相匹配行为自动降级为提示，不发送告警。这个机制上线之后，告警收敛立竿见影，维护人员和安全人员都舒服了很多。

4. 调度、数据分级与告警：让雷达不吵又不瞎

4.1 扫描频率怎么定：不用什么都每天都扫

调度策略直接决定了雷达系统的性价比。很多系统最后被弃用，都是因为“什么都扫，扫得又勤，告警又乱”，最后运维和安全团队自己都麻木了。PLFM_RADAR 的调度设计遵循一条原则：扫描频率和数据变化速度、风险等级成正比。

我们给不同模块定了不同的基准频次：

这组频率不是拍脑袋定的，是拿真实数据调出来的。比如资产发现一开始我们也跑每天一次，后来发现很多临时环境在白天被创建、晚上被销毁，如果不把频率提高到 10 分钟，就看不到它们存在的痕迹。而依赖漏洞全量扫描如果也跑 10 分钟一次，扫描器集群 CPU 会直接被打满，还会和业务发布抢资源，得不偿失。

4.2 告警分诊：严重程度、责任人、闭环

扫描发现一堆问题只是开始，真正难的是让问题被正确的人跟进处理。PLFM_RADAR 的告警模型参考了事故响应里的分级方法：所有告警按严重程度分成 High、Medium、Low 三档，每档有不同的通知策略。High 级通知立刻推送给服务负责人和安全团队，并通过手机推送再加一道强提醒；Medium 级在白天工作时间推送，要求当天内确认；Low 级只在雷达系统的看板里展示，每周汇总一次到周报里。

责任人推导是这里最关键的细节。我们原本以为“扫描结果打到哪个服务的资产，就通知哪个服务的负责人”是顺理成章的事，但实际做下来发现很多告警落在“来源不明的资产”上——雷达发现了问题，却不知道找谁来解决。后来我们给每个资产加上了owner字段，并允许通过三种方式自动推导：从 CMDB 里读服务描述里的负责团队、从容器编排平台的 Label 里取，或者通过 Git 提交历史里对服务配置文件修改最频繁的人来推测。最后一招并不严谨，但用来兜底效果不错。

告警闭环上我们做了一个很轻的状态机：新告警 -> 待确认 -> 处理中 -> 已解决 / 已忽略。所有状态变更都需要留备注，比如忽略时必须写清楚“为什么这不是问题”。这个机制看起来简单，但非常有用，它让团队积累了一套“之前为什么判定不处理”的历史记录，后面做安全审计时直接拉出来看就行。

5. 落地过程中的真实踩坑与排障记录

5.1 踩坑一：SBOM 版本误报，差点封了正常发布

第一个大坑发生在 SBOM 上线后的第一周。我们有一个服务，代码全量依赖扫描报告了高危漏洞，但我们排查后发现漏洞库里的漏洞影响版本范围包含了该依赖的所有版本，而实际上这个漏洞的利用条件在我们平台里根本不存在——容器里没有那个可利用的组件、也没有对应的网络入口。由于我们当时“高危必须拦截”的策略是硬性的，这个服务的发布被卡了两天，业务方意见不小。

后来我们调整了两件事。一是从“高危即拦截”改成“高危加可利用性评分”再决定是否拦截，这个可利用性的评估，我们结合了运行时采集到的数据：服务是否真的暴露了受影响的功能、容器是否具备漏洞描述里提到的场景。二是在例外流程里增加了时效性，一个例外只允许保留三十天，三十天后如果依赖版本还没升级，系统会自动重新打开阻断。这个机制逼迫团队必须把修复排进迭代里，而不是永远挂着一个“已接受风险”的标签。

5.2 踩坑二：敏感信息扫描规则把测试数据当泄漏

第二个坑来自敏感信息扫描的误报淹没。我们的测试环境里，开发者经常随手写类似password: "123456"、secret_key: "test"这样的配置，这些内容本身是为了本地调试方便，不属于真正的密钥，但 Gitleaks 的通用规则库会把它当成可疑信息报出来。上线第一周，我们收到几百条 Medium 级告警，几乎全是测试代码和示例配置。

解决误报，不能简单粗暴地“加进白名单”，因为这样容易把真正的泄漏也白名单掉。我们的做法是给扫描规则增加上下文判断。比如一条疑似密钥的记录，如果同文件里能匹配到测试类关键词（test、mock、example、stub），且没有匹配到生产环境的域名特征，就自动降级为 Low，只记录不通知。真正的密钥通常会和真实域名、真实密钥格式一起出现，各类上下文才能共同指向“这是真货”。

5.3 踩坑三：调度重叠，扫描把自己扫挂

第三个坑就比较经典了，属于基础设施层面的问题。某天下午，调度器一次性触发了十几个全量扫描任务，包括几台扫描器主机上同时跑着资产发现、DNS 枚举、镜像漏洞扫描。结果扫描器的磁盘空间瞬间被日志和中间文件塞满，其中一台直接宕机，导致当轮所有扫描结果丢失，而且因为任务队列里的重试机制，宕机恢复后所有任务又同时重新入队，把系统冲垮了第二遍。

这个故障给了我们三个教训。一是调度器必须加上并发上限，每个扫描任务类型只能同时运行固定数量的实例，超出的排队等待。二是扫描器的工作目录要做磁盘配额和自动清理，每次任务结束之后检查临时文件是否残留，超过一小时的老文件直接删除。三是任务队列要设计熔断：如果某个任务连续失败三次，该任务类型入口自动关闭，只保留报警通知，等人工处理后重新打开。后来这三条都写成了平台侧检查项，每次上线前筛查一遍。

5.4 常见问题速查表

最后整理了我们在运维 PLFM_RADAR 过程中最常被问到的几个问题，直接做成表给你参考。

6. 部署与维护成本：小团队也能跑起来吗

6.1 组件清单与资源预算

很多团队想复制这套方案，又担心成本太高、人手不够。我把我们生产环境的基本资源配置列出来供参考。这套系统依赖的组件不多：核心是 PostgreSQL、Elasticsearch、调度器服务、扫描器工作节点，外加二进制 agent。扫描器节点用容器化部署，可弹性伸缩，夜间全量扫描时临时扩容，白天缩容到一两个副本。

如果你所在的团队规模更小，比如只有三五个后端工程师兼任运维，我建议不要把目标定得太大，可以先从两个模块启动：Git 仓库敏感信息扫描加依赖 SBOM 审计。这两个模块可以完全跑在 CI 里面，不需要常驻 agent，不需要额外存储，成本几乎为零。等团队觉得这套流程确实有价值，再逐步上资产发现和运行态探测。PLFM_RADAR 在最早期的 MVP 版本里甚至只有两个脚本，一个在 CI 里跑 Gitleaks，一个用 Trivy 扫镜像，硬撑了两个多月。

6.2 维护要点：规则库更新、白名单管理、数据保留

系统跑起来以后的维护工作，可能比搭建更需要认真对待。我个人觉得有三件事是必须形成固定节奏的。

规则库更新是安全类系统的生命线。我们的做法是订阅漏洞库和威胁情报的更新流，每周二做一次规则快照更新，更新之前先在预发环境的扫描器上跑一轮回归，确认新规则不会对现有业务产生大规模误报之后，再推送到生产环境。这个习惯救过我们很多次，因为有些第三方规则库的更新会把某些常见的业务域名特征误判为高危连接，直接推送会造成告警洪峰。

白名单管理要设计成可审计的。任何加白名单的操作都要有理由和时效，比如“这个测试密钥是本地 mock 用，永久白名单”和“这个密钥临时出现在仓库里，将在本周内删除”是两种完全不同的情况。我们给白名单记录加了expires_at字段，过期后自动重新激活检测，并且每周把本周新增的白名单列表同步到安全周报里，让所有人看到最近哪些规则被放行了。

数据保留周期上，原始扫描结果我们只保留 30 天，因为 Elasticsearch 存储成本会随着资产规模线性上涨；聚合后的资产变更记录和告警记录则保留一年，作为安全审计和复盘的数据基础。这个保留策略不是省钱的权宜之计，而是基于真实需求倒推的：日常排障要看原始结果只需要看最近一个月的，再久远就直接看结论而不需要看过程。

最后再分享一个我印象很深的小细节：PLFM_RADAR 上线三个月后，我们做了一次红蓝对抗演练，蓝队模拟攻击方在内网执行了一些探测动作。以前这种演练很大程度依赖防守方经验，但那次雷达系统在攻击方刚扫描完端口、还没来得及做下一步动作时，就通过运行态异常探测把它们标记了出来，并把外连目标和敏感端口变化直接关联成一条完整线索。这让我觉得，安全能力真正有效的体现不是某个单点工具多强，而是整个平台能否持续感知自己的状态变化、能否在噪声中抓住那一点点不寻常。如果你们的平台还没有这样一台“雷达”，我建议先从一个最小模块开始跑起来，然后慢慢让数据积累成基线，你会发现平台的很多问题在自己暴露之前，早就有了征兆。