Category Archives: 开发安全

最近科技圈最受关注的安全事件，莫过于Anthropic旗下AI编程助手ClaudeCode的源码意外泄露。51.2万行完整未混淆的TypeScript源码，通过公开npm包裸奔曝光，而这一切的起因，仅仅是一个低级的配置失误——这样的“翻车”，给所有AI企业、开发者敲响了数字安全的警钟。

不同于复杂的黑客攻击，这次泄露更具警示意义：它不是技术壁垒被突破，而是流程疏忽导致的“自曝”，背后藏着供应链安全、流程管理、危机应对的诸多问题，值得每一个数字产品从业者深思。

一、ClaudeCode源码泄露事件完整复盘

1. 事件核心信息

主角：Anthropic 旗下 AI 编程助手 Claude Code（版本 v2.1.88）

事发时间：2026年3月31日

泄露规模：51.2万行完整TypeScript源码，涵盖产品核心架构、工具链、未发布功能，无任何混淆处理，相当于把产品的“底牌”完全公之于众。

2. 泄露原因：一个低级且可避免的失误

此次泄露的直接原因，说出来令人惋惜——并非高级黑客入侵，也不是内部人员泄密，而是团队在通过npm发布产品时，未在.npmignore文件中过滤cli.js.map（Source Map）文件。

可能有朋友对Source Map文件不太了解，简单说，它的作用是帮助开发者调试代码，相当于给编译后的代码“配了一把钥匙”，能反向还原出完整的源代码。正常情况下，这类文件绝不会出现在公开发布的包中，只需在.npmignore中添加过滤规则，就能轻松避免泄露。

更值得警惕的是，这已经是Anthropic第二次犯同样的错误——2025年2月，ClaudeCode就曾因Source Map文件泄露过部分代码，当时团队仓促下架修复，却没有从流程上补漏，最终导致同样的悲剧再次发生。

3. 泄露后果：不可逆的损失的连锁反应

数字时代，代码一旦公开，就会被全网镜像、传播，即便事后紧急下架npm包、通过DMCA删除相关仓库，也无法挽回损失——泄露的源码早已在全网流转，形成“永生”状态。

此次泄露带来的影响是多方面的：

一是技术壁垒崩塌：核心架构、工具链被完全曝光，竞争对手可以轻松借鉴其技术思路，甚至针对性推出同类产品，Anthropic长期积累的技术优势被大幅削弱；

二是公司声誉受损：连续两次犯同样的低级错误，让用户、投资者对其安全管理能力产生严重质疑，甚至影响公司估值；

三是潜在风险隐患：源码中可能包含未公开的功能逻辑、内部测试脚本，若被恶意利用，可能引发后续的安全漏洞或功能滥用问题。

二、ClaudeCode泄露带来的核心启示

启示1：供应链安全是生命线，低级失误最致命

很多企业总把“安全”和“复杂技术”绑定，认为只有抵御高级黑客攻击才算做好安全，但ClaudeCode的泄露告诉我们：单点的低级失误，足以引发全局崩溃。

现代软件的交付链很长，从代码编写、构建、打包，到发布、CDN分发，任何一个环节的微小疏漏，都可能让核心资产裸奔。而此次泄露，仅仅是打包发布环节的一个配置疏忽，却造成了不可逆的损失。

这也给所有企业提了个醒：安全流程必须“防呆”，不能靠“我以为没问题”。尤其是在npm、PyPI等公开仓库发布产品时，一定要反复检查，删除所有敏感文件，避免因一时疏忽留下安全隐患。

启示2：流程漏洞比技术漏洞更可怕，重复犯错不可饶恕

此次泄露最令人诟病的，不是失误本身，而是“二次犯错”。2025年已经发生过一次Source Map泄露事件，说明团队已经意识到了问题，但却没有从流程上彻底解决——没有在CI/CD流水线中添加自动化安全扫描，没有建立发布前的审计清单和双人复核机制，过度依赖人工判断，最终导致同样的错误再次发生。

这背后反映的，是企业安全文化的缺失：安全不是某一个人的事，而是全员、全流程的事。任何一次安全事故后，都必须进行根因分析，补全流程漏洞，建立长效机制，而不是简单下架修复、敷衍了事。否则，同样的错误只会反复出现，造成更大的损失。

启示3：危机应对的态度，决定损失的下限

Anthropic在此次泄露事件中的应对，略显消极且被动：事发后仓促下架npm包、通过DMCA删除相关仓库，但却没有第一时间向用户、投资者坦诚说明情况，也没有给出明确的补救措施和后续改进计划。

这种“掩盖式”的应对方式，不仅无法挽回损失，反而会加剧用户和投资者的不信任。要知道，代码泄露已经不可逆，此时最该做的，是透明沟通、主动承担责任，向公众说明泄露的范围、影响，以及后续的安全改进措施，最大限度降低声誉损失。

