如何在 2023 年保持安全

已发表: 2023-04-09

安全性和性能是您开发的每个项目、站点、应用程序和组件的基石。但在这个不断变化的环境中，保持在基本最佳实践之上的同时进行创新可能具有挑战性。

在此对话中，聆听顶级技术专家讲述他们如何在 2023 年保持安全和性能领先。

视频：如何在 2023 年保持安全领先地位

演讲嘉宾：

WP Engine 高级副总裁兼首席技术官 Ramadass Prabhakar
Lawrence Edmondson，Barbarian 首席技术官
Sergi Isasi，Cloudflare 应用程序性能产品副总裁
Tim Nash，timnash.co.uk 的 WordPress 安全顾问
Jimmy Squires，space150 首席技术官

成绩单：

RAMADASS：大家好。欢迎来到解码的第四版。看到参加者每年都在增长真是太好了。在过去几年中，整个行业的安全格局发生了重大变化。我们经常看到有关安全漏洞和安全性的新闻公告，这是与客户和开发人员等讨论中经常出现的话题。所以今天，我们召集了一群对安全充满热情的行业专家，他们来这里回答我们的问题并与我们分享他们的经验教训。因此，让我们先简单介绍一下我们的小组成员。劳伦斯，交给你了。

劳伦斯·埃德蒙森：非常感谢您邀请我们。 Lawrence Edmondson 是 Barbarian 的首席技术官。 Barbarian 是一家提供全方位服务的数字机构。我们位于纽约。

拉姆达斯：谢谢你，劳伦斯。交给你了，塞尔吉。

塞尔吉·伊萨西：谢谢。我是 Cloudflare 的产品副总裁。 Cloudflare，我们开发的产品可以让我们的客户和合作伙伴（如 WPE）更安全、更快地连接到互联网，我在旧金山。

主持人：谢谢你，塞尔吉。蒂姆，交给你了。

TIM NASH：我是英国的一名 WordPress 安全顾问。而且我基本上一生都在吓唬开发人员。

主持人：谢谢。还有吉米。

JIMMY SQUIRES：好的，谢谢。我在 Space 150 工作，它也是明尼阿波利斯的一家提供全方位服务的数字机构，也是那里的首席技术官。

主持人：感谢您今天同意参加我们的小组讨论。因此，我想先谈谈您今天在您的组织或团队中在安全方面所做的一些独特的事情。那么也许让我们从 Sergi 开始吧。

SERGI ISASI：是的，我会从 Tim 的介绍开始，他在那里吓到开发人员。我们在 Cloudflare 尝试做的更多事情之一是让我们的客户更深入地了解他们的流量并减轻运营负担。所以从历史上看，如果你想找到可能影响你的网络的东西，你可能会看到什么可能的攻击，你会部署一个 WAF，你会把它置于日志模式，然后你会让安全分析师查看日志和看看它检测到什么。而如今可用于此的资源却少了很多。

因此，我们今年的重点是让我们的客户了解我们在他们身上看到的攻击，即使他们今天没有使用可以防止这种攻击的产品。这样他们就可以知道他们的应用程序是否受到攻击，或者总体上处于良好状态。这是我们今年剩余时间的重点，介绍我们所有的安全产品，让我们的客户知道他们的网络上可能正在发生什么或实际发生了什么，以及他们是否想要阻止它。

主持人：太好了。这听起来真的很强大。我期待听到更多相关信息。那么蒂姆，你自己呢？

TIM NASH：所以我与许多不同的客户合作，既有代理机构，也有较小的个人网站。我做了很多代码审查和网站审查。直到今年，我还没有看到真正关心的人有如此多的增长，以至于人们很乐意得到评论并只做你告诉他们做的工作。所以如果你给他们一堆建议，他们就会照做。但如果明年我回到该网站，我只是给他们另一堆建议。所以我在去年看到了很多人真正关心问题的转变。所以对我来说，代码审计已经被丢弃在这个文件的第 6、4、2 行，废话，需要像这样完成。

我摆脱了所有这些，真正开始关注教育，并且意识到，老实说，大多数人想要的不是被告知，你必须修复这条线，而是被告知，这是修复的方法那里的每一条线。所以对我来说，最大的变化和重点变化一直是教育。这是整个行业的事情。我认为今年谈论安全的人比去年越来越多，而且比前几年越来越多。

主持人：不，那太好了。我真的很喜欢这种从给你鱼到教你如何抓鱼的转变。所以那真的是——

