也许您的组织已经在试验 DevOps 工具，或者正在考虑如何转向 DevOps。也许您仍然依赖于临时的流程。然后突然间，您的 C 级高管或审计员提出了对安全且敏捷的开发流程进行标准化的需求。DevSecOps 由此应运而生。
为了缓解 DevSecOps 采纳带来的挑战，您需要使其成为团队合作。以下是您需要做的。
从小处着手
至关重要的是，从一个小型概念验证项目开始，应用您吸取的经验教训，然后在您的成功基础上再接再厉。选择小型项目最好通过让业务利益相关者参与进来，他们愿意将他们较小的项目之一转移到 DevSecOps 开发模型中。应用程序迁移到云端是进行此类概念验证项目的绝佳时机。
在您的组织内培养 DevSecOps 倡导者
就像 DevOps 一样，转向 DevSecOps 最终是关于人和文化。
转向 DevSecOps 需要您建立内部 DevSecOps 倡导者来传播福音。以下是一些您应该考虑的日常倡导者和拥护者
- 一位个人贡献者和早期采用者，渴望构建更安全的应用程序：想想其他开发人员遇到问题时会向谁请教。
- 一位业务利益相关者，他们将通过提高安全性或通过转向 DevSecOps 来促进销售而受益：想想销售人员或业务开发人员，如果您的公司能够安全地交付更多功能和版本，他们就能更好地为客户服务。一个政府机构经理（拥有预算控制权），他们的部门正在将其遗留应用程序迁移到云端以满足 FedRAMP 合规性，这可能是另一个潜在的倡导者。
- 开发团队项目负责人，他们管理交付代码的团队，但却陷入无休止的安全更新循环中，以缓解进入生产环境的安全问题：DevSecOps 为他们提供自动化和框架，可以减轻他们团队的一些工作负担，以便他们可以将注意力放在更具战略意义的任务上。
在团队支持下逐步实施自动化
自动化安全检查对一些高管和财务人员来说听起来很有吸引力；他们听到“自动化”，就想到“通过裁员来节省资金”。这种观点不利于获得开发人员的支持。
当您从 DevOps 转向 DevSecOps 时，自动化和安全性之间存在微妙的平衡。分析您的 DevOps 工具链中已有的自动化工具，并确定它们是否支持安全集成。然后，您可以从那里构建您的自动化策略。在实施的每个步骤中与将从自动化中受益的团队合作。您希望为您的团队沟通前进的方向，并消除任何关于因 DevSecOps 而失去工作的在家工作焦虑症。
防止开发人员负担过重
当您将安全责任添加到他们现有的工作负载中时，您可能会面临造成开发人员负担过重的风险。毕竟，我们正进入一个对开发人员友好的应用程序安全工具进入市场的时代。
如今，太多的应用程序安全工具是为安全团队设计的，通常需要数小时到数天的时间，安全团队才能将他们的调查结果交付给开发团队进行补救。您的领导层有责任落实工具、培训和框架，以帮助防止开发人员负担过重。
最后一点
快速进入 DevSecOps 轨道意味着照顾好您的员工，并在他们担心自动化时积极主动。当团队在推动转型发生的过程中发挥积极作用时，他们从 DevOps 到 DevSecOps 的转型中获益最多。
评论已关闭。