最近，网络安全行业出现了一些非常受欢迎的动向。在许多组织中，围绕着在软件构建中尽可能早地优先考虑安全问题的情绪似乎已经开始改善。这一点，再加上拜登关于网络安全的行政命令等官方措施，已经非常清楚地表明，每个人都需要尽自己的努力来确保软件安全和数据安全。尤其令人振奋的是，围绕开发人员在维护安全编码标准方面的作用的对话继续发展，甚至在政府层面也是如此。

然而，对话中缺少一些东西。行政命令表明，开发人员需要经过验证的安全技能，然而目前还没有这种官方认证。许多公司在寻求合规性和更高的软件安全标准时仍然遵循NIST（他们提供了更新的指南），但如果我们考虑的是大幅减少漏洞的策略，同时结合正确的工具并保持发布速度，那么大多数策略都太过通用，无法创造出理想的结果。这也是很多公司陷入困境的原因，他们坚持进行有限的开发人员培训，或者没有在一般的基础上使他们具备实际的、可操作的技能。

有安全意识的开发人员不是长在树上的，但有了正确的工具，他们可以更快地得到培养和提升。为此，我们很高兴地宣布，根据美国政府行政命令的指导方针，我们自己的NIST合规性专有课程。

为开发者提供有意义的、代码级的支持

在这里，我们使用NIST的行政命令关键型（EO-critical）软件指南，将课程结构化，以达到五个关键目标，最终提高政府最高层使用的重要软件的安全性，最好是作为从头开始的高质量开发的基准。

为了在开发团队中实现真正的突破，任何技能提升都必须超越理论，并以一种不会导致在工作和培训之间不断切换环境的方式来寻找答案和保持敏捷的方式来实施。一丝不苟的安全实践（更不用说安全团队了）被视为按时开发冲刺的障碍，并严重阻碍了一般以功能为中心的工程师的风格。 

根据开发者的需求定制的短小精悍的微观学习，得到的回应要少得多，而且能带来令人难忘的实用技能培养。 

看看我们的NIST课程是如何安排的吧。

目标1：保护EO关键软件和EO关键软件平台免受未经授权的访问和使用。

安全错误配置和不恰当的认证做法被攻击者用来成功渗透系统、接管账户和窃取数据。它们是一种常见的错误，如果被成功利用，会导致巨大的问题。

在 Secure Code Warrior Learning Platform，开发人员可以根据真实世界的代码片段进行挑战，这些代码片段准确地反映了这些bug在日常工作中的表现，并让他们找到准确的解决方案来保护它们。对于DevOps工程师来说，确保基础设施的安全需要细致的访问控制配置，在Terraform、CloudFormation和Ansible等基础设施即代码（IaC）语言以及Docker和Kubernetes中使用的代码中，有专门的挑战来满足这一要求。

目标2：保护EO关键软件和EO关键软件平台使用的数据的保密性、完整性和可用性。

对于这个目标，所有的道路都通向访问控制。破损的访问控制最近取代了注入缺陷，成为OWASP 2021年十大排名的首要条目，它是一个严重的错误，需要有安全意识的开发人员的技能来尽早发现和修复。

该课程涉及代码层面的最小权限等概念，并帮助灌输将用户账户的访问限制在必要的领域内的方法，作为最佳实践。

目标3：识别和维护EO关键软件平台和部署在这些平台上的软件，以保护EO关键软件不被利用。

在大型组织中，最大的挑战之一是维持对目前所有不同的软件、系统和组件的安全监督。当涉及到风险管理和补丁时，这些内容必须是任何安全计划中的优先事项，开发人员要高度警惕地进行安全维护。 

在Secure Code Warrior Learning Platform ，开发人员可以进行挑战，这将有助于他们识别和修复脆弱的组件，以及基于权限的安全错误配置。

目标4：快速检测、应对和恢复涉及EO-关键软件和EO-关键软件平台的威胁和事件。

不幸的是（也是对时间和金钱的浪费），许多组织在处理网络安全问题时仍然专注于事件响应，而不是预防。这是一种我们正在努力改变的文化，而开发人员在接受适当的安全最佳实践培训后，可以提供预防性的火力支持。 

目标4要求开发人员，在他们的角色范围内，持续监控他们环境中的安全，以及软件和网络层面的端点。日志和监控不足是另一个常见的、阴险的错误，工程师能够在日常工作中成功驾驭这个问题至关重要。

在Secure Code Warrior Learning Platform ，开发人员可以通过挑战来磨练这些技能，无论是使用网络、API还是云语言。

具有可持续性的安全意识。

目标5：加强对人类行为的理解和表现，促进关键的EO软件和关键的EO软件平台的安全。

这一条比较笼统，但却是最需要实现的......如果不掌握前四个目标，就无法做到这一点。这条准则要求经常开展安全意识活动，并且所有关于EO关键软件的 "人类行动 "都由那些在其角色和职责范围内受过充分培训的人执行。

除了安全配置和访问控制之外，开发人员也是最接近和接触代码的人。他们的安全技能必须得到培养，为了达到NIST规定的高标准，实践课程结构可能是解决这个问题的有效方法，特别是对于大型开发团队。 

今天就开始增加你的开发团队的经验值和安全智商。

本文最初发表于 安全大道.此处已对其进行了更新和聚合。

‍

我们的集体心理几乎根深蒂固，认为更多的好东西是更好的东西。如果你有一件你真正喜欢的东西，那么拥有两件或三件，甚至更多，也没有什么不对。毕竟，你不能拥有太多的好东西，对吗？

