安全代码见解

像安全行业的许多人一样，我和几位同事在三月份踏上了旅程 RSA 会议 在旧金山。尽管一年中非常繁忙，但这确实是我最喜欢的活动之一。我特别期待的一部分是 Bugcrowd 的 造币厂的混乱，这是在漫长的会议日之后放松身心并与同行和朋友共度美好时光的机会。

但是，今年略有不同。我们有很多值得亲自庆祝的地方。作为活动的赞助商，当晚我们有自己的鸡尾酒（当然是Secure Code Sangria），但真正让我想参加派对的是我们与 错误人群。这是官方消息：我们正在联手对开发人员进行安全编码方面的教育、赋权和启发。

我喜欢并赞赏整个行业对这一公告所表达的热情，尤其是来自的文章和播客节目 ITSP 杂志。在与Bugcrowd的凯西·埃利斯和杰森·哈迪克斯交谈时，编辑肖恩·马丁真正体现了我们为什么要做我们所做的事情的本质：这是因为有意义的变革需要人群。Bugcrowd 早就意识到了这一点，共同努力将世界各地的软件工程师变成安全超级英雄是梦想成真。

经过二十多年的破坏、发现和修复给世界造成严重破坏的漏洞，围绕安全的讨论比以往任何时候都更加明显，必须改变。“黑客并不总是坏人；他们固有的技能在软件强化过程中是无价的，我们需要齐心协力 从左开始。有朝一日尝试它不应该是一个新颖的概念，它应该是软件开发生命周期的核心。为此，我们和 Bugcrowd 致力于改变许多开发人员对安全的看法：安全是构建功能和特性的不便障碍。

迄今为止，安全培训不足。频率极低，通常与日常编码活动无关，或者根本无法吸引开发人员的心灵和思想。Secure Code Warrior力求改变这种状况——学习安全编码可能很有趣，在Bugcrowd的支持下，这一信息可以在我们非常关心和寻求鼓励的社区中广泛传播。

最终，我们必须达到这样的地步：软件安全是软件质量的代名词；如今，风险实在太大了，无法表明情况并非如此。我相信通过这种合作关系，我们可以让开发人员真正对安全开发感到兴奋。一个蓬勃发展的安全意识和积极的文化环境是关键，我想不出有其他公司能让我们实现这一目标。

关注此空间：安全对话即将急剧向左移动。

设备加密是对 Android 设备上的所有数据进行加密的过程。在 Android 设备上启用此功能后，所有用户创建的数据都会立即加密，然后再写入存储。这样可以保护数据，因此即使任何未经授权的一方试图访问数据，他们也无法读取数据。对于智能手机设备来说，这是一项特别好的功能，因为它们由用户随身携带，并且比其他计算设备更容易丢失或被盗。除非能够解锁手机，否则任何好奇的发现者或小偷都无法访问数据。

安卓有 两种类型 设备加密：全盘加密和基于文件的加密。

全盘加密

全盘加密是在 API 级别 19（安卓 4.4 KitKat）中引入的，但是 API 级别 21（安卓 5.0 Lollipop）中的新功能确实开始了它的使用。全盘加密使用单个密钥来保护整个设备的用户数据分区。密钥受用户凭证保护，必须在启动时提供密钥，然后才能访问磁盘的任何部分。

这对于安全性非常有用，但也意味着在用户输入凭据之前，设备的大部分功能都不可用。这意味着，当设备重启但未解锁时，某些功能，例如警报器无法运行，服务不可用，电话无法接听电话。出于这个原因，创建了第二种加密模式。

基于文件的加密

基于文件的加密是第二种设备加密模式，从 API 级别 24（Android 7.0 Nougat）开始可用。在此模式下，不同的文件使用不同的密钥进行加密，这些密钥可以独立解锁。随着这种加密模式的出现 直接启动 模式，允许加密设备直接启动到锁屏，在解锁设备之前启用先前缺少的功能。

直接启动允许应用程序在设备解锁之前在有限的环境中运行。这样，它们仍然可以在不影响用户信息的情况下按预期运行。为了提供此功能，Android 设备需要两个存储位置：

1. 凭据加密存储。默认存储位置，仅在用户解锁设备后才可用。
2. 设备加密存储。在 “直接启动” 模式下可用，也可以在用户解锁设备后使用。

如果您的应用程序在直接启动模式下运行时需要访问数据，则应使用设备加密存储。但是要注意安全隐患！不应使用设备加密存储来存储任何敏感数据！设备加密存储使用密钥进行加密，该密钥将在设备成功启动后立即可用。任何仅供用户访问的数据都应保存在默认位置，即凭据加密存储。

