你写出健壮的代码，并能快速修复漏洞。这是一个良好的开端，但受监管场景下的软件审计会考察得更加深入。审计人员会审视你整个软件开发生命周期，检查你如何管理变更、采用何种测试方法，以及如何开展风险评估。
安全需要一套覆盖设计、实现与部署的稳固框架，其中包括数据处理与用户访问控制等更广泛的领域。
你需要为更全面的安全审查做好准备。本指南将帮助你理解这些关键领域，并详细说明审计人员重点检查的内容。内容速览→
这里是一些工具评估经常忽略的部分：今天最安全的系统是7年后你仍然可以修补和审核的系统。
将安全性作为生命周期学科意味着维护和审计阶段关注长期支持、向后兼容性和可重复构建。如果你无法重复你所发布的版本，你无法自信地进行修补、认证或解释。
RAD Studio 13增加了一个非常实用的机制来控制更改：GetIt包版本管理，这样团队可以选择特定版本，而不是被迫使用最新的包。这并不起眼，但正是如何减少意外行为更改并保持审计证据一致的方式。参考：RAD Studio 13 Florence的新功能。（ embarcadero.com）
这里的定位很简单：RAD Studio 作为一个安全的开发环境，用于长期存在的、受监管的系统，基于工具链的稳定性、明确的控制和减少依赖的复杂性。
大量的操作安全是减少你无法控制的隐藏层。RAD Studio 强调真正的原生编译和可预测的行为。
但这并不意味着“原生的就是自动安全的。”这意味着系统可以更简单地进行推理和更容易地进行稳定，这是运营安全的两个核心属性。
表格：两种常见的部署形状及其对运营安全的影响
| 维度 | 本地编译（较少的层） | 运行时密集型（更多层） |
| 攻击面 | 较小的堆栈进行修补和验证 | 更多需要修补的组件（虚拟机、嵌入式浏览器、运行时） |
| 变更控制 | 减少强制升级 | 由运行时安全建议驱动的更频繁的升级 |
| 审计证据 | 更容易映射版本 → 实体 | 更难证明确切的有效运行时版本控制 |
| 操作行为 | 更可预测的性能 | 更多由于运行时行为变化导致的方差 |
许多团队在人工智能方面受到IP和合规性限制，特别是在代码或数据可能离开受控环境的情况下。
RAD Studio 的 AI 方向被设定为可选的：对需要它的团队有帮助，但不会强迫那些由于政策限制无法采用它的团队。在受监管的环境中，这很重要：一个需要云 AI 来完成核心工作流程的工具可能对安全开发来说是一个决定性因素。采用可选的方法，您可以在符合您的政策的情况下采用 AI 帮助，而不是围绕供应商的默认设置重新编写您的治理模型。
关于本版本中AI方向和工具的官方概述，请从这里开始：RAD Studio 13 Florence中的新功能。（ embarcadero.com）
详细内容请参考：Regulated Software Security – The Audit Survival Guide