不幸的是，虽然这种逻辑在某些情况下行得通，但有时在较高的音量下很快就会失灵。在某些情况下，你会开始体验到收益递减。第 13 块巧克力蛋糕到底能给你带来多少额外的价值或快乐？还有一些时候，好东西做多了，会给你或你的组织带来巨大的风险。

太多的网络安全工具

近年来，网络安全工具在大多数组织中都呈现出失控的态势。Dark Reading》杂志的一项研究发现，大多数首席信息安全官平均依赖 55 到 75 种不同的安全产品或应用程序来保护他们的网络。然而，攻击仍然屡禁不止。根据《Verizon 2023 年数据泄露调查报告》，成功的攻击正在增加，其中最复杂的攻击需要比以往更长的时间才能被发现。

攻击者如何规避表面上看起来不可能完成的75种或更多的网络安全工具？事实是，他们经常会触发警报，但人类防御者忙于维护他们的防御工具或应对每天数以千计的警报而没有注意到。拥有大量的安全工具实际上可以给攻击者提供他们所需要的掩护，以保持不被发现。

TechRadar最近的一份报告强调了拥有太多的网络安全工具所带来的负面影响。在接受调查的公司中，71%的公司认为他们拥有的工具比他们的网络安全团队能够成功管理的还要多。这实际上导致他们的安全态势随着更多工具的增加而变得更糟。事实上，与认为更多的工具等于更多的安全相反，绝大多数的受访者报告说，由于在他们的环境中安装了所有的网络安全工具，他们的安全感大大降低。

随着大多数组织向云计算的大规模转移，情况只会变得更糟。将大量网络安全工具分层到网络中以覆盖所有可能的攻击途径的做法之所以流行，是因为在一个几乎完全是内部资产的时代，这种策略是可行的。或者说，至少企业没有那么快遇到收益递减和负面的后果。然而，在云环境中，你增加的工具越多，你产生的复杂性和漏洞就越多。

除了维护重叠工具的工作，以工具为中心的方法的另一个大问题是，随着更多的工具上线，肯定会出现大量的误报。追查误报会耗尽人类安全人员的所有时间，而对组织没有真正的好处。同时，真正的攻击可以很容易地隐藏在所有的错误警报中。网络安全专家可能永远不会发现真正的威胁，直到为时已晚。

一个更好的方法

从你的环境中删除所有的安全工具将是灾难性的。但是，你也不希望有这么多的工具，以至于那些真正能提供帮助的关键工具没有得到足够的重视。重要的是，要找到正确的工具选择，并确保你没有太多的工具耗费你的时间和资源。

让工具整合发挥作用的关键是同时投资于以人为主导的安全方法。这应该包括使用一种传统上没有被部署到该角色的资产：负责编码被攻击者锁定的应用程序和软件的开发人员团队。

虽然传统上开发人员没有安全任务，但这种情况正在改变。事实上，鼓励开发者专注于安全是DevSecOps运动的一个关键方面，在这个运动中，每个人都对部署安全的应用程序承担一些责任。没有人期望开发人员突然成为安全专家，或在他们的组织中承担安全的主要责任，但教他们如何编写安全的代码，并奖励他们完成的工作，可以在很大程度上为消除所有这些重叠的安全工具奠定基础。

如果你从好的、安全的代码开始，那么你就可以很容易地开始消除数以百计的网络安全工具，这些工具被设计用来扫描常见的漏洞和欺诈行为。最终，你将培养一个环境，让开发人员创建安全的代码，而一些选定的网络安全工具可以作为一个额外的检查，便于安全团队监控和维护，而不会因为太多的所谓的好东西而过载。

毋庸置疑，网络攻击正在上升。根据Verizon 2021年数据泄露调查报告，今天的威胁形势比以往任何时候都更加危险。各种规模的组织正经历着更多的攻击，而针对他们的威胁者的复杂程度也更高。而攻击者的成功率也在急剧上升。

分析最近的攻击，有助于揭示黑客在这次对网络防御的空前突击中所使用的一些最常见的漏洞和技术。一些最流行的攻击，例如那些进入开放网络应用安全项目（OWASP）2021年十大安全风险和漏洞的攻击，涉及到窃取或以其他方式破坏证书。而根据Akamai进行的安全研究，绝大多数（近75%）直接针对API持有的凭证。

API的崛起和可能的毁灭

难怪应用编程接口（大多被称为API）在几乎每个组织的网络中都在上升。它们是大多数基于云的服务的重要组成部分，这些服务正在迅速取代大多数公司、组织和政府机构的内部资产的功能。如今，你几乎无法在没有云的情况下运行任何种类的业务或任务，特别是那些面向公众的业务。这意味着API肯定会成为支撑每个网络中相当多的服务的粘合剂。

API的神奇之处在于，它们在网络资源分配方面大多是小而不显眼的。而且它们是完全灵活的，因此它们可以被赋予执行几乎任何工作的任务。就其核心而言，API是为控制或管理一个特定程序而定制的单个软件片段。它们可以被用来执行非常具体的功能，如从主机操作系统、应用程序或服务中访问数据。

不幸的是，正是这种同样的灵活性，以及它们往往很小并被安全团队忽视的事实，使得API成为有吸引力的目标。大多数API是由开发人员设计的，具有完全的灵活性，例如，即使它们所管理的核心程序被修改或改变，它们也能继续发挥作用。而且很少有标准。几乎就像雪花一样，许多API都是独一无二的，因为它们是为特定网络上的单个程序提供特定功能而创建的。如果它们是由那些没有很好的安全意识的开发者编写的，或者他们没有特别专注于安全，那么它们可以而且很可能会有任何数量的漏洞被攻击者发现和利用。