TIM NASH：我试图不惜一切代价避免这种类比，因为它是陈词滥调。

主持人：谢谢。

TIM NASH：干得好。

主持人：好的，吉米。

JIMMY SQUIRES：是的，我认为有很多，我决定专注于一件非常具体的事情来讨论这个答案。当您处理 API 令牌和访问时，这确实限制了您的范围。我认为去年的 Heroku、GitHub 存储库泄露事件很好地提醒我们，你只能控制这么多事情。因此，当我们与我们的开发人员合作时，提醒他们在您可能使用的任何平台或系统上的范围访问策略的重要性。很多时候，为了方便起见，开发人员确实希望在开发早期就拥有相当广泛的开放访问权限。有时那些我们可能——都羞于承认——他们没有被收紧到生产前应该达到的水平。因此，尽早开始真正考虑这些安全范围。

主持人：谢谢你，吉米。劳伦斯，我知道你也经常与开发人员一起工作。那么你们都在那个前面寻找什么？

劳伦斯·埃德蒙森：是的，当然。只是为了建立在吉米所说的基础上，当然，我们都从事广告工作。因此，我认为当您在广告环境中工作与在产品环境中工作时，我们会看到很多相同的挑战。对于我们来说，我们接触了很多不同的技术，很多不同的技术栈。我们必须在技术上不可知论。所以我们看到的是，消费者现在通过移动和社交以多种方式参与。几年前，桌面是访问网站和内容的主要方式。现在完全颠倒了。它从桌面到移动，再到现在的社交。

因此，您的 API 层和应用程序层必须以一种与它们相关联的健康偏执狂的方式被锁定。因此，我们看到的是攻击范围正在扩大，因此我们一直在寻找新的方法让 DevOps 像程序员一样思考，以便他们了解破坏事物的可能方式。这就是我们今天正在做的事情。

主持人：谢谢你。你提到了攻击向量是如何增加的。这就是我们在 WP Engine 上所拥有的东西，一直在从如何采用深度防御机制的角度进行更多研究。所以不要相信任何层都是安全的。那么你如何将它融入你的编码方式和你编写软件的方式中。非常感谢你的帮忙。正如你们都在谈论那里正在发生的变化趋势，以及过去一年发生的违规行为。展望 2023 年，你们都在关注哪些重大主题或威胁？也许，Sergi，你可以让我们开始。是的。

塞尔吉·伊萨西：当然。这听起来很愚蠢，因为现在是 2023 年，我要说 DDOS 这个词，但这仍然是一个问题。在 DDOS 世界的过去 9、12 个月里，这确实是一个有趣的转变。如今，Volumetric 并不是真正的 DDOS 向量。反射少了很多。从威胁行为者的角度来看，启动 DDOS 更容易，因为你有很多现成的工具，对吧？我们几乎又回到了脚本 TD 时代，但您要攻击的受感染系统也少了很多。因此，如果您尝试进行反射，那么没有多少基础设施是由可能没有为系统打补丁的人管理的，因此您可以拿一个数据包并将其变成 10 个。这不再是什么大事了。

所以他们正在转移到第 7 层。第 7 层的启动成本更高，因为你需要大量的 CPU 来完成它，但它的缓解成本也高得多。所以如果你有某种 DDOS 保护系统，你实际上必须接受连接，检查它然后开始丢弃它而不是你可以在较低层丢弃它的东西。就在上个月，我们发现并缓解了有记录以来报告的最大的第 7 层 DDOS。这些攻击的主题是更强大的设备。

因此，如果您想想这些天我们在家里插入的所有东西，该设备上的处理器甚至比三四年前要好得多。所以你的相机做的更多。所以它有一个更强大的 CPU，甚至你的路由器实际上也是一台相当强大的机器。对这些设备的任何妥协都可能引发一场非常非常大的攻击，尤其是因为如果你妥协了一个设备，你现在基本上会危及所有连接的设备。

这些天我们谈论的另一件事是，但比较安静的是，我们已经从受感染的硬件设备转移到受感染的云服务帐户。云服务实际上拥有无限的 CPU。因此，如果我可以访问多个个人或公司帐户并在该云系统中启动我想要的任何内容，那么我就可以发起一次非常大的攻击。这就是我们在破纪录的攻击中看到的。所以是的，2023 年，DDOS 仍然存在，仍然是一个问题，但现在在第 7 层与较低层。

