这篇文章的一个版本发表在 Infosecurity杂志.它已被更新并在此转发。

‍

在过去的两年里，对每个人来说都是一次火的洗礼，但大多数组织的网络安全蓝图受到了考验，因为我们中的许多人几乎在一夜之间就被扔进了远程工作模式。作为一个行业，我们真的必须提高警惕和适应，特别是在绝望的威胁者导致自大流行病开始以来网络犯罪报告激增300%之后。

我们都吸取了一些教训，我感到欣慰的是，不仅一般的网络安全得到了重视，代码级的软件安全和质量也得到了重视。拜登关于确保软件供应链安全的行政命令让人们看到了关键问题，尤其是在SolarWinds大规模漏洞事件之后。我们都需要更加关注安全问题，并 努力通过可衡量的安全意识来减少漏洞，这种想法无疑是对话中的一个重要部分。

也就是说，在与网络犯罪分子作斗争时，我们需要尽可能地与他们保持同步，以预防的心态抢占他们的游戏场地。 

这里是我认为他们在未来一年可能开始掀起波澜的地方。

元域是一个新的攻击面

元空间可能是互联网的下一个演变，但在大多数行业对待软件和数字环境安全的方式上，类似的转变还没有实现。 

虽然像网络钓鱼诈骗这样的一般网络安全隐患将不可避免（而且在每个人都在寻找他们的脚步的时候，可能会有很多），但使这种沉浸式虚拟世界成为可能的实际基础设施和设备将需要是安全的。与智能手机帮助我们在线生活的方式类似，像VR头盔这样的外围设备是通往用户数据山的新门户。越来越复杂的嵌入式系统安全需要使物联网小工具安全，主流VR/AR的勇敢新世界也不例外。正如我们在Log4Shell漏洞中看到的那样，代码层面的简单错误可以成为威胁者的后台通行证，而在模拟现实中，每一个动作都会产生可以被窃取的数据。  

虽然处于起步阶段，但一个成功的元空间将需要实际采用加密货币（而不是随意囤积最新的纪念币），以及像NFT这样的价值项目，这意味着我们现实生活中的财富、身份、数据和生计有可能被开放给一个新的 "狂野西部"，从而使人们处于危险之中。在我们的工程师开始疯狂地开发史诗般的功能和增强功能之前，从头开始将这个新的、巨大的攻击面最小化应该是一个优先事项。

Log4Shell事件后的立法

对于那些陷入混乱，争相寻找是否有任何可利用的广泛使用的Log4j日志工具版本的实例或与之相关的依赖关系的数十名开发人员来说，我不认为假日期间会是一个快乐的时刻。 

这个零日攻击是有史以来最糟糕的攻击之一，人们将Log4Shell与毁灭性的Heartbleed OpenSSL漏洞相提并论，后者在6年后仍在被人利用。如果这条时间线是什么，我们将在未来很长一段时间内处理Log4Shell的宿醉问题。很明显，即使从Heartbleed中吸取了教训--至少在需要尽快推出和实施补丁方面--许多组织仍然没有足够快的行动来保护自己。根据公司的规模，打补丁可能是令人难以置信的困难和官僚主义，需要跨部门的文件和实施。很多时候，IT部门和开发人员对所有正在使用的库、组件和工具没有百科全书式的了解，并且被严格的部署时间表所束缚，以尽量减少中断和应用程序的停机时间。这种工作方法有其合理的理由（阅读：没有人想在工作中扔一个扳手，破坏一些东西），但打补丁太慢就是坐以待毙。

正如SolarWinds攻击事件改变了软件供应链的游戏规则一样，我预测在Log4Shell事件之后也会发生类似的情况。虽然在一些关键行业已经有补丁管理的授权和建议，但广泛的立法是另一回事。预防性的软件安全将永远是我们完全避免紧急安全补丁的最好机会，但安全的最佳实践决定了补丁是一个不可商量的优先措施。我认为这将是一个热门话题，并导致不那么隐晦的建议，即快速和经常打补丁。 

更加强调架构安全（而开发者还没有准备好）。

新的OWASP Top 10 2021有一些重要的新成员，以及一个令人惊讶的现象，即注入漏洞从第一的位置下降到一个低的第三位。这些新增加的内容说明了开发人员在安全编码和安全最佳实践方面的 "第二阶段"，可悲的是，除非经过适当的培训，否则大多数人都没有能力对降低风险产生积极的影响。

我们已经知道，如果我们要打击代码中常见的安全漏洞，开发人员必须具备安全技能，而且组织对开发人员驱动的预防前提做出了更好的反应。然而，随着不安全设计在OWASP的前十名中占据一席之地，并且成为架构安全问题的一个类别，而不是单一类型的安全漏洞，开发人员一旦掌握了这些基础知识，就需要被推动到更高的水平。涵盖威胁建模的学习环境--最好是在安全团队的支持下--在开发人员成功提高技能后，可以减轻严重的压力，但就目前而言，这对大多数软件工程师来说是一个重要的知识差距。

对抗这种情况 "需要一个村庄"，而组织可以在为开发者创造积极的安全文化方面发挥作用，在不对他们的工作流程造成重大干扰的情况下吸引他们的好奇心。

这篇文章的一个版本出现在 SC杂志.它已被修改并在此转发。
如果

你曾经被小偷闯入过你的家，你会明白最初的那种沉甸甸的感觉，觉得有些不对劲，然后意识到你确实被偷了，被侵犯了。这通常会导致持久的不适，更不用说转而采取能与诺克斯堡相媲美的安全措施了。

现在想象一下，你的家被攻破了，因为窃贼给自己配了一把钥匙。他们蹑手蹑脚，想来就来，想走就走，但却小心翼翼地保持不被发现。然后，有一天，你发现你藏在冰箱里的珠宝不见了，你的保险箱被清空了，你的个人物品被洗劫一空，这一切都太晚了。这就是一个组织在遭受零日网络攻击时面临的同等现实。2020年，Ponemon研究所的一项研究显示，80%的成功数据泄露是零日漏洞的结果，可悲的是，大多数公司仍然没有能力对这一统计数字作出重大改进。