可悲的是，这个问题很快就失控了。据Gartner称，到2022年，涉及API的漏洞将成为所有网络安全类别中最频繁的攻击载体。

攻击者想要破坏API的关键原因不是为了接管API执行的任何具体功能，而是为了窃取与之相关的凭证。API最大的问题之一，除了有很多漏洞之外，就是它们的核心功能往往被过度授权。为简单起见，大多数API在网络上有接近管理员级别的访问权限。如果攻击者获得了对一个API的控制权，他们往往可以利用其权限对网络进行更深入、更大量的入侵。而且，由于API有权限执行攻击者重定向的任何任务，他们的行动往往可以绕过传统的网络安全监控，因为API没有违反任何规则，这要归功于其访问所有区域的VIP后台许可。

如果企业不小心，他们的网络和云中的API的兴起，如果被攻击者盯上，也会带来大麻烦。

捍卫API

尽管API的情况变得很危险，但它远非无望。通过像DevSecOps这样的运动，有很大的努力帮助开发人员提高安全意识，并将安全和最佳实践引入软件创建的所有方面，从开发到测试和部署。将API安全作为培训的一部分，对于任何想在2022年及以后抵御API剥削趋势的组织来说都是至关重要的。

也就是说，在API安全方面，现在有一些真正好的最佳实践可以实施。

第一件事是为所有的API包括严格的身份控制。在分配权限时，你几乎应该把它们看成是人类用户。仅仅因为一个API被设计成只做一个特定的功能，你就必须考虑如果一个攻击者能够破坏它，会发生什么。考虑使用基于角色的访问控制。理想情况下，你最终应该对你的API和用户采用零信任原则，但这往往是一条漫长的道路。良好的身份管理是一个好的开始。只要确保将API作为该计划的一部分。

你还应该尽可能地严格控制你的API所进行的各种调用。如果你把这些调用限制在以上下文为中心的请求上，那么攻击者就很难为邪恶的目的而修改它们。你甚至可以将你的API分层，由最初的API对另一个API进行高度的上下文调用，这个API知道要寻找什么，以及要忽略什么。这可以成为一种有效的方式来限制威胁行为者可用的功能，即使他们能够利用和破坏该链中的API。

针对API的威胁当然看起来是压倒性的。但是，通过实施最佳实践，并协助和奖励那些成为安全卫士的开发人员，情况似乎不那么无望。通过良好的培训和实践，你可以建立一个强大的安全计划，即使攻击者以某种方式破坏了你的一个微小但重要的API工作母机，他们也没有什么回旋余地。

你上次进行公路旅行是什么时候？根据你所处的位置，可能只是最近才回到议程上，但真的，没有什么比开放的道路和获得风景的改变更好。 

当然，除非你是一个软件漏洞。

我们已经详细谈到了汽车行业网络安全措施松懈所带来的危险，像特斯拉和吉普车已经与安全研究人员合作，发现可利用的漏洞，如果不及早发现并及时修复，可能会导致严重的安全问题。我们也曾谈到，总的来说，软件安全仍然 处于狂野的西部。软件在我们身边无处不在，对于许多连接设备、车辆及其外围设备，所需的安全措施远远超出了最终用户的教育和警惕。

API漏洞正变得特别阴险，仅在过去6个月，恶意API流量就增长了300%以上。这是相当令人担忧的，因为现代汽车本质上是车轮上的API。它们是连接的，与其他应用程序非常健谈，并可能作为许多易受攻击的端点之一陷入目标攻击。 

当你的电动车充电器说得太多时

联网车辆的软件安全受到了严格的审查，但它们的配件呢？Pen Test Partners的天才团队在六个家用电动车充电品牌以及一个广泛的公共电动车充电网络中发现了几个代码级的漏洞。

谁在乎一个充电器？攻击者能得到什么？不幸的是，强大、深入的技术为我们加班工作的缺点之一是，一般来说，这些设备有一个糟糕的TMI案例。电动车充电器在基于云的环境中，通过API与配套的移动应用程序进行通信，如果不进行安全编码和配置，所有这些都容易被利用。根据设计，API为应用程序之间的通信打开了闸门，如果这些端点没有仔细配置，可能会有太多东西被分享--或者更糟的是，通过一个脆弱的应用程序后门访问。

Pen Test Partners发现了极其危险的漏洞，这些漏洞可能导致数以百万计的电动车充电器被劫持，还有几例允许接管账户和远程控制/访问账户的API授权问题，甚至还有可能通过同步控制多个电动车设备来破坏电网。这些问题都被修补了，但事实上，几行代码是攻击者与核心功能和服务基础设施完全中断之间的全部障碍，这令人深感担忧。 

这也不像是主谋的事情。例如，Wallbox在其API中有两个不安全的直接对象引用（IDOR），如果被利用，就可以接管账户。IDOR属于破损的认证，在OWASP十大API漏洞中位居第二。它像泥土一样普遍，这表明在学习和执行高质量代码方面的失败。我们不能坚持通过无数有漏洞的通信途径来连接敏感设备和应用程序，而配置不良的API就是这样。 

安全地使用汽车API需要教育和耐心

API安全令人沮丧的是，它被吹捧为新一波网络安全灾难的尝试和缓解，而实际上，它只是我们几十年来在网络开发中看到的同样的老问题的一个新设置。跨站脚本、注入、错误配置：听起来很熟悉？

最近来自NIST等组织的指标是有希望的，表明软件安全正在变得更加规范化和标准化。然而，我们仍然缺乏所需的专家，甚至无法对每天编写的大量代码进行保护。开发人员需要提高他们的安全知识和责任，而不是由他们来采取主动。如果你有一个团队在研究电器中的嵌入式系统，或可能把汽车变成某人的遥控玩具的API，那么你必须确保他们配备了他们所需要的东西来停止引入常见的漏洞。 

