文章总结： BREAK框架从v0.9到v2.23的进化体现在数据量增长（条目从443增至3227）和知识模型重构。核心改进包括：立体化实体关系（区分直接/间接风险关联）、新增1797个真实案例库和600个行业术语表、引入桑基图攻击路径分析等可视化功能。框架支持STIX2.1标准化导出，通过150+验证脚本保障数据质量，致力于成为业务安全领域的基础知识设施。 综合评分： 87 文章分类： 安全建设,技术标准,解决方案,安全工具,漏洞分析

从443到3227：BREAK框架的进化之路

JDArmy

2026年6月23日 23:39 新疆

在小说阅读器读本章

去阅读

以下文章来源于梦之光芒的电子梦 ，作者Monyer 梦之光芒

梦之光芒的电子梦 .

这里会不定期发布一些安全从业经验和感悟，谢谢关注！ 知乎请关注：Monyer 微博请关注：@monyer

JDArmy BREAK v2.23 正式发布

说实话，从 BREAK 框架发布至今的几年里，我们自己也没预料到BREAK会走到今天这个样子。

2024年9月，BREAK还是一个v0.9的”知识清单”——196个风险点、140个规避手段、68个攻击工具、39个威胁行为者，再加14个业务场景。功能上就是一个JSON驱动的静态网页，能看，能查，仅此而已。

现在，v2.23。285次提交，26万行代码变动。

350个风险、300个规避手段、110个攻击工具、70个威胁行为者、600个行业术语、1797个典型案例、18个业务场景。 总条目从443增长到3227——但数字增长只是表象，真正的变化在水面之下。

这几年，业务安全的世界变了

写这篇文章之前，我回头翻了翻，自2022年发布0.1版以来，到2026年这段时间，业务安全领域还是发生了很大的变化。

最大的变量是AI。 不是那种”AI是未来”的泛泛而谈，而是AI真的开始被黑灰产拿来用了。深度伪造过人脸核身、大模型生成钓鱼话术、AI批量注册养号——这些已经不是安全会议上的PPT概念，而是真实的对抗场景。影子AI风险、AI内容溯源、智能体行为沙箱……这些我们在v2.0前后陆续加进来的规避手段，每一个背后都对应着实实在在的攻防案例。目前BREAK中AI相关的风险条目已经有37个，横跨金融、电商、社交、政务等多个业务场景。

第二个变量是新兴领域的爆发。 Web3和区块链不再是少数极客的玩具。DeFi闪电贷攻击、跨链桥安全事件、智能合约重入漏洞、Rug Pull——这些词从币圈黑话变成了安全团队必须关注的风险面。我们新增了Web3与区块链（BS15）、物联网（BS16）、元宇宙（BS17）三大业务场景，补充了23个区块链相关风险、23个物联网风险、10个元宇宙风险。光是行业术语就新增了600个，其中区块链相关的有15个专业术语（智能合约、DeFi、NFT、DAO、Layer2、跨链桥、闪电贷……），不是为了蹭热点，而是因为做业务安全评估的人真的需要一套统一的术语体系。

第三个变量是智能汽车。 新能源车的渗透率已经过半，车联网安全、自动驾驶对抗、V2X通信风险不再只是车厂关心的事。我们在汽车场景（BS11）下新增了车联网和自动驾驶相关的风险条目，虽然数量不多（6个），但代表了BREAK从纯互联网业务向物理世界延伸的方向。

业务安全的边界在扩大。框架如果不跟着扩大，就会被甩在后面。

不只是”加数据”——我们重构了知识模型

说完外部变化，说说内部的事。

如果只是往JSON文件里塞更多条目，那不叫进化，叫填表。我们做的最重要的决策是 重构知识模型本身。

关系从”扁平”走向”立体”

v0.9时代，实体之间的关系是单一的。风险有规避手段，攻击工具造成风险，威胁行为者使用工具——就这么简单。

现在呢？我们把”造成风险”拆成了 directCauseRisks（直接造成） 和 indirectSupportRisks（间接支撑），这不是咬文嚼字。一个DDoS工具对服务中断是直接造成关系，但对交易数据篡改可能只是间接支撑——区分这两者，对安全评估的优先级判断完全不一样。

我们还给每类实体加上了 横向关系：风险之间有relatedRisks，规避手段之间有relatedAvoidances，攻击工具之间有relatedAttackTools，威胁行为者之间有relatedThreatActors。每组横向关系按共同连接数自动派生Top 6，由脚本维护而非人工编辑。一个DDoS攻击工具和一个CC攻击工具可能共同关联5个风险——这种”同行关系”在做攻击面分析时非常有价值，但此前的模型里根本表达不了。