零日攻击，顾名思义，给了开发人员零的时间去发现和修补现有的可能被利用的漏洞，因为威胁者首先进入了。损失已经造成，然后就是疯狂地修复软件和对企业的声誉损害。攻击者总是处于优势地位，而尽可能地缩小这种优势是至关重要的。 

没有人想要的节日礼物--Log4Shell--目前正在互联网上炸开了锅，据说有超过10亿台设备受到了这个灾难性的Java漏洞的影响。这将是有史以来最严重的0day攻击，而我们才刚刚开始。尽管一些报告称，漏洞在公开披露前几天就开始了，但2016年黑帽会议上的一份报告表明，这已经是一个已知的问题了。哎哟。更糟糕的是，它很容易被利用，地球上的每一个脚本儿童和威胁行为者都在利用这个漏洞追逐利益。

那么，对于抵御狡猾、阴险的威胁，更不用说在软件开发过程中被遗漏的漏洞，什么才是最好的发展道路？让我们来看一看。 

针对大目标的零日攻击很罕见（而且代价高昂）

在暗网中有一个巨大的漏洞市场，而零日漏洞往往价格不菲，本文中的一个例子在写作时被列为250万美元。据报道，这是一个针对苹果iOS系统的漏洞，安全研究员的要价很高，这并不奇怪；毕竟，这确实可能是入侵数百万设备的通道，收获数十亿敏感数据记录，而且在被发现和打补丁之前尽可能地做。

但到底谁有那么多钱呢？通常情况下，有组织的网络犯罪集团会拿出现金，如果它被认为是值得的，特别是对于一直流行的勒索软件攻击。然而，全球政府和国防部门是他们可以用来获取威胁情报的客户，在更积极的情况下，公司本身可能是他们自己的潜在零日漏洞的买家，这样他们就可以减轻灾难。 

2021年，现场零日漏洞发现的记录被打破，而大型组织、政府部门和基础设施最有可能被探测到任何弱点。没有办法完全避免零日攻击的可能性，但你可以通过提供一个慷慨的、结构良好的漏洞赏金计划来 "玩游戏"。与其等到有人在暗网市场上提供你的软件城堡的钥匙，不如让合法的安全爱好者站在你这边，为他们提供体面的奖励，让他们进行道德披露和潜在修复。

如果它恰好是一个令人毛骨悚然的零日威胁，可以肯定的是，你需要拿出比亚马逊礼品卡更多的钱（而且你这样做也是值得的）。

你的工具可能成为你的安全人员的负担

长期以来，繁琐的安全工具一直是一个问题，平均CISO在他们的安全武库中管理着55至75种工具。根据Ponemon研究所的一项研究，除了是世界上最混乱的（比喻）瑞士军刀之外，53%的企业甚至不相信它们在有效地工作。另一项研究显示，只有17%的CISO认为他们的安全栈是 "完全有效的"。

在一个以职业倦怠、缺乏安全技能人才以满足需求和需要敏捷性而闻名的领域，迫使安全专业人员以数据、报告和监控庞大工具集的形式处理信息过载，是一种负担。这正是那种可能导致他们错过关键警报的情况，在正确评估Log4j的弱点时很可能就是这种情况。 

预防性安全应包括开发者驱动的威胁建模

代码级的漏洞往往是由开发人员引入的，他们需要精确的指导和定期的学习途径来建立安全编码技能。然而，下一级的安全开发人员已经有机会学习和实践威胁建模，作为其软件创建过程的一部分。

最了解他们的软件的人是那些坐在那里创造软件的开发者，这不应该是一个惊喜。他们拥有强大的知识，知道用户如何与之互动，在哪里使用这些功能，以及当有足够的安全意识时，可能出现的破坏或被利用的情况。

如果我们把这个问题带回Log4Shell漏洞，我们很不幸地看到这样一种情况：一个灾难性的漏洞没有被专家和复杂的工具组发现，然而，如果该库被配置为净化用户输入，它可能根本就不会发生。不这样做的决定似乎是为了增加便利性的一个不起眼的功能，但却使它很容易被利用（想想SQL注入级别，当然不是天才的东西）。如果威胁建模是由一群敏锐的、精通安全的开发人员完成的，那么这种情况很可能已经被理论化并被考虑了。

一个伟大的安全计划有一个情感的组成部分，人类的干预和细微差别是解决人类创造的问题的核心。威胁建模需要同理心和经验才能有效，软件和应用程序架构层面的安全编码和配置也一样。这不是开发人员应该在一夜之间就能完成的事情，但有一个明确的途径来提高他们的技能，使他们能够为这个重要的任务减轻安全团队的压力，这是理想的做法（而且这是建立两个团队之间关系的好办法）。 

零天导致N天

应对零日病毒的下一步是尽快打出补丁，希望每个使用易受攻击软件的用户都能尽快打出补丁，当然要赶在攻击者之前打出。有了Log4Shell，它的耐力和效力可能会超过Heartbleed，因为它被嵌入到数以百万计的设备中，并在软件构建中产生复杂的依赖关系。

现实上，没有办法完全阻止这种阴险的攻击。然而，只要承诺利用一切途径来创建高质量、安全的软件，并以对待关键基础设施的相同心态来对待开发，我们都可以有一个战斗的机会。

开发人员用各种方法创建和测试自己的代码。其中一种方法是单元测试--一种非常流行的测试自己代码中最小部分的方法。如果写得好，单元测试可以帮助提高你的代码质量，并减少成本和开发时间。无论是否作为测试驱动开发（TDD）的一部分，单元测试都是现代开发实践的一个关键部分，其重要性导致了许多测试框架的产生。

但是，如果没有适当的测试框架和指导，单元测试可能会变得复杂和不可读，因为重点转移到覆盖率和数量，而不是质量和可读性。这在一个有许多单元测试的大型活跃代码库中尤其如此。

一个好的测试框架有助于创建良好的可读测试，这些测试是简单的，并注重质量测试。它们也有助于记录使用你的代码的方法。AssertJ就是这样一个框架。

AssertJ是一个流畅的API，用于在Java中编写单元测试。它让你写的测试断言读起来像英语，有上下文感知的自动完成功能。如果你有大量的测试，并需要提高它们的可读性，你可能希望将所有的测试迁移到AssertJ，并确保所有未来的测试都充分利用AssertJ的优势。