例如，一个安全的API和一个因XSS而易受攻击的API之间的差别很小，但开发人员需要被告知区分不良编码模式和良好编码模式的细微差别。除此之外，懒惰的开发过程在API配置中往往是照常进行的，许多人被赋予了巨大的权限，超过了它执行既定任务的最低要求，从而打开了如此多的额外威胁面和潜在的数据盗窃。这些因素需要在构建过程中加以考虑，但如果它们没有被根植于可接受的开发实践中，那么这个过程将继续成为一个风险因素。

避开新的威胁行为者的乐园

API作为威胁者的目标的急剧增加表明，人们的注意力正在转移到一个被认为是低垂的果实上......在这种情况下，除了潜在的车辆接管形式对生命的威胁外，它还可能是一个通往重大报酬的管道。 

如果对API的安全问题听之任之，那么以后肯定会出现问题，最坏的情况是可能造成毁灭性的后果，最好的情况是令人沮丧的返工和低性能。作为软件通信生态系统的一部分，它应该是一个重要的考虑因素，并在一流的安全计划中占据重要地位。这方面的关键是把每个API当作人类来对待，并评估它应该有哪些访问权限。会计部的吉姆是否应该访问整个公司的所有敏感法律文件？也许不应该，而且一般来说，在现实世界中的人员的情况下，访问控制是正确的。对于API来说，情况并非如此，重要的是要记住，它们是强大的话匣子，如果不采用与其他事物相同的零信任方法进行配置，它们会让所有人知道你的秘密。

组织必须保持高度警惕，而开发人员是需要在现场的眼睛，以创建高质量的代码，不受这些脆弱的绝望门户的影响。现在是时候让他们有机会作为有安全意识的工程师成长和发展了，他们要有实现这一目标的正确心态和在创建的关键阶段做出正确决定的实践技能。

本文的一个版本曾作为《福布斯》杂志的一个专题报道出现。 福布斯技术委员会.它已被更新并在此转发。

‍

没有什么比站在数据泄露的错误一边更有意义的了。起初，人们可能会否认，然后是恐慌。一旦所有的脏话都被说出来，CISO不得不在凌晨2点与公共关系部门进行电话会议，现在是时候卷起袖子开始工作，保护端点和系统，并迅速消除任何潜在的攻击载体。至少可以说，这不是野餐。 

然而，这是一个未来将降临到许多组织的现实，而且绝对必须通过一个全面的网络安全事件响应计划来准备。然而，问题是，这种被动的策略是大部分时间、资源和精力集中的地方，而不是在前期努力防止或减少网络攻击的潜在严重性。这有点像为疑似心脏病发作叫救护车；其结果往往不那么积极--更不用说更具破坏性--如果在为时已晚的情况下采取预防保健措施。 

为此，一个预防性的计划是什么样子的？让我们来探讨一下安全专家如何运用他们所掌握的所有工具来减轻每天不断增加的网络风险。

了解摆在面前的工作范围 

这似乎是显而易见的，但减轻网络风险的 "正确 "计划在不同行业之间确实有细微的差别，重要的是要预先了解需要什么来达到预期的结果。

目前存在哪些安全问题？它们占用了哪些时间和资源？其中有多少是重复出现的问题？这些都是重要的因素，并将给你一个基础的起点。考虑任何需要填补的角色，工具方面的差距，以及从专业知识和工具的角度需要什么，以确保端点的安全，减少攻击面，同时预先阻止其他潜在的风险领域。

最近的一份报告显示，11个行业在过去一年中每天都看到一个严重的漏洞，涉及至少一半的应用程序。特别是，公用事业、公共管理和专业服务行业平均需要288天来修补已知的漏洞。这是令人难以置信的缓慢，如果这些漏洞在打补丁之前被发现，攻击者有足够的时间进行严重破坏。这一点，再加上企业遭遇数据泄露的概率接近30%，清醒地提醒我们，对事件的反应是不够的，如果对大规模网络攻击的影响保持警惕并寄希望于最好的结果，风险实在是太大了。

为获得文化变革的认同做好准备

颠覆现状确实容易引起一些人的注意，但事实是，安全计划应该处于持续不断的改进状态。每个组成部分都应该保持相关性，新的发展应该被评估和考虑进去。 

强调预防性--而不是反应性--的方法可能不会被安全团队以外的人广泛理解，特别是在没有发生大的、坏的、安全事件的情况下。它可能被认为是没有坏的东西，不需要修复。在这种情况下，获得管理层的支持是至关重要的。他们需要考虑的一些更相关的要点是。

• 相对于突发事件的潜在成本，预防措施，如基于角色的培训和相关工具，可以节省时间和成本 
• 现在如何寻找和修复漏洞，以保证按时发布，减少安全团队的阻挠。
• 为什么从开发团队到发布，准备和预防潜在的安全风险，总体上可以节省更多的时间（更不用说大量现金）。从这个角度来看，在测试阶段发现的后期漏洞--或者更糟糕的是，在后期制作中发现的漏洞--平均可以提高3000%的成本。
  

至关重要的是，提议的文化变革要与业务目标保持一致，即使它们一开始看起来很不舒服。 

安全意识是什么，安全技能是一切

作为一个行业，我们经常谈论安全意识的重要性，这也是企业中每个员工越来越重要的组成部分。然而，仅仅停留在口头上的服务和被动的培训是不够的，特别是对于那些技术岗位上的人。