规避手段新增了 effectiveness（有效性分级） 字段。同样是应对撞库攻击，多因素认证和IP限速的有效性显然不在一个量级。有了有效性分级，安全团队做规避方案时就有了优先级参考。

1797个案例：让知识框架”接地气”

这是v2.15引入的全新实体类型。1797个典型案例，涵盖刑事判决、行政查处、安全事件、漏洞通报、学术研究和新闻报道六大类别。

说句实在话，最初我们对要不要加案例是犹豫的。案例数据量大、质量参差不齐、维护成本高——但用户反馈让我们改变了想法。很多人说：”我知道这个风险存在，但我需要一个真实案例来说服老板立项。”

每个案例至少关联一个风险，可选关联攻击工具和威胁行为者。我们没有让案例进入关系图谱（1797个节点会直接压垮布局），而是在风险详情页通过倒排索引做反查——你看一个风险，往下拉就能看到相关的真实案例。数据通过懒加载管理，首页不会去拉3MB的案例数据，只在你真正需要的时候才加载。

案例的来源我们也在持续治理。批量采集用的是Scrapingdog多引擎搜索配合大模型提炼复核，但最终入库前有去重、质量审计和来源分级。目前高价值案例的primary source覆盖还在持续补强中——这事急不得，每一条链接都要确认可达且权威。

600个行业术语：统一安全团队的语言

“撞库”和”凭证填充”是一个意思吗？”薅羊毛”英文怎么说？”闪电贷”到底是什么？

业务安全领域有太多的黑话、缩写和跨语言术语，团队协作时经常鸡同鸭讲。600个行业术语，每个都有定义、描述、使用场景示例，还关联了相关的风险、规避手段、攻击工具和业务场景。

这不是一本词典。是让安全团队、风控团队和业务团队能在同一套语言下对话的基础设施。

看得见的变化：可视化、交互与体验

知识模型的进化需要配套的呈现方式。过去21个月里，前端经历了从”能看”到”能用”再到”能分析”的三级跳。

关系图谱：从展示到推理

关系图谱从D3.js迁移到ECharts，带来了更好的渲染性能和交互体验。但更重要的是可视化逻辑的进化：

桑基图攻击路径分析——这是v2.14引入的核心功能。你可以选一个威胁行为者或攻击工具作为起点，看到”威胁行为者→使用攻击工具→造成风险→需要规避手段”的完整攻击链路。每段路径都标注了成立原因和来源字段——是”直接造成”还是”间接支撑”？是”自建工具”还是”使用工具”？路径还支持按四个维度继续筛选，不是让你看一张复杂的图，而是帮你做攻击面的缩小和聚焦。

规避覆盖面板——选中一个风险节点，右侧面板会展示它有哪些规避手段，其中哪些是风险自身的、哪些来自相关攻击工具，以及两者的重叠来源。安全负责人看一眼就知道防御有没有漏洞。

关系可解释性——每条关系线都有人类可读的解释文本、证据等级和影响分析。不只是告诉你A和B有关系，而是告诉你为什么、关系有多强、影响面有多大。

全面移动端适配

安全评估不是只在办公桌前做的。现场检查、客户沟通、应急响应——很多场景需要在手机上快速查阅。我们做了完整的移动端适配：关系图可平移缩放、知识库列表返回时保持滚动位置、历史记录支持……每一个细节背后都是用户真实反馈。

移动端的性能也经过了Lighthouse基线验证。Sankey关系页的LCP从5.7秒优化到2.3秒，靠的是路由预取分流、i18n按需加载和首屏骨架先行等一系列工程手段。

暗色模式与全文搜索

暗色模式支持亮色/暗色/跟随系统三种模式，包括Canvas画布的主题同步——听起来简单，实现起来涉及ECharts实例销毁重建和大量CSS变量联动。

全文搜索支持1字符起搜，覆盖全部7类实体，结果按分组展示。搜索高亮我们还修了一个XSS漏洞——搜索结果的v-html渲染如果不做HTML转义，来自外部JSON的文本可能被注入恶意代码。这种安全问题不大也不小，但作为一个安全框架，被搜索XSS打穿实在说不过去。

水面下的工程

说几件用户看不见、但决定了框架能不能持续演进的事。