但是完整的迁移需要花费巨大的精力和时间来手动完成，所以它经常被跳过或推迟到其他开发任务。因此，我们创建了Sensei - 一个高度可定制的IntelliJ插件，可以帮助迁移你当前的单元测试，以使用AssertJ，并使所有未来的测试以正确的方式编写。这是通过Sensei"开发团队 "已经为你创建的一些配方（规则）完成的。Sensei 使得执行一次性迁移或采取渐进式迁移到AssertJ的方法变得容易，一次一个测试。一旦你迁移到AssertJ，配方将继续帮助开发人员在编写单元测试时应用快速修复，以便你的单元测试在整个代码库中继续保持统一、标准和一致。

‍

关于Sensei

Sensei 是一个高度可定制的IntelliJ插件，可以在输入时扫描和修复不良代码--有数百个可下载的代码转换和迁移配方（规则），以及一个内置的能力来制作你自己的。有了Sensei ，开发人员可以在输入时纠正不良的代码模式，这样他们就可以更快地交付高质量的代码，并最终以一致和标准的方式跨团队和项目编写代码。

下面是一个迁移样本的例子，也许可以帮助你看到Sensei 是如何使你的单元测试迁移到使用AssertJ时不费吹灰之力。

为什么说AssertJ是编写单元测试的优秀框架？

而不是像这样写一个JUnit断言的测试。

你可以用AssertJ写这个。

这意味着你可以像阅读英文句子一样从左到右阅读断言，而且很清楚哪个是期望值（在这种情况下，尺寸为3）。你有多少次把断言写错了，像这样？

这些只是简单的例子。你的检查和断言越复杂，AssertJ就越能帮助你使你的测试简单和可读。它与你的IDE的自动完成功能配合得很好。只要你输入

它将弹出所有你可以检查的东西，基于myResult的类型。如果它是一个集合，你可以检查它的内容、大小、是否包含某些值或类型，等等。

AssertJ支持基元和它们的盒式类型、原子类型、集合、数组、地图、日期、java.time、期货、文件/路径、InputStreams、Throwables和URL。如果你有一个喜欢的Hamcrest自定义匹配器，你可以通过HamcrestCondition将其与AssertJ一起使用。

可读的单元测试使开发人员很容易用正常的英语阅读代码，因此很容易发现错误以及增加覆盖率--这使得AssertJ成为良好的Java单元测试不可缺少的框架。

将传统的单元测试转移到AssertJ的配方

我们编写了一本食谱，帮助你用AssertJ编写一致的代码。它可以帮助你将你的断言从这些框架中的任何一个迁移到AssertJ。JUnit 3、JUnit 4、JUnit 5和FEST-Assert。

这个食谱可以在Sensei 中配置，以便立即使用，你可以在这里找到Sensei 的安装说明。

在写代码时写出更好的单元测试--逐步提高JUnit质量

Sensei AssertJ的食谱不只是帮助你从其他框架迁移过来。它有一些食谱，可以帮助你改进你的测试编写，打破旧的习惯，并编写更多的AssertJ测试。

例如，假设你写了一个测试，它看起来像这样。

也许你甚至使用上面的一个迁移配方，从这个JUnit风格的断言中迁移了它。

Sensei AssertJ的食谱有一个配方，也可以检测到这种老式的断言，并提出将其转换为这种断言。

另一个配方可以从以下方面进行转换。

到这一点。

一次性迁移和跨团队的统一编码实践--与Sensei

从上面的例子我们可以看出，手动迁移单元测试到使用AssertJ会涉及到大量的精力和时间，而这些时间最好用在编写更好的测试上。通过使用Sensei ，你可以轻松地将你的单元测试迁移到AssertJ上，而且很有信心。你可以执行一次性迁移，或者在遇到个别测试时将其迁移到AssertJ。Sensei ，提供这种灵活性，使代码迁移不那么痛苦。

单元测试迁移只是许多方法中的一个例子，Sensei ，可以用来在你的项目中编写一致的代码。你可以随时注意在拉动请求中或自己编码时经常遇到的反模式或某些手动代码转换。如果你有一套经常被开发人员遗漏的编码准则，那么你可以将这些准则转化为配方--使开发人员能够自信地应用经批准的代码转换。

如果你有任何问题，我们很愿意听到你的意见在Slack上加入我们：sensei-scw.slack.com

迁移代码（阅读：遗留代码）并不有趣。它需要大量的计划和努力来使它跨越界限。虽然对开发人员来说，这不是最令人兴奋或最有动力的工作，但它确实需要决心和正确的经验来将遗留代码迁移到新的库版本。Joda-Time到java.time就是这样一个需要缜密计划和执行的迁移。

如果你的Java项目是在Java SE 8之前开始的，并且使用了日期/时间处理，那么它可能使用了Joda-Time--一个优秀的库，并且是SE 8之前处理日期和时间功能的事实标准。如果你的项目仍然使用Joda-Time，但希望迁移到java.time，那么请继续阅读。

Java SE 8的发布包括一个新的和改进的标准日期和时间API，通常被称为java.time（JSR-310）。Joda-Time项目现在建议迁移到java.time（JSR-310）。

虽然java.time（JSR-310）在很大程度上受到了Joda-Time的启发，但它并不向后兼容，概念和术语也发生了变化。这就是为什么从Joda-Time迁移到java.time需要仔细关注你所改变的每一行代码。这可能会很耗时，而且几乎会让你希望有一种更容易的、自动化的迁移方式。

有一种更好的迁移方式，我们使用Sensei ，这是一个IntelliJ插件，可以根据你定义的配方（规则）自动执行代码转换。把你的时间花在定义可重用的配方上，而不是执行重复的迁移任务。这种自动化不仅可以转换你的传统Joda-Time代码，还可以帮助团队在编写新代码时就在IDE中遵循这些准则。

为了帮助你取得先机，我们创建了一个公开的Sensei cookbookStandardization on java.time (JSR-310)，其中包括以较少痛苦的方式从Joda-Time迁移到java.time的配方。这是一个不断增长的食谱集，我们将继续扩大，以增加更多的食谱的覆盖面。