简单地说，任何接触代码的人，如果他们没有掌握安全编码的技能，就会有潜在的安全风险。对基本安全参数的一般认识是一个良好的开端，但如果没有良好的、安全的编码模式的背景知识，不良的习惯就会普遍存在，而攻击者正是依靠这种缺乏高质量的开发技能来完成他们的肮脏工作。 

不要撇开你的开发人员。

虽然态度正在转变，但许多组织的结构是这样的：开发人员很少在安全缓解计划中被真正考虑。一些行业--如银行和金融业--有严格的合规性和监管要求，导致所有员工都要加强安全实践和培训。虽然他们肯定领先于其他垂直行业，但地球上几乎每一个组织都可以从内部的安全意识开发者大军中受益，他们都有一个基准能力，可以在常见的安全漏洞发生之前嗅出它们。大多数企业还没有达到安全计划拼图的这一关键部分--如果我们有希望确保逐年增加的大量代码的安全，那么这就是必要的。

预防性安全应该从手指触摸键盘创建软件的那一刻开始，但不能指望开发人员单独弥补安全技能的差距。他们需要正确的工具集和上下文指导，以达到更高的代码质量标准，而最好的结果总是在成为他们日常工作的一部分，而不是在每年的合规性要求出现时才零星地推出的事后想法。

这篇文章的一个版本出现在 报道的版本出现在TechCrunch上。.它已被更新并在此转发。

‍

仿佛我们在 "无法命名的一年 "中还没有经历足够的破坏，2021年对美国政府来说是以震耳欲聋的巨响开始的，其形式是有史以来最严重的数据泄露事件之一。SolarWinds事件是一次毁灭性的、复杂的民族国家攻击，使一些政府部门和大型组织陷入恐慌，争相保护他们的端点。几乎所有SolarWinds软件的终端用户都受到了影响，这一事件充分说明了软件供应链中的网络安全和防御是至关重要的。

显然，网络安全很重要，但在供应链的背景下，网络安全究竟意味着什么？

普通开发团队中的网络安全状况

每天都有大量的软件被生产出来，每年有数十亿行的代码，而且随着我们逐渐数字化的生活方式所产生的需求，这种情况还在不断增加。到2024年，全球开发者人口将膨胀到近2900万，而目前还没有正式的认证来评估和认证他们安全编码的能力。这并不是说每个开发者都会产生或重复使用不安全的代码，但无疑存在着一个持续的风险，即基本的安全弱点可能被引入到我们信任的数据的软件中。

开发人员的评估标准是他们能否以最快的速度创建功能和发送代码。在大多数组织中，安全并不是他们成功的基准，但随着越来越多的公司意识到他们在软件创建的最早阶段预防常见安全漏洞的潜力，这种看法开始改变。然而，意识到和实施是两码事，由于大多数三级开发courses ，省略了任何围绕安全编码实践的背景，往往要靠开发人员的工作场所来弥补不足之处。如果技能建设和知识共享不经常或不相关，那么它很可能是无效的。因此，由于缺乏技能发展而导致的漏洞重复出现的循环仍未打破。 

自然，解决世界上的网络安全问题并不是普通软件开发者的责任；毕竟，企业雇用那些非常昂贵的安全专家是有原因的。然而，安全大师是供不应求的，而开发者肯定可以在减少压力方面发挥作用。 

但是，在防止毁灭性的网络攻击方面，这让我们--以及为关键基础设施和敏感组织开发软件的供应商--何去何从？这至少需要改变软件采购的现状。

阻碍安全软件供应链的陷阱

不幸的是，当涉及到软件供应时，一个链条只有最薄弱的环节才是最强大的，这句老话同样适用。如果你的公司已经加强了安全的最佳实践，投资于开发人员的技能提升，并转向功能性的DevSecOps环境（即每个人都分担尽可能安全地制造软件的责任），这真的并不重要；如果你使用一个有安全问题的供应商的软件，你将把它们继承到你的生态系统中并承担后果。

当然，安全团队应该帮助评估第三方添加到技术栈的安全性，但可以根据业务需要做出决定，在解决方案中没有什么选择。在这一点上，这可能是一个信任的练习。供应商是否像你的公司一样关心安全问题？供应商能否真正评估只有你才能理解的风险，以及你需要保护的资产？

透明度是评估供应商软件添加的安全可行性的一个重要因素。他们是否直截了当地介绍自己的安全实践？他们应该为自己保持数据安全的方法感到自豪，这应该是一个首要任务。如果安全实践没有在任何地方公布，或者没有任何信息，那么很有可能安全问题没有被放在首位。供应商应该能够回答技术问题，像ISO27001和SOC2这样的独立认证也无妨。此外，如果你不能 "查看引擎盖 "并扫描漏洞，作为你自己内部尽职调查和安全实践的一部分，那就别想了。

由于需求推动了软件需求的快速实施，特别是如果供应商的代码被折叠到现有的系统中，以在新的环境中执行操作，供应商和买方都需要在他们的游戏中处于领先地位，并且都应该让他们的开发人员作为地面上的靴子，在他们发货之前捡起常见的安全漏洞和缺陷。如果在现有的技术解决方案的蛛网中加入一个新的附件，可能会有成百上千的依赖关系被破坏，而一个小的故障可能会导致灾难性的失败。

那么，解决方案是什么呢？在公司内部从头开始编写所有的代码？如果是在1998年，这可能是有意义的。然而，正如我们不再 "询问Jeeves "最近的洗车店在哪里一样，我们需要实施现实的保障措施，在今天的环境中发挥作用。

仍然没有银弹，但有解决方案

对于买家来说，供应商软件和开发实践的安全assessment ，应该是整个安全计划和风险缓解计划的重点。围绕他们的认证、实践和开发人员的安全声誉提出问题。