如果你想进一步了解什么是加密或为什么它很重要，请查看 该视频 在安全代码勇士门户网站上。或者你可以尝试通过玩一些来测试你对加密的了解 挑战。

需要设备分步指南吗？退房 这篇文章 来自 Pixel Privacy 的比尔·赫斯。

我希望你学到了一些新东西。下周见！

凭据加密存储，这是默认存储位置，仅在用户解锁设备后才可用。

https://developer.android.com/training/articles/direct-boot.html

新的研究探讨了高质量安全培训的好处。 

高质量的安全代码培训对你的组织有什么潜在的影响--它是否是一项值得的投资？为了找到一些答案，让我们来看看最近关于开发人员对安全编码、安全代码实践和安全操作的态度的研究中的一些见解，该研究由Secure Code Warrior 与 Evans Data Corp*进行。

当开发人员和他们的经理被问及培训如何改变了他们的编码方式时，每个群组的回答略有不同。这些差异与他们如何对待自己的工作以及他们在软件开发生命周期中的角色相一致。但总的来说，基本的主题是，高质量安全代码培训的影响是压倒性的积极。 

55%的开发者透露，良好的培训增加了他们对自己编码技术的信心，而53%的开发者表示，良好的培训让他们在调试和测试自己的代码时更加谨慎。 

最重要的是，53%的人认为他们在编写代码时更加注意安全 - 导致更少的漏洞和更少的返工。 

管理人员实现更快的软件发布

虽然43%的管理者同意安全代码培训帮助他们的组织在调试和测试代码时变得更加谨慎，但前两个变化反映了管理者的责任。47%的人透露，良好的培训让他们在工具选择上更有选择性，可以提供更多的安全性。而44%的人表示，安全代码培训和技术有助于节省时间和加快软件发布。

安全编码对生产力的影响

当涉及到提高生产力时，安全编码实践可以产生强大的效果。在被问及安全编码如何有助于提高生产力时，超过63%的开发者透露，编写安全/高质量的代码可以通过防止重复出现的漏洞来减少返工。70%的开发人员说，质量培训可以消除后来导致返工或修补的错误。 

安全编码对开发生命周期的影响

随着开发人员和他们的经理将安全编码实践纳入他们的开发生命周期，他们的培训对现实世界的影响可以被衡量。 

看起来改进是全面的，从SDLC的开始就提高了生产力。超过一半的受访开发者声称，良好的培训提高了生产力，应用设计、编码、调试和测试。

调试和测试阶段受到的影响最大，56%的开发人员表示他们在这些活动中变得更有效率。虽然更好的扫描和测试工具可能缩短了这一阶段的开发时间，但安全编码实践促进了使用和重复使用被证明没有代码漏洞的经过审查的代码，以及设计应用程序的安全意识方法。通过在开发生命周期中 "从左边开始 "的安全方法，开发人员可以在调试阶段节省时间。

尽管44%的开发者透露，他们甚至在部署方面也变得更有成效，但在更下游的部署方面受到的影响较小。这是与安全编码实践相关的发布速度提高的结果。

一条行之有效的改善培训之路

毫无疑问，高质量的安全代码培训会带来很多好处。问题是，你如何判断安全代码培训的质量？ 

为了找到答案，我们询问了开发人员他们想要什么。75%的开发者更喜欢结构化的在职培训。他们更喜欢边做边学的方法，而不是枯燥乏味的基于理论的静态学习。当涉及到阻止漏洞时，开发人员处于战斗的最前线。 因此，他们希望培训注重实际应用--这是目前大多数培训项目所严重缺乏的。

作为安全编码变革的推行者，Secure Code Warrior 采取以人为本的方法，帮助您建立以人为本的防御。我们经过验证的learning platform ，在50多种语言：框架中提供上下文的实践培训内容，并模仿开发人员在现实世界中面临的挑战。所有这一切都通过在漏洞成为明天的新闻之前预防漏洞来减少成本和发布时间。

如果你想看看它对你的团队和他们更快地交付安全代码的能力的潜在影响，现在就预订一个演示。

在为移动设备开发时，应用程序通常必须向系统请求一些权限。他们可能需要访问用户的联系人、蓝牙连接或发送短信的能力。上面提到的所有权限都是平台权限，由 Android 框架定义。

但是在某些情况下，这些还不够，应用程序需要定义自己的自定义权限。我将以我们自己的公司为例。Secure Code Warrior可能会创建一个应用程序，将一些私人数据保存为个人资料的一部分，包括用户在SCW平台上的表现。如果用户允许另一款安全培训应用程序（例如DevTrainer）使用这些数据，我们希望允许他们使用这些数据。这是敏感数据，用户当然不想让任何人知道这一点，但是SCWApp不应该完全隐藏和保护它，因为它可能很有用。因此，我们希望让用户控制它。这就是自定义权限的用武之地。