下面是一个迁移样本的例子，也许可以帮助你了解Sensei 是如何使迁移遗留代码变得不费力气的。

从重复的手工迁移到自动化的代码转换

让我们看一个创建新DateTime的例子，它展示了从Joda-Time向java.time迁移一行代码时的一些隐藏陷阱。然后，我们将看一下我们的Sensei 菜谱，它来自我们的java.time标准化（JSR-310）菜谱，并展示它是如何捕获所有这些信息的，这样，任何开发人员都可以重复使用这种相同的迁移。

在这个例子中，我们要从代表DateTime字段值的7个int参数中构造一个Joda-Time DateTime。

我们如何将其迁移到与java.time相当的地方？

Joda-Time中关于这个构造函数的javadoc说。

使用默认时区的ISOChronology从数据字段值中构建一个实例。

起初，我们可能会认为java.time中有DateTime类，但其实并没有。如果你在谷歌上搜索 "从Joda time迁移到java time"，你很可能会找到Stephen Colebourne的博文《从Joda-Time转换到java.time》。

这给了你一个好的开始，并为我们指明了使用java.time.ZonedDateTime或java.time.OffsetDateTime的方向。这里是我们的第一个问题，我应该使用哪一个？根据Stephen的评论，可能是ZonedDateTime。

查阅ZonedDateTime的javadoc，我们根本看不到任何构造函数。回到Stephen的博文，我们再往下看。

构造。Joda-Time有一个构造函数，接受一个Object并进行类型转换。java.time只有工厂方法，所以转换是一个用户问题，尽管为字符串提供了parse()方法。

所以一定有一个静态工厂方法，搜索静态方法，我们找到一个看起来很接近的方法，但并不完全相同。

它有7个int参数，就像我们原来的Joda-Time DateTime构造函数一样，但是如果你不注意，你会错过一个重要的细节。 第7个参数不再代表毫秒，而是期待纳秒，这是因为java.time比Joda-Time提高了精度，测量的是纳秒级的时刻。这是一个重要的细节，你很容易就会错过。此外，这个方法还期望有一个ZoneId，所以它让你想知道为什么你以前不需要，现在又为什么需要。

记得我们原来的构造函数的javadoc提到它将使用默认的时区，也许有一种方法可以获得默认的ZoneId？

ZoneId的javadoc没有告诉我们所列出的任何构造函数，但看一下静态方法，我们可以使用systemDefault()。

现在我们已经解决了ZoneId的问题，我们应该如何处理毫秒到纳秒的转换呢？也许我们可以使用java.util.concurrent.TimeUnit来进行转换。

这个方法返回一个long，而我们的方法期望是一个int，所以现在我们也有一个转换问题要解决。也许我们可以尝试一些简单的方法。一个乘法？

这可以工作，但确实看起来有点不合适。如果你还没有注意到，我们已经花了相当多的时间和精力来迁移一行代码。但你可以想象，我们有很多这样的编辑工作要手工完成，而且没有更好的办法。

然而，如果我们再仔细研究一下java.time API，我们可以发现一个看起来更流畅的解决方案。

尽管ZonedDateTime没有明显的方法来设置毫秒，但可以使用with(TemporalField field, long newValue)方法，使用ChronoField.MILLI_OF_SECOND作为TemporalField。

而java文档中提到，它将为我们进行纳秒级的转换。

当这个字段用于设置一个值时，它的行为应该与设置NANO_OF_SECOND的方式相同，其值乘以1,000,000。

因此，我们可以简单地在工厂方法中指定纳秒为0，然后使用with方法创建一个ZonedDateTime，其中有所有原始值和毫秒。

看看我们的最终结果，看起来我们只改变了一行代码，这并没有真正显示出我们为研究一个迁移所做的努力!

‍

创建一个配方，更快、更容易地进行迁移

Sensei 为我们提供了一个与其他开发者分享这些来之不易的信息的方法。通过创建一个捕捉所有这些要求的配方，它将允许Sensei 用户通过点击鼠标来执行这种迁移。

一个Sensei 的食谱包括3个主要部分。

• 元数据
• 搜索
• 可用的修复方法

让我们看看一个Sensei recipe（也可以看作是YAML recipe），它将帮助我们把这个调用迁移到它的java.time等价物。

DateTime foo = new DateTime(year, monthOfYear, dayOfMonth, hourOfDay, minuteOfHour, secondOfMinute, millisOfSecond) 。

元数据部分

元数据部分包含关于配方的信息以及如何使用它。

搜索部分

Sensei 配方的搜索部分指定了这个配方应该适用于哪些代码元素。

search:
instanceCreation:
args:
1:
type: int
2:
type: int
3:
type: int
4:
type: int
5:
type: int
6:
type: int
7:
type: int
argCount:7
type: org.joda.time.DateTime

‍

在这个搜索部分，我们看到，我们是。

• 搜索一个instanceCreation，即一个构造函数的用法。注意：还有许多其他的搜索目标可用
• 构造函数应该有7个参数，这是由argCount属性指定的。
• args1-7应该是int类型的
• 我们正在搜索org.joda.time.DateTime类型的构造函数。

‍

可用的修复部分

availableFixes部分可以指定一个或多个可以应用于匹配代码元素的修复。每个修复可以有多个动作，在我们的例子中，我们有一个单一的修复，执行两个动作。

‍

• 修复的名称在 "快速修复 "菜单中显示给用户，并描述了如果用户应用这个快速修复会发生什么。
• 行动列表显示了这个快速修复将执行哪些行动
• 重写动作将使用一个mustache模板重写代码元素。它可以利用变量和字符串替换函数。
• modifyAssignedVariable动作将检查这个构造函数是否被用来为一个变量赋值。如果是这样，这个动作将修改该变量，使其被声明为type指定的类型

‍

使用配方来进行代码转换

在我们的配方写好并启用后，它扫描我们的代码，并突出显示可以应用的部分。

在下面的截图中，我们可以看到目标构造函数已经被Sensei 。悬停在被标记的构造函数上，我们可以看到Recipe shortDescription和Quickfix选项Migrate to java.time.ZonedDateTime。

‍

在我们选择了Migrate to java.time.ZonedDateTime这个快速修复方法后，代码就会根据我们在配方中指定的动作进行转换。

