对于开源软件安全动员计划，我们是否足够成熟？
在当前的经济环境和威胁形势下，我当然不会羡慕普通的CISO。他们的任务是提供安全、合规性、创新和商业价值，同时面临着预算缩减和审查增加的艰苦斗争。也许更紧迫的是，每个组织（及其各自的开发团队）都处于不同的安全成熟度阶段，并不是所有的组织都有能力在网络防御方面发挥其最佳作用。
过去几年，网络安全事件不断升级，使安全领导者很难保持领先一步。仅仅瞥了一眼关于我们日益增长的困境的一些数据驱动的见解，就可以看出一些火药桶的情况：仅在2023年就有超过330亿条记录被网络犯罪分子窃取，比2018年增加了175%。据预测，到2025年，网络犯罪的成本将达到10.5万亿美元，数据泄露的平均成本已经飙升至424万美元（尽管我们只需要看看像Equifax或Solar Winds这样的事件，就会发现情况可能更糟）。
作为一个行业，我们已经花了很长时间等待一个英雄出现，把我们从网络安全的坏人手中解救出来，这些坏人的力量似乎比我们想象的要大，甚至在十年前也是如此。我们在等待更多的网络安全专业人士加入进来，将我们提升到更高的安全项目标准，但这是我们无法弥补的差距。我们在等待银弹式的工具解决方案，承诺将我们从日益增长的风险中自动化，但它并不存在，也不太可能存在。我们在等待我们的天行者卢克来帮助我们对抗黑暗面。
事实证明，帮助（和希望）正在到来，其形式是《开源软件安全动员计划》。然而，我们都必须总结并诚实地评估我们的组织是否足够成熟--以及我们的开发团队是否有正确的安全意识和技能水平--以实施最新和最伟大的防御策略，特别是当它们需要开发团队的支持和执行时。
什么是开源软件安全动员计划？
这个十点计划是由开源软件基金会（OpenSSF）和Linux基金会牵头，联合白宫官员、顶级CISO和来自37家私营技术公司的其他高级领导人共同发起的。在这种行动和资金的共同支持下，开源软件的安全标准将变得更加强大。
特别有趣的是，他们把重点放在开发人员层面的基线教育和认证，以及旨在简化内部软件材料清单（SBOM）活动的措施。这些都是出了名的难以实施，难以产生持久的影响，这可以部分归因于组织安全计划中的成长痛苦，以及开发团队中普遍缺乏安全成熟度，这不是他们自己的错。他们处在一个压力锅的环境中，面对越来越多不合理的最后期限，代码量的速度是最高的。在没有增加可用时间的情况下，以安全询问和SBOM维护的形式增加更多的任务，这是一个在开始之前就已经失败的秘诀，可悲的是，这比我们预期的还要普遍。
因此，让我们来看看引擎盖下的情况。
开发者的安全认证。我们还没有到那一步吗？
如果有一件事我们是肯定的，那就是具有安全技能的开发人员仍然是一种稀有商品。这是现实，原因有很多，即直到最近，当涉及到组织内的软件安全策略时，开发人员并不是等式的一部分。再加上开发人员没有什么理由优先考虑安全问题（他们的培训不充分或不存在，需要更长的时间，这不是他们KPI的一部分，他们最关心的是做他们最擅长的事情：构建功能），你的开发团队没有准备好在代码层面真正处理安全问题，也没有在现代化的、以DevSecOps为中心的软件开发生命周期（SDLC）中发挥作用。
如果我们看一下《开源软件安全动员计划》，十点计划的第一条就是解决开发人员的安全技能，"向所有人提供基线安全软件开发教育和认证"，这对建立开发团队的安全成熟度至关重要。他们强调了我们已经讨论了一段时间的问题，包括大多数软件工程courses ，安全编码是MIA的事实，在高等教育阶段。看到这一点是令人难以置信的，因为它得到了个人和部门的支持，可以改变行业现状，而且世界上99%的软件至少包含一些开源代码，这个开发领域是一个伟大的地方，可以开始关注开发人员的安全培训。
该计划引用了受人尊敬的资源，如OpenSSF安全软件基础知识 courses ，以及OWASP基金会的广泛、长期的资源。这些信息枢纽是非常宝贵的。为提高开发人员的技能，拟推出的这些材料涉及汇集公共和私营部门的广泛合作伙伴网络，以及与教育机构合作，使开源安全开发成为课程的关键特征。
至于他们将如何赢得全世界软件工程师的心--其中许多人已被强化为安全不是他们的工作或优先事项，该计划详细说明了奖励和认可战略，以维护开源库的开发人员和需要看到安全认证价值的在职工程师为目标。
我们从经验中知道，开发者对激励措施反应良好，显示进度和技能的分层徽章系统在学习环境中的效果与在Steam或Xbox等平台上的效果一样好。
然而，值得关注的是，我们没有解决其中一个核心问题，那就是在组织的安全计划中提供学习模块。在我职业生涯的大部分时间里，我都与开发人员密切合作，我知道他们对工具和培训是多么的怀疑，更不用说任何看起来可能会破坏工作的东西了，而工作是第一优先事项。开发人员的能力建设需要他们不断地参与到课程材料中去，而要想成功，就必须在他们的日常工作中找到意义。
如果我们考虑像软件保障成熟度模型（SAMM）这样的成熟度模型，"教育和指导 "是Governace层的一个核心组成部分，并且有一个关键的重点是开发者教育。该模型整体上是庞大的，在达到更高的成熟度水平方面有渐进的步骤。然而，初始阶段只建议对开发人员进行1-2天的正式培训，这几乎不足以触及安全意识的表面。即使如此，企业战略集团（ESG）最近的一份报告显示，只有不到一半的组织要求开发人员每年参加一次以上的正式安全培训。我们自己与Evans Data联合进行的研究显示，只有29%的开发者认为应该优先考虑编写无漏洞代码的积极做法。在如何提供和接受教育，以及它在实现安全成熟度方面的真正作用之间存在明显的脱节，特别是如果开发人员没有看到价值。
软件材料清单。这个计划是否打破了采用障碍？
该计划寻求解决的另一个领域是围绕软件材料清单（SBOM）的创建和维护经常存在的灾难，其中 "SBOM无处不在--改进SBOM工具和培训以推动采用 "的项目研究如何使开发人员及其组织更容易创建、更新和使用SBOM以推动更好的安全成果。
就目前而言，SBOM在大多数垂直行业中没有被广泛采用，这使得它们在减少安全风险方面的潜力难以实现。该计划有一个出色的策略，为SBOM的制定定义了关键标准，以及适合开发人员工作方式的易于创建的工具。仅仅这些就可以大大减少开发人员在SDLC中的另一项任务的负担，因为他们已经在为以需求的速度创建软件而旋转了很多盘子。
然而，我担心的是，在一般的组织中，安全责任对开发者来说可能是一个真正的灰色地带。谁对安全负责？归根结底，是安全团队，但如果我们希望开发人员提供帮助，就需要把他们带入这个旅程。任务和期望需要被明确定义，他们需要时间来承担这些额外的成功措施。
从开放源码软件到软件世界的其他部分
开源软件安全动员计划是雄心勃勃的，大胆的，也正是推动开发者对安全负责所需要的。这需要一些强大的参与者组成一个 "反叛联盟"，但这证明我们正朝着正确的方向前进，并抛开网络安全技能差距会神奇地自行解决的想法。
这是我们的新希望，需要我们所有人来推动这个结构超越开放源码。然而，安全专家必须审视自己的内心，并分析从事他们负责保护的代码的开发团队。他们必须对自己目前的能力、差距所在进行诚实的assessment ，并努力创造一个成熟的后期状态，这个状态是密不透风的、积极主动的，并包括一个将真正的安全技能传授给开发团队的计划。在它们被有意义地启用之前，我们在处理代码级漏洞的方法上可能仍然有点不成熟。
>> 用我们的实践、互动的XSS挑战来测试你的团队的安全成熟度!
皮特-丹休
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA认证。
在博客上深入了解我们最新的安全编码见解。
我们广泛的资源库旨在增强人类对安全编码技术提升的方法。
获取关于开发者驱动的安全的最新研究
我们广泛的资源库充满了有用的资源，从白皮书到网络研讨会，让你开始使用开发者驱动的安全编码。现在就去探索它。
对于开源软件安全动员计划，我们是否足够成熟？
在当前的经济环境和威胁形势下，我当然不会羡慕普通的CISO。他们的任务是提供安全、合规性、创新和商业价值，同时面临着预算缩减和审查增加的艰苦斗争。也许更紧迫的是，每个组织（及其各自的开发团队）都处于不同的安全成熟度阶段，并不是所有的组织都有能力在网络防御方面发挥其最佳作用。
过去几年，网络安全事件不断升级，使安全领导者很难保持领先一步。仅仅瞥了一眼关于我们日益增长的困境的一些数据驱动的见解，就可以看出一些火药桶的情况：仅在2023年就有超过330亿条记录被网络犯罪分子窃取，比2018年增加了175%。据预测，到2025年，网络犯罪的成本将达到10.5万亿美元，数据泄露的平均成本已经飙升至424万美元（尽管我们只需要看看像Equifax或Solar Winds这样的事件，就会发现情况可能更糟）。
作为一个行业，我们已经花了很长时间等待一个英雄出现，把我们从网络安全的坏人手中解救出来，这些坏人的力量似乎比我们想象的要大，甚至在十年前也是如此。我们在等待更多的网络安全专业人士加入进来，将我们提升到更高的安全项目标准，但这是我们无法弥补的差距。我们在等待银弹式的工具解决方案，承诺将我们从日益增长的风险中自动化，但它并不存在，也不太可能存在。我们在等待我们的天行者卢克来帮助我们对抗黑暗面。
事实证明，帮助（和希望）正在到来，其形式是《开源软件安全动员计划》。然而，我们都必须总结并诚实地评估我们的组织是否足够成熟--以及我们的开发团队是否有正确的安全意识和技能水平--以实施最新和最伟大的防御策略，特别是当它们需要开发团队的支持和执行时。
什么是开源软件安全动员计划？
这个十点计划是由开源软件基金会（OpenSSF）和Linux基金会牵头，联合白宫官员、顶级CISO和来自37家私营技术公司的其他高级领导人共同发起的。在这种行动和资金的共同支持下，开源软件的安全标准将变得更加强大。
特别有趣的是，他们把重点放在开发人员层面的基线教育和认证，以及旨在简化内部软件材料清单（SBOM）活动的措施。这些都是出了名的难以实施，难以产生持久的影响，这可以部分归因于组织安全计划中的成长痛苦，以及开发团队中普遍缺乏安全成熟度，这不是他们自己的错。他们处在一个压力锅的环境中，面对越来越多不合理的最后期限，代码量的速度是最高的。在没有增加可用时间的情况下，以安全询问和SBOM维护的形式增加更多的任务，这是一个在开始之前就已经失败的秘诀，可悲的是，这比我们预期的还要普遍。
因此，让我们来看看引擎盖下的情况。
开发者的安全认证。我们还没有到那一步吗？
如果有一件事我们是肯定的，那就是具有安全技能的开发人员仍然是一种稀有商品。这是现实，原因有很多，即直到最近，当涉及到组织内的软件安全策略时，开发人员并不是等式的一部分。再加上开发人员没有什么理由优先考虑安全问题（他们的培训不充分或不存在，需要更长的时间，这不是他们KPI的一部分，他们最关心的是做他们最擅长的事情：构建功能），你的开发团队没有准备好在代码层面真正处理安全问题，也没有在现代化的、以DevSecOps为中心的软件开发生命周期（SDLC）中发挥作用。
如果我们看一下《开源软件安全动员计划》，十点计划的第一条就是解决开发人员的安全技能，"向所有人提供基线安全软件开发教育和认证"，这对建立开发团队的安全成熟度至关重要。他们强调了我们已经讨论了一段时间的问题，包括大多数软件工程courses ，安全编码是MIA的事实，在高等教育阶段。看到这一点是令人难以置信的，因为它得到了个人和部门的支持，可以改变行业现状，而且世界上99%的软件至少包含一些开源代码，这个开发领域是一个伟大的地方，可以开始关注开发人员的安全培训。
该计划引用了受人尊敬的资源，如OpenSSF安全软件基础知识 courses ，以及OWASP基金会的广泛、长期的资源。这些信息枢纽是非常宝贵的。为提高开发人员的技能，拟推出的这些材料涉及汇集公共和私营部门的广泛合作伙伴网络，以及与教育机构合作，使开源安全开发成为课程的关键特征。
至于他们将如何赢得全世界软件工程师的心--其中许多人已被强化为安全不是他们的工作或优先事项，该计划详细说明了奖励和认可战略，以维护开源库的开发人员和需要看到安全认证价值的在职工程师为目标。
我们从经验中知道，开发者对激励措施反应良好，显示进度和技能的分层徽章系统在学习环境中的效果与在Steam或Xbox等平台上的效果一样好。
然而，值得关注的是，我们没有解决其中一个核心问题，那就是在组织的安全计划中提供学习模块。在我职业生涯的大部分时间里，我都与开发人员密切合作，我知道他们对工具和培训是多么的怀疑，更不用说任何看起来可能会破坏工作的东西了，而工作是第一优先事项。开发人员的能力建设需要他们不断地参与到课程材料中去，而要想成功，就必须在他们的日常工作中找到意义。
如果我们考虑像软件保障成熟度模型（SAMM）这样的成熟度模型，"教育和指导 "是Governace层的一个核心组成部分，并且有一个关键的重点是开发者教育。该模型整体上是庞大的，在达到更高的成熟度水平方面有渐进的步骤。然而，初始阶段只建议对开发人员进行1-2天的正式培训，这几乎不足以触及安全意识的表面。即使如此，企业战略集团（ESG）最近的一份报告显示，只有不到一半的组织要求开发人员每年参加一次以上的正式安全培训。我们自己与Evans Data联合进行的研究显示，只有29%的开发者认为应该优先考虑编写无漏洞代码的积极做法。在如何提供和接受教育，以及它在实现安全成熟度方面的真正作用之间存在明显的脱节，特别是如果开发人员没有看到价值。
软件材料清单。这个计划是否打破了采用障碍？
该计划寻求解决的另一个领域是围绕软件材料清单（SBOM）的创建和维护经常存在的灾难，其中 "SBOM无处不在--改进SBOM工具和培训以推动采用 "的项目研究如何使开发人员及其组织更容易创建、更新和使用SBOM以推动更好的安全成果。
就目前而言，SBOM在大多数垂直行业中没有被广泛采用，这使得它们在减少安全风险方面的潜力难以实现。该计划有一个出色的策略，为SBOM的制定定义了关键标准，以及适合开发人员工作方式的易于创建的工具。仅仅这些就可以大大减少开发人员在SDLC中的另一项任务的负担，因为他们已经在为以需求的速度创建软件而旋转了很多盘子。
然而，我担心的是，在一般的组织中，安全责任对开发者来说可能是一个真正的灰色地带。谁对安全负责？归根结底，是安全团队，但如果我们希望开发人员提供帮助，就需要把他们带入这个旅程。任务和期望需要被明确定义，他们需要时间来承担这些额外的成功措施。
从开放源码软件到软件世界的其他部分
开源软件安全动员计划是雄心勃勃的，大胆的，也正是推动开发者对安全负责所需要的。这需要一些强大的参与者组成一个 "反叛联盟"，但这证明我们正朝着正确的方向前进，并抛开网络安全技能差距会神奇地自行解决的想法。
这是我们的新希望，需要我们所有人来推动这个结构超越开放源码。然而，安全专家必须审视自己的内心，并分析从事他们负责保护的代码的开发团队。他们必须对自己目前的能力、差距所在进行诚实的assessment ，并努力创造一个成熟的后期状态，这个状态是密不透风的、积极主动的，并包括一个将真正的安全技能传授给开发团队的计划。在它们被有意义地启用之前，我们在处理代码级漏洞的方法上可能仍然有点不成熟。
>> 用我们的实践、互动的XSS挑战来测试你的团队的安全成熟度!
