揭开政府供应链管道中网络漏洞的面纱
这篇文章的一个版本出现在 报道的版本出现在TechCrunch上。.它已被更新并在此转发。
仿佛我们在 "无法命名的一年 "中还没有经历足够的破坏，2021年对美国政府来说是以震耳欲聋的巨响开始的，其形式是有史以来最严重的数据泄露事件之一。SolarWinds事件是一次毁灭性的、复杂的民族国家攻击，使一些政府部门和大型组织陷入恐慌，争相保护他们的端点。几乎所有SolarWinds软件的终端用户都受到了影响，这一事件充分说明了软件供应链中的网络安全和防御是至关重要的。
显然，网络安全很重要，但在供应链的背景下，网络安全究竟意味着什么？
普通开发团队中的网络安全状况
每天都有大量的软件被生产出来，每年有数十亿行的代码，而且随着我们逐渐数字化的生活方式所产生的需求，这种情况还在不断增加。到2024年，全球开发者人口将膨胀到近2900万，而目前还没有正式的认证来评估和认证他们安全编码的能力。这并不是说每个开发者都会产生或重复使用不安全的代码，但无疑存在着一个持续的风险，即基本的安全弱点可能被引入到我们信任的数据的软件中。
开发人员的评估标准是他们能否以最快的速度创建功能和发送代码。在大多数组织中，安全并不是他们成功的基准，但随着越来越多的公司意识到他们在软件创建的最早阶段预防常见安全漏洞的潜力，这种看法开始改变。然而，意识到和实施是两码事，由于大多数三级开发courses ，省略了任何围绕安全编码实践的背景，往往要靠开发人员的工作场所来弥补不足之处。如果技能建设和知识共享不经常或不相关，那么它很可能是无效的。因此，由于缺乏技能发展而导致的漏洞重复出现的循环仍未打破。
自然，解决世界上的网络安全问题并不是普通软件开发者的责任；毕竟，企业雇用那些非常昂贵的安全专家是有原因的。然而，安全大师是供不应求的，而开发者肯定可以在减少压力方面发挥作用。
但是，在防止毁灭性的网络攻击方面，这让我们--以及为关键基础设施和敏感组织开发软件的供应商--何去何从？这至少需要改变软件采购的现状。
阻碍安全软件供应链的陷阱
不幸的是，当涉及到软件供应时，一个链条只有最薄弱的环节才是最强大的，这句老话同样适用。如果你的公司已经加强了安全的最佳实践，投资于开发人员的技能提升，并转向功能性的DevSecOps环境（即每个人都分担尽可能安全地制造软件的责任），这真的并不重要；如果你使用一个有安全问题的供应商的软件，你将把它们继承到你的生态系统中并承担后果。
当然，安全团队应该帮助评估第三方添加到技术栈的安全性，但可以根据业务需要做出决定，在解决方案中没有什么选择。在这一点上，这可能是一个信任的练习。供应商是否像你的公司一样关心安全问题？供应商能否真正评估只有你才能理解的风险，以及你需要保护的资产？
透明度是评估供应商软件添加的安全可行性的一个重要因素。他们是否直截了当地介绍自己的安全实践？他们应该为自己保持数据安全的方法感到自豪，这应该是一个首要任务。如果安全实践没有在任何地方公布，或者没有任何信息，那么很有可能安全问题没有被放在首位。供应商应该能够回答技术问题，像ISO27001和SOC2这样的独立认证也无妨。此外，如果你不能 "查看引擎盖 "并扫描漏洞，作为你自己内部尽职调查和安全实践的一部分，那就别想了。
由于需求推动了软件需求的快速实施，特别是如果供应商的代码被折叠到现有的系统中，以在新的环境中执行操作，供应商和买方都需要在他们的游戏中处于领先地位，并且都应该让他们的开发人员作为地面上的靴子，在他们发货之前捡起常见的安全漏洞和缺陷。如果在现有的技术解决方案的蛛网中加入一个新的附件，可能会有成百上千的依赖关系被破坏，而一个小的故障可能会导致灾难性的失败。
那么，解决方案是什么呢？在公司内部从头开始编写所有的代码？如果是在1998年，这可能是有意义的。然而，正如我们不再 "询问Jeeves "最近的洗车店在哪里一样，我们需要实施现实的保障措施，在今天的环境中发挥作用。
仍然没有银弹，但有解决方案
对于买家来说，供应商软件和开发实践的安全assessment ，应该是整个安全计划和风险缓解计划的重点。围绕他们的认证、实践和开发人员的安全声誉提出问题。
供应商（实际上是任何创建软件的公司），必须准备好证明安全是最重要的，并且应该把重点放在提高技能上。具有安全技能的开发人员需求量很大，如果有合适的工具和支持，他们可以从你的现有团队中建立起来，并有能力抵御由常见漏洞引起的攻击。但是，不要把任何旧的培训扔给他们。给他们时间，让他们在安全工具的帮助下茁壮成长，这些工具是对他们现有工作流程的补充。尽可能让它变得简单，然后看着那些讨厌的错误开始在为业务提供动力的代码中变得越来越少。
底线是，任何软件风险如果是供应链的一部分，就会立即加剧，影响到所有用户和任何利用了脆弱组件的系统。如果供应商没有像实施其软件的公司那样认真对待安全问题--或者供应商和组织都缺乏安全计划--那么像SolarWinds这样更具破坏性、影响深远的供应链攻击将不可避免地成为常态--而这对所有人来说都是一个关键问题。
首席执行官、主席和联合创始人
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示
首席执行官、主席和联合创始人
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA认证。
这篇文章的一个版本出现在 报道的版本出现在TechCrunch上。.它已被更新并在此转发。
仿佛我们在 "无法命名的一年 "中还没有经历足够的破坏，2021年对美国政府来说是以震耳欲聋的巨响开始的，其形式是有史以来最严重的数据泄露事件之一。SolarWinds事件是一次毁灭性的、复杂的民族国家攻击，使一些政府部门和大型组织陷入恐慌，争相保护他们的端点。几乎所有SolarWinds软件的终端用户都受到了影响，这一事件充分说明了软件供应链中的网络安全和防御是至关重要的。
显然，网络安全很重要，但在供应链的背景下，网络安全究竟意味着什么？
普通开发团队中的网络安全状况
每天都有大量的软件被生产出来，每年有数十亿行的代码，而且随着我们逐渐数字化的生活方式所产生的需求，这种情况还在不断增加。到2024年，全球开发者人口将膨胀到近2900万，而目前还没有正式的认证来评估和认证他们安全编码的能力。这并不是说每个开发者都会产生或重复使用不安全的代码，但无疑存在着一个持续的风险，即基本的安全弱点可能被引入到我们信任的数据的软件中。
开发人员的评估标准是他们能否以最快的速度创建功能和发送代码。在大多数组织中，安全并不是他们成功的基准，但随着越来越多的公司意识到他们在软件创建的最早阶段预防常见安全漏洞的潜力，这种看法开始改变。然而，意识到和实施是两码事，由于大多数三级开发courses ，省略了任何围绕安全编码实践的背景，往往要靠开发人员的工作场所来弥补不足之处。如果技能建设和知识共享不经常或不相关，那么它很可能是无效的。因此，由于缺乏技能发展而导致的漏洞重复出现的循环仍未打破。
自然，解决世界上的网络安全问题并不是普通软件开发者的责任；毕竟，企业雇用那些非常昂贵的安全专家是有原因的。然而，安全大师是供不应求的，而开发者肯定可以在减少压力方面发挥作用。
但是，在防止毁灭性的网络攻击方面，这让我们--以及为关键基础设施和敏感组织开发软件的供应商--何去何从？这至少需要改变软件采购的现状。
阻碍安全软件供应链的陷阱
不幸的是，当涉及到软件供应时，一个链条只有最薄弱的环节才是最强大的，这句老话同样适用。如果你的公司已经加强了安全的最佳实践，投资于开发人员的技能提升，并转向功能性的DevSecOps环境（即每个人都分担尽可能安全地制造软件的责任），这真的并不重要；如果你使用一个有安全问题的供应商的软件，你将把它们继承到你的生态系统中并承担后果。
当然，安全团队应该帮助评估第三方添加到技术栈的安全性，但可以根据业务需要做出决定，在解决方案中没有什么选择。在这一点上，这可能是一个信任的练习。供应商是否像你的公司一样关心安全问题？供应商能否真正评估只有你才能理解的风险，以及你需要保护的资产？
透明度是评估供应商软件添加的安全可行性的一个重要因素。他们是否直截了当地介绍自己的安全实践？他们应该为自己保持数据安全的方法感到自豪，这应该是一个首要任务。如果安全实践没有在任何地方公布，或者没有任何信息，那么很有可能安全问题没有被放在首位。供应商应该能够回答技术问题，像ISO27001和SOC2这样的独立认证也无妨。此外，如果你不能 "查看引擎盖 "并扫描漏洞，作为你自己内部尽职调查和安全实践的一部分，那就别想了。
由于需求推动了软件需求的快速实施，特别是如果供应商的代码被折叠到现有的系统中，以在新的环境中执行操作，供应商和买方都需要在他们的游戏中处于领先地位，并且都应该让他们的开发人员作为地面上的靴子，在他们发货之前捡起常见的安全漏洞和缺陷。如果在现有的技术解决方案的蛛网中加入一个新的附件，可能会有成百上千的依赖关系被破坏，而一个小的故障可能会导致灾难性的失败。
那么，解决方案是什么呢？在公司内部从头开始编写所有的代码？如果是在1998年，这可能是有意义的。然而，正如我们不再 "询问Jeeves "最近的洗车店在哪里一样，我们需要实施现实的保障措施，在今天的环境中发挥作用。
仍然没有银弹，但有解决方案
对于买家来说，供应商软件和开发实践的安全assessment ，应该是整个安全计划和风险缓解计划的重点。围绕他们的认证、实践和开发人员的安全声誉提出问题。
供应商（实际上是任何创建软件的公司），必须准备好证明安全是最重要的，并且应该把重点放在提高技能上。具有安全技能的开发人员需求量很大，如果有合适的工具和支持，他们可以从你的现有团队中建立起来，并有能力抵御由常见漏洞引起的攻击。但是，不要把任何旧的培训扔给他们。给他们时间，让他们在安全工具的帮助下茁壮成长，这些工具是对他们现有工作流程的补充。尽可能让它变得简单，然后看着那些讨厌的错误开始在为业务提供动力的代码中变得越来越少。
底线是，任何软件风险如果是供应链的一部分，就会立即加剧，影响到所有用户和任何利用了脆弱组件的系统。如果供应商没有像实施其软件的公司那样认真对待安全问题--或者供应商和组织都缺乏安全计划--那么像SolarWinds这样更具破坏性、影响深远的供应链攻击将不可避免地成为常态--而这对所有人来说都是一个关键问题。
这篇文章的一个版本出现在 报道的版本出现在TechCrunch上。.它已被更新并在此转发。
仿佛我们在 "无法命名的一年 "中还没有经历足够的破坏，2021年对美国政府来说是以震耳欲聋的巨响开始的，其形式是有史以来最严重的数据泄露事件之一。SolarWinds事件是一次毁灭性的、复杂的民族国家攻击，使一些政府部门和大型组织陷入恐慌，争相保护他们的端点。几乎所有SolarWinds软件的终端用户都受到了影响，这一事件充分说明了软件供应链中的网络安全和防御是至关重要的。
显然，网络安全很重要，但在供应链的背景下，网络安全究竟意味着什么？
普通开发团队中的网络安全状况
每天都有大量的软件被生产出来，每年有数十亿行的代码，而且随着我们逐渐数字化的生活方式所产生的需求，这种情况还在不断增加。到2024年，全球开发者人口将膨胀到近2900万，而目前还没有正式的认证来评估和认证他们安全编码的能力。这并不是说每个开发者都会产生或重复使用不安全的代码，但无疑存在着一个持续的风险，即基本的安全弱点可能被引入到我们信任的数据的软件中。
开发人员的评估标准是他们能否以最快的速度创建功能和发送代码。在大多数组织中，安全并不是他们成功的基准，但随着越来越多的公司意识到他们在软件创建的最早阶段预防常见安全漏洞的潜力，这种看法开始改变。然而，意识到和实施是两码事，由于大多数三级开发courses ，省略了任何围绕安全编码实践的背景，往往要靠开发人员的工作场所来弥补不足之处。如果技能建设和知识共享不经常或不相关，那么它很可能是无效的。因此，由于缺乏技能发展而导致的漏洞重复出现的循环仍未打破。
自然，解决世界上的网络安全问题并不是普通软件开发者的责任；毕竟，企业雇用那些非常昂贵的安全专家是有原因的。然而，安全大师是供不应求的，而开发者肯定可以在减少压力方面发挥作用。
但是，在防止毁灭性的网络攻击方面，这让我们--以及为关键基础设施和敏感组织开发软件的供应商--何去何从？这至少需要改变软件采购的现状。
阻碍安全软件供应链的陷阱
不幸的是，当涉及到软件供应时，一个链条只有最薄弱的环节才是最强大的，这句老话同样适用。如果你的公司已经加强了安全的最佳实践，投资于开发人员的技能提升，并转向功能性的DevSecOps环境（即每个人都分担尽可能安全地制造软件的责任），这真的并不重要；如果你使用一个有安全问题的供应商的软件，你将把它们继承到你的生态系统中并承担后果。
当然，安全团队应该帮助评估第三方添加到技术栈的安全性，但可以根据业务需要做出决定，在解决方案中没有什么选择。在这一点上，这可能是一个信任的练习。供应商是否像你的公司一样关心安全问题？供应商能否真正评估只有你才能理解的风险，以及你需要保护的资产？
透明度是评估供应商软件添加的安全可行性的一个重要因素。他们是否直截了当地介绍自己的安全实践？他们应该为自己保持数据安全的方法感到自豪，这应该是一个首要任务。如果安全实践没有在任何地方公布，或者没有任何信息，那么很有可能安全问题没有被放在首位。供应商应该能够回答技术问题，像ISO27001和SOC2这样的独立认证也无妨。此外，如果你不能 "查看引擎盖 "并扫描漏洞，作为你自己内部尽职调查和安全实践的一部分，那就别想了。
由于需求推动了软件需求的快速实施，特别是如果供应商的代码被折叠到现有的系统中，以在新的环境中执行操作，供应商和买方都需要在他们的游戏中处于领先地位，并且都应该让他们的开发人员作为地面上的靴子，在他们发货之前捡起常见的安全漏洞和缺陷。如果在现有的技术解决方案的蛛网中加入一个新的附件，可能会有成百上千的依赖关系被破坏，而一个小的故障可能会导致灾难性的失败。
那么，解决方案是什么呢？在公司内部从头开始编写所有的代码？如果是在1998年，这可能是有意义的。然而，正如我们不再 "询问Jeeves "最近的洗车店在哪里一样，我们需要实施现实的保障措施，在今天的环境中发挥作用。
仍然没有银弹，但有解决方案
对于买家来说，供应商软件和开发实践的安全assessment ，应该是整个安全计划和风险缓解计划的重点。围绕他们的认证、实践和开发人员的安全声誉提出问题。
供应商（实际上是任何创建软件的公司），必须准备好证明安全是最重要的，并且应该把重点放在提高技能上。具有安全技能的开发人员需求量很大，如果有合适的工具和支持，他们可以从你的现有团队中建立起来，并有能力抵御由常见漏洞引起的攻击。但是，不要把任何旧的培训扔给他们。给他们时间，让他们在安全工具的帮助下茁壮成长，这些工具是对他们现有工作流程的补充。尽可能让它变得简单，然后看着那些讨厌的错误开始在为业务提供动力的代码中变得越来越少。
底线是，任何软件风险如果是供应链的一部分，就会立即加剧，影响到所有用户和任何利用了脆弱组件的系统。如果供应商没有像实施其软件的公司那样认真对待安全问题--或者供应商和组织都缺乏安全计划--那么像SolarWinds这样更具破坏性、影响深远的供应链攻击将不可避免地成为常态--而这对所有人来说都是一个关键问题。
点击下面的链接，下载本资料的 PDF 文件。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
查看报告预定一个演示
首席执行官、主席和联合创始人
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA认证。
这篇文章的一个版本出现在 报道的版本出现在TechCrunch上。.它已被更新并在此转发。
仿佛我们在 "无法命名的一年 "中还没有经历足够的破坏，2021年对美国政府来说是以震耳欲聋的巨响开始的，其形式是有史以来最严重的数据泄露事件之一。SolarWinds事件是一次毁灭性的、复杂的民族国家攻击，使一些政府部门和大型组织陷入恐慌，争相保护他们的端点。几乎所有SolarWinds软件的终端用户都受到了影响，这一事件充分说明了软件供应链中的网络安全和防御是至关重要的。
显然，网络安全很重要，但在供应链的背景下，网络安全究竟意味着什么？
普通开发团队中的网络安全状况
每天都有大量的软件被生产出来，每年有数十亿行的代码，而且随着我们逐渐数字化的生活方式所产生的需求，这种情况还在不断增加。到2024年，全球开发者人口将膨胀到近2900万，而目前还没有正式的认证来评估和认证他们安全编码的能力。这并不是说每个开发者都会产生或重复使用不安全的代码，但无疑存在着一个持续的风险，即基本的安全弱点可能被引入到我们信任的数据的软件中。
开发人员的评估标准是他们能否以最快的速度创建功能和发送代码。在大多数组织中，安全并不是他们成功的基准，但随着越来越多的公司意识到他们在软件创建的最早阶段预防常见安全漏洞的潜力，这种看法开始改变。然而，意识到和实施是两码事，由于大多数三级开发courses ，省略了任何围绕安全编码实践的背景，往往要靠开发人员的工作场所来弥补不足之处。如果技能建设和知识共享不经常或不相关，那么它很可能是无效的。因此，由于缺乏技能发展而导致的漏洞重复出现的循环仍未打破。
自然，解决世界上的网络安全问题并不是普通软件开发者的责任；毕竟，企业雇用那些非常昂贵的安全专家是有原因的。然而，安全大师是供不应求的，而开发者肯定可以在减少压力方面发挥作用。
但是，在防止毁灭性的网络攻击方面，这让我们--以及为关键基础设施和敏感组织开发软件的供应商--何去何从？这至少需要改变软件采购的现状。
阻碍安全软件供应链的陷阱
不幸的是，当涉及到软件供应时，一个链条只有最薄弱的环节才是最强大的，这句老话同样适用。如果你的公司已经加强了安全的最佳实践，投资于开发人员的技能提升，并转向功能性的DevSecOps环境（即每个人都分担尽可能安全地制造软件的责任），这真的并不重要；如果你使用一个有安全问题的供应商的软件，你将把它们继承到你的生态系统中并承担后果。
当然，安全团队应该帮助评估第三方添加到技术栈的安全性，但可以根据业务需要做出决定，在解决方案中没有什么选择。在这一点上，这可能是一个信任的练习。供应商是否像你的公司一样关心安全问题？供应商能否真正评估只有你才能理解的风险，以及你需要保护的资产？
透明度是评估供应商软件添加的安全可行性的一个重要因素。他们是否直截了当地介绍自己的安全实践？他们应该为自己保持数据安全的方法感到自豪，这应该是一个首要任务。如果安全实践没有在任何地方公布，或者没有任何信息，那么很有可能安全问题没有被放在首位。供应商应该能够回答技术问题，像ISO27001和SOC2这样的独立认证也无妨。此外，如果你不能 "查看引擎盖 "并扫描漏洞，作为你自己内部尽职调查和安全实践的一部分，那就别想了。
由于需求推动了软件需求的快速实施，特别是如果供应商的代码被折叠到现有的系统中，以在新的环境中执行操作，供应商和买方都需要在他们的游戏中处于领先地位，并且都应该让他们的开发人员作为地面上的靴子，在他们发货之前捡起常见的安全漏洞和缺陷。如果在现有的技术解决方案的蛛网中加入一个新的附件，可能会有成百上千的依赖关系被破坏，而一个小的故障可能会导致灾难性的失败。
那么，解决方案是什么呢？在公司内部从头开始编写所有的代码？如果是在1998年，这可能是有意义的。然而，正如我们不再 "询问Jeeves "最近的洗车店在哪里一样，我们需要实施现实的保障措施，在今天的环境中发挥作用。
仍然没有银弹，但有解决方案
对于买家来说，供应商软件和开发实践的安全assessment ，应该是整个安全计划和风险缓解计划的重点。围绕他们的认证、实践和开发人员的安全声誉提出问题。
供应商（实际上是任何创建软件的公司），必须准备好证明安全是最重要的，并且应该把重点放在提高技能上。具有安全技能的开发人员需求量很大，如果有合适的工具和支持，他们可以从你的现有团队中建立起来，并有能力抵御由常见漏洞引起的攻击。但是，不要把任何旧的培训扔给他们。给他们时间，让他们在安全工具的帮助下茁壮成长，这些工具是对他们现有工作流程的补充。尽可能让它变得简单，然后看着那些讨厌的错误开始在为业务提供动力的代码中变得越来越少。
底线是，任何软件风险如果是供应链的一部分，就会立即加剧，影响到所有用户和任何利用了脆弱组件的系统。如果供应商没有像实施其软件的公司那样认真对待安全问题--或者供应商和组织都缺乏安全计划--那么像SolarWinds这样更具破坏性、影响深远的供应链攻击将不可避免地成为常态--而这对所有人来说都是一个关键问题。
.png)