‍

一次性迁移和跨团队的统一编码实践--与Sensei

从上面的例子我们可以看出，一行代码的迁移可能涉及到来之不易的知识。Sensei ，可以把这些知识变成可操作的食谱或食谱，在团队中共享。你可以计划一个一次性的迁移冲刺，或者在你遇到Joda-Time代码时，采取对java.time进行增量即时转换的方法。你可以启用/禁用配方，作为一种在逻辑阶段或步骤中进行迁移的方式，甚至，通过Sensei ，扩大或减少扫描的文件范围--这种灵活性使代码迁移不那么痛苦。

库迁移只是Sensei 用来规范你的项目的许多方法中的一个例子。你可以随时注意在拉动请求中或自己编码时经常遇到的反模式或某些手动代码转换。如果你有一套经常被开发人员遗漏的编码准则，那么你可以将这些准则转化为配方--使开发人员能够自信地应用经批准的代码转换。

如果你有任何问题，我们很愿意听到你的意见在Slack上加入我们：sensei-scw.slack.com

如果你以任何方式与软件打交道，无论你是开发人员、QA、工程负责人还是AppSec专业人员，安全都是你工作的一部分。安全团队的工作是指出软件的漏洞，而开发者的工作则是尽力写出没有缺陷的代码。但是，为了尽可能有效地完成这些工作，重要的是，所有各方都要共同对付安全威胁，从你的应用程序所运行的代码开始。 

然而，有效地学习安全编码并保留这些知识，可能会使它看起来是固有的困难。有了正确的工具，它不一定是这样。但要说服利益相关者和上级投资于正确的培训并不容易。选择培训的唯一目的是为了勾选合规性，而且很多时候培训与开发人员的日常工作无关。但是，如果开发者可以在他们日常工作的语言和框架中实时学习安全知识，并从中获得乐趣，那会怎样？而最重要的是什么？你的组织同时也遵守了行业标准。

我们会支持你的。以下是一些策略，以获得你的同行、领导和组织内的最终决策者的效忠，从而加入以开发人员为重点的安全编码培训计划。   

从一开始就避免软件漏洞，可以节省不可估量的时间和金钱。

你是否发现自己花了太多的时间去寻找、报告或修复重复的安全问题？你并不孤单。 

想象一下下面的情景。一旦AppSec发现一个漏洞并将其报告给开发部门，开发人员就会跳进相关的培训课程，不仅学习如何修复该漏洞，而且学习如何避免在未来犯同样的错误。你认为结果会是什么？那位开发者很可能会因为那堂课的相关性而记住它，并且不太可能再犯同样的错误。这意味着，如果你在一个安全团队工作，那就是一个开发人员不太可能在不知情的情况下再次制造那个漏洞，而且同一个开发人员也不太可能再回去修复它。

请看我们的客户Contrast Security提供的视频，了解实时培训对他们的开发团队来说是多么强大。

如果所有的开发人员都参加了定期的安全代码培训，并拥有了实时了解安全问题的工具，那么重新获得的时间就可以创造出令人惊奇的软件并从事安全项目的工作，这是无法估量的。听起来像是一个很好的理由，让你的组织投资于这样一个工具，对吗？ 

如果你发现了一个很好的工具，你很想用它来提高安全方面的技能，比如（咳嗽）。 Secure Code Warrior，这是一个很好的论据，可以向你组织内的CISO或CTO推荐它。 

被授权的开发者能提供更好的结果，他们会更高兴

时间和金钱对你的管理团队当然非常重要，但你的工作满意度也很重要。满意的员工会带来更好的结果，在他们的工作岗位上呆得更久，并为一个积极的工作环境做出贡献。这就是为什么职业建设和培训是一种投资，而不是一种成本。如果培训实际上是有趣的，并且教给你一些相关的东西？这就是一张通往成功的黄金门票。 

好消息是，开发人员通常有很强的动力去学习安全，因为他们知道安全对他们的工作有多重要。我们在与埃文斯数据公司的研究中调查了来自世界各地的开发者，发现开发者想学习安全知识的原因是：。 

1. 它能提高生产力和效率
2. 他们很好奇，并且个人有兴趣了解它
3. 他们希望避免与不安全的代码有关的问题
4. 他们明白这为职业发展提供了潜力。
5. 这是对人力资源更有效的利用
   

(在此下载完整的白皮书。)

唯一的问题是，大多数安全编码培训都让他们失望。它与他们的日常工作无关，而且，让我们面对它，它是彻头彻尾的无聊。这些特点通常不会在保留信息和实际学习方面带来好的结果。然而，当learning platform ，以开发人员为中心，有趣和有吸引力，并与他们的工作相关时，它可以提供真正的结果，并创造出想要编写安全代码的授权个人。为什么你的老板，无论是开发领导还是CISO或CTO，都不希望开发人员对安全编码感兴趣并拥有这样的技能？

对安全的理解使整体上成为更好的工程师 

当工程师了解软件如何容易受到攻击时，他们在工作中就会考虑到这一点。

不仅如此，质量差的代码更有可能包含软件漏洞，而且开发人员更容易在不知情的情况下将漏洞引入该代码中。为什么呢？因为他们做的很多事情都是阅读和修改代码。当这些代码组织得不好，使用的逻辑也不好时，执行这些任务需要更长的时间，而且更容易改变一些东西，意外地引入一个关键的安全漏洞。

当对安全和如何避免问题有了了解，你也会更努力地思考该代码的整体质量，以及如何以这样的方式编写代码，使错误不容易被意外地引入。安全培训是一个双赢的过程。开发人员学习安全编码，但同时他们也成为更好的工程师。 

数字的力量

另一个让你的领导买账采用安全编码的好策略learning platform ，就是让你的同事加入进来。对提高安全知识感兴趣的开发人员越多，就越容易说服管理层或C-suite进行投资。

那么，你是如何做到这一点的呢？鉴于大多数开发人员都明白需要在安全方面做得更好，并且想要学习，这应该不会太难。你也可以让他们看一下这个secure code warrior 开发者展示，偷看一下我们的产品，开始测试他们的安全编码技能。一旦他们看到不安全代码的影响，并了解到学习安全知识可以很有趣，他们就会觉得有能力去学习更多。