启示4：AI产品的核心壁垒，从来不是源码

值得庆幸的是，此次ClaudeCode泄露的，主要是前端和工具链的代码，并没有涉及模型权重、核心训练数据和用户隐私——这也是此次损失能够可控的关键原因。

这也暴露了AI产品安全的一个核心逻辑：对于AI产品来说，源码其实不是最核心的资产。AI产品的真正壁垒，是模型权重、核心训练数据和用户隐私，这些才是无法被轻易复制、能够形成长期竞争优势的核心资产。

这也提醒所有AI企业：必须对核心资产进行分级保护。绝密级资产（模型权重、核心训练数据、用户隐私）要进行最高级别的防护，甚至物理或逻辑隔离；机密级资产（核心业务逻辑、未发布功能）要严格管控访问权限；普通级资产（工具链、UI代码、配置文件）则可以在保证安全的前提下，简化管控流程，避免因小失大。

三、针对AI产品的安全自检清单

结合ClaudeCode泄露事件的教训，整理了一份专门针对AI产品的安全自检清单，尤其是涉及npm等公开仓库发布的产品，发布前务必逐一核对，避免低级失误。

一、供应链安全自检

1. 公开包（npm/pip/docker等）检查：删除所有敏感文件，重点过滤Source Map文件（.map）、.git文件夹、密钥文件（.env、.key、密钥配置等）、内部测试脚本、未公开功能代码、数据库配置文件，确保公开包中仅包含必要的运行文件。

2. CI/CD流水线配置：已添加自动化安全扫描环节，重点拦截Source Map文件、源码、密钥等禁止出库的内容；扫描规则定期更新，覆盖最新敏感文件类型，避免遗漏。

3. 发布前审计：已制定明确的审计清单，涵盖文件检查、权限检查、漏洞扫描三项核心内容；实行双人复核机制，审计记录留存可追溯，杜绝单人操作的疏忽。

4. 开源组件检查：所有引入的开源组件、依赖包，已完成安全漏洞扫描，无高危漏洞；明确开源协议，避免版权纠纷和协议漏洞带来的安全风险。

二、核心资产分级保护自检

1. 绝密级资产（模型权重、核心训练数据、用户隐私数据）：已实现物理/逻辑隔离，仅授权人员可访问；建立访问日志，异常访问可实时告警；定期备份，备份文件加密存储，防止泄露或丢失。

2. 机密级资产（核心业务逻辑、未发布功能、核心算法）：已配置访问权限管控，禁止未经授权的复制、传播；代码未在公开渠道留存，内部传输需加密，避免二次泄露。

3. 普通级资产（工具链、UI代码、公开配置）：已做基础安全检查，无敏感信息泄露；可根据需求简化管控流程，提升开发效率，但需定期排查安全隐患。

三、危机应对准备自检

1. 已制定安全事故应急预案，明确源码泄露、数据泄露等不同场景的应对流程、责任分工、沟通话术，确保事发后能够快速响应。

2. 建立应急沟通渠道，可快速向用户、投资者、公众传递信息，说明事件真相、影响范围和补救措施，避免谣言扩散。

3. 定期开展安全事故复盘，尤其是针对已发生的失误，深入分析根因，补充流程漏洞，杜绝重复犯错，形成长效安全机制。

四、最后想说的话

ClaudeCode的源码泄露，从来不是一个偶然的低级失误，而是企业安全流程缺失、安全文化薄弱的必然结果。它给所有AI企业上了生动的一课：数字安全从来不是“事后补救”，而是“事前预防”；不是靠复杂的技术，而是靠严谨的流程、全员的重视。

对于AI产品而言，源码的泄露或许可以弥补，但模型、数据的泄露则是毁灭性的。与其在泄露后仓促补救，不如在开发、发布的每一个环节做好防护，建立“防呆”流程，分级保护核心资产，才能真正守住数字安全的底线。

近期游戏圈也上演了一场“反常规”的安全事件——爆款肉鸽卡牌游戏《杀戮尖塔2》，在Steam抢先体验上线仅40小时，就被完全破解，甚至被快速移植到安卓平台，盗版资源全网泛滥。

《杀戮尖塔2》被快速破解，从一开始就是开发者Mega Crit的“主动选择”。更令人意外的是，面对盗版泛滥，官方不仅佛系不设防、不追责，游戏销量还一路飙升，首周销量破300万份，目前累计销量已达460万份，峰值同时在线人数突破57万，口碑始终保持“特别好评”。

这场“破解与热销并存”的奇观，彻底打破了“防破解=保销量”的固有认知，也给游戏开发者、数字产品从业者，带来了关于技术架构、商业防御、用户运营的全新思考——它用实际成绩证明，最好的“反盗版”，从来不是加密，而是让正版变得不可替代。而这份“不可替代”，既源于开发者对技术与成本的理性权衡，也离不开IP沉淀、平台加持与社区认同的共同助力。