供应商（实际上是任何创建软件的公司），必须准备好证明安全是最重要的，并且应该把重点放在提高技能上。具有安全技能的开发人员需求量很大，如果有合适的工具和支持，他们可以从你的现有团队中建立起来，并有能力抵御由常见漏洞引起的攻击。但是，不要把任何旧的培训扔给他们。给他们时间，让他们在安全工具的帮助下茁壮成长，这些工具是对他们现有工作流程的补充。尽可能让它变得简单，然后看着那些讨厌的错误开始在为业务提供动力的代码中变得越来越少。

底线是，任何软件风险如果是供应链的一部分，就会立即加剧，影响到所有用户和任何利用了脆弱组件的系统。如果供应商没有像实施其软件的公司那样认真对待安全问题--或者供应商和组织都缺乏安全计划--那么像SolarWinds这样更具破坏性、影响深远的供应链攻击将不可避免地成为常态--而这对所有人来说都是一个关键问题。

虽然对任何在软件开发之外工作的人来说，这可能是反直觉的，但多年来，许多受雇于应用安全的专业人员都在这些关键岗位上工作，几乎没有编程经验。这些应用安全专业人员是团队的一部分，他们负责确保没有漏洞潜入已成为许多行业和组织命脉的应用程序，但他们中很少有人能真正直接评估或修复代码。 

许多安全专家不是来自编码背景，而是从围绕攻击载体、威胁、漏洞和商业风险的关键知识的角度来对待他们的角色；他们对代码的看法有限。虽然不是每个AppSec大师都有相同的技能，但许多人的典型工作包括与代码审查员和扫描工具合作，以确保程序和系统按照组织标准或相关行业和政府框架进行安全。然后他们写出关于他们的发现的报告，并发回关于可能破坏代码的攻击载体的信息。然后由开发人员进行必要的修复，无论这对当前的工作有多大的干扰。

情况之所以发展成这样，是因为多年来的普遍逻辑是，保护网络和应用程序的工作非常庞大，期望每个从事网络安全的人都能胜任每个角色是没有意义的。深度编码技能被留给了开发人员，而对编写或编辑开发管道中更远处的代码的能力则没有给予重视。

这种心态正在迅速改变，这为开发人员提供了一个独特的机会，使他们能够跳槽到AppSec，并实现职业转变。 不是每个开发人员都想拥抱所谓的黑暗面，许多开发人员对AppSec团队的意见并不特别积极。但对于那些愿意的人来说，现在是抓住这个越来越诱人的铜环的最好时机。

DevSecOps几乎推动了每个行业的发展

在任何组织中，提高安全意识的程序员和开发人员的价值的最大因素之一，是几乎普遍地接受更敏捷的开发实践，如DevSecOps。当开发、安全和运营结合在一起时，网络安全就会成为一种共同的责任，从头到尾融入新软件的开发。在这种环境下，编码能力越来越多地被看作是一种宝贵的资产，这对那些天生就懂得安全的工程师来说尤其如此。

一个不仅对网络安全有高度了解，而且还了解使一切运作的代码的应用安全专业人员，对任何组织来说都比那些知识集中在理论上的人更有价值。能够快速发现和评估代码中的漏洞，然后缓解这些问题，是DevSecOps如此受欢迎的核心原因。

在AppSec工作的开发人员还为任何雇用他们的组织带来另一个很大的优势。他们来自开发部门，因此很容易与开发人员讨论安全和漏洞问题。这也使得他们更容易成为开发团队的教练，帮助他们成为更好的编码者。随着时间的推移，他们甚至能够消除AppSec的 "黑暗面 "的污名，并帮助统一整个组织的软件开发团队。

网络安全技能短缺的情况越来越严重

莎士比亚曾说过，这是一股恶风，吹不动任何人。他的意思是，即使是最黑暗的情况也可能对某人有利。网络安全技能的短缺就是一个很好的例子。

几乎所有的地方都能敏锐地感受到人员的短缺。在战略与国际研究中心最近进行的一项调查中，82%的IT决策者表示，他们的组织遭受了网络安全技能的短缺，71%的人表示，这种短缺已经对他们的组织造成了直接和可衡量的损害。为了更好地看待这一危机，该报告指出，仅在美国，2020年就有超过52万个网络安全职位未被填补，而这一领域只有约94万名雇员。

对于试图保护其基础设施、业务和数据免受日益危险的威胁的组织来说，网络安全人员的短缺是个坏消息。但对于希望进入AppSec和安全领域的开发者来说，这也是一个好机会。机会是，网络安全和AppSec职位几乎到处都有。随着网络安全职位如今平均需要多花21%的时间来填补，工资也在全面上涨。

跃升至应用安全

对于开发人员来说，现在可能是最好的时机，让他们跳到生活中阳光灿烂的安全方面去，这是很有利可图的。有安全意识的开发人员不再被视为只是权宜之计的安全方法的一部分，而是作为网络安全防御者填补了一个完整和受尊重的角色。这对于那些接受了DevSecOps和其他更敏捷的开发方法的组织来说尤其如此。而网络安全人才的短缺意味着几乎每个公司、政府机构或组织都有职位。那些拥有正确技能的人可以选择他们想工作的地方。

转移到AppSec可能不适合每个人，当然，大多数开发人员将继续专注于构建惊人的功能。但对于那些正在考虑跳槽的人来说，投资于安全培训以增强他们现有的编码技能可以打开很多大门。最好的AppSec人员来自工程领域，因为他们深刻理解技术，并对其他开发者的困境感同身受。DevSecOps意味着无论如何现在每个人都要对安全负责，所以为什么不利用目前关键技能的短缺来推动你的职业生涯进入应用安全呢？现在是为你自己、你的家人和你的事业做出积极行动的最好时机。