一旦你采用了正确的工具，让你的开发者参与进来的一个好方法就是进行一些健康的竞争。试着用一个tournament.NET平台来启动你的培训计划。 

看看Nelnet是如何通过tournaments ，在他们公司内部建立安全文化的。

持续的安全培训促进了理想的公司文化

培训不一定是枯燥的，也不应该是枯燥的。我们知道，讲座是昂贵的，难以组织--特别是在分布式团队中--而且你不太可能从讲座中得到什么。但是，企业继续为开发人员提供安全编码培训，而这些培训只是每年为合规性打勾而已。仅仅维持现状已经不够了。现在是时候让开发经理和AppSec加强他们的游戏，共同实施一个培训工具，以促进持续和参与的学习。而这要从说服决策人开始。

持续的实践培训是必要的，原因有很多。网络安全威胁在不断演变，因此，打击这些威胁的培训自然也要不断进行。不仅如此，如前所述，当我们实时学习时，我们更有可能保留我们所学的东西。在编码时考虑到安全问题是很难实现的，因为期望一个开发人员回忆起他们从幻灯片上学到的东西，也许是一年前的背景，是不现实的。但是，如果他们在某个软件漏洞被报告给他们的那一刻，就学会了如何避免这个漏洞，同时感觉自己在玩游戏，这就是一个全新的球赛。 

一旦实施了实践性的相关培训，安全就会成为公司文化的一部分，不再被当作事后的想法。它从软件开发生命周期的一开始就被纳入开发过程。 

那么你还在等什么呢？开始你的旅程，在你的组织内提高安全性，保护重要的公司和客户数据。让你的开发人员和老板们加入进来，在你的组织中把安全编码提高到一个新的水平。通过从一开始就考虑安全问题，一劳永逸地停止一次又一次经历同样的漏洞。 

需要更多资源？

下载完整的 "说服你的CISO/CTO工具包"

10月初，Apache发布了2.4.49版本，修复了一个路径遍历和远程代码执行漏洞，随后又发布了2.4.50版本，以解决2.4.49版本修复不完整的问题。也许你已经在社交媒体上看到了关于更新到最新版本以避免这些风险的重要性的讨论，因为根据一些估计，Apache为25%的互联网提供动力。但这是怎么回事呢？这里存在多大的风险？

为什么不自己尝试一下呢？ 

我们已经建立了一个任务来展示真实环境中的风险，并将其公开供大家尝试。在这个任务中，我们将引导你了解路径穿越漏洞如何影响你的基础设施和应用程序。点击下面直接进入，或继续阅读以了解更多关于该漏洞的细节。

关于路径穿越漏洞 

该漏洞是在2.4.49版本中引入的（由于URL规范化功能的改变），其中引入了一个新的路径规范化功能。不幸的是，它未能正确规范URL编码的路径。这使得如果不存在以下配置，就有可能进行路径遍历攻击。

而如果mod_cgi 被启用，它也可以被利用成为一个远程代码执行的漏洞。但是，让我们首先挖掘一下URL编码，以更好地了解出错的原因。

URL 编码

在最基本的情况下，该漏洞的发生是由于缺乏对具有URL编码的URL的考虑。新引入的路径规范化功能没有完全处理点状物是URL编码的情况。 

请记住，要进行路径遍历攻击，你需要用.../这个序列进行遍历。然而，规范化函数足够聪明，可以将其剥离出来。那么你是怎么做的呢？你可以将.（Dot）编码为%2e，并使用.%2e/这样的序列。这在很多情况下对Apache 2.4.40都有效。但你也可以更进一步，对它进行双重编码。.%2e/ 的URL编码版本是.%252e/。这进一步能够绕过Apache试图进行的规范化。

但有一个问题

如果有人想直接在他们的浏览器中尝试利用这个漏洞，他们不会成功。这是由于浏览器也试图将发送到服务器的URL规范化。这意味着，即使是我们的双重编码序列也会被删除。这也意味着我们不能简单地用浏览器来证明这一点。

你可以通过使用-path-as-is 标志来证明这一点，这可以防止它在发送URL之前对其进行规范化。

预防和缓解

为了完全防止这个问题，重要的是保持与Apache的最新补丁同步。具体来说，你至少要升级到2.4.51。但定期升级以保持最新也是一个好的做法。

如果你运行的是2.4.49，为了减轻这个问题，请确保你在你的Apache配置中包含以下内容。

为了防止远程代码执行，如果你不使用mod_cgi ，请禁用它。

亲身体验其影响

有兴趣探究到底发生了什么，并亲自尝试一下吗？ 

‍

Micha Martinez是Nelnet的网络安全分析师和摄影师，Nelnet是一家美国企业集团，从事学生贷款和教育金融服务的管理和还款。当他负责为开发人员创建一个围绕安全编码的培训项目时，他采取了创造性的方法来吸引他的团队。我们对他的安全编码培训项目的运作方式印象深刻，因此我们与他坐下来了解更多。 

底线是什么？ 

创造一种安全文化，并从你的开发团队中培养你的内部安全倡导者，"成为善的力量"。 

"通过专注于安全代码，我们帮助使公司更强大、更安全。" 

在Nelnet，Micha和他的安全团队明白从一开始就建立安全代码的重要性。他们希望以一种有吸引力的、相关的和有价值的方式来实现这一目标。他发现，通过识别对安全编码有强烈兴趣和熟练程度的开发人员，并培养他们成为安全冠军，这些冠军成为改变整个安全培训心态的催化剂。这些人在点对点的层面上指导那些需要更多帮助的同事，并成为在组织内实施安全代码实践变革的领导者。 

以下是米哈关于他和他的团队如何围绕安全预防转变思维方式和文化的更多信息，这使他们的公司 "更强大、更安全"。

这是所有关于吹嘘的权利......和减少漏洞的问题

米哈经营的不是普通的安全培训项目。他利用竞争和他的电影天赋，使tournaments ，极大地吸引和成功。开发人员所获得的是高度相关的、实用的知识，从而使安全代码更加强大。 

由于他们的产品变得更加安全，并对软件漏洞提供了更高层次的保护，因此企业也会赢。学习软件安全不一定是一个典型的、枯燥的学习经历，而只是检查一个盒子而已。开发人员希望培训经历是身临其境的，具有挑战性的，并且与他们的日常工作相关。 

