DevSecOps 中的规划和设计确定安全性是从一开始就内置在产品中还是以后以应对风险。 在早期做出有力的决策，有助于团队将安全内建于设计中作为默认做法，并利用数据和现代架构来指导构建内容。
此功能区域介绍了如何通过安全设计实践、告知决策的数据和见解以及塑造产品的技术体系结构和设计选择，将安全性内置到最早的工作阶段。
随着组织成熟，规划和设计从反应式、传统驱动型活动转向更加不同的位置。 威胁建模从单个工作发展到业务级规则，数据从默认报告发展到预测分析，体系结构从即席设计发展到现代、弹性甚至抗量子模式。
核心功能区域
DevSecOps 中的规划和设计侧重于三个子功能：
设计安全：在规划期间如何应用威胁建模和保护设计做法。
数据和见解：产品、团队和客户数据如何告知决策和策略。
技术体系结构和设计：体系结构模式如何演变为现代、安全且可复原的方法。
阶段
规划和设计经历五个成熟度阶段。 这些阶段展示了 DevSecOps 原则在最早的开发阶段如何出现，从由旧投资塑造的被动规划到在行业中创建区分地位的规划和设计实践。
| 总体阶段 | 阶段名称 | 它的外观 |
|---|---|---|
| 临时 | 响应式 | 传统投资推动活动，缺少利用创新的机会。 |
| 启动 | 故意 | 对规划进行整理并提供信息支持，可促进协作并实现更加协调一致的成果。 |
| 协调 | 协调 | 人与技术的协同在各类产品和服务中逐渐显现。 |
| 精简 | 集成 | 在规划和设计方面的优先投资表明明确的价值。 |
| 开创性 | 差异化 | 规划和设计卓越导致行业处于不同地位。 |
响应式（临时）
在团队开始有意识地进行规划之前，既有投资往往会主导相关行动，并限制采用较新方法的机会。
设计安全：设计阶段的安全性仅由个人安全参与者处理。 对于大多数团队来说，这都是事后才会想到的事，甚至根本不会考虑。
数据和见解：数据收集和报告保持在默认级别。 团队仅定期评审它们，很少使用它们来推动操作。
技术体系结构和设计：设计和体系结构是临时的，缺乏标准或准则。 开发成本很高，几乎没有代码共享或使用开放源代码。
有意（正在启动）
对规划和设计进行组织并为其提供依据，能够促进协作形成，并带来更加协调一致的成果。
安全设计：威胁建模在技术层面进行，并应对严重级别较高的问题，但通常发生在流程后期。 团队使用数据加密和安全通信协议。
数据和洞察：团队利用现有产品信号推动改进。 客户见解有限，不匹配的数据使得分析变得困难。
技术体系结构和设计：Teams 开始采用云和微服务等新式模式，或在嵌入式系统中使用硬件安全模块（HSM）。
协调（编排）
随着规划和设计变得更加有意，人和技术一致性开始出现在产品和服务中。
设计安全：威胁建模使用定义的流程和标准在产品级别运行。 智能应用包括防护措施和防范威胁，例如提示注入。 强大的身份和机密信息架构已建立到位。
数据和见解：产品数据收集、策展和共享使决策更快、更自信。 实时产品监视提高了透明度，团队见解改进了工作流和流程，并定期收集客户见解并影响路线图。
技术体系结构和设计：云和微服务等现代模式的采用范围更广。 嵌入式体系结构包括硬件加速的安全性和安全固件更新。
集成（精简）
通过优先投资于规划和设计，其效益会逐渐显现，并体现出相应的价值。
安全设计：威胁建模扩展到业务级别，包括缓解 AI 威胁（如内存中毒、知识损坏和代理推理操作）的努力。 多代理通信和信任链经过仔细考虑并得到适当的保护。
数据和见解：跨系统产品数据统一和实时处理提供全面的可见性，并将产品改进连接到关键业务指标。 严格的团队见解收集支持持续改进，客户见解有助于推动策略。
技术体系结构和设计：Teams 采用高级方法，例如无服务器体系结构、更广泛的容器使用和选择性移动到多云环境中。 设计还支持无线更新和微分段。
差异化（开创性）
规划和设计卓越帮助组织在行业中树立了不同的地位。
安全设计：团队创建高级滥用场景，并与开发人员和系统管理员协作开展安全检查。 红队演练和类似策略有助于验证设计和概念的有效性。
数据和见解：跨产品、团队和客户数据的探索揭示了客户需求、流程改进和业务影响之间的更深层次关系。 预测和游戏规划可以通过预测分析实现。
技术体系结构和设计：组织开发可以抵御量子计算机攻击的加密算法。