SCWApp 创建自定义权限，DevTrainer 请求此权限，用户可以决定是否要允许此权限。这是一种常见的做法，也是限制访问白名单应用程序的好方法。

不幸的是，从安全的角度来看，自定义权限存在一些不直观的行为，这使它们具有风险。任何应用程序都可以随时定义具体的自定义权限，“第一个获胜”，这种策略会带来一些后果。

对于以下场景，我们定义了上面介绍的两个应用程序配置文件（所有这些应用程序都是虚构的，用于演示目的）：

1。 scwApp：定义自定义权限并使用此权限保护组件的应用程序。

2。 开发者训练器：此应用程序定义了与 scwApp 相同的权限，并向用户声明它希望持有此权限。

这是一个常见的场景，被命名为 “同行应用案例”。如果 DevTrainer 应用程序只是 SCWApp 的插件，则不必定义自定义权限。在这种情况下，假设SCWApp将在DevTrainer之前安装，并且不会发生意外行为。如果用户确实以某种方式首先安装了 DevTrainer，则用户不会被告知权限请求。如果用户随后安装了SCWApp，则不会追溯性地授予DevTrainer的权限，因此DevTrainer应用程序尝试使用安全组件将失败。

这就是 Peers 应用案例的用武之地。在某些情况下，你不能指望先安装一个应用程序。比如说，如果Facebook和Twitter都想使用彼此的组件，他们必须定义彼此的自定义权限。

但是，这才是棘手的地方。如果首先安装了 DevTrainer 应用程序，则不会告知用户其自定义权限请求。此时，即使没有通知用户，DevTrainer 仍拥有自定义权限并且可以访问安全组件。

它变得更加棘手了。DevTrainer 应用程序可以更改权限保护级别。Android 不使用防御者的保护级别，而是使用首先定义的保护级别，这意味着无论哪个应用程序最先安装都可以定义它。这意味着，如果 DevTrainer 将权限级别更改为正常，那么任何未来请求此权限的应用程序都无需得到用户的确认，而是会自动获得访问权限。

此场景的灵感来自于对该问题的解释 cwac-安全github。

“先者胜” 策略会带来一些危险的后果，不知道其行为可能会导致开发人员根据不可信的输入做出安全决策，并允许非预期的应用程序访问敏感数据或受保护的服务。要了解有关通过不可信输入避免安全决策的更多信息， 访问我们的平台。自 Android 5.0（Lollipop）起，此行为已更改。但是从目前开始 超过 22% 的 Android 设备仍在运行较低版本的 Android，因此降低应用程序中原始行为的风险非常重要。检查应用程序首次运行时是否已定义权限，如果是这种情况，请采取适当的措施来解决任何安全风险。

祝你编程好运，下周见！

通过定义自定义权限，应用程序可以与其他应用程序共享其资源和功能。

https://developer.android.com/guide/topics/permissions/defining.html

2018 年 1 月 27 日。安全代码勇士的生日是澳大利亚国庆日的第二天。在考虑又一个美好的一年时，我意识到我的生活中实际上有两个三岁的孩子，一个生意和一个人... 有着显著的相似之处：

• 如果没有适当的例行程序，他们很难在晚上上床睡觉

“只要阅读刚刚收到的最后一封电子邮件... 或者等一下，我很快就需要与我们在美国的团队通电话同步... 否则这个提案确实需要在今晚之前发布。该死的。又过了午夜。”

• 当他们取得成就时，他们会让你感到非常自豪

即使你在 3 周内睡眠不正常，没有时间运动，或者只需要清理烂摊子... 但你的飞行员展示了对开发人员安全技能的影响，客户很乐意承诺再与我们合作三年！繁荣！能量峰值。到处都是蛋糕。突然之间，睡眠不足并不重要。

• 他们长得太快了

你可以和团队一起潜入巴厘岛，在海滨别墅里研究平台的下一个功能的日子已经一去不复返了。去年，我们的初创企业增长了4-6倍（取决于员工、客户还是收入），其工程部门位于悉尼（澳大利亚）和布鲁日（比利时），销售和营销位于美国、欧洲和澳大利亚。我记得一年前，有一家澳大利亚大型银行成为客户，我真的很兴奋。今天，我们正在与全球前100家金融机构中的10家以及一些正在开发下一代在线服务的主要电信和科技公司合作（注意：我仍然为澳大利亚银行感到非常自豪，他们是我们的第一批客户！）。