主持人：谢谢。这很可怕，但与此同时，我认为它指出了我们如何继续增强我们的安全协议以及重点领域的持续增长。我知道，劳伦斯，你和我过去曾谈过人工智能既是繁荣又是威胁。我很想听听您对生成式 AI 的一些想法，以及您如何看待它对 2023 年安全领域的实际影响。

劳伦斯·埃德蒙森：所以我非常兴奋，非常看好人工智能。我们身处野蛮人，但与此同时，它也非常可怕。以恶意方式使用诸如 chatGPT 之类的东西的可能性。例如，您可以让 Chat GPT 评论您的代码。它实际上做得相当不错，这取决于你的代码是什么语言和混乱程度，它做得很好。所以接下来，我想，我们将看到的是 Chat GPT——这可能已经在进行中，因为每天，Chat GPT 都会这样做。就像今天，我只是看到它可以在 Slack 中响应并在 Slack 中找到答案。

所以我认为，就安全性而言，Chat GPT 的下一步是让 Chat GPT 发现漏洞并将代码实际写入——恶意代码，以真正利用它发现的弱点。所以我们看到了这一点，尤其是在内存中的潜力。所以记忆攻击不会一直留下签名。因此，传统的病毒和病毒扫描程序致力于寻找攻击的特征。在内存攻击中，您是在攻击应用程序。您正在做类似缓冲区溢出的事情。您希望在运行时破坏应用程序。我想我认为 Chat GPT 实际上已经准备好做到这一点。而且我认为我们看到第一个大规模的 ChatGPT 漏洞利用只是时间问题。

蒂姆·纳什：您如何看待实际发生的情况？因为显然 ChatGPT 的核心只是一组对服务器的 API 请求。你发送了一个请求，说，嘿，给我生成一些恶意代码。它正在返回它。我的意思是，已经有很多人在生成恶意代码。那么，您将如何使它变得比已经存在的恶意代码更糟糕？

LAWRENCE EDMONDSON：没错。已经有一个大型存储库可供学习。所以 ChatGPT，它所做的，它实际上看的是——你必须训练模型。所以随着时间的推移，工程师们训练模型来识别当有人说这句话时，这实际上是他们的意思。所以理解语境。所以它确实如此，但以不同的方式。它训练模型实际编写代码及其实际含义。有些语言非常简单。所以 PHP，很容易用 PHP 编写代码。这些解释性语言要容易得多。它更加混乱，但是与必须编译的 Java 之类的东西相比，您知道我的意思吗？

所以我认为一个简单的方法是创建一个基于 chatGPT 3 的模型，实际上，你训练它实际 - 你通过语法知识，你通过所有基本的计算机科学知识，然后你接受它更上一层楼，好的，这些 NPM 包有这些漏洞。寻找它并找出一种方法来实际 - 他们有这些漏洞，我很抱歉，并寻找一种方法来利用这些漏洞。我保证，我们离看到类似的事情发生并不遥远。

主持人：谢谢你，劳伦斯。我认为这是一个非常新兴的领域。这个领域的有趣之处在于人工智能，一般来说，它在你可以利用它的目的之间取得了平衡，无论是实际使用这些签名来预防还是从中学习，看看你如何防止我们编写糟糕的代码或易受攻击的代码。同时，就像我们看到人们谈论的那样，嘿，我用 Chat GPT 在五分钟内编写了我的第一个插件，我想 – 是的，更多的是这是否开始让人们能够稍微创建恶意软件快点？但我认为它有两个方面。

它更多地是关于您如何继续利用这些工具中的任何一个来更好地编写代码，但编写更安全的代码。我知道，蒂姆，这是你热衷的领域。您想多谈谈您如何看待 Secure Code 在 2023 年的发展以及您在该领域所做的事情吗？

TIM NASH：嗯，我的意思是，在很多方面，Chat GPT 就是一个很好的例子。如果我在考虑攻击向量，老实说，我并没有想到它会进行大规模扫描，作为一个坏演员向它提供很多东西。我将其视为普通代码开发人员，他们试图节省时间，将内容输入 Chat GPT 并将其丢弃，但不一定完全理解所有正在编写、正在生成的代码，还没有编写任何测试随它去吧。这只是一件很快的事情，它只是一个快速的脚本，一切都很好。它投入生产，它不好，它全部燃烧。

现在这与每个开发人员每天所做的事情完全相同，无论如何。 Chat GPT 并没有改变这一点，但它确实更容易启用它。它确实给了——障碍更少了。