i18n架构重写

早期的英文翻译是把中文JSON整个复制一份然后翻译——字段齐全，但维护噩梦。一个风险新增一条规避手段，要改中文文件和英文文件两处。

现在的架构是 单一数据源+运行时合并。中文src/BREAK/是结构和关系的唯一来源，英文src/i18n/en/BREAK/只维护可翻译文本（title、description、keywords等）。运行时由mergeWithStructure函数合并：结构取中文，文本取英文。改一个风险的规避手段？只改中文文件。英文翻译缺了？中文兜底。

配套的校验脚本会检查英文翻译有没有误写结构字段、有没有中文残留、有没有模板化占位文本。npm run validate:data一跑就知道i18n是否健康。

构建产物不再入库

这件事可能只有做过GitHub Pages的人才能体会痛苦。此前我们把构建产物（docs/目录）提交到Git里，仓库随迭代膨胀到218MB。v2.20把构建产物完全移出版本库，改由GitHub Actions自动构建部署。仓库瘦身之外，更重要的是消除了”本地构建产物和源码不同步”这类幽灵Bug。

STIX 2.1 & JSON-LD 标准化导出

v2.23新增的能力。将全部7类实体和26,000+关系边映射为合法的STIX 2.1 Bundle，同时支持JSON-LD语义网格式。中英文双Bundle导出，UUID使用v5确定性生成——同一个实体在中文和英文Bundle里有相同的ID。

为什么做这个？因为BREAK不应该是一个孤岛。企业的SIEM、SOAR、CTI平台如果想消费BREAK的知识，用STIX是最自然的方式。JSON-LD则面向知识图谱和RDF/SPARQL场景——比如你想用SPARQL查”所有与DeFi相关且规避手段有效性为高的风险”，导入JSON-LD就能做到。

150+验证脚本和门禁

数据schema校验、关系悬空检查、英文翻译同步、关键词规范审计、引用链接可达性检查、业务场景覆盖校验、bundle预算门禁、Lighthouse性能基线、关系图谱稳定性回归……这些验证脚本串成了一条完整的质量门禁链路。每次构建（npm run build）都会自动跑完，CI和Deploy也是同样标准。

听起来像过度工程化？但当你有3227个条目、26000+关系边、中英文双语数据时，人工review早就靠不住了。一个漏掉的avoidance引用、一个拼错的实体ID、一个英文文件里的中文残留——任何一个都可能在用户那里表现为”数据不对”。工程化是唯一的出路。

一些思考

做BREAK这一年多，有几点感受想分享。

第一，业务安全的知识是需要”版本管理”的。 安全威胁在变，防御手段在变，行业格局在变。一个两年前标注为”高复杂度”的风险，可能因为攻击工具的普及而变成”中级”；一个曾经有效的规避手段，可能因为新攻击技术的出现而需要更新。框架不是写完就放在那里的——它需要像软件一样持续迭代。我们给每个实体加了version字段和updated字段，用auto-version脚本自动追踪变更，就是这个道理。

第二，结构化比堆数量重要。 3227个条目如果只是堆在那里，价值有限。真正的价值在关系——风险和规避手段的映射、攻击工具和威胁行为者的关联、同类实体之间的横向连接。26000+关系边，每一条都是可查询、可推理、可导出的结构化知识。

第三，开放才有生命力。 BREAK的数据是JSON，schema是公开的，导出格式用的是国际标准（STIX 2.1），API用npm包分发，搜索引擎是零依赖的Python脚本。我们不想做一个封闭的”框架”，而是想做安全团队工具链中的一个可插拔的知识节点。

下一步

坦白说，BREAK还有很多不完美的地方。引用链接的健康治理还在继续，高价值案例的权威来源覆盖还不够，关系页的工程债需要持续还，可视化从”解释型”到”推理型”的进化才刚刚开始。

但方向是清晰的：让BREAK成为业务安全领域的 基础知识设施——不只是给人看的，也是给机器用的；不只是枚举风险的，也是能做攻击面推理的；不只是一个中文框架，也是能在国际安全社区流通的。

框架地址：https://break.jd.army/

GitHub：https://github.com/JDArmy/BREAK

如果你在做业务安全评估、风控能力建设、或者安全知识图谱相关的工作，欢迎使用、反馈和贡献。

JDArmy — 专注于挖掘和解决企业安全运行风险隐患的专业型红队

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：JDArmy 《从443到3227：BREAK框架的进化之路》