一、《杀戮尖塔2》被快速破解事件完整复盘

1. 事件核心信息

主角：Mega Crit工作室开发的肉鸽卡牌游戏《杀戮尖塔2》

事发时间：2026年3月6日（Steam抢先体验上线），3月8日完成破解并全网传播

破解规模：上线40小时内，完整破解PC版核心内容，随后被快速移植至安卓平台，多个盗版网站同步分发，无需付费即可体验单机核心玩法，盗版资源短期内覆盖全网。

官方态度：全程佛系，不添加复杂DRM加密，不追究盗版传播者责任，甚至欢迎开发者研究游戏代码，专注于正版内容更新与独占功能优化。

2. 破解原因：主动选择的“低防护”，藏着理性的权衡

《杀戮尖塔2》的快速破解，并非技术壁垒薄弱，而是开发者主动放弃了“强防护”——这一切的起因，要从一场引擎风波说起。

这款游戏初期曾耗费两年时间，原本使用Unity引擎进行开发，但2024年Unity宣布将根据游戏下载次数向开发者收取费用，这一政策引发了全球开发社区的强烈不满，尽管Unity后续撤回了该决定，但Mega Crit已经下定决心改弦更张，彻底转向开源引擎Godot开发。

Godot引擎的核心优势的是完全开源、免费可用，用户协议中明确允许“用于任何用途”，这不仅帮Mega Crit规避了Unity的授权费用争议，还能更灵活地进行功能定制化，契合这个仅12人小团队的开发需求。但开源也意味着“双刃剑”——引擎的运行逻辑是透明的，破解者可以更轻松的查看、解析、编译，这让破解变得门槛很低。

其实，Mega Crit在选择Godot引擎时，就已预判到破解会快速到来，但他们却主动放弃了复杂的DRM加密。用首席程序员Jake Card的话来说：“想盗版的人总能找到办法，没必要浪费开发资源在这上面”，与其花费精力防破解，不如把时间和成本投入到游戏内容本身。

而放弃复杂加密的另一重关键考量，是为了让社区能更自由地开发MOD，同时节省团队精力成本。Mega Crit的联合创始人Casey Yano曾明确表示，团队高度支持MOD社区发展，复杂DRM会给MOD开发设置重重障碍——既限制玩家对游戏代码的访问修改，还可能引发MOD与加密程序的兼容性问题，影响使用体验。对于肉鸽卡牌游戏而言，MOD是延长生命周期、提升玩家粘性的核心：初代《杀戮尖塔》能长期保持热度，正是得益于社区开发的各类MOD，它们丰富了游戏内容、优化了游玩体验，形成了独特生态。Mega Crit深谙这一点，因此放弃加密，让玩家自由开发安装MOD，既满足了玩家个性化需求，借助社区力量丰富生态，也让这个仅12人的小团队得以全身心投入内容更新，实现双赢。

3. 看似“失控”的结局：破解泛滥，销量却逆势飙升

在很多人看来，“快速破解+盗版泛滥”必然会导致销量崩盘，但《杀戮尖塔2》却走出了一条反常规之路：

数据层面，游戏上线首周销量就突破300万份，玩家爬塔次数超2500万次，目前累计销量已达460万份，总收入超9200万美元，远超同期其他独立游戏，其中三分之一的玩家来自中国；口碑层面，Steam累计评论超4.6万条，好评率稳定在95%左右，即便曾因平衡补丁引发中文区短期差评潮，全平台总评依旧保持“特别好评”。

这一切的关键，在于Mega Crit找到了“破解与正版”的平衡点——放弃“防破解”，却守住了“正版的不可替代性”：盗版只能复制单机内容，却复制不了正版独有的服务、生态与专属体验。而游戏能持续大卖，更离不开三大核心支撑：
其一，成熟IP的沉淀效应，初代《杀戮尖塔》作为肉鸽卡牌标杆，积累了庞大核心玩家与超高口碑，玩家对续作期待值拉满，无需过多宣传便主动购买，构成销量基础盘；
其二，Steam平台的强大粘性，作为全球最大PC游戏分发枢纽，其收藏、成就、社交等生态让玩家难以迁移，而《杀戮尖塔2》作为Steam独占游戏，搭配国区88元高性价比定价，进一步推动销量增长；
其三，社区对正版的普遍认可，经过多年市场培育，PC核心玩家普遍认同“买正版就是支持开发者”，再加上Mega Crit的坦诚开放，玩家主动选择正版、自发宣传，形成正向口碑闭环。

二、事件背后的核心启示，重构数字产品防御逻辑

启示1：技术架构的选择，本质是风险与收益的权衡

《杀戮尖塔2》的案例，彻底打破了“开源=不安全”“闭源=安全”的误区——技术架构本身没有绝对的安全与否，只有是否契合产品定位的选择。

