您的组织真的准备好迎接 DevSec 了吗？接受测试吧。

2020 年才刚过半，我们却已走在创下严峻数据泄露记录的路上，被盗数据量与 2019 年上半年相比激增了 273%。如今，更准确的问题或许是：还有多少数据尚未被盗？随着 COVID-19 疫情等全球性事件的发生，此类攻击的频率和威力不断攀升，目标也变得愈发脆弱。

我们早已达成共识：安全不再是可选项，我们必须采取先发制人的策略。要实现这一目标，SDLC 中的每个人都必须具备安全意识，尤其是开发人员。这就是 DevSecOps 中“DevSec”的含义，它是当前环境下理想的软件开发方法论，但许多组织尚未做好充分准备来有效执行。DevSecOps，

请结合您在组织中的角色思考以下问题。如果接受 DevSec 测试，您的组织表现如何？

DevSec 自我评估：您的 SDLC 环境是否已准备好培养具备安全意识的工程师？

1. 内部开发流程中是否将安全放在首位？
   各种网络安全风险因素可能让首席信息安全官（CISO）彻夜难眠，但令人担忧的现实是，尽管许多公司越来越重视安全，但其内部方法可能不足以化解潜在的灾难（或者至少会给应用安全团队带来巨大麻烦，并导致软件交付延迟）。
   DevSecOps 可能是目前安全领域的理想境界，但很少有公司真正采用这种方法。如果您仍在使用敏捷（Agile）甚至瀑布式（Waterfall）开发，那么安全通常仍被视为远离流程、在 SDLC 后期才介入的专家领域，他们往往会突然出现，要求开发人员修复代码漏洞，从而打乱工作节奏。在这种环境下，推动 DevSec 文化将充满挑战：开发人员热爱并优先考虑功能构建，且缺乏足够的安全实践经验，难以将其视为理想的技能提升路径。事实上，他们与安全的接触往往伴随着挫败感和负面情绪。必须迅速纠正这一点，才能让软件开发流程中的每个人都树立起安全至上的意识。
   ‍
2. 在威胁建模方面，您的组织是否仍在疲于奔命？
   一个令人警醒的数据是，60% 的中小企业在遭受成功的网络攻击后六个月内倒闭，就像其他灾难一样，如果没有充分的规划，其影响将远超预期。
   威胁建模是安全最佳实践的关键要素，它使应用安全专业人员能够评估攻击面的全貌，并构建适当的防御、对策和规划。在全面拥抱 DevSecOps 的公司中，安全功能在 CI/CD 流水线的早期阶段就已启用，且不会像过去那样拖慢生产进度。安全、安全编码和持续交付都是流程的一部分，开发团队获得了所需的资源和接触机会，成为产出严密代码的核心引擎。
   ‍
3. 开发经理是否优先考虑安全最佳实践？
   无论他们是否愿意，开发经理都是团队的榜样。这不仅仅关乎文化和氛围，比如在办公室穿人字拖或如何“向上管理”。他们的工作重点不可避免地会被团队成员吸收，如果安全不是关键目标，或者在培训和支持方面缺乏规划，那么下属工程师就会错失良机，企业也将面临不必要的风险。
   ‍
4. 开发人员是否有理由关心安全？
   根据我的经验，让一个人产生抵触情绪最快的方法，就是告诉他们必须做一些与其当前方法格格不入的事情，却不解释原因。
   
   被告知要“改变”意味着之前的方法是错误的，而实际上在许多情况下，这只是一种改进，有望让后续工作更轻松、更高效。要真正拥抱 DevSec 运动，首先需要给开发人员一个关心安全的理由——毕竟在大多数组织中，这仍然被视为“别人的问题”（即被锁在遥远房间里的应用安全专家的问题）。
   
   如果安全不是共同责任，DevSecOps 就无法奏效。开发人员需要合适的工具、支持和培训来履行职责……而这需要时间来推广和完善，并将其作为整体安全计划的一部分。最糟糕的方法是那种让人不知所措和产生疏离感的方法，当开发人员面临过多相互冲突的优先级，且在没有帮助的情况下难以应对时，往往就会出现这种情况。这是一种文化转变，不可能一蹴而就。
   ‍
5. 您是否依赖少数几位“安全独角兽”来承担众人的任务？
   安全专业人员非常短缺，我们需要的远不止目前这些。这是事实，但越来越多的开发人员正在转向更侧重安全的岗位。通常，他们的头衔可能是“安全工程师”或“DevOps 工程师”（幸运的话，我们迟早会看到这个头衔演变为DevSecOps 工程师！）。一名出色的 DevOps 工程师能够为几乎任何应用程序开发功能，并使用真正的 CI/CD 流水线进行部署。他们负责端到端的全流程工作，通常具备良好的安全意识。从这个意义上说，他们确实像魔法一样，因此也十分稀缺。
   
   然而，一些公司犯了错误，他们雇佣了这些专业工程师，把他们扔进团队，期望他们能解决开发流程中每个阶段的所有安全问题，并认为这本身就是万灵药。如果让您的 DevSecOps 魔术师负担过重，您最终会回到原点——在没有检查、平衡和安全精度的情况下交付不安全的代码。至关重要的是，要提升整个开发团队的技能，并在积极的安全环境中培养他们，使他们有能力以有意义的方式分担工作。

找到您希望在组织中看到的改变。

如果您将稳健的培训作为安全计划的一部分，您就会在开发人员中发现一些“隐藏的宝石”。尽管他们在日常工作中可能经历过负面体验，但这些人对安全编码和安全最佳实践有着某种热情。他们是团队中安全倡导者的最佳人选；作为安全与工程之间的联络点，他们能为他人树立榜样，保持高安全意识，并协助开展参与度计划。他们的人际交往能力对于在更广泛的范围内传播安全理念，以及向管理层和安全团队传达开发人员的需求也至关重要。

探讨“我能从中获得什么”是一个积极的进步。

即使是最崇高的人，也需要一点“胡萝卜”来尝试陌生的领域，或者参与那些学习曲线并不那么愉快的活动。
从“开发”跨越到“DevSec”对开发人员的职业生涯是一个巨大的提升。具备安全意识的开发人员努力理解安全，在自己可控的范围内承担责任，并秉持“只有安全的代码才是高质量代码”的理念。通常，开发人员希望进步、解决新问题并创造令人羡慕的功能，从而在同行中脱颖而出。为他们提供通往更高水平软件开发的路径，这是一个双赢的局面。

打造您的 DevSec 梦之队，永远都不晚。

如果您管理开发人员、领导应用安全意识团队，或者您是众多致力于制定安全计划策略的智囊之一，现在是时候比“左移”更进一步了。通过正确的培训、工具和环境，您可以为开发人员创建一个安全孵化器，这将为各方带来丰厚的回报。如果这份清单强调了一些需要改进的领域，那么您现在就有一个绝佳的机会，为您的组织打造一个以 DevSec 为导向的工程部门，从而从 SDLC 的最开始就降低风险。