在流行文化中，有很多关于流氓人工智能和机器人的说法，以及电器对其人类主人的背叛。这在很大程度上浸透了科幻小说的乐趣和幻想，但随着物联网和联网设备在我们的家庭中变得越来越普遍，围绕网络安全保障的对话也应该如此。软件就在我们身边，我们很容易忘记我们在多大程度上依赖代码行来完成那些为我们提供如此多的创新和便利的聪明事。与基于网络的软件、API和移动设备一样，嵌入式系统中的脆弱代码如果被攻击者在野外发现，就会被利用。 

虽然不太可能因为网络攻击而出现一支微波军队来奴役人类（虽然，特斯拉机器人有点令人担忧），但恶意的网络事件仍然是可能的。我们的一些汽车、飞机和医疗设备也依靠复杂的嵌入式系统代码来执行关键任务，这些物体被破坏的前景不仅令人震惊，而且可能威胁到生命。

与其他类型的软件一样，开发人员是最早接触代码的人之一，就在创建阶段的开始。和其他类型的软件一样，这可能是阴险的、常见的漏洞的温床，这些漏洞在产品上线之前可能不会被发现。 

开发人员不是安全专家，任何公司也不应该期望他们扮演这个角色，但他们可以配备一个强大得多的武器库来应对与他们相关的那种威胁。随着我们的技术需求不断发展，嵌入式系统--通常是用C和C++编写的--将被更频繁地使用，对开发人员进行这种环境下的工具的专门安全培训是至关重要的。 

爆炸的空气炸锅、流氓车辆......我们是坐以待毙吗？

虽然有一些围绕所有安全开发的标准和规定来保证我们的安全，但我们需要在所有类型的软件安全方面取得更精确、更有意义的进展。想到有人入侵空气炸锅会造成问题似乎很牵强，但它已经以远程代码执行攻击的形式发生了（允许威胁者将温度提高到危险水平），正如导致车辆被接管的漏洞一样。

特别是汽车，特别复杂，车上有多个嵌入式系统，每个系统都负责微观功能；从自动雨刷到发动机和制动能力，无所不包。与不断增加的通信技术（如Wi-Fi、蓝牙和GPS）交织在一起，联网车辆代表了一个复杂的数字基础设施，暴露在多种攻击媒介之下。预计到2023年，全球将有7630万辆联网汽车上路，这代表着需要为真正的安全奠定防御基础的巨石。

MISRA是一个与嵌入式系统威胁作斗争的重要组织，它制定了准则来促进嵌入式系统背景下的代码安全、保障、可移植性和可靠性。这些准则是每个公司在其嵌入式系统项目中必须努力达到的标准中的一颗北极星。

然而，要创建和执行遵守这一黄金标准的代码，需要嵌入式系统工程师对工具充满信心--更不用说安全意识了。 

为什么嵌入式系统安全技能的提升如此具体？

以今天的标准来看，C和C++编程语言已经很老旧了，但仍然被广泛使用。它们构成了嵌入式系统代码库的功能核心，而嵌入式C/C++作为连接设备世界的一部分，享受着闪亮的现代生活。

尽管这些语言有着相当古老的根基--并且在注入缺陷和缓冲区溢出等常见问题方面表现出类似的漏洞行为--但开发人员要想真正成功地减轻嵌入式系统中的安全漏洞，他们必须亲身体验模仿他们工作环境的代码。如果在嵌入式C语言环境中花费额外的时间和精力，一般安全实践的通用C语言培训就不会那么有效和令人难忘。

一辆现代汽车上有十几个到一百多个嵌入式系统，当务之急是为开发人员提供精确的培训，让他们知道在IDE中寻找什么，以及如何修复它。
。

从底层保护嵌入式系统是每个人的责任

许多组织的现状是，开发速度胜过安全，至少在涉及到开发人员的责任时是如此。他们很少被评估他们产生安全代码的能力，但快速开发令人敬畏的功能是黄金标准。对软件的需求只会越来越大，但这种文化却让我们在与漏洞的斗争中败下阵来，以及随后的网络攻击中被允许。 

如果开发人员没有接受过培训，那不是他们的错，这是一个漏洞，AppSec团队中的某个人需要通过为整个开发社区推荐正确的、可获得的（更不用说可评估的）提高技能的项目来帮助填补。在软件开发项目之初，安全问题就应该是一个首要考虑的问题，每个人--尤其是开发人员--都应该得到他们所需要的东西来发挥他们的作用。 

亲身体验嵌入式系统的安全问题

缓冲区溢出、注入缺陷和业务逻辑错误都是嵌入式系统开发中的常见陷阱。当深埋在单个车辆或设备的微控制器的迷宫中时，从安全的角度来看，它可能会带来灾难。

缓冲区溢出尤其普遍，如果你想深入了解它是如何帮助破坏我们之前谈到的那个空气炸锅的（允许远程代码执行），请查看这个关于CVE-2020-28592的报告。

现在，是时候在真正的嵌入式C/C++代码中亲身体验一下缓冲区溢出漏洞了。玩这个挑战，看看你是否能找到、识别并修复导致这个阴险的漏洞的不良编码模式：

你的表现如何？请访问www.securecodewarrior.com，以获得关于嵌入式系统安全的精确、有效的培训。

作为一名应用安全专家，你的工作是确保你的组织的应用程序的网络安全。然而，你并不负责编写应用程序运行的代码。开发团队中的工程师负责。那么，你如何确保他们在开发这些系统时考虑到安全问题？ 