Mega Crit选择开源Godot引擎、放弃复杂DRM，看似“放弃防护”，实则是理性权衡：对这个小团队而言，开源引擎的“无授权费、高灵活性、易定制”，远比“强防破解”更重要；放弃DRM不仅节省开发维护成本，还避免了加密对正版用户体验的干扰——很多DRM会导致游戏卡顿、闪退，反而伤害核心玩家。

这也给所有开发者提了个醒：技术选型时，不必盲目追求“极致防护”，更要结合团队规模、产品定位、核心需求，平衡好“防护强度”与“开发效率、用户体验”。如果产品核心竞争力在内容和服务，而非代码本身，适当降低防护成本，反而能实现收益最大化。

启示2：防御思维升级：从“防破解”到“防盈利”，打造正版护城河

长期以来，很多开发者都陷入了一个误区：把反盗版的核心放在“阻止用户获取盗版”上，不惜花费大量成本研发、部署复杂的DRM加密，却忽略了“正版用户真正需要什么”。《杀戮尖塔2》的成功，恰恰在于它跳出了这个误区——放弃“防住所有盗版”的幻想，转而专注于提升正版价值，让用户“主动选择正版”。

Mega Crit的核心做法，总结起来有三点，值得所有数字产品借鉴：

一是打造盗版无法复制的独占功能：游戏的多人联机模式，包含独立的解锁内容和专属角色，这是盗版版本完全无法实现的，也是吸引核心玩家购买正版的关键理由；

二是持续迭代，强化正版体验：官方专注于内容更新、平衡性调整（尽管曾因补丁引发争议，但核心迭代方向始终围绕玩家需求），而盗版版本难以同步跟进这些更新，久而久之，盗版用户会因体验落后而转向正版；

三是拥抱开源，传递正向价值：官方不仅不禁止玩家研究代码，反而欢迎其他开发者通过阅读游戏代码学习，这种开放的态度不仅圈粉，还强化了正版用户的认同感——购买正版，也是对开发者开放精神和持续创作的支持。

本质上，未来数字产品的反盗版战争，早已不是“代码加密的攻防战”，而是“服务与生态的壁垒战”。只要正版的价值足够高，盗版就很难抢走核心用户和利润。

启示3：危机应对的最高境界，是“预判危机、主动接纳”

Mega Crit在此次破解事件中的表现，堪称“危机应对的典范”——他们没有试图掩盖、没有盲目追责，而是从一开始就预判到了危机，并主动接纳了“破解会发生”的事实。

这种“主动接纳”，并非放任不管，而是建立在对产品价值、用户需求的深刻理解之上：他们知道，真正的核心用户，不会因为有盗版就放弃正版；而那些只想免费体验的盗版用户，即便花大力气阻止，也很难转化为付费用户，反而会消耗大量开发资源。

更难得的是，官方在面对破解时，始终保持坦诚、开放的态度：不指责盗版用户，不抱怨破解者，而是把所有精力放在提升正版价值上。这种态度不仅没有损害品牌口碑，反而让玩家感受到了开发者的务实与真诚，进一步推动了正版销量的增长。

启示4：独立游戏的破局之路，内容与诚意远比加密更重要

《杀戮尖塔2》作为一款独立游戏，团队规模小、资源有限，却能在破解泛滥的情况下逆势热销，核心原因只有一个：内容足够优质，态度足够真诚。

初代《杀戮尖塔》积累的超高口碑，为续作奠定了基础——续作延续核心玩法，新增新职业、新卡牌、新机制，精准满足玩家期待；Mega Crit放弃Unity、改用Godot引擎，即便延长开发时间也要坚守开发者权益，这份坚持赢得了玩家尊重；再加上国区88元的高性价比定价，以及46%的超高愿望单转化率（远超行业7%-10%的平均水平），进一步降低了玩家购买门槛。

这也给所有独立开发者启示：对于资源有限的小团队而言，与其花费大量成本做加密、防破解，不如把有限的资源投入到内容创作和用户服务上。优质的内容的是吸引用户的核心，真诚的态度是留住用户的关键，这两者结合，远比任何加密技术都更能抵御盗版。

三、总结一下

《杀戮尖塔2》的快速破解与逆势热销，给所有数字产品开发者上了生动的一课：数字安全的核心，从来不是“把代码锁起来”，而是“让代码的价值，通过服务和生态得以延续”；反盗版的关键，也从来不是“阻止用户获取盗版”，而是“让用户主动选择正版”。

数字时代，真正的壁垒从来不是技术加密，而是产品价值、服务质量和用户信任。对于开发者而言，与其在“防破解”上耗费大量精力，不如静下心来打磨内容、提升服务，让正版变得不可替代。毕竟，用户愿意为优质的内容和真诚的服务付费，而不是为“无法破解的加密”买单。

四、看似都很美好，但是一盆冷水