SERGI ISASI：是的，所以它与从 Stack Overflow 复制和粘贴不太一样，我认为这就是你所指的，Tim，这基本上是我为代码所做的一切。但我认为这肯定会提高效率，无论是积极的还是消极的。但我确实认为它允许更微妙的变化和更快地利用更多基于签名的引擎无法真正赶上的东西。所以当你做检测时，你真的需要有一个系统说，这看起来是否与我过去看到的东西相似，而不是直接匹配我过去看到的东西。而这实际上在检测方面也可能最好与 ML 或 AI 或任何你想称之为的东西一起使用。

我们了解到，随着自动流量的增加，基本上是机器人。了解他们如何绕过基于签名的检测的最佳方法是使用机器学习。但是你现在正在从，我绝对知道这很糟糕，到，好吧，它可能是自动化的，或者可能看起来像我以前见过的签名，但不是完全匹配。

主持人：太好了。谢谢。谢谢 Sergi 和 Tim 提供的补充内容。因此，在我们的与会者中，我们今天有很多开发商和机构。很多人都在考虑建立最佳实践，尤其是当场景在威胁向量方面发生变化时。那么，在构建网站、应用程序或平台时，或者在您开始新项目时，您会推荐哪些最佳实践。那么人们应该注意哪些事情呢？

SERGI ISASI：那么我可以开始了。它将更多地出现在运营方面而不是开发方面。我认为我们在这里宣扬的一件事是，假设会发生不好的事情。所以突破口即将到来，你不能只是对它感到惊讶。这很可能会在某个时候发生。还有我们的关键——所以，一个，为此创建一个运行手册。因此，当它确实发生时，要知道要联系哪些人以及你的反应是什么，包括检测和响应，但如果它影响到你的客户，也要与他们沟通。在这一点上，我认为，我们在 Cloudflare 做得很好，它已经成为我们品牌的一部分，我认为它对我们很有帮助，那就是在任何事情上都保持坦率、开放和沟通那事发生了。

开放性对于在确实发生某些事情时重建与客户的信任非常关键，无论是软件漏洞还是您在事件方面犯下的一些错误。躲在它后面永远不是正确的选择。

主持人：是的。

JIMMY SQUIRES：我认为我们还有其他事情 - 现在每个人显然都处于远程状态，尤其是在开发团队中，实际上是在项目开始时花时间做一些白板和架构规划。深入了解需求并完成开发故事是如此容易，但花时间与您的同行一起挑战如何利用它？运行场景。我们做了很多场景规划，这导致了很多很好的对话，我们希望如何支持应用程序的不同部分。

LAWRENCE EDMONDSON：关于这一点，我不知道是否有人知道，但 MPM 实际上是最大的共享存储库——它是最大的应用程序库存储库，但这意味着它也带来了最大的风险。因此，如果我们使用 NPM，在开展一个新项目时，我们非常清楚的一件事是确保我们正在研究漏洞，我们锁定我们推送到生产的版本，在我们之前在进行更新时，我们确保它是兼容的，但也非常安全。没有公开的威胁，因为我们已经看到很多漏洞在 NPM 蔓延。所以这只是需要注意的一件事。

TIM NASH：我认为我们正在循环播放。

JIMMY SQUIRES：继续，蒂姆。

TIM NASH：我认为我们正在围绕这样一个想法循环：实际上，多年来，信任在开发周期中被完全打破。人们现在才意识到这一点。例如，如果您是在 WordPress 中工作的 PHP 开发人员，您会坐在那里调用操作和过滤器，但您不应该信任这些操作和过滤器。任何进来的数据，你都应该验证，你应该检查它。它应该被消毒。但是当它从数据库中出来时，你仍然不应该相信它。

即使您可能已将该数据放入数据库，您也不应相信即将输出的数据。如果我们将某些东西传递给第三方库，无论是 NPM、作曲家包还是另一个 WordPress 插件，它都会立即离开我们的控制，我们不再信任它。但是当它回来的时候，即使我们已经检查过了，我们仍然不相信它。如果你以这种心态进入，作为一名开发人员，每条数据都不应该被信任并且应该一直被隔离并且你应该在每个给定点对其进行安全检查，你会想出有一个更安全的系统。你可能会得到一个稍微慢一点的系统。您可能会遇到一个稍微令人沮丧的系统，并且需要进行更多测试以确保您正在做的事情实际上不会造成比它帮助更多的问题。

主持人：是的。

TIM NASH：增加复杂性，但您最终会得到一个更安全的系统。对于大多数人来说，这就是他们想要的。

劳伦斯·埃德蒙森：是的。

