将风险管理框架（RMF）融入开发运维
信息安全应位于每个在用系统的核心位置。美国《联邦信息安全管理法案》（FISMA）规定，通过基于风险的网络安全评估后，信息技术系统即可获得运行授权（ATO）。
ATO问题
但是，ATO过程可能会给现代开发运维（DevOps）流程带来一些挑战，因为此过程要求授权官员（AO）在系统投入运行之前针对预设的风险控制措施批准系统。
由于假定系统的网络安全状态三年内不会发生重大变化，ATO有效期通常定为三年。但这个假定往往很不现实，导致“一劳永逸”式ATO不足以保障系统安全。所以，我们需要重新评估和授权系统，整个成本和最终用户交付时间表也就受到了负面影响。而且，这也违反了开发运维的敏捷原则：
采纳持续的集成、测试和交付
将运维嵌入团队，内化交付和维护方面的专业知识
风险管理框架（RMF）解决方案
卡内基梅隆大学的一项研究表明，风险管理框架（RMF）可通过持续授权决策或持续重授权，替代传统的三年ATO过程。题为《将风险管理框架应用于联邦信息系统：安全生命周期方法》的指南又名NIST SP 800-37，提供了保护、授权和管理IT系统的结构化过程。RMF定义了过程周期，可以通过运行授权（ATO）和集成持续风险管理（持续监视）来实现初始系统防护。
RMF将传统认证和认可（C＆A）过程转换为六个步骤，一步一步将信息安全和风险管理活动集成到系统开发生命周期中。这六个步骤是：
步骤1：分类信息系统
步骤 2：选择安全控制措施
步骤 3：实现安全控制措施
步骤 4：评估安全控制措施
步骤 5：授权信息系统
步骤 6：监测安全控制措施
RMF假定这些系统“已被评估为具有足够健壮的系统级持续监视程序”，并且与开发运维的核心原则无缝贴合，从而为DevSecOps铺平了道路。
开发运维中的安全
安全通常在软件开发的测试阶段受到重视，而安全活动常在软件开发过程之外进行。因此，安全活动的结果呈现在不适用于任何软件开发活动的文档中。
我们的目标应该是指导新活动的开发并调整现有活动，使之能够将安全有效融入敏捷过程中。通过在持续集成/持续交付（CI/CD）流水线中插入必要的步骤，将安全活动纳入软件开发生命周期（SDLC），可帮助开发团队将安全和合规功能无缝集成到常规工作流程中。
持续重授权的好处
RMF的持续重授权概念直接符合开发运维的四个重要方面：
团队和角色间的协作
基础设施即代码（IaC）创建脚本化基础设施配置
任务、过程和工作流的自动化
应用程序和基础设施监测
持续重授权将授权视角从事件更改为流程，令系统更加安全。这是因为持续重授权能够：
减少开发过程中的错误
提供持续反馈和监测
随时可用
可重复
减少部署和错误解决耗时
响应业务需求
一开始就应引入安全和运维团队，还有流水线相关的常规活动，确保在流水线中建立起正确的安全步骤。团队之间协同一致，有助于建立和增强对软件开发中所用流水线的信任。在软件开发过程早期布置安全要求，可以帮助开发人员将必要的安全保护措施织入工作流程当中，建立起安全团队信任的交付流水线。
自动化过程和工作流可以减小人为失误造成的缺陷。通过在流水线中嵌入自动化安全控制措施与测试，应用开发人员能够交付性能更高、质量更好的产品。而自动化无需人工干预的任务和批准手续，可以帮助应用开发人员规避瓶颈，更加快速地交付功能。
将安全作为推动力
许多人认为安全是软件交付的障碍，而且是不可避免的障碍。但事实上，安全可以提升整个开发运维的速度。将安全正确集成到开发运维中可加速软件交付，因为整个软件开发生命周期（SDLC）中都在持续完成安全检查和修正缺陷。
这对每个人来说都是个好消息。开发人员看到自己的产品可以更快部署。安全团队可以更轻松地授权系统——因为本就是遵从组织策略开发的。运维团队继承了值得在自身网络上运行的系统。
此外，安全团队可以通过审计跟踪、治理措施和实时合规报告，在SDLC的每个步骤中收获透明度和有用洞见，无需等待开发人员在开发后生成和共享报告。这些持续的洞见，加上对可信流水线的信心，消除了安全人员与开发团队间来回往复的浪费，令ATO快上许多。
当安全完全集成到整个软件开发、维护和运行生命周期中时，便可以借助足够健壮的系统级连续监测程序，实现持续重授权了。