请看Micha谈论他如何通过tournaments ，包括物理冠军腰带作为奖品，使安全编码培训变得有趣。只需要一点健康的竞争，就能让他的团队保持安全至上的理念。 

谁不喜欢一些吹嘘的权利？ 

‍

拥抱以安全编码为中心的文化......工具是不够的

Micha给我们留下了最后一个想法，即他为什么推荐Secure Code Warrior 。该平台是引导他创建预防文化和主动学习的载体。建立培训计划需要时间，也需要对培训和表现良好的开发人员进行投资。这需要一种变革性的文化来培养每个开发人员的技能，以采用预防性的方法来安全地编码。 

这里有更多来自Micha的关于为什么拥抱安全编码文化会使Secure Code Warrior 。

Secure Code Warrior ，为开发人员提供一个身临其境和引人入胜的安全编码learning platform 。对演示感兴趣吗？在下面预订一个。 

在这个日益混乱的世界上，总是有一些人们可以可靠地指望的常数。太阳在早晨升起，晚上又落下，马里奥永远比刺猬索尼克酷，而注入式攻击将永远占据开放网络应用安全项目（OWASP）十大最常见和最危险漏洞名单的首位，攻击者正在积极利用这些漏洞。

好吧，太阳明天就会升起，马里奥仍然 "胜过 "索尼克，但在2021年刷新的臭名昭著的OWASP名单上，注入攻击已经跌出了第一的位置。作为最古老的攻击形式之一，注入漏洞的存在时间几乎与计算机网络一样长。这一空白漏洞造成了广泛的攻击，包括从传统的SQL注入到针对对象图导航库（OGNL）发起的攻击。它甚至包括使用操作系统命令注入技术对服务器的直接攻击。对于攻击者来说，注入漏洞的通用性--更不用说可能被攻击的地方的数量--使这一类别多年来一直处于领先地位。

但注水王已经倒下了。国王万岁。 

这是否意味着我们终于解决了注射漏洞的问题？不可能。它并没有从头号安全敌人的位置上跌落很远，只是在OWASP的名单上降到了第三位。低估注入攻击的持续危险是一个错误，但是另一个漏洞类别能够超过它的事实是很重要的，因为它显示了新的OWASP头号漏洞实际上是多么的广泛，以及为什么开发人员需要密切关注它的发展方向。

然而，最有趣的是，2021年的OWASP十大排名反映了一次重大改革，全新的类别首次出现。不安全的设计、软件和数据完整性故障，以及基于社区调查结果的条目。服务器端请求伪造。这些都表明，人们越来越关注架构漏洞，并超越了软件安全基准的表面缺陷。

破损的访问控制夺得桂冠（并揭示了一种趋势

破解访问控制从OWASP十大漏洞名单中的第五位一路飙升到目前的第一位。与注射和不安全设计等新条目一样，破坏性访问漏洞包含了广泛的编码缺陷，这增加了其可疑的受欢迎程度，因为它们共同允许在多个方面的损害。该类别包括任何违反访问控制策略的情况，从而使用户可以在其预期权限之外采取行动。 

OWASP在将该系列漏洞提升到最高位置时引用了一些访问控制被破坏的例子，包括使攻击者能够修改URL、内部应用状态或HTML页面的一部分。它们还可能允许用户改变他们的主要访问密钥，使应用程序、网站或API认为他们是其他人，如具有更高权限的管理员。它甚至包括攻击者不被限制修改元数据的漏洞，让他们改变JSON网络令牌、cookies或访问控制令牌等东西。

一旦被利用，这个系列的漏洞可以被攻击者用来绕过文件或对象的授权，使他们能够窃取数据，甚至执行破坏性的管理员级功能，如删除数据库。这使得破损的访问控制除了越来越普遍之外，还具有极大的危险性。

认证和访问控制漏洞正在成为攻击者利用的最肥沃的土壤，这一点相当引人注目--但并不令人惊讶。Verizon最新的数据泄露调查报告显示，访问控制问题几乎在每个行业都很普遍，尤其是IT和医疗行业，而且在所有泄露事件中，有高达85%的事件涉及人为因素。现在，"人为因素 "包括像网络钓鱼攻击这样的事件，这不是一个工程问题，但3%的违规事件确实涉及可利用的漏洞，根据该报告，主要是旧的漏洞和人为错误导致的，如安全错误配置。

虽然那些像XSS和SQL注入这样的腐朽的安全漏洞继续绊倒开发者，但越来越多的情况是，核心安全设计正在失效，让位于对威胁者非常有利的架构漏洞，特别是如果它们在一个特定版本的应用程序的安全漏洞被公开后没有被修补。 

问题是，很少有工程师得到超越基础知识的培训和技能发展，更少有工程师真正将他们的知识和实际应用扩大到超越局部的、代码级的错误，而这些错误通常是由开发人员引入的。

防止机器人很少发现的bug

新归类的破损访问控制漏洞家族是相当多样化的。你可以在我们的YouTube频道和博客上找到一些破损访问控制的具体例子以及如何阻止它们。

然而，我认为有必要庆祝这个新的OWASP Top 10；事实上，它更加多样化，包含了更广泛的攻击载体，包括那些扫描仪不一定会发现的攻击载体。对于每一个被发现的代码级弱点，更复杂的架构缺陷会被大多数安全技术堆栈所忽视，无论武器库中有多少自动盾牌和武器。虽然OWASP前十名名单中的大部分仍然是根据扫描数据编制的，但涵盖不安全设计和数据完整性故障的新条目--以及其他--表明开发人员的培训视野需要迅速扩大，以实现机器人无法实现的目标。

简而言之，安全扫描器并不能成为伟大的威胁建模者，但一个具有安全技能的开发人员团队可以帮助AppSec团队，使他们的安全智商与最佳实践以及业务需求相一致。这需要考虑到一个良好的安全计划，并了解到虽然OWASP前10名是一个很好的基线，但威胁情况是如此的快节奏（更不用说内部开发目标的要求），必须有一个计划来更深入和更具体地提高开发人员的安全技能。如果不这样做，将不可避免地导致错过早期补救的机会，并阻碍成功的整体方法来预防，以人为本的网络安全。