我们在许多方面成长得如此之快，但去年的关键里程碑之一实际上是定义我们公司的愿景。在早期，我们非常专注于积累、执行和确保有现金，以至于我们常常忘记停下来反思我们想要实现的目标。加入 Secure Code Warrior 的人越多，我们吸引的客户越多，拥有一致的愿景和了解我们的发展方向就越重要。我们在 2017 年就这样做了。

另一个关键里程碑与技术有关。我们很早就意识到，培养开发人员的技能只是安全编码之旅的开始。他们需要身边的工具来嵌入安全性并使其变得容易，而不是事后才想到的，也不是你在完成代码编写后想到的东西。不，需要在编写代码时从一开始就建立安全性。

我们的团队一直在努力为最常见的IDE（IntelliJ、Visual Studio、Android Studio等）编写安全指导插件，这些插件实际上可以帮助开发人员编写更安全的代码。不仅要指出潜在的安全漏洞，还要真正成为一名教练，并在开发人员编写与安全领域领先实践不一致的代码时积极参与。安全指导插件名为Sensei，它确实允许开发人员接受现场培训（微学习），在某些情况下，它将提供自动更正选项以立即修复代码。

我对接下来的12个月将带来什么感到非常兴奋。我们已经看到，软件安全不再只是银行、电信或科技公司等开发人员密集型公司关注的问题。所有类型的组织都继续受到软件漏洞的威胁，尽管SQL注入最终可能会消失，但还有许多其他组织在等待取而代之。

现在，各行各业的客户、市场和董事会对公司保护其代码安全的期望越来越高。合规性也将继续推动组织朝着这个方向前进（例如GDPR（适用于在欧洲开展业务的任何人，澳大利亚出台的数据泄露法等）

这意味着我相信我们的SCW平台将继续在全球和新行业中快速增长。当然，这对我们的业务来说是个好消息，但它也帮助我的团队实现我们的愿景，我认为这对于我们所处的软件时代来说是非常值得的。

使用我们工具的开发人员确实可以而且正在为公司的安全发挥更加积极的作用。他们拥有编写安全代码的技能和工具，可以成为公司的第一道防线。

作为一个三岁孩子的父母兼Secure Code Warrior的首席执行官，我也有同样的感受：每年都比去年好。我等不及要看看这个四岁的孩子是如何成长的！

我们的愿景是通过提高安全性，为开发人员提供从一开始就编写安全代码的技能和工具，使他们成为组织中的第一道防线。

与开发人员会面，无论他们身在何

希望通过 DevSecOps 获得更快、更安全的版本的组织都知道通过集成的技术堆栈优化开发人员生产力的重要性。Secure Code Warrior 的软件集成为您的开发人员提供安全的开发资源，这些资源集成在他们每天使用的工具中，例如 GitHub、Jira 等。

Secure Code Warrior 确保将您的安全代码程序直接内置到您的首选产品和开发人员的工作流程中，从而实现及时修复和更具粘性的学习成果。

通过更快的修复减少漏洞

发现和修复漏洞就像解开一个没有部分碎片和有用的封面的大拼图一样，有时可能需要几天、几周甚至几个月才能完成一个强大的解决方案。当开发人员可能不知道如何解决问题时，这可能尤其困难，要么是因为他们以前从未遇到过问题，要么是因为他们对部署未经测试或未经验证的解决方案犹豫不决。

