代码“不落云”就安全吗？企业AI评审、SRC运营与邮件TLS的现实选择｜总第321周
原创 群秘 2026-08-31 08:00 北京
本期周报简介：
1、数据不落云是否等于不出域？TEE的信任根应如何验证？
2、AI挖洞普及后，SRC价值如何量化？企业应自建、众测还是组合运营？
3、邮件TLS应优先保障送达率，还是对重点通信强制加密？
0x1本周话题
话题一：代码“不落云”，是否就等于代码不出域？云端AI参与代码评审时，真正越过边界的是什么？
《代码不出内网，也能用上 AI 智能评审：云效现已支持 GitLab》
A1：仓库虽然仍在企业内部，但云端模型要完成评审，就需要接收与任务相关的代码内容。代码库没有整体迁移到云上，并不等于代码数据没有越过企业边界。
A2：首先要厘清，是企业使用了公有云算力，还是把GitLab部署到了云上？
如果是前者，那问题就是：代码以什么粒度、通过什么链路进入模型，进入后由谁处理、是否留存。
A3：即使企业与服务商签订数据保护协议，并约定代码不用于训练，也只能解决部分管理要求。协议并不能代替对真实数据流、访问权限和日志留存的技术核验。
A4：从责任边界看，PAT由企业提供，Token权限范围由企业选择，Webhook和网络通道也由企业配置。
一旦发生问题，很容易被解释为企业主动授权云端服务访问。因此，安全评估还要看授权链路和责任如何落到合同与配置上。
Q：TEE能否实现“代码可用不可见”？
A5：可以通过TEE等可信执行环境承载模型推理。客户端与TEE内程序加密通信后，服务器运维人员理论上无法直接看到其中的数据，GPU资源也未必必须由单一甲方独占。
A6：这个主要集中于两个边界：
运行的是企业自己部署的模型，
运行的是服务商提供的模型；
服务器运维方看不见，是否意味着模型运维方和日志系统同样看不见。
A7：TEE是否真实启用，也不能仅凭网络另一端的声明来判断。企业需要能够验证运行环境和身份，知道数据在什么位置解密、谁能接触明文，以及所使用的模型和推理服务是否真的完成了适配。
A8：密钥“在客户手里”也不是问题的全部。客户端通信密钥可以由客户控制，但TEE的硬件信任根仍来自芯片或设备体系。
换句话说，TEE并没有消除信任，而是把信任从云平台运维人员转移到了硬件、密钥体系和证明机制。
A9：从技术成熟度看，TEE并不是新概念，真正困难的往往是甲方如何向内部法务、合规和审计解释。
技术上能够隔离，并不代表组织上已经接受；乙方是否完整披露实现方式，也直接影响甲方能否作出判断。
Q：企业最终应该选择哪一种部署方式？
A10：主要有两个方面：
如果在自有IDC中部署开源模型，数据边界最容易说明，但企业需要承担模型能力、算力和运维成本；
如果使用商业API，则可能获得更强的模型能力，但必须要求服务商提供更清晰的隔离、日志、密钥和责任说明。
A11：最终还是要回到可验证的问题：哪些数据会离开内网，哪里会出现明文，哪些角色能够访问，是否记录日志，密钥和信任根由谁掌握，发生事件后责任如何划分？这也是非常值得思考。
话题二：AI挖洞时代，SRC还要不要继续做，部分SRC收缩，是否意味着AI正在取代白帽体系？
《平安PSRC关停背后：大模型“漏洞海啸”与白帽经济的黄昏》
A1：企业关闭或收缩SRC，可能同时受到安全预算、审核成本、业务规模和平台运营压力影响，AI只是加速变化的变量之一。
A2：AI确实正在改变漏洞发现的成本结构。相比长期维持人员和赏金投入，企业可能更愿意购买算力和Token，用内部工具持续审计代码；白帽也在使用AI提高挖洞效率，供需两端都在变化。
A3：SRC处在漏洞治理链条较靠后的环节。漏洞被发现以后，企业仍要投入排查、修复、验证和上线资源。如果AI Coding能够把部分检测和修复前移到编码阶段，企业的关注点就会从“收到多少漏洞”转向“能否在开发过程中减少并闭环漏洞”。
Q：SRC的价值为什么越来越难衡量？
A4：SRC运营中，大量精力可能消耗在低价值或重复报告上，真正能够威胁业务的严重漏洞并不多。但一年收到少数高价值漏洞，对企业可能非常重要；困难在于，个位数成果很难用常规报表和趋势图呈现。
A5：如果管理者理解安全，一年发现一个真正影响业务的漏洞，也可能被认为有价值。更现实的做法，是尝试把漏洞影响映射到业务损失、攻击路径和修复成本，而不是只统计报告数量。
A6：“同样的投入，SRC和AI哪个产出更高”并不是一个完整的比较。SRC、AI工具和正式安全人员承担的角色不同：SRC提供外部发现渠道，AI提高自动化能力，内部人员则负责确认、修复和推动业务闭环。
Q：不同规模的企业，应该采用什么运营模式？
A7：对于规模较小的企业，自建SRC除了奖金，还需要持续投入审核和运营人员，固定成本可能高于实际发放的奖励。在这种情况下，接入第三方众测平台可能更符合投入产出。
A8：对于已经具备SRC体系的企业，AI更像能力增强而不是简单替代：它可以提升内部代码审计和漏洞发现效率，但新增结果越多，越需要完善确认、修复、复测和责任跟踪。
A9：白帽同样会使用AI，因此AI并不会让外部研究者自动失去价值。它可能改变的是报告数量、质量分布和激励方式，企业需要相应调整准入、审核和奖励机制。
A10：SRC还有一个容易被忽视的作用：它是面向外部研究者和用户的安全沟通窗口。平台是否存在、响应是否及时，也会影响外界对企业安全投入的判断。
A11：因此，问题不应该只用“保留还是关停”解决。更合理的判断是：企业能否承担自建运营成本，是否存在足够的外部研究价值，内部是否具备漏洞闭环能力，以及众测、AI工具和自建SRC应当如何组合。
话题三：邮件网关启用TLS，如何平衡加密效果与邮件送达，客户端已经加密，企业邮件在互联网上还可能明文传输吗？
A1：邮件客户端到我们公司的邮件服务器的通信已经加密，但我们公司邮件服务器到外部企业邮件服务器之间还没启用TLS，主要目标是降低互联网链路被监听的风险。
A2：一种可行配置是在邮件网关上优先协商TLS。对方网关支持时使用加密传输，不支持时降级为非加密，这样才能保证邮件送达。
A3：问题是，服务端之间的TLS并非对端默认都会配置，如果大量外部域名不支持协商，企业单方面启用“优先加密”的实际覆盖率可能有限。
Q：应该强制TLS，还是允许失败后降级？
A4：如果要求对端必须部署并正确配置密钥或TLS能力，企业就需要对供应商和合作方进行较强管理。否则，严格模式可能直接影响外部邮件往来。
A5：如果采用“TLS优先、失败后明文”的宽松模式，可以优先保障送达率，但无法保证所有外部邮件都经过加密。它改善的是部分传输链路，不等同于端到端加密。
A6：因此，配置选择取决于企业真正要防范的风险。若目标是尽量减少互联网明文传输，机会式TLS有一定意义；若目标是确保特定外部通信必须加密，就需要对通信对象实施更严格的协同和约束。
A7：但是对最终的实施效果还有顾虑：
过于宽松，可能投入后仍有大量明文；
过于严格，又可能造成丢信。
邮件加密方案必须同时回答覆盖范围和业务连续性两个问题。
0x2 群友分享
【安全管理】
《绿灯变死局：当谷歌微软的CI/CD全线通过，攻击者已拿走了永久权限》
【安全资讯】
【公告】关于 AI 生成漏洞报告提交违规行为通告及成长守卫分规则更新
《Anthropic确认Claude突破测试环境，入侵3家组织》
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
往期群周报：
关于国产大模型安全能力评估与跨网数据流动监控的探讨｜总第319周
OVTP范式下的权限管控、域名异常指向溯源与AI大模型告警研判探讨｜总第318周
如何进群？
如何下载群周报完整版？
请见下图：