对于独立开发者，包括一些小开发团队，在拥有强大的游戏IP、成熟的社区、充沛无比的资金之前，咱们还是要生存优先：
1、选择合适的引擎，做好必要的加密，收到钱养活自己和团队，坚持把游戏做好做下去。
2、谋定而后动，只有游戏理念、营销策略、社区情况等多重原因都符合的情况下，再尝试开源。
3、希望未来，优秀的你也可以用Mega Crit的思维方式，不断推出更好的作品。

最近和朋友聊天的时候，大家聊到了MCP，然后聊到了MCP的安全问题。
大家后面一致认为，MCP协议，目前只描述了如何通讯，如何调用MCP服务端的能力，在安全方面还是很薄弱的。

尤其是当前阶段，暂且不说个人提供的MCP服务品质，其实各大厂提供的MCP服务也只是做了部分的能力封装而已。
而应用MCP的下游，无论是服务器还是应用，在处理MCP返回输出方面，如何进一步规避风险，是严重缺乏经验和手段的。

这就导致了，无论是MCP的客户端还是服务端，都很容易成为攻击者，也很容易成为被攻击者。

很多传统的攻击方式，都可以用到MCP攻击上，比如：
1、DNS攻击
2、中间人攻击
3、MCP供应链攻击
4、大模型投毒
5、大模型地址替换
6、社会工程学攻击

举个例子，对一个自动编码的MCP服务，一旦攻破该MCP服务，就可以返回代码时，自动插入一段删除数据文件的恶意代码。
如果MCP的下游，没有做任何校验，就执行了代码，后果不堪设想。

目前看来，最好的方式，还是相对集中式的管理。
1、统一的平台，审核、发布、维护MCP服务，各厂商负责开发，最后发布到统一平台上。
2、建立MCP服务的信息评价体系，对于恶意版本及时下线，对于恶意厂商及时封堵。
3、推行零信任的认证方式。

传统开发中，“安全” 往往是上线前的 “临门一脚”—— 发现漏洞再返工，不仅延误工期，还可能因紧急修复引入新问题。而 DevSecOps 的核心逻辑是 “安全左移 + 持续防护”，将安全需求、检测、加固融入开发全生命周期，让安全成为开发的 “内置功能” 而非 “额外负担”。今天就拆解 DevSecOps 的核心流程与关键技术，帮你搭建从计划到适应的全链路安全体系。

一、计划阶段：安全前置，从源头定规则
开发未动，安全先行，这一步的核心是 “明确安全需求，搭建防护框架”：
梳理安全需求与设计规范，结合业务场景制定安全编码规范（如避免 SQL 注入、XSS 攻击的编码准则）；
开展威胁模型与风险评估，识别潜在攻击面（如核心接口、数据存储环节），提前规划防护策略；
统一安全框架与 API，选用经过安全验证的组件和工具，避免因基础架构存在漏洞埋下隐患；
全员开展安全培训与宣导，提升开发、测试、运维人员的安全意识，让安全理念贯穿团队。

二、创建阶段：编码防护，实时规避基础漏洞
编码过程中嵌入安全检测，及时发现并修复漏洞，避免漏洞积累：
开发工具集成安全插件：在 IDE 中安装静态扫描（SAST）插件、恶意组件 / 函数库扫描（SCA）工具，实时检测代码漏洞、依赖组件漏洞；
遵循安全编码规范：通过自动化工具校验代码是否符合安全准则，比如禁止硬编码密钥、规范输入校验逻辑；
搭建纵深防御体系雏形：提前规划 WAF、HIDS、RASP 等安全工具的部署方案，确保后续开发与防护工具兼容。

三、验证阶段：全面检测，不留安全死角
测试环节不仅验证功能，更要全面排查安全漏洞，核心是 “多维度检测，精准定位问题”：
自动化安全测试：通过动态扫描（DAST）模拟攻击场景，检测运行时漏洞；用交互式安全检测（IAST）结合静态与动态优势，提升漏洞检测准确率；
专项渗透测试：开展外部渗透测试，模拟黑客攻击行为，挖掘隐藏漏洞（如逻辑漏洞、权限绕过）；
敏感信息与配置检查：检测代码中是否存在敏感信息泄露（如密码、接口密钥），校验系统安全加固配置是否合规；
容器与镜像安全：针对容器化部署场景，进行镜像扫描，排查基础镜像中的漏洞，确保容器运行环境安全。

四、预发布与发布阶段：安全门禁，守住上线最后一关
上线前的安全校验与发布后的持续防护，确保系统在生产环境中安全稳定：
预发布阶段：设置安全门禁，只有通过所有安全测试（漏洞修复率 100%、配置合规）的版本，才能进入发布流程；
发布阶段：进行签名校验，防止部署过程中代码被篡改；同步开启运行时安全检测（如 RASP 实时拦截攻击）；
灰度发布防护：发布初期逐步放量，结合 UEBA（用户与实体行为分析）监控异常行为，快速响应潜在安全问题。

