开发人员如何定义 “安全编码”？
这篇文章的一个版本出现在 科技共和国。它已在此处更新和发布。
要创造一个让安全团队与开发人员目标保持一致的环境，这是一场艰苦但必不可少的战斗。我们还有很长的路要走，但是阻碍为软件安全共同责任打开大门所需的协同作用所面临的障碍越来越明显。聪明的公司希望制定战略以避免这些陷阱，找到富有成效的前进方向，并充分利用DevSecOps发挥其以人为本的潜力。
我没想到的是，对什么构成安全编码行为的看法还有待商榷。根据与Evans Data合作的全新研究，这种情绪以黑白形式展现出来。这个 《2022年开发者驱动的安全现状》调查 深入研究 1200 名活跃开发者的关键见解和经验，阐明他们在安全领域的态度和挑战。
主要发现之一是 只有14％的开发人员在编码时将安全性视为优先事项。尽管这表明还有很大的改进余地，但它证实了我们已经知道的：功能构建是开发者世界中的王道，他们仍然没有能力将安全性作为其DNA的一部分。但是，如果再加上有关开发人员定义安全编码对他们意味着什么的数据，就会令人担忧。
这些看法是由开发人员在工作日中的经验驱动的，它反映了许多组织的环境，即开发人员根本不是应对常见漏洞的焦点。它们的支持至关重要，但与此同时，我们必须迅速就 “安全编码” 的范围以及我们对安全技能熟练的开发人员应有的期望达成共识。
我们需要揭开开发者世界中安全的神秘面纱。
网络安全是一个多方面的、笨手笨脚的野兽，虽然安全编码只是整体格局的一部分，但它是系统中的一个复杂齿轮，需要专家的关注。
调查显示，对于普通开发人员来说，使用安全代码的概念非常孤立，他们的范围通常仅限于一个类别，而不是对基本原理及其他方面的整体看法。开发人员表示依赖于使用现有（或预先批准的）代码，而不是编写没有漏洞的新代码的做法。而有关第三方组件（尤其是补丁）的安全意识以及 Log4Shell 的崩溃就是一个很好的例子： 自 12 月以来，30% 的实例仍未打补丁) 非常重要，测试现有代码也非常重要，光靠这些代码还不能满足安全编码能力的功能级别。
代码级漏洞是由学习了不良编码模式的开发人员引入的，不重视在 KPI 中编写安全代码（再加上乏善可陈的安全文化）只会强化其作为可接受的标准。
安全领导者首先要确保向开发团队展示安全编码的全部内容，从而在提高初始意识和确定最紧迫的知识差距方面大有帮助。测试和扫描预先批准的代码是一项功能，但是要减少漏洞，就需要使用正在使用的语言和框架进行有关良好、安全的编码模式的动手培训。
情境对于开发人员技能提升至关重要，在实现业务安全目标时，需要让他们踏上旅程。
许多组织需要升级其安全程序。
在过去十年中，软件驱动技术的爆炸式增长为网络安全事件的快速增长铺平了道路，我们都在争先恐后地跟上威胁行为者的步伐，以发现宝贵系统中的漏洞。
DevSecOps 方法建立在每个人共同承担安全责任的理念之上，包括开发人员，这是 SDLC 成立之初的主要考虑因素。问题在于，尤其是在大公司中，它们可能是 正是 远未将 DevSecOps 作为标准来实施。在2017年， 项目管理协会的一项研究 显示 51% 的组织仍在使用 Waterfall 进行软件开发。这项研究现已进行了五年，但知道大型企业的变化是多么缓慢，因此不太可能急剧过渡到最新的安全导向方法。这些传统流程可能会给安全专业人员带来一场艰苦的战斗，他们试图通过全面的战略覆盖所有基础以防范网络威胁，而在这种环境中改造开发人员及其需求是一项挑战。
但是，我们不能以此为借口。业务中的安全专业人员可以利用开发人员制定更高的策略；他们只需要熟悉自己的需求，并将其视为防御策略的一部分即可。他们需要全面的培训，任何安全责任都需要根据他们的技术堆栈和工作流程来履行。
安全编码 = “太难了” 的篮子？
Evans Data的研究表明，有惊人的86％的开发人员认为实践安全编码具有挑战性，92％的开发人员经理也承认他们的团队需要更多的安全框架培训。令人担忧的是，48％的受访者承认他们故意在代码中留下漏洞。
这描绘了一幅非常令人担忧的画面。总体而言，开发人员似乎没有得到频繁和充分的培训，也没有足够的机会接触到良好的安全实践和卫生习惯。从字里行间看，它强化了问题的症结所在：开发人员在工作中考虑安全性根本不是优先事项。这以及他们接受的培训并不能建立他们的信心或实践技能，也无助于他们了解发布易受攻击代码的决定所产生的影响。
Colonial Pipeline勒索软件攻击是过去一年中最具破坏性的供应链安全事件之一，引发了人们对美国东海岸一半天然气供应将被无限期切断的担忧。值得庆幸的是，它们很快就恢复了运行状态，但社区中并非没有严重的担忧。那是关键时刻之一，公众面临着网络事件的可能性，该事件严重影响了物理世界中不一定被视为软件驱动的元素，也不一定是网络攻击的风险。而所有这些混乱都是由两个未修补的旧漏洞造成的，其中一个是阴险但广为人知的 SQL 注入。如果开发人员知道在选择发布易受攻击的代码时真正危在旦夕，他们很快就会发现这种情况是不可接受的业务风险。
功能 “P-P-T” 不由开发人员决定。
如果没有经过深思熟虑的策略，就无法实现著名的 “人员、流程和工具” “金三角”，如果不考虑他们的需求和挑战，开发人员就无法融入有效的安全流程。
要提升开发人员驱动的安全性，需要进行大规模的文化转变，首先是教育途径，使工程师和安全团队都变得更加清晰。
对什么构成安全编码行为的看法尚有待商榷。根据与Evans Data合作的最新研究，这种情绪以黑白形式展现出来。2022年开发者驱动的安全状况调查深入研究了1200名活跃开发者的关键见解和经验，阐明了他们在安全领域的态度和挑战。
首席执行官、主席和联合创始人
Secure Code Warrior可帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全置于首位的文化。无论您是应用安全经理、开发人员、首席信息安全官还是任何与安全相关的人员，我们都能帮助您的组织降低与不安全代码相关的风险。
预约演示
首席执行官、主席和联合创始人
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA认证。
这篇文章的一个版本出现在 科技共和国。它已在此处更新和发布。
要创造一个让安全团队与开发人员目标保持一致的环境，这是一场艰苦但必不可少的战斗。我们还有很长的路要走，但是阻碍为软件安全共同责任打开大门所需的协同作用所面临的障碍越来越明显。聪明的公司希望制定战略以避免这些陷阱，找到富有成效的前进方向，并充分利用DevSecOps发挥其以人为本的潜力。
我没想到的是，对什么构成安全编码行为的看法还有待商榷。根据与Evans Data合作的全新研究，这种情绪以黑白形式展现出来。这个 《2022年开发者驱动的安全现状》调查 深入研究 1200 名活跃开发者的关键见解和经验，阐明他们在安全领域的态度和挑战。
主要发现之一是 只有14％的开发人员在编码时将安全性视为优先事项。尽管这表明还有很大的改进余地，但它证实了我们已经知道的：功能构建是开发者世界中的王道，他们仍然没有能力将安全性作为其DNA的一部分。但是，如果再加上有关开发人员定义安全编码对他们意味着什么的数据，就会令人担忧。
这些看法是由开发人员在工作日中的经验驱动的，它反映了许多组织的环境，即开发人员根本不是应对常见漏洞的焦点。它们的支持至关重要，但与此同时，我们必须迅速就 “安全编码” 的范围以及我们对安全技能熟练的开发人员应有的期望达成共识。
我们需要揭开开发者世界中安全的神秘面纱。
网络安全是一个多方面的、笨手笨脚的野兽，虽然安全编码只是整体格局的一部分，但它是系统中的一个复杂齿轮，需要专家的关注。
调查显示，对于普通开发人员来说，使用安全代码的概念非常孤立，他们的范围通常仅限于一个类别，而不是对基本原理及其他方面的整体看法。开发人员表示依赖于使用现有（或预先批准的）代码，而不是编写没有漏洞的新代码的做法。而有关第三方组件（尤其是补丁）的安全意识以及 Log4Shell 的崩溃就是一个很好的例子： 自 12 月以来，30% 的实例仍未打补丁) 非常重要，测试现有代码也非常重要，光靠这些代码还不能满足安全编码能力的功能级别。
代码级漏洞是由学习了不良编码模式的开发人员引入的，不重视在 KPI 中编写安全代码（再加上乏善可陈的安全文化）只会强化其作为可接受的标准。
安全领导者首先要确保向开发团队展示安全编码的全部内容，从而在提高初始意识和确定最紧迫的知识差距方面大有帮助。测试和扫描预先批准的代码是一项功能，但是要减少漏洞，就需要使用正在使用的语言和框架进行有关良好、安全的编码模式的动手培训。
情境对于开发人员技能提升至关重要，在实现业务安全目标时，需要让他们踏上旅程。
许多组织需要升级其安全程序。
在过去十年中，软件驱动技术的爆炸式增长为网络安全事件的快速增长铺平了道路，我们都在争先恐后地跟上威胁行为者的步伐，以发现宝贵系统中的漏洞。
DevSecOps 方法建立在每个人共同承担安全责任的理念之上，包括开发人员，这是 SDLC 成立之初的主要考虑因素。问题在于，尤其是在大公司中，它们可能是 正是 远未将 DevSecOps 作为标准来实施。在2017年， 项目管理协会的一项研究 显示 51% 的组织仍在使用 Waterfall 进行软件开发。这项研究现已进行了五年，但知道大型企业的变化是多么缓慢，因此不太可能急剧过渡到最新的安全导向方法。这些传统流程可能会给安全专业人员带来一场艰苦的战斗，他们试图通过全面的战略覆盖所有基础以防范网络威胁，而在这种环境中改造开发人员及其需求是一项挑战。
但是，我们不能以此为借口。业务中的安全专业人员可以利用开发人员制定更高的策略；他们只需要熟悉自己的需求，并将其视为防御策略的一部分即可。他们需要全面的培训，任何安全责任都需要根据他们的技术堆栈和工作流程来履行。
安全编码 = “太难了” 的篮子？
Evans Data的研究表明，有惊人的86％的开发人员认为实践安全编码具有挑战性，92％的开发人员经理也承认他们的团队需要更多的安全框架培训。令人担忧的是，48％的受访者承认他们故意在代码中留下漏洞。
这描绘了一幅非常令人担忧的画面。总体而言，开发人员似乎没有得到频繁和充分的培训，也没有足够的机会接触到良好的安全实践和卫生习惯。从字里行间看，它强化了问题的症结所在：开发人员在工作中考虑安全性根本不是优先事项。这以及他们接受的培训并不能建立他们的信心或实践技能，也无助于他们了解发布易受攻击代码的决定所产生的影响。
Colonial Pipeline勒索软件攻击是过去一年中最具破坏性的供应链安全事件之一，引发了人们对美国东海岸一半天然气供应将被无限期切断的担忧。值得庆幸的是，它们很快就恢复了运行状态，但社区中并非没有严重的担忧。那是关键时刻之一，公众面临着网络事件的可能性，该事件严重影响了物理世界中不一定被视为软件驱动的元素，也不一定是网络攻击的风险。而所有这些混乱都是由两个未修补的旧漏洞造成的，其中一个是阴险但广为人知的 SQL 注入。如果开发人员知道在选择发布易受攻击的代码时真正危在旦夕，他们很快就会发现这种情况是不可接受的业务风险。
功能 “P-P-T” 不由开发人员决定。
如果没有经过深思熟虑的策略，就无法实现著名的 “人员、流程和工具” “金三角”，如果不考虑他们的需求和挑战，开发人员就无法融入有效的安全流程。
要提升开发人员驱动的安全性，需要进行大规模的文化转变，首先是教育途径，使工程师和安全团队都变得更加清晰。
这篇文章的一个版本出现在 科技共和国。它已在此处更新和发布。
要创造一个让安全团队与开发人员目标保持一致的环境，这是一场艰苦但必不可少的战斗。我们还有很长的路要走，但是阻碍为软件安全共同责任打开大门所需的协同作用所面临的障碍越来越明显。聪明的公司希望制定战略以避免这些陷阱，找到富有成效的前进方向，并充分利用DevSecOps发挥其以人为本的潜力。
我没想到的是，对什么构成安全编码行为的看法还有待商榷。根据与Evans Data合作的全新研究，这种情绪以黑白形式展现出来。这个 《2022年开发者驱动的安全现状》调查 深入研究 1200 名活跃开发者的关键见解和经验，阐明他们在安全领域的态度和挑战。
主要发现之一是 只有14％的开发人员在编码时将安全性视为优先事项。尽管这表明还有很大的改进余地，但它证实了我们已经知道的：功能构建是开发者世界中的王道，他们仍然没有能力将安全性作为其DNA的一部分。但是，如果再加上有关开发人员定义安全编码对他们意味着什么的数据，就会令人担忧。
这些看法是由开发人员在工作日中的经验驱动的，它反映了许多组织的环境，即开发人员根本不是应对常见漏洞的焦点。它们的支持至关重要，但与此同时，我们必须迅速就 “安全编码” 的范围以及我们对安全技能熟练的开发人员应有的期望达成共识。
我们需要揭开开发者世界中安全的神秘面纱。
网络安全是一个多方面的、笨手笨脚的野兽，虽然安全编码只是整体格局的一部分，但它是系统中的一个复杂齿轮，需要专家的关注。
调查显示，对于普通开发人员来说，使用安全代码的概念非常孤立，他们的范围通常仅限于一个类别，而不是对基本原理及其他方面的整体看法。开发人员表示依赖于使用现有（或预先批准的）代码，而不是编写没有漏洞的新代码的做法。而有关第三方组件（尤其是补丁）的安全意识以及 Log4Shell 的崩溃就是一个很好的例子： 自 12 月以来，30% 的实例仍未打补丁) 非常重要，测试现有代码也非常重要，光靠这些代码还不能满足安全编码能力的功能级别。
代码级漏洞是由学习了不良编码模式的开发人员引入的，不重视在 KPI 中编写安全代码（再加上乏善可陈的安全文化）只会强化其作为可接受的标准。
安全领导者首先要确保向开发团队展示安全编码的全部内容，从而在提高初始意识和确定最紧迫的知识差距方面大有帮助。测试和扫描预先批准的代码是一项功能，但是要减少漏洞，就需要使用正在使用的语言和框架进行有关良好、安全的编码模式的动手培训。
情境对于开发人员技能提升至关重要，在实现业务安全目标时，需要让他们踏上旅程。
许多组织需要升级其安全程序。
在过去十年中，软件驱动技术的爆炸式增长为网络安全事件的快速增长铺平了道路，我们都在争先恐后地跟上威胁行为者的步伐，以发现宝贵系统中的漏洞。
DevSecOps 方法建立在每个人共同承担安全责任的理念之上，包括开发人员，这是 SDLC 成立之初的主要考虑因素。问题在于，尤其是在大公司中，它们可能是 正是 远未将 DevSecOps 作为标准来实施。在2017年， 项目管理协会的一项研究 显示 51% 的组织仍在使用 Waterfall 进行软件开发。这项研究现已进行了五年，但知道大型企业的变化是多么缓慢，因此不太可能急剧过渡到最新的安全导向方法。这些传统流程可能会给安全专业人员带来一场艰苦的战斗，他们试图通过全面的战略覆盖所有基础以防范网络威胁，而在这种环境中改造开发人员及其需求是一项挑战。
但是，我们不能以此为借口。业务中的安全专业人员可以利用开发人员制定更高的策略；他们只需要熟悉自己的需求，并将其视为防御策略的一部分即可。他们需要全面的培训，任何安全责任都需要根据他们的技术堆栈和工作流程来履行。
安全编码 = “太难了” 的篮子？
Evans Data的研究表明，有惊人的86％的开发人员认为实践安全编码具有挑战性，92％的开发人员经理也承认他们的团队需要更多的安全框架培训。令人担忧的是，48％的受访者承认他们故意在代码中留下漏洞。
这描绘了一幅非常令人担忧的画面。总体而言，开发人员似乎没有得到频繁和充分的培训，也没有足够的机会接触到良好的安全实践和卫生习惯。从字里行间看，它强化了问题的症结所在：开发人员在工作中考虑安全性根本不是优先事项。这以及他们接受的培训并不能建立他们的信心或实践技能，也无助于他们了解发布易受攻击代码的决定所产生的影响。
Colonial Pipeline勒索软件攻击是过去一年中最具破坏性的供应链安全事件之一，引发了人们对美国东海岸一半天然气供应将被无限期切断的担忧。值得庆幸的是，它们很快就恢复了运行状态，但社区中并非没有严重的担忧。那是关键时刻之一，公众面临着网络事件的可能性，该事件严重影响了物理世界中不一定被视为软件驱动的元素，也不一定是网络攻击的风险。而所有这些混乱都是由两个未修补的旧漏洞造成的，其中一个是阴险但广为人知的 SQL 注入。如果开发人员知道在选择发布易受攻击的代码时真正危在旦夕，他们很快就会发现这种情况是不可接受的业务风险。
功能 “P-P-T” 不由开发人员决定。
如果没有经过深思熟虑的策略，就无法实现著名的 “人员、流程和工具” “金三角”，如果不考虑他们的需求和挑战，开发人员就无法融入有效的安全流程。
要提升开发人员驱动的安全性，需要进行大规模的文化转变，首先是教育途径，使工程师和安全团队都变得更加清晰。
点击下面的链接并下载此资源的PDF。
Secure Code Warrior可帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全置于首位的文化。无论您是应用安全经理、开发人员、首席信息安全官还是任何与安全相关的人员，我们都能帮助您的组织降低与不安全代码相关的风险。
查看报告预约演示
首席执行官、主席和联合创始人
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA认证。
这篇文章的一个版本出现在 科技共和国。它已在此处更新和发布。
要创造一个让安全团队与开发人员目标保持一致的环境，这是一场艰苦但必不可少的战斗。我们还有很长的路要走，但是阻碍为软件安全共同责任打开大门所需的协同作用所面临的障碍越来越明显。聪明的公司希望制定战略以避免这些陷阱，找到富有成效的前进方向，并充分利用DevSecOps发挥其以人为本的潜力。
我没想到的是，对什么构成安全编码行为的看法还有待商榷。根据与Evans Data合作的全新研究，这种情绪以黑白形式展现出来。这个 《2022年开发者驱动的安全现状》调查 深入研究 1200 名活跃开发者的关键见解和经验，阐明他们在安全领域的态度和挑战。
主要发现之一是 只有14％的开发人员在编码时将安全性视为优先事项。尽管这表明还有很大的改进余地，但它证实了我们已经知道的：功能构建是开发者世界中的王道，他们仍然没有能力将安全性作为其DNA的一部分。但是，如果再加上有关开发人员定义安全编码对他们意味着什么的数据，就会令人担忧。
这些看法是由开发人员在工作日中的经验驱动的，它反映了许多组织的环境，即开发人员根本不是应对常见漏洞的焦点。它们的支持至关重要，但与此同时，我们必须迅速就 “安全编码” 的范围以及我们对安全技能熟练的开发人员应有的期望达成共识。
我们需要揭开开发者世界中安全的神秘面纱。
网络安全是一个多方面的、笨手笨脚的野兽，虽然安全编码只是整体格局的一部分，但它是系统中的一个复杂齿轮，需要专家的关注。
调查显示，对于普通开发人员来说，使用安全代码的概念非常孤立，他们的范围通常仅限于一个类别，而不是对基本原理及其他方面的整体看法。开发人员表示依赖于使用现有（或预先批准的）代码，而不是编写没有漏洞的新代码的做法。而有关第三方组件（尤其是补丁）的安全意识以及 Log4Shell 的崩溃就是一个很好的例子： 自 12 月以来，30% 的实例仍未打补丁) 非常重要，测试现有代码也非常重要，光靠这些代码还不能满足安全编码能力的功能级别。
代码级漏洞是由学习了不良编码模式的开发人员引入的，不重视在 KPI 中编写安全代码（再加上乏善可陈的安全文化）只会强化其作为可接受的标准。
安全领导者首先要确保向开发团队展示安全编码的全部内容，从而在提高初始意识和确定最紧迫的知识差距方面大有帮助。测试和扫描预先批准的代码是一项功能，但是要减少漏洞，就需要使用正在使用的语言和框架进行有关良好、安全的编码模式的动手培训。
情境对于开发人员技能提升至关重要，在实现业务安全目标时，需要让他们踏上旅程。
许多组织需要升级其安全程序。
在过去十年中，软件驱动技术的爆炸式增长为网络安全事件的快速增长铺平了道路，我们都在争先恐后地跟上威胁行为者的步伐，以发现宝贵系统中的漏洞。
DevSecOps 方法建立在每个人共同承担安全责任的理念之上，包括开发人员，这是 SDLC 成立之初的主要考虑因素。问题在于，尤其是在大公司中，它们可能是 正是 远未将 DevSecOps 作为标准来实施。在2017年， 项目管理协会的一项研究 显示 51% 的组织仍在使用 Waterfall 进行软件开发。这项研究现已进行了五年，但知道大型企业的变化是多么缓慢，因此不太可能急剧过渡到最新的安全导向方法。这些传统流程可能会给安全专业人员带来一场艰苦的战斗，他们试图通过全面的战略覆盖所有基础以防范网络威胁，而在这种环境中改造开发人员及其需求是一项挑战。
但是，我们不能以此为借口。业务中的安全专业人员可以利用开发人员制定更高的策略；他们只需要熟悉自己的需求，并将其视为防御策略的一部分即可。他们需要全面的培训，任何安全责任都需要根据他们的技术堆栈和工作流程来履行。
安全编码 = “太难了” 的篮子？
Evans Data的研究表明，有惊人的86％的开发人员认为实践安全编码具有挑战性，92％的开发人员经理也承认他们的团队需要更多的安全框架培训。令人担忧的是，48％的受访者承认他们故意在代码中留下漏洞。
这描绘了一幅非常令人担忧的画面。总体而言，开发人员似乎没有得到频繁和充分的培训，也没有足够的机会接触到良好的安全实践和卫生习惯。从字里行间看，它强化了问题的症结所在：开发人员在工作中考虑安全性根本不是优先事项。这以及他们接受的培训并不能建立他们的信心或实践技能，也无助于他们了解发布易受攻击代码的决定所产生的影响。
Colonial Pipeline勒索软件攻击是过去一年中最具破坏性的供应链安全事件之一，引发了人们对美国东海岸一半天然气供应将被无限期切断的担忧。值得庆幸的是，它们很快就恢复了运行状态，但社区中并非没有严重的担忧。那是关键时刻之一，公众面临着网络事件的可能性，该事件严重影响了物理世界中不一定被视为软件驱动的元素，也不一定是网络攻击的风险。而所有这些混乱都是由两个未修补的旧漏洞造成的，其中一个是阴险但广为人知的 SQL 注入。如果开发人员知道在选择发布易受攻击的代码时真正危在旦夕，他们很快就会发现这种情况是不可接受的业务风险。
功能 “P-P-T” 不由开发人员决定。
如果没有经过深思熟虑的策略，就无法实现著名的 “人员、流程和工具” “金三角”，如果不考虑他们的需求和挑战，开发人员就无法融入有效的安全流程。
要提升开发人员驱动的安全性，需要进行大规模的文化转变，首先是教育途径，使工程师和安全团队都变得更加清晰。
%20(1).avif)
.avif)