‍

我们已经为OWASP Top 10 2021做好了准备，而这仅仅是个开始让你的开发人员走上一条 晋升安全技能的途径今天就开始吧。

网络威胁的情况正变得越来越复杂。攻击者不断扫描网络，寻找易受攻击的应用程序、程序和云实例，而这个月的最新口味是API，由于其安全控制往往很松散，人们普遍认为它很容易获胜。他们是如此顽固，以至于新的应用程序有时可以在部署后几小时内被破坏和利用。Verizon 2021年数据泄露调查报告非常清楚地表明，今天针对企业和组织的威胁比历史上任何时候都要危险。

越来越清楚的是，真正加固正在创建的软件的唯一方法是确保其建立在安全代码之上。换句话说，阻止威胁行为者入侵的最好方法是首先不让他们在你的应用程序中找到立足点。一旦你开始打这场战争，大部分的优势就会向攻击者倾斜。

这种情况首先产生了敏捷开发和DevOps，后来又产生了整个DevSecOps运动，在这个运动中，安全是参与创建软件的每个人从开发到部署过程中的共同责任。但是，这个金字塔的底部，也可以说是最重要的部分，是开发人员。虽然大多数开发人员都想尽自己的职责，编写安全的代码，但他们工作的许多组织却不太支持这样一个优先级的重大转变所需要的变化。

被设计的失败

多年来，开发人员被告知，他们在组织中的主要角色是在一个快节奏的环境中快速构建和部署应用程序，在这个环境中，业务从未停止，客户从未睡觉。开发人员编写代码的速度越快，能够部署的功能越多，他们在绩效评估方面的价值就越大。

安全问题是事后才想到的，甚至根本没有考虑。相反，所有这些都留给了应用安全（AppSec）团队来解决。大多数开发者不喜欢应用安全团队，因为他们经常把已经完成的应用送回开发中，以应用安全补丁或重写代码来补救漏洞。开发人员在已经 "完成 "的应用程序上花费的每一个小时，都是他们没有创造新的应用程序和功能的时间，从而降低了他们的性能（以及他们的价值，在一个特别惩罚性的公司眼中）。

而后，威胁环境改变了大多数公司对安全的重视和优先考虑。根据IBM和Ponemon研究所最近发布的《数据泄露成本报告》，现在每起网络安全泄露事件的平均成本约为380万美元，尽管这几乎是上限。仅一家公司在其网络被入侵后就造成了13亿美元的损失。今天的公司想要DevSecOps提供的安全性，但遗憾的是，他们对响应这一号召的开发人员的奖励却很缓慢。

仅仅告诉开发团队要考虑安全问题是行不通的，特别是如果他们仍然仅仅根据速度来进行激励。事实上，在这样的系统中，那些花时间学习安全知识并确保其代码安全的开发人员实际上可能会失去更好的绩效评估和有利可图的奖金，而他们那些安全意识不强的同事却能继续获得。这几乎就像公司在不知不觉中为自己的安全失误操纵了系统，这又回到了他们对开发团队的看法上。如果他们不把他们视为安全前线，那么利用他们的劳动力的可行计划就很难实现。

而这甚至还没有考虑到缺乏培训的问题。一些非常熟练的开发人员有几十年的编码经验，但在涉及到安全问题时却很少......毕竟，从来没有人要求他们这样做。除非公司为他们的熟练程序员提供良好的培训计划，否则很难指望他们的开发人员突然获得新的技能，并以一种有意义的方式将它们付诸行动，积极减少漏洞。

奖励开发者的良好安全实践

好消息是，绝大多数开发人员做他们的工作是因为他们发现它既有挑战又有回报，而且他们喜欢他们的职位所带来的尊重。终身职业编码员Michael Shpilt最近写了所有激励他和他的编码同事从事开发工作的事情。是的，他在这些激励中列出了金钱报酬，但令人惊讶的是，它在名单上排得很靠后。相反，他把创造新事物的快感、学习新技能和知道自己的工作将直接用于帮助他人的满足感放在首位。他还谈到希望在他的公司和社区中感到被重视。简而言之，开发人员就像很多优秀的人一样，对自己的工作感到自豪。

像Shpilt和其他开发者不希望威胁者破坏他们的代码，并利用它来伤害他们的公司，或他们试图帮助的用户。但是，他们不能在没有支持的情况下突然将他们的优先事项转向安全。否则，这几乎就像系统会对他们不利。

为了帮助开发团队提高他们的网络安全能力，首先必须向他们传授必要的技能。利用支架式学习和即时培训（JiT）等工具可以使这个过程不那么痛苦，并有助于在正确的背景下建立现有的知识。 

JiT的原则是在正确的时间向开发者提供正确的知识，例如，如果JiT开发者培训工具检测到一个程序员正在创建一段不安全的代码，或者不小心在他们的应用程序中引入了一个漏洞，它可以激活并向开发者展示他们如何能够解决这个问题，以及如何在未来编写更安全的代码来执行同样的功能。

随着对提高技能的承诺的到位，过去那种只根据速度来评估开发人员的方法需要被淘汰。相反，编码员应该根据他们创建安全代码的能力得到奖励，最好的开发人员会成为安全冠军，帮助团队其他成员提高他们的技能。而这些冠军需要得到公司声誉和金钱报酬的奖励。同样重要的是要记住，开发人员通常在安全方面没有积极的经验，通过积极的、有趣的学习和激励措施来提高他们的兴趣，将大大有助于确保知识的保留和继续培养技能的愿望。

公司仍然可以将编码速度作为开发人员评估的一部分，但期望开发安全应用程序可能需要更长的时间，特别是在编码人员学习这些新技能的时候。

DevSecOps可以成为抵御日益危险的威胁环境中的黑暗艺术的终极防御。只是不要忘记，这个新世界的拥护者，那些不断创造新代码的开发者，需要得到尊重，并为他们的工作得到补偿。

想让你的安全技能与世界各地的其他开发者一决高下吗？请看 Secure Code Warrior’s 2021年开发奥林匹克运动会，你可以在我们的全球tournaments ，获得一个重大奖项！