五、运营阶段：检测响应，快速处置安全事件
系统上线后，安全防护不能松懈，核心是 “实时监控、快速响应、持续优化”：
实时检测与预警：通过安全感知平台收集漏洞情报，结合日志分析，实现漏洞分析预警与检测响应综合分析；
应急响应机制：建立安全事件处理流程，一旦发生漏洞攻击、数据泄露等事件，快速启动应急方案，减少损失；
持续优化迭代：根据安全事件复盘结果，优化安全技术、工具与策略；动态调整纵深防御体系，适配新的业务场景与攻击手段；
合规与风险再评估：定期开展系统漏洞扫描、风险评估，确保系统符合行业安全合规要求，及时应对新的安全威胁。

总结：DevSecOps 的核心逻辑 ——“安全不是负担，而是生产力”
DevSecOps 不是 “给开发加活”，而是通过 “提前规划、实时检测、持续优化”，将安全成本分摊到开发全流程，避免后期返工的高额代价。其核心是 “人人都是安全员”：开发人员关注编码安全，测试人员聚焦漏洞检测，运维人员保障部署与运行安全，形成全链路安全闭环。
随着攻击手段的不断升级，只有将安全深度融入开发流程，才能从源头抵御风险，让系统在高并发、复杂环境中稳定运行。

你在落地 DevSecOps 时遇到过哪些难点？是工具集成问题还是团队意识磨合？欢迎在评论区分享你的经验～

2020年7月，TOG（The Open Group）联合SABSA，正式发布中文版指南《安全架构实践的公理》（其英文版发布于2019年7月），其中20条安全架构实践公理如下：

公理1：业务风险驱动安全
安全架构应通过最大化收益和最小化损失来支持业务目标。
必须牢记的是，组织资产并不是为了被保护而存在，它们的存在是为了创造价值。而利用资产创造价值，通常意味着使该资产面临风险。这正是矛盾之处。
为了提供最优架构，安全架构师不仅要从防止负面结果的角度来看待它们对组织的贡献，还要从促成积极结果的角度来看待它们。
如果安全架构无法支撑组织利用其资产来完成业务工作，则该安全架构可能被边缘化和显得无用。
安全架构应基于业务风险驱动，并且应该是对这些风险进行适当响应。

公理2：场景
不要虚构场景，否则后果自负。专为一种场景而设计的安全系统或解决方案，并不总是可以有效地在另一种场景中工作。
这并不是反对重用，可重用的基于组件的架构有很多好处。但是，如果为了节省时间和精力，将安全系统重用于不同的用例，则需要针对这两个用例之间的差异，进行新的风险分析。
该指南还专门针对系统设计中的一个常见错误——访问控制过程的身份识别、身份验证、授权过程的混淆，进行了澄清。

公理3：范围
明确定义安全架构的范围很重要。在这方面，系统收益（SOI）的概念很有用（如ISO/IEC/IEEE 42010：2011中所定义）。

公理4：情报
安全系统应利用情报来主导响应活动。通过威胁情报，既可以了解对手的意图、能力、攻击方式，也可以了解自身的漏洞情况。
建议对潜在威胁场景进行建模分析，来实现最佳效果。

公理5：信任
安全架构应该保障系统可以准确建模业务实体关系中存在的信任的性质、类型、级别、复杂性。
信任是人际关系的特征。但我们可能要给非人员对象以信任。当这样做时，其实是在说，我们可以信任操作这类对象的人员，或可被操作这类对象的人员所信任。因此，一个可信的系统是指我们信任参与系统生命周期过程的人员。
信任从来都不是二进制，而是一个很长的灰度连续体，很少有黑色或白色。
“信任”和“被信任”不是镜像关系。
即使是最复杂的信任关系，也可以自顶向下分析成一系列简单的单向信任关系。通过严格执行此项分析，可以将任何业务关系分解为简单且独立的单向信任组件。

公理6：整体分析
安全需求应与其它的功能性需求和非功能性需求集成在一起。安全需求通常被描述为非功能需求（NFR），并且不应将其与其他功能需求或非功能需求分离。只有将所有需求都视为SOI（系统收益）整体风险的一部分时，安全架构才能有效工作。
架构通常被视为不同视角的一系列观点。这些观点通常被称为架构域。例如：业务架构域、应用架构域、信息架构域、数据架构域、服务管理架构域、技术架构域。就像看一座被群峰环绕的山谷，远近高低的观点各不同。
而安全架构域是从另一个视角来看的另一种观点，但与其它视角有很大不同，因为它是一个跨领域的域，必须以整体的方式解决所有其它域的安全和风险管理问题。因为风险无法分为孤立的架构域，所以安全架构师必须同时从所有视角看到山谷，即拥有可以随意旋转的全息视图。