最有可能的是，你正在做以下一些甚至全部工作。 

• 审查所有代码的安全缺陷，并将其反馈给开发团队进行修复。 
• 在你的安全开发生命周期中执行严格的同行审查程序。 
• 由内部或外部安全团队定期进行应用assessment/渗透测试。
• 实施扫描工具以发现漏洞。
  

这些都是很好的最佳做法，但它们也很昂贵，类似于每次生病都要服用一轮抗生素。这不仅成本高，而且随着时间的推移会失去疗效，并会削弱你的免疫系统。 

你怎样才能真正确保开发人员交付的代码首先是安全编写的？ 

撇开安全编码不谈，先想想人们如何学习。我们大多数人都是视觉学习者，我们通过实践来学习。然而，安全代码培训往往是作为一种 "打勾 "的活动，与开发人员的日常工作没有关系。它的目的是为了证明开发人员已经接受了安全培训，以符合行业标准，而不是让开发人员真正保留这些知识，更不用说享受学习过程了。 

人类倾向于学习的另一种方式是通过我们的错误，与我们的免疫系统一样。T细胞记得他们过去遇到过什么样的病原体，并成功地将其消灭，这样他们就可以在未来保护他们。这正是开发人员在你的安全 SDLC中应该扮演的角色。

指望他们不犯错误是不现实的，但你可以让他们做好准备，能够识别出将来会转化为安全漏洞的编码模式。 

这也是一个强大的同行评审过程变得如此强大的原因。一个开发人员没有注意到一个安全漏洞，并不意味着另一个开发人员也不会注意到。而且，开发团队的整体训练越好，漏洞就越有可能被发现，并永远不会进入生产。 

软件漏洞就像病原体

软件漏洞就像病原体一样，你必须记住它们才能对抗它们。对于病原体，我们的免疫系统往往需要多次接触才能记住如何对抗它，以避免严重的疾病或更糟的情况。 

一个成功的网络攻击来自脆弱的软件，可以严重削弱或杀死一个组织。但是，如果开发人员首先在受控环境中接触到软件漏洞，他们可以通过增加和定期练习他们的安全编码知识和技能来建立对威胁的免疫力。 

让开发人员在受控环境中接触安全缺陷

我们永远无法完全保护自己不生病，但我们可以做一些事情来提高我们的免疫系统并尽可能保持健康。像定期锻炼、健康饮食和充足的睡眠等，都是通常与强大的免疫系统相关的生活方式选择。但所有这些事情都需要一点努力，而且必须持续进行。连续一周每天慢跑或连续一个月戒酒几乎不会对你的整体健康产生什么影响。也不建议我们在开始跑步的第一天就去跑10公里。我们首先需要让我们的心脏和肌肉暴露在运动中。我们也知道，这需要进行一些试验，直到我们找到适合我们身体的健康食品和我们喜欢的运动的平衡。

当涉及到安全软件开发时，这并没有什么不同。学习是随着时间和实践发生的，开发人员需要同样的持续培训来定期提高他们的安全编码技能。更不用说，软件开发总是在不断地发展和调整，这意味着漏洞也是如此。这就是为什么一个简单的培训课程是不够的。开发人员需要定期提高技能，以便对潜在的威胁有足够的了解，从而有能力抵御它们。 

力求在开发团队中实现群居性免疫

一个人不可能防止任何和所有的安全问题。在团队中拥有安全卫士是很好的，但是为了得到最好的保护，越多的人了解安全漏洞和如何防止它们，你的组织就越有机会防止它们。同样，这与免疫系统有不同类型的T细胞用于不同的目的没有多大区别。每个开发人员都是确保安全的团队的一部分。如果他们被授权承担责任，做好这件事，甚至喜欢做这件事，那么你就可以在开发团队中创造出对网络威胁的群体免疫力，作为结果。

反复曝光，保持安全至上的理念

我们的大脑的学习方式与我们的免疫系统的工作方式类似。德国心理学家赫尔曼-艾宾浩斯是记忆和学习领域的先驱者。他推断出，学习必须随着时间的推移和多次学习而发生。当我们在学校时，我们从未被期望在第一次介绍后保持新知识。首先，信息被呈现给我们，然后我们在指导下练习它，然后我们自己练习。即使我们学得很好，足以通过考试，但如果我们不经常使用我们花了时间和精力学习的知识，这些信息往往不久就会被遗忘。我们中有多少人可以说自己记得高中时的法语？

因此，我们怎么可能相信，看一天的幻灯片，听一个人谈安全问题，就真的能让那些与会的开发人员更安全地编码？

漏洞反复出现的模式告诉我们，这根本行不通。 

如何实现安全的开发免疫力？

答案就在我们的天性中。我们的身体和思想以同样的方式工作，它们为问题提供了美丽的解决方案，只要我们与它们合作而不是对抗它们。 

为了确保你的应用程序是安全的，你需要从提高开发人员编写安全代码的技能开始。否则，AppSec将继续花费他们所有的时间来审查所有代码的安全缺陷，并将相同的重复出现的漏洞报告给开发部门，但很快就会被修复，而没有学到任何东西。然后在下一个版本中再做一遍。

因此，让我们重申一下。

如果你和你的开发经理一起努力做到这一点，你不仅会实施一个安全的SDLC和勾选安全培训要求的合规性，你还会对开发过程产生实际的影响。更重要的是，AppSec将不再遇到并向开发团队报告重复的漏洞，开发人员将花更少的时间来修复这些漏洞。这意味着他们可以花更多的时间去创造和改进那些让我们的世界更美好的软件。 

准备好提高你的开发团队的技能了吗？来吧，跟我们预约一个演示。