根据EdgeScan 2022年漏洞统计报告，在整个堆栈中定位漏洞的平均修复时间 (MTTR) 为 57.5 天 (Edgescan2022 漏洞统计报告）。

这是一个关键的窗口，在这个窗口中，宝贵的数据可能会受到损害，失去信任，浪费宝贵的开发人员生产力。由于对所部署的解决方案缺乏知识或信心，您的代码发布速度会降低，并最终通过快速修复或草率拼凑而积累更多的技术债务。

Secure Code Warrior的集成提供了值得信赖的补救建议，使开发人员能够自信地解决安全漏洞，同时保持流程顺利进行。通过授权开发人员在源头上拥有补救措施，AppSec 可以专注于风险监控和加强组织的安全态势。

通过在工作项中嵌入上下文安全编码指南，开发人员可以立即获得帮助，以进一步了解检测到的漏洞以及如何修复这些漏洞，从而降低 MTTR，此外还可以提供有价值的粘性学习成果，主动减少源代码漏洞。

在团队中扩大学习规模

SCORM LMS 集成

SCORM 表示可共享内容对象参考模型，是电子课程的国际标准。如果你的课程以 SCORM 格式发布，你可以确定几乎所有的学习管理系统 (LMS) 都能识别它。使用 SCORM，您可以轻松管理 安全代码培训 与其他培训平台一起编程。

在发货代码之前检查熟练程度

适用于 Okta 工作流程的安全代码勇士连接器 借助可内置到流程中的安全能力检查功能，有助于防止不安全的代码被引入到您的代码库中。在开发代码库时，例如在 GitHub 存储库中，您可以将所需的课程和评估设置为在库中进行编码的限定条件。这使您的领导者能够确保每位开发人员都准备好在相关的代码库中工作，从而帮助提升整个组织的安全态势。

通过确保每个开发人员都具备必要的安全编码技能，从而将安全性引入整个软件开发生命周期，从而获得提交代码的回购权限。这种集成将确保开发人员通过SCW极具吸引力的平台了解最新的安全实践，并减轻手动代码审查的部分负担，从而腾出工程时间在不牺牲质量的情况下提供更多功能。

了解有关 Okta + SCW 的更多信息或者参见 演示 这里。

提交代码时提供即时支持

GitHub 版 SCW 支持在 GitHub 工作流程内进行情境训 要么在 SARIF 文件中，要么直接在他们正在处理的问题和拉取请求中。这使开发人员能够在最需要的时候获得知识，从而帮助他们更快地交付高质量的代码。这种集成不只是启用了通常在不理解的情况下应用的补丁。它不断强化良好、安全的编码模式，从而能够快速识别易受攻击的代码。

了解有关 SCW+GitHub 的更多信息或者参见 演示

GitLab 中集成了可操作的安全编码指南 嵌入了高度相关的安全代码勇士培训链接，指向漏洞报告的 “漏洞详细信息” 部分。通过启用这种集成，这最终有助于缩短知识学习和应用之间的时间间隔，从而确保将来的使用。例如，如果漏洞扫描程序在应用程序代码中检测到跨站请求伪造 (CSRF)，则漏洞详细信息将使用相关的培训链接进行更新。

“通过在我们的平台上提供 Secure Code Warrior 在安全编码方面的广泛情境学习，我们将使开发人员从一开始就拥护安全第一，不仅可以节省时间，还可以帮助他们发展新技能。”-GitLab 副总裁 Nima Badiey

了解更多 关于 SCW + GitLab

新思科技 Seeker 集成 在 Seeker 中嵌入了 Secure Code Warrior 资源、视频和漏洞发现的培训链接。这通过微学习确保遵守行业标准和法规，通过Seeker中易于访问的培训指南来识别和解决漏洞。

了解有关 Synopsys + SCW 的更多信息

立即在需要时在票证内提供帮助

别再只发现安全漏洞了，找人帮忙修复这些漏洞 适用于 Jira 的安全代码勇士。 开发人员可以直接在 Jira 问题跟踪器中接受情境培训，让开发人员能够在最需要的时候获得知识，从而帮助他们更快地交付高质量的代码。Secure Code Warrior for Jira 可以检测到这些问题的详细信息，让开发人员有机会通过访问他们熟悉的环境中的特定培训视频来学习如何修复这些问题。通过情境式微学习，开发团队可以减少整个代码库中的漏洞，并通过 Jira 进行跟踪和报告，从而保持其领先地位。

了解更多 关于 SCW + Jira

快速编写安全代码

Secure Code Warrior 的技术堆栈集成可通过业界信赖的常见漏洞指南和解决方案，实现微学习和更快的补救速度。

• 培训链接以评论形式附在议题和拉取请求中，因此在需要时可以轻松访问指南。

• 内容高度相关，是根据常见漏洞枚举 (CWE) 或开放式 Web 应用程序安全项目 (OWASP) 参考文献提取的。

• 广泛的覆盖范围意味着学习资源来自世界领先的安全编程培训集合。

由于采取了被动措施，常见漏洞在SDLC中仍然存在，其中许多漏洞已为人所知。扫描工具和渗透测试只能发现问题，而且通常是在应用程序已经投入生产之后。众所周知，它们速度非常缓慢——出现多个误报和阴性信息需要人工审查——很少能解决问题的原因或来源。

为开发人员提供工作流程中的微学习和补救建议，并为他们提供支持，可以帮助他们在开发过程的早期发现安全漏洞，以免它们变得昂贵，或者更糟糕的是，留下漏洞可供日后利用。Secure Code Warrior 集成可以满足开发人员在工作地点的需求，不仅可以帮助他们更快地发现和修复漏洞，还可以从可信资源和小规模的指导中学习，以增强他们的技能并增强安全性，这是软件开发生命周期的关键组成部分。

想了解更多？

• 观看我们的产品讲座网络研讨会，了解我们在 SCW 上所有令人兴奋的集成
• 查看 Okta 的演示
• 观看 GitHub 的演示
• 免费试用安全代码战士

本文的一个版本刊登在 网络安全内幕》。 本文已更新并在此联合发布。

‍

从大型语言模型（LLM）代码创建器到复杂的人工智能代理，人工智能助手的采用为软件开发人员带来了大量好处。然而，麻省理工学院的一项新研究强调，最近的研究结果发出了一个警告：对人工智能的严重依赖可能会导致用户丧失批判性思维能力。

在软件领域，与人工智能相关的安全风险与人工智能的采用同步增长，这种认知能力的丧失确实可能导致灾难性的后果。对于开发人员和组织而言，在软件开发生命周期（SDLC）的早期积极主动地识别、了解和缓解安全漏洞是一项道德义务。令人震惊的是，当今许多组织都忽视了这一职责，他们面临的潜在安全威胁也同样急剧上升，其中一些可直接归咎于人工智能。

争论的焦点不在于是否要使用人工智能，因为人工智能在生产力和效率方面的优势实在太大，不容忽视。相反，真正的问题是如何最有效地应用人工智能：在保障安全的同时最大限度地提高产出。而这最好由精通安全的开发人员来完成，他们要深刻理解自己的代码，无论其源于何处。

过度依赖人工智能可能导致认知能力下降

麻省理工学院媒体实验室于 6 月初发布的这项研究测试了波士顿地区五所大学 54 名学生在写作文时的认知功能。这些学生被分为三组：使用大语言模型（LLM）的学生、使用搜索引擎的学生和没有外援的老式学生。研究小组使用脑电图（EEG）记录参与者的大脑活动，并评估认知参与度和认知负荷。研究小组发现，"老派"、"只用大脑 "组表现出最强烈、最广泛的神经活动，而使用搜索引擎的组表现出中等程度的活动，而使用 LLM（本例中为 OpenAI 的 ChatGPT-4）的组表现出最少的大脑活动。

这可能并不特别令人惊讶--毕竟，当你使用一种工具来替你思考时，你就会减少思考的次数。然而，研究还显示，LLM 用户与论文之间的联系较弱：83%的学生甚至在完成论文几分钟后都很难回忆起论文内容，没有一个参与者能提供准确的引文。与其他组相比，作者的主人翁意识缺失。只用大脑的学员不仅主人翁意识最强，大脑活动范围最广，而且他们写出的论文也最具原创性。而 LLM 组的成果则较为单一，而且事实上很容易被评委们识别为人工智能的作品。

从开发者的角度来看，关键的结果是使用人工智能导致批判性思维能力下降。当然，单次依赖人工智能可能不会导致基本思维能力的丧失，但长期持续使用会导致这些能力萎缩。这项研究提出了一种在使用人工智能时保持批判性思维的方法，即让人工智能帮助用户，而不是用户帮助人工智能，但真正的重点必须是确保开发人员掌握构建安全软件所需的安全技能，并将这些技能作为日常工作的重要组成部分。

开发人员教育：人工智能驱动的生态系统必不可少

麻省理工学院这样的研究并不能阻止人工智能的应用，各行各业都在推动人工智能的发展。斯坦福大学的《2025 年人工智能指数报告》发现，78% 的组织在 2024 年报告使用了人工智能，而 2023 年只有 55%。预计这种增长还将继续。但是，使用增加的同时，风险也在增加：报告发现，与人工智能相关的网络安全事件同期增长了 56%。 

斯坦福大学的报告强调了改善人工智能治理的迫切需要，因为报告还发现，各组织在实施安全保障措施方面存在松懈现象。尽管几乎所有组织都认识到了人工智能的风险，但只有不到三分之二的组织对此采取了措施，这使它们容易受到一系列网络安全威胁，并有可能违反日益严格的合规监管要求。

如果答案不是停止使用人工智能（没有人会这么做），那就必须更加安全可靠地使用人工智能。麻省理工学院的研究为如何实现这一目标提供了一条有用的线索。在研究的第四个环节，研究人员将 LLM 用户分成了两组：一组是在向 ChatGPT 寻求帮助之前自己开始撰写论文，在研究中被称为 "从大脑到 LLM "组；另一组是先让 ChatGPT 写出初稿，然后再由他们亲自处理，被称为 "从 LLM 到大脑 "组。Brain-to-LLM 组使用人工智能工具帮助改写他们已经起草好的文章，他们的记忆力和大脑活动都较高，其中一些区域与搜索引擎用户相似。而 "LLM-to-Brain "组则是让人工智能启动论文写作，他们的神经活动协调性较差，而且偏向于使用LLM词汇。

从大脑到 LLM 的方法可能有助于让用户的大脑更加敏锐，但开发人员也需要掌握安全编写软件的具体知识，并严格评估人工智能生成的代码是否存在错误和安全风险。他们需要了解人工智能的局限性，包括其引入安全漏洞的倾向，如提示注入攻击的漏洞。

这就需要全面改革企业安全计划，确保以人为本的 SDLC，在这种 SDLC 中，开发人员可以获得有效、灵活、实践性强和持续的技能提升，这也是全企业安全第一文化的一部分。开发人员需要不断提高技能，以跟上快速发展的复杂威胁，尤其是人工智能在软件开发中发挥重要作用所带来的威胁。例如，这可以防止日益常见的提示注入攻击。但是，要使这种保护发挥作用，企业需要一个由开发人员驱动的计划，重点关注安全设计模式和威胁建模。

总结

当 LLM 或代理机构做繁重的工作时，用户就成了被动的旁观者。研究报告的作者说，这可能会导致 "批判性思维能力减弱，对材料的理解不深，长期记忆形成较少"。认知参与度降低也会导致决策能力下降。 

在网络安全方面，企业不能缺乏批判性思维。由于高度分布式、基于云的环境中的软件缺陷已成为网络攻击者的首要目标，因此网络安全首先要确保代码安全，无论是由开发人员、人工智能助手还是代理创建的代码。尽管人工智能功能强大，但企业比以往任何时候都更需要高度磨练的解决问题和批判性思维能力。而这不能外包给人工智能。

SCW Trust Agent的全新人工智能功能可为您提供所需的深度可观察性和控制能力，让您在不牺牲安全性的前提下，自信地在SDLC中管理人工智能的采用。 了解更多.

越来越明显的是，公司必须将 Secure by Design 原则嵌入到其产品开发流程中——这不仅是为了合规性，也是作为一项关键业务要求。这些指导方针已制定，供公司在将产品推向市场之前识别和缓解其产品中可利用的缺陷。将这些指导方针视为基础支柱，而不仅仅是附加组件的组织根据这些原则构建的产品往往在这个竞争日益激烈的市场中保持领先地位。

但是，自从美国政府的网络安全与基础设施安全局（CISA）发布已有两年了 “通过设计确保安全” 指南，实际上，现实世界的实施仍然是我们难以解决的全行业难题。我们都知道这些原则很重要，但是我们如何才能有效地大规模实施这些原则呢？

在我们最新的白皮书中，我们的联合创始人彼得·丹希厄和马蒂亚斯·马杜博士与包括首席信息安全官、AppSec领导人和安全专业人员在内的二十多位企业安全领导者坐了下来，找出了这个难题的关键部分，揭示了安全由设计运动背后的现实。这是安全团队的共同抱负，但没有共同的策略。

了解一些主要发现：

• 大多数安全从业者和商业领袖都认同 “通过设计实现安全” 计划的理念和价值；但是，从某种意义上说，它仍然有待解释，而且没有标准的全行业实施方法。

• 威胁建模不仅仅是合规清单中需要勾选的东西，它是一种至关重要的、一致的做法，可以帮助精通安全的开发人员及其AppSec同行在风险成为漏洞之前保持领先地位。

• 人工智能这把双刃剑——人工智能既是一项突破，也是一种强大的安全风险，它极大地扩大了攻击面。它的爆炸性增长带来了快速变化的风险，而非熟练的开发人员和资源不足的 AppSec 团队往往难以缓解这些风险。

问题不在于对应用安全设计原则的重要性缺乏理解——如果有的话，对安全软件的需求已成为基本需求和基准期望。缺少的是一个协调的、可扩展的策略，将这些原则嵌入到整个软件开发生命周期中。

我们似乎也缺乏明确的基准或可衡量的结果来确定成功推出。没有这些，团队只能猜测他们的努力是否真正产生了影响。目前，我们似乎有一个统一的战线，但没有共同的战略。

“通过设计确保安全” 是必不可少且不可避免的，而不仅仅是高合规性行业。还必须赋予开发人员权力，而不是增加负担。如果掌握了正确的技能、工具和支持，他们天生就不只是建设者，而是捍卫者，将安全嵌入到最重要的地方：源头。

立即下载 并了解您的团队如何利用强大的开发人员风险管理策略和精确度量来推动企业内部成功、统一的 Secure by Design 计划。

软件开发人员已经表明，他们已经准备好并愿意利用生成式人工智能（AI）来编写代码，而且他们也普遍看到了一些有利的结果。但也有很多迹象表明，他们可能在玩一场危险的游戏。

根据GitHub 最近的一项调查，超过 90% 的美国开发人员正在使用人工智能编码工具，他们认为人工智能编码工具具有更快的完成时间、快速解决事件和更具协作性的环境等优势。使用人工智能工具可以让开发人员放弃常规任务，让他们从事更有创造力的工作，使公司受益，同时也减少了在职倦怠的几率。

然而，研究也表明，人工智能工具在编写代码时容易引入缺陷。Snyk 公司的一项调查发现，尽管 75.8% 的受访者表示人工智能代码比人类代码更安全，但 56.4% 的受访者承认人工智能有时会引入编码问题。令人震惊的是，80% 的受访者表示，他们在开发过程中绕过了人工智能代码安全策略。

自 2022 年 11 月 OpenAI 的ChatGPT首次亮相以来，生成式人工智能模型的使用已经以迅雷不及掩耳之势在金融服务的代码开发流程中蔓延开来，在许多其他领域也是如此。GitHub Copilot、OpenAI Codex 以及越来越多的其他模型的快速出现表明，我们对生成式人工智能所能做的事情和所能产生的影响还只是略知一二。但是，要想产生积极的影响，我们必须确保其生成的代码是安全的。

编码错误会迅速传播

无论是由人类开发人员还是人工智能模型创建的代码，都会包含一些错误。随着人工智能帮助加快代码开发，以满足高度分布式、基于云的计算环境中日益增长的需求，错误代码在被发现之前大肆传播的几率可能会增加。 

正在接受编写代码训练的人工智能模型会摄取数千个执行各种任务的代码示例，然后它们可以借鉴这些示例创建自己的代码。但是，如果它所使用的示例包含缺陷或漏洞--无论它们最初是由人类还是其他人工智能创建的--模型就会将这些缺陷转移到新的环境中。 

研究表明，人工智能模型并不能可靠地识别其所使用代码中的缺陷，因此几乎不存在防止缺陷和漏洞扩散的内置防御措施。人工智能不仅会在编码时犯错，而且会重复自己和其他来源的错误，直到漏洞在某个地方被发现--也许是以使用它创建的软件成功入侵公司的形式。

防止编码漏洞扩散的真正办法是人类和人工智能模型共同合作。人类开发人员应该监督人工智能代码的编写，并对不安全的编码实践和易受攻击的代码进行检查。但要做到这一点，开发人员必须在安全代码编写的最佳实践方面接受全面培训，这样他们才能识别人工智能可能犯的编码错误，并迅速加以纠正。

创建和修复人工智能代码的挑战

像 ChatGPT 这样的大型语言模型（LLM）的突然爆发是一把双刃剑。一方面，公司和普通用户通过使用人工智能处理耗时、繁重或困难的琐事，极大地提高了工作效率。另一方面，也有很多例子表明，如果盲目信任人工智能来处理工作，会出现什么问题。

人工智能模型犯过明显的错误，出现过偏差，也产生过幻觉。在许多情况下，问题的根源在于训练数据不足或不负责任。任何人工智能模型的好坏都取决于它的训练数据，因此训练数据必须全面且经过仔细审核。但即便如此，还是会犯一些错误。

使用人工智能进行编码也面临许多同样的障碍。人工智能生成的代码已被证明包含一系列缺陷，如跨站脚本和代码注入漏洞，以及人工智能和机器学习（ML）特有的攻击，如提示注入。人工智能模型也是在黑盒中运行的，因为它们的过程并不透明，这就使安全或开发团队无法看到人工智能是如何得出结论的。因此，模型可能会重复犯同样的错误。可能影响代码编写的缺点同样适用于使用人工智能进行代码修复和满足合规性要求。 

人工智能模型制造或重复出现漏洞的可能性越来越大，以至于 LLM 现在有了自己的开放式 Web 应用程序安全项目（OWASP）十大漏洞列表。

开发人员和人工智能可携手创建安全代码

对人工智能生成代码潜在缺陷的担忧，可能会让一些组织在采用该技术时产生短暂的犹豫。但潜在的好处不容忽视，尤其是随着人工智能开发人员不断创新和改进其模型。金融服务业就不太可能把精灵放回瓶子里。银行和金融服务公司已经是技术驱动型企业，而且它们所处的领域一直在寻求竞争优势。 

关键是要以最小化风险的方式实施人工智能模型。这意味着开发人员要有安全意识，并接受过安全编码最佳实践的全面培训，这样他们才能自己编写安全代码，并密切监控人工智能模型生成的代码。让人工智能引擎和人类开发人员紧密合作，开发人员拥有最终决定权，公司就能获得提高生产力和效率的好处，同时还能提高安全性、限制风险并确保合规性。 

要全面了解安全编码如何帮助金融服务公司确保成功、安全和利润，您可以阅读最新发布的Secure Code Warrior 指南：金融服务安全趋势终极指南。

‍

‍

查看 Secure Code Warrior博客页面，了解有关网络安全、日益危险的威胁环境的更多信息，以及如何利用创新技术和培训来更好地保护您的组织和客户。

‍