公理7：简洁性
系统和服务应在保证功能性的前提下尽可能简洁。
复杂是安全的敌人，必须在保持整体性的同时，将其简化为子结构进行管理。安全架构将会受益于面向服务的架构（SOA）方法，在这种方法中，我们看到了“一切即服务”（EaaS）。服务的性能对于实现顶级业务绩效目标至关重要。
任何架构类型的主要目标之一就是管理复杂性。必须通过自上而下的分解来分解高度复杂的SOI（系统收益），从最高级别的业务目标开始，并创建逐渐简化的SOI层次，并对其逐层解决。
高度复杂的系统，倾向于表现出涌现性。涌现性的示例包括：两个或多个进程争用同一系统资源时发生死锁；网络在超出容量后的流量拥塞。
系统安全漏洞主要来自两个来源：设计错误和涌现性。两者不相同，不应混淆。涌现性是系统工程的一种现象，并非一开始就被设计出来。复杂性本身就是导致出现这一现象的原因。

公理8：重用
在可行的情况下，尽可能重用受信任的系统开发实践和系统组件。
安全架构师不应从零开始，不要重新发明轮子。从通用框架和参考架构开始，并针对特定的场景进行定制，始终是效率更高的方法。
框架示例包括：
NIST网络安全框架（CSF）：是150多个RFI响应和许多利益相关方会议的产物。
ISO 27000系列：是用于组织和监控企业安全机制的一组控件和过程。
ISO 31000-2018：定义了一个周期性的风险管理流程。
SABSA平衡风险模型：提供了定义风险相关组件的组织结构。

公理9：弹性
安全系统应在受到胁迫时依然正常运行。
架构的弹性不仅仅是设备，还必须包括人员和流程。
弹性的关键特征是计划内的系统降级——通过控制将系统降级，而非由于无法控制导致故障。
良好的弹性设计的一个例子，是在大容量云服务数据中心中使用混沌工程。混沌工程通过在时间敏感的在线服务中，不断进行故障自动转移测试，来验证系统弹性。

公理10：过程驱动
安全开发过程应使用清晰的生命周期，来解决要求的时间跨度，并引入利益相关方。
战略：安全架构的目标是支持组织的长期的业务战略。安全架构本身是一项战略活动，需要长期的投资和管理层的支持。
战术：安全架构是通过一系列步骤开发和实施的：利用变更项目从而使长期愿景变为现实。
运营：安全架构提供技术、工具、流程来确保日常的安全，并对业务运营提供风险管理。

公理11：优化冲突解决
安全应通过平衡业务风险，来优化解决利益相关方的冲突。
利益相关方的关注通常会发生冲突。安全架构的作用之一是以最佳方式解决这些冲突，在功能需求和其他非功能需求与安全需求之间取得平衡。这些利益冲突可能非常复杂，源于安全架构的跨复杂领域的性质。

公理12：清晰的沟通
安全应使用有利于业务和技术利益相关方之间进行有效沟通的通用术语。
安全架构师必须至少会两种“语言”，能熟练使用业务涉众的语言（“业务术语”）和技术人员的知识（“技术术语”）。

公理13：易用性
安全系统应该尽可能对用户透明且易于使用。
不易使用或导致生产受到影响/破坏的安全控制措施，通常会被忽略、禁用、废除，导致资源容易受到攻击，从而失去了控制措施的价值。而被绕过或未被使用的安全系统将毫无价值。
可用性差的经典示例，是密码的使用。另一个示例是Web浏览器使用PKI证书对网站进行验证。

公理14：安全设计
安全性应依赖于经过验证的特定控制措施，而非隐藏。
每本安全书籍都强烈建议不要使用“通过隐藏构建安全性”。其实通常被否定的，是希望安全漏洞不被发现的侥幸心理。
安全不应依赖于暗箱操作或其它晦涩的形式，而应依赖于经过验证的特定控制。就像密码学的安全性，应取决于对加密密钥的保护，而非加密算法。

公理15：优先级
使用较强的保护机制来保护较弱的机制，而非相反。
最重要的事物不应依赖于不重要的事物。

公理16：设备主权
所有设备均应能够在不受信任的网络上保持其安全策略。
保护机制通常位于本地或靠近被保护的资源更有效。这使得防护机制更容易随受保护资源一起迁移。
物联网设备的市场壁垒，使得设备主权原则难以适用。安全架构师必须面对这一挑战。不可能强迫市场将高级安全性集成到IoT设备中，因为这是一种市场驱动的现象，受成本和收益的感知驱动，但是设计整体集成的分层方式将改善一定程度的安全性。

公理17：纵深防御
通过分层防御可以获得更高的安全性。
纵深防御是一种传统方法，它通过在攻击路径上应用多层或多级安全性，来最大程度地保护每个资源。
为了使纵深防御有效，各层之间必须彼此独立，各层应该由不同类型的控制措施组成，而非多层使用同一类型的控制。
当控制措施失效时，选择失效而开放，还是失效而关闭，取决于资源的敏感性和它所支持的服务的需求。在此领域，有限状态机（FSM）建模可用于探索系统可能进入的所有可能状态。