主持人：是的。你是绝对正确的。这是关于不信任任何其他正在通过的代码。对于 Jimmy 和 Sergi 所说的，它有一个计划，从架构的角度，或从运营的角度，但将所有这些结合到您的整体实践中，无论是安全编码机制还是有事件剧本。所以蒂姆，我很想听听你周围的更多信息——你做了很多培训，你在世界各地做了很多教学。当人们开始从事项目时，你看到的一些常见错误是什么，或者你可能犯过的错误，我已经犯了很多。

TIM NASH：我想说的是，我很确定我对我将要谈论的每一个错误感到内疚。最重要也是最简单的就是做一个好人。大多数开发人员都认为是善意的。大多数人假设您将按照编写他们的应用程序的方式使用他们的应用程序。现在很多时候，我们不编写文档，因此用户首先不知道如何使用该应用程序，但这是一个单独的问题。一个糟糕的演员会进来并抓住任何错误然后离开，这不是错误，对于一个糟糕的演员来说，这是一个功能。那是一个机会。它正在做一些开发人员没有预料到的事情，因此，有一条潜在的途径可以做到这一点。

总的来说，当你说，哦，看，你有一组单元测试时，你会一次又一次地看到。哦，太好了。但是你只测试了积极的东西，你想要的结果。您还没有测试如果我们超出这些界限会发生什么。您刚刚进行了测试，以确保该系统按照您老板的要求运行。所以你真正拥有的是验收测试，可疑的验收测试。然后它回到所有基础知识。作为开发者，倒退到这个，不要轻信东西。特别是如果您是 WordPress 开发人员，WordPress 实际上有一些非常好的辅助功能来执行我们要求人们执行的所有标准安全操作。

这是关于教育和学习使用它们。当我进行代码审查时，我会一遍又一遍地看到同样的问题。如果我在一段代码中看到它一次，我将在同一组代码中看到它 1,000 次。它会是这样的，好吧，我们只是允许任何旧的东西出现在页面上。我们懒得去检查里面有没有东西。是的，我们把东西存入数据库。哦，看，它可能看起来像一个 SQL 查询，也可能不是。

所有这些事情都很容易修复，我们已经提供了修复工具。我们不修复它们的原因往往不是因为人们不知道他们不应该让这些事情发生，而是我们变得懒惰，我们做事很快，我们从 Stack Overflow 获取代码，我们正在让 Chat GPT 为我们做事，我们不会检查一切。而很多安全问题都来自于这种状态，我必须着急。我必须赶时间。我必须赶时间，我必须完成这件事。我要继续下一件事，我要继续下一件事。

很奇怪，对于很多开发人员来说，实际上只是给他们时间和空间，然后说，花时间实际检查你所做的事情是可以的，这样当它下来时——在我参与的情况下，我回来说，好吧，所有这些事情和开发人员看起来都不好意思。他们要去，是的，我们知道这一切。我们只是没有时间。

因此，希望能给人们更多时间并实际为他们提供我们已经在 WordPress 中特别提供的工具。 WordPress 有一组非常出色的辅助函数，可以解决您在 WordPress 插件或主题中遇到的最常见的安全问题。所以这只是关于学习这些，然后投入时间来实际实施它们。

主持人：是的。我认为这真的很强大，投入时间。大多数情况下，开发人员知道需要修复什么。所以给他们时间。所以我真的很喜欢这个信息。吉米，我知道你已经将其纳入你所在机构的工作流程中。您想多谈谈您实施的安全工作流程实践吗？

JIMMY SQUIRES：是的，当然。实际上，一切始于 Sergi 所说的制定计划，实际上是为您的开发团队提供可遵循的指导方针和标准。我知道这听起来可能很基本，但我见过很多组织，也从我们多年来聘用的很多工程师那里听说它不存在。他们所在的工作地点没有组织。

所以我们喜欢做的是我们有一套标准的指导方针，我们所有的新工程师都需要从头到尾通读一遍。它没有那么重，不是消耗品。我们喜欢将它保存在 markdown 中，所以它都在一个存储库中。我们可能会在某个时候真正开源它。那里没有任何真正专有的东西，然后我们鼓励每个人都为它做出贡献。这是对所有工程师的要求。