公理18：最小特权
主体（人员、事物、流程等）应仅被授予执行其授权任务所需的权限。
部署最小特权系统和服务的能力，在一定程度上取决于可以执行细粒度访问控制的技术和流程。细粒度的访问控制，要求以一种方式捕获或存储有关资源或资产以及最终用户的元数据，以便访问控制系统可以通过它来做出有关资源的访问决策。
职责分离也是从纵深防御中衍生出来的一种特殊形式的最小特权。

公理19：访问管理
访问控制包括三种不同的操作过程：
识别：识别并区分主体；
认证：验证主体的身份；
授权：授予主体适当的访问权限。

公理20：通信安全
设备和应用程序应使用开放、安全的协议进行通信。
在当今过度连接的世界中，无法假设未加密的传输具有任何级别的安全性。
最重要的一点是，无论加密服务是否已打开并处于最佳运行状态，网络服务都无法向应用服务发出信号。因为网络无法理解应用程序的数据结构。
规则很简单：网络需要网络安全服务来保护。应用程序需要应用安全服务来保护。
通信安全架构是一门复杂的学科。它必须在通信设备之间采用敌对环境，并且必须同时满足应用程序层安全性和网络层安全性。

参考：
《网络安全架构：安全架构实践的公理》
安全内参是个很好的安全类技术网站，大家可以关注一下：安全内参官网

谈到安全开发，咱们就要先明确一个问题，安全开发的目的是什么呢？

所有做过开发的小伙伴，一定会有一个概念，一个程序的逻辑Bug，一定越早发现，损失越小。
如果能在需求阶段，发现并解决这个Bug，损失可以是最小的。

安全开发也是这样，希望达到的目的就是：
安全风险左移，早发现，早管理，持续改进

在安全开发上面，其实有一些现成的框架可以遵循，比如SSDLC（适合迭代式开发）、DevSecOps（适合DevOps式开发）等。

本文就说一下，我们的SSDLC是如何执行的。

当前，在能执行之前，需要进行相关的建设，包括：
明确安全风险，明确安全基线，指定安全策略，进行安全教育，部署安全工具，进行相关培训等等。
这个每个公司差异比较大，选择的组件和厂商也大不相同，就不详细描述了。
我们重点说一下，一个安全相关的需求，是如何落地的。

1、安全需求
1.1安全需求识别
组织应该达成一个共识，哪些需求比如过安全评审，比如：
a、任何账号、密码相关的
注册、登录、密码验证、验证码、密码修改、账号注销等等
b、任何用户可以发布信息的
留言、灌水、内容发布、即时通讯、提交信息并展示
c、任何上传和下载的
d、任何交易相关的
大促、活动、秒杀、刷单、刷票、业务风险响应
e、任何钱相关的
积分、交易、资金往来、营销、相关接口
f、涉及SQL编写的
g、任何敏感信息存储或展示的
购买、支付、个人信息查询、添加删除信息、充值密码
移动端图片保存、人脸识别、手势密码
h、任何证书相关的
i、任何访问控制相关的
前后端访问控制、系统对接、日志、短信、邮件
j、任何批量操作相关的
查询、导入、导出
k、合规安全相关
隐私政策、个人信息采集、敏感信息传输、生物特征识别、账号注销
等等。
1.2安全需求强制纳入安全评审，安全管理人员可以指定其他需求进入安全评审、
1.3安全小组对需求进行评审，判定是否可以继续推进

2、安全设计
2.1设计人员给出方案
2.2安全小组评审设计方案，判定是否可以继续推进
2.3测试同学，同步书安全测试用例
2.4安全小组评审设测试用例，判定是否可以继续推进

3、安全开发
3.1、开发同学IDE安装好安全组件，组件可规范编码，并进行静态扫描，及时发现代码问题
3.2、开发同学自测后，提交代码库
3.3、开发同学在测试环境，运行流水线
3.4、流水线自动混淆、编译、加固、打包、部署，同步进行各类扫描，包括：黑盒、白盒、组件、镜像、隐私检测等
3.5、流水线给出相关漏洞
3.6、开发同学修复漏洞

4、安全测试
4.1、测试同学进行功能验证
4.2、测试同学进行安全验证：渗透、越权等
4.3、测试同学进行性能验证
4.4、验证通过后，提交相关报告

5、安全验证
5.1、此时可以进行UAT验证
5.2、在版本库相同的情况下，开发同学将代码发布到UAT环境
5.3、流水线门禁根据规则判定，是否可以发布
5.4、测试同学初步验证
5.5、用户验证

6、安全部署
6.1、此时可以把代码部署到生产环境

当然，上面的开发流程，只是整个安全开发体系中的一环。
实施安全开发流程，需要庞大的前期资源投入，以及渡过一个较长的不断改进的过程。