因此，即使在我们的指导方针中，也要在我们可以添加的地方、我们可以做得更好的地方戳洞，不断发展。但是花时间在这上面，一些基本的东西，比如 OWASP，这是一个非常古老的做法，但是要通过你的应用程序，考虑这些东西。蒂姆就是这么说的，真的很花时间，并且愿意花时间去做。我想在 AI 对话中加一分。上周与我们的一些工程师交谈实际上发生了一个事件。我们使用 Chat GPT 的目的实际上是单元测试。采用一个函数并以有趣的方式探索它，您如何利用诸如 Chat GPT 之类的东西来编写单元测试，而您不会成为该单元测试的最佳作者，就 Tim 而言。这就是我认为我们可以以预防方式更多地利用人工智能的地方。

劳伦斯·埃德蒙森：是的。我们这边正在做的事情，我认为清单和剧本很棒。我们正在使用诸如 SonarQube 之类的自动化工具，并且确实有 linting 之类的东西，只是为了通过 linting 提高代码质量，但也使用 SonarQube 来确保代码更安全，我们正在寻找对于漏洞和类似的东西。正如我之前提到的，我认为某些语言比其他语言更容易找到漏洞，这只是因为语言的性质。还有某些框架，其中通常为该代码库做出贡献的编码人员的质量——我们通常在开源中看到这一点，就像——有很多 Stack Overflow 复制和粘贴正在进行，而不是那些实际研究过的人CS，真的知道他们在做什么。所以这只是我所看到的一件事。

TIM NASH：我觉得我们应该指出，当然是为了我自己，我几乎每天都使用 Stack OverFlow。所以我们都为此感到内疚。批评它很好，但我不认为——我的意思是，我记得我第一次开始编码的时候。我拿到一本杂志，正在从杂志中输入代码并按下 Enter。如果我们仍然坚持这样做并且没有 Stack Overflow 或类似的东西，我无法想象今天的网络真的有效。

塞尔吉：不，是促进剂。希望人工智能是下一个阶段。但是，是的，这是一个有趣的模因。

主持人：谢谢。所以稍微动了动。围绕 Headless 和 Headless 实现的行业正在发生很多势头。我们还在今天的其他一些频道或其他会议上看到了关于 Headless 的话题。因此，当我们开始在 WP Engine 中使用 Atlas 时，我们遇到了很多开发人员，安全性始终是一个关键的动力。那么您如何看待 Headless 的安全性？我知道，吉米，这是一个你围绕它做了一些项目的领域。我们很乐意听取您的意见。

JIMMY SQUIRES：是的，我们在 Headless 中做了很多工作。我认为目前我们几乎所有的项目都可能采用无头架构方法。我认为我只想就此提出几点，因为它与安全性有关。所以我认为第一个是，当你选择 Headless 架构时，你通常会在开始时将自己更多地放在开源阵营中。当然，关于什么更安全、开源还是闭源，存在很多争论。我倾向于属于 OSS 项目的阵营，这些项目本质上更安全。所以你选择了像 Next、WordPress 这样的框架，在那里你有一个巨大的社区。这往往会通过仅仅暴露来增加安全性。

所以我认为这是一个。我认为第二个是静态生成之类的东西。因此，构建的许多网站和产品，您不需要大型内容管理的动态特性，传统意义上的整体系统。您可以利用 Cloudflare 之类的东西并真正静态地生成该应用程序的大部分内容，从而减少矢量和曝光的足迹。所以我们是它的忠实粉丝。然后，当然，您也可以获得所有性能优势。所以这些只是我想就无头架构提出的几点。但从安全的角度来看，我们喜欢它的原因还有很多。但我认为这可能是两个最突出的领域。

TIM NASH：我想稍微反驳一下，提醒人们后面还有一个内容管理系统。我经常听到，Headless 是完全安全的。就像，是的，但是那个暴露的 WordPress 实例仍然在那里，只是因为你没有直接从网站调用它，是的，它仍然在 admin.yoursite.com 上。你还没有——有一种信念认为，哦，是的，好吧，我们现在很安全，所以我们不需要担心保持最新状态，因为它不是网站。就像，不，不，你仍然需要你以前做的所有事情，现在我们也有了另一面。

我的意思是，Headless 是一个很好的术语，它指的是已经存在了很长时间并且势头强劲的东西，但我们在 WordPress 拥有 REST API 之前就开始这样做了。我们将内容从 WordPress 推送到 Jekyll 之类的东西，以至少从中获得一个静态站点。这样做的最初原因是为了改变网络中的 WordPress 系统或内容管理系统。所以你可以把它锁起来，让它远离大而可怕的网络。

现在我们有很多提供 Headless 解决方案的托管公司。 And that infrastructure is now out in the cloud again. So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. 谢谢。 And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.