从 "左边的左边 "开始。安全的代码总是高质量的代码吗？
这篇文章的一个版本出现在 黑暗阅读.它已被更新并在此转发。
当与开发人员谈论安全问题时，我的一个口号是："唯一优质的代码是安全的代码"。这仍然是事实；当90年代有漏洞的软件在野外出现时，我们可能躲过了灾难，但今天不值得冒险。多年来，许多人努力向开发人员灌输安全意识的心态，在这样做的过程中，希望在涉及到他们的代码的自我assessment ，使安全成为质量的同义词。
经过思考（以及我的同行之间的一些辩论），然而，这也许是过度简化了这个概念。我们完全有可能创造出确实安全的代码，但却显示出新手开发技术的迹象，或其他使其不太理想的问题领域。
我们的行业详细地讨论了 "向左转移 "的概念。在我看来，这都是关于 "开始 "向左移动，使工程组群能够分担安全责任（作为质量的一个方面），并给予他们权力来消除他们（字面上）指尖上的常见漏洞。不过，鉴于目前的这个难题，似乎必须把信封推得更远一点。
具有一定质量水平的代码根据其定义也是安全的，但所有安全的代码不一定是好的质量。从 "左边的左边 "开始，是确保纯安全编码标准的公式吗？
质量差 "的安全代码是什么样子的？
让我们把放大镜放在这个代码片段上。
如果我们从安全的角度来分析这段代码，这段代码确实是安全的，而不是攻击者利用SQL注入漏洞的入口。
这是一个高质量代码的例子吗？很不幸，不是。简单地将参数从int(eger)改为String值，就可以让用户自由输入来操作查询，而数字则不能。这种改变--或者从其他地方胡乱复制和粘贴String sql--立即创造了一个可能存在SQL注入漏洞的环境，以及与之相关的所有风险。
安全措施在这里的范围非常有限，而一个更彻底的（或者，有经验的）开发者可能会采取不同的方法，并考虑低效参数结构的影响。运送这样的代码不仅是糟糕的做法，而且为开发组中的其他人树立了一个坏榜样。
软件的 "三重威胁"。形式、功能、堡垒般的？
娱乐业中的 "三重威胁 "是指能够以同样高的技术水平表演、跳舞和唱歌的人。他们是每次试镜时令人恐惧和羡慕的人，是已经竞争激烈的领域中的独角兽。每个行业都有自己版本的顶级、特殊的产品和服务的例子，软件也不例外。
如果我们想一想应用程序中很难与同等（高）质量相平衡的三个关键因素，它们可能是功能/优雅，加上铁一般的安全，再加上考虑所需的交付速度时的成本效益。现在，最后一个属性无疑是其他两个选项应用得好坏的决定性因素，它可以成为整体质量随着时间推移而下滑的催化剂。
然而，是否所有的软件都需要像休-杰克曼那样表现，或者我们可以用尼古拉斯-凯奇来逃避？这样说吧：如果你能让金刚狼加入你的团队，那么你就给它最好的机会。
马丁-福勒（Martin Fowler）在软件开发中提出了 "高质量是否值得"的问题，他的结论是，不仅 "值得"，而且随着时间的推移，它实际上更便宜。大多数用户不会去看引擎盖下的代码是否一团糟，也不会去看安全是否和其他东西一样重要。然而，那些工具上的人将浪费宝贵的时间重做马虎的代码，以增加更新的功能，或遍历项目的主要部分，以了解发生了什么，或者，最糟糕的情况是：修复一个从AppSec团队反弹回来的漏洞，推迟生产。现在花时间使代码既安全又优质，可以节省很多未来的心痛，更不用说解开执行不力的工作的成本。
熟练的有安全意识的开发人员编写的代码，在功能交付中保留了他们创造性的、解决问题的视野，并考虑消除工程师在其阶段可以控制的常见安全隐患。安全代码在孤立的情况下并不十分有效，这就是为什么 "从左到右 "的概念将有助于支持安全文化成为开发人员的第二天性，建立在他们提供惊人的功能并降低风险的能力中。
从 "左边的左边 "开始是安全用户体验的关键。
长期以来，安全问题一直是软件用户体验中的一个考虑因素，但显然结果是好坏参半。在过去的一年中，安全配置错误占了基于云计算的数据泄露的21%，业余时间的错误，如以明文存储密码，给受影响的公司带来了一些生产力、收入和客户信任的严重损失。
而且，在保护自己的数据方面，用户自己可能是他们自己最大的敌人。太多的人仍在使用 "密码 "作为他们的密码，或在多个敏感账户中使用相同的组合。
我不知道有哪个开发者在被告知他们必须在登录屏幕上工作的时候会拍手叫好，这也难怪：设计一个安全流程是一个微妙的平衡，既要稳健、实用，又要让用户能够以一种对他们有意义的方式来浏览，而且干扰最小。
放置太多复杂的步骤和限制，用户可能会关闭，再也不会回来（这对一个新的应用程序来说是一场灾难），让它变得太混乱，你可能会让支持团队在处理用户试图访问他们的账户的询问时集体偏头痛。如果把它弄得太简单，那么你在安全方面就有点失败了。
一个成功的安全用户体验需要将严密的安全编织到一个有意义的流程中，并以一种不影响软件其他引人注意的方式呈现。你当然可以满足编码安全登录功能的目标，放入各种复杂的密码要求、验证码、小老板和四波僵尸，但如果它是一个完全混乱的、令用户厌恶的东西，它就没有达到目标。
为卓越的软件奠定基础。
作为一名开发人员，我知道我们绝大多数人都对自己的工作感到自豪，并希望做正确的事情。讨厌的曲线球，如时间限制，当前目标的突然变化，或紧急的热修复，会扰乱流程并导致错误，但残酷的事实是，许多软件工程师没有为成功做好准备。
从 "左边开始 "是一个开发者优先的概念，需要企业认真对待提高他们的工程队列的问题。有安全意识的开发人员是物有所值的，以培训的形式提供支持，提供正确的工具，并提供机会让更多有经验的开发人员对其进行指导，这将培养一种环境，使代码以安全第一的心态制作，并以精确和注重细节的方式将软件推向新的水平。
准备好点燃自己身上的安全编码之火了吗？ 迎接挑战.
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员，拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中，马蒂亚斯领导了多个应用安全研究项目，并将其转化为商业产品，他拥有超过10项专利。当他离开办公桌时，Matias曾担任高级应用安全培训courses ，并定期在全球会议上发言，包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
这篇文章的一个版本出现在 黑暗阅读.它已被更新并在此转发。
当与开发人员谈论安全问题时，我的一个口号是："唯一优质的代码是安全的代码"。这仍然是事实；当90年代有漏洞的软件在野外出现时，我们可能躲过了灾难，但今天不值得冒险。多年来，许多人努力向开发人员灌输安全意识的心态，在这样做的过程中，希望在涉及到他们的代码的自我assessment ，使安全成为质量的同义词。
经过思考（以及我的同行之间的一些辩论），然而，这也许是过度简化了这个概念。我们完全有可能创造出确实安全的代码，但却显示出新手开发技术的迹象，或其他使其不太理想的问题领域。
我们的行业详细地讨论了 "向左转移 "的概念。在我看来，这都是关于 "开始 "向左移动，使工程组群能够分担安全责任（作为质量的一个方面），并给予他们权力来消除他们（字面上）指尖上的常见漏洞。不过，鉴于目前的这个难题，似乎必须把信封推得更远一点。
具有一定质量水平的代码根据其定义也是安全的，但所有安全的代码不一定是好的质量。从 "左边的左边 "开始，是确保纯安全编码标准的公式吗？
质量差 "的安全代码是什么样子的？
让我们把放大镜放在这个代码片段上。
如果我们从安全的角度来分析这段代码，这段代码确实是安全的，而不是攻击者利用SQL注入漏洞的入口。
这是一个高质量代码的例子吗？很不幸，不是。简单地将参数从int(eger)改为String值，就可以让用户自由输入来操作查询，而数字则不能。这种改变--或者从其他地方胡乱复制和粘贴String sql--立即创造了一个可能存在SQL注入漏洞的环境，以及与之相关的所有风险。
安全措施在这里的范围非常有限，而一个更彻底的（或者，有经验的）开发者可能会采取不同的方法，并考虑低效参数结构的影响。运送这样的代码不仅是糟糕的做法，而且为开发组中的其他人树立了一个坏榜样。
软件的 "三重威胁"。形式、功能、堡垒般的？
娱乐业中的 "三重威胁 "是指能够以同样高的技术水平表演、跳舞和唱歌的人。他们是每次试镜时令人恐惧和羡慕的人，是已经竞争激烈的领域中的独角兽。每个行业都有自己版本的顶级、特殊的产品和服务的例子，软件也不例外。
如果我们想一想应用程序中很难与同等（高）质量相平衡的三个关键因素，它们可能是功能/优雅，加上铁一般的安全，再加上考虑所需的交付速度时的成本效益。现在，最后一个属性无疑是其他两个选项应用得好坏的决定性因素，它可以成为整体质量随着时间推移而下滑的催化剂。
然而，是否所有的软件都需要像休-杰克曼那样表现，或者我们可以用尼古拉斯-凯奇来逃避？这样说吧：如果你能让金刚狼加入你的团队，那么你就给它最好的机会。
马丁-福勒（Martin Fowler）在软件开发中提出了 "高质量是否值得"的问题，他的结论是，不仅 "值得"，而且随着时间的推移，它实际上更便宜。大多数用户不会去看引擎盖下的代码是否一团糟，也不会去看安全是否和其他东西一样重要。然而，那些工具上的人将浪费宝贵的时间重做马虎的代码，以增加更新的功能，或遍历项目的主要部分，以了解发生了什么，或者，最糟糕的情况是：修复一个从AppSec团队反弹回来的漏洞，推迟生产。现在花时间使代码既安全又优质，可以节省很多未来的心痛，更不用说解开执行不力的工作的成本。
熟练的有安全意识的开发人员编写的代码，在功能交付中保留了他们创造性的、解决问题的视野，并考虑消除工程师在其阶段可以控制的常见安全隐患。安全代码在孤立的情况下并不十分有效，这就是为什么 "从左到右 "的概念将有助于支持安全文化成为开发人员的第二天性，建立在他们提供惊人的功能并降低风险的能力中。
从 "左边的左边 "开始是安全用户体验的关键。
长期以来，安全问题一直是软件用户体验中的一个考虑因素，但显然结果是好坏参半。在过去的一年中，安全配置错误占了基于云计算的数据泄露的21%，业余时间的错误，如以明文存储密码，给受影响的公司带来了一些生产力、收入和客户信任的严重损失。
而且，在保护自己的数据方面，用户自己可能是他们自己最大的敌人。太多的人仍在使用 "密码 "作为他们的密码，或在多个敏感账户中使用相同的组合。
我不知道有哪个开发者在被告知他们必须在登录屏幕上工作的时候会拍手叫好，这也难怪：设计一个安全流程是一个微妙的平衡，既要稳健、实用，又要让用户能够以一种对他们有意义的方式来浏览，而且干扰最小。
放置太多复杂的步骤和限制，用户可能会关闭，再也不会回来（这对一个新的应用程序来说是一场灾难），让它变得太混乱，你可能会让支持团队在处理用户试图访问他们的账户的询问时集体偏头痛。如果把它弄得太简单，那么你在安全方面就有点失败了。
一个成功的安全用户体验需要将严密的安全编织到一个有意义的流程中，并以一种不影响软件其他引人注意的方式呈现。你当然可以满足编码安全登录功能的目标，放入各种复杂的密码要求、验证码、小老板和四波僵尸，但如果它是一个完全混乱的、令用户厌恶的东西，它就没有达到目标。
为卓越的软件奠定基础。
作为一名开发人员，我知道我们绝大多数人都对自己的工作感到自豪，并希望做正确的事情。讨厌的曲线球，如时间限制，当前目标的突然变化，或紧急的热修复，会扰乱流程并导致错误，但残酷的事实是，许多软件工程师没有为成功做好准备。
从 "左边开始 "是一个开发者优先的概念，需要企业认真对待提高他们的工程队列的问题。有安全意识的开发人员是物有所值的，以培训的形式提供支持，提供正确的工具，并提供机会让更多有经验的开发人员对其进行指导，这将培养一种环境，使代码以安全第一的心态制作，并以精确和注重细节的方式将软件推向新的水平。
准备好点燃自己身上的安全编码之火了吗？ 迎接挑战.
这篇文章的一个版本出现在 黑暗阅读.它已被更新并在此转发。
当与开发人员谈论安全问题时，我的一个口号是："唯一优质的代码是安全的代码"。这仍然是事实；当90年代有漏洞的软件在野外出现时，我们可能躲过了灾难，但今天不值得冒险。多年来，许多人努力向开发人员灌输安全意识的心态，在这样做的过程中，希望在涉及到他们的代码的自我assessment ，使安全成为质量的同义词。
经过思考（以及我的同行之间的一些辩论），然而，这也许是过度简化了这个概念。我们完全有可能创造出确实安全的代码，但却显示出新手开发技术的迹象，或其他使其不太理想的问题领域。
我们的行业详细地讨论了 "向左转移 "的概念。在我看来，这都是关于 "开始 "向左移动，使工程组群能够分担安全责任（作为质量的一个方面），并给予他们权力来消除他们（字面上）指尖上的常见漏洞。不过，鉴于目前的这个难题，似乎必须把信封推得更远一点。
具有一定质量水平的代码根据其定义也是安全的，但所有安全的代码不一定是好的质量。从 "左边的左边 "开始，是确保纯安全编码标准的公式吗？
质量差 "的安全代码是什么样子的？
让我们把放大镜放在这个代码片段上。
如果我们从安全的角度来分析这段代码，这段代码确实是安全的，而不是攻击者利用SQL注入漏洞的入口。
这是一个高质量代码的例子吗？很不幸，不是。简单地将参数从int(eger)改为String值，就可以让用户自由输入来操作查询，而数字则不能。这种改变--或者从其他地方胡乱复制和粘贴String sql--立即创造了一个可能存在SQL注入漏洞的环境，以及与之相关的所有风险。
安全措施在这里的范围非常有限，而一个更彻底的（或者，有经验的）开发者可能会采取不同的方法，并考虑低效参数结构的影响。运送这样的代码不仅是糟糕的做法，而且为开发组中的其他人树立了一个坏榜样。
软件的 "三重威胁"。形式、功能、堡垒般的？
娱乐业中的 "三重威胁 "是指能够以同样高的技术水平表演、跳舞和唱歌的人。他们是每次试镜时令人恐惧和羡慕的人，是已经竞争激烈的领域中的独角兽。每个行业都有自己版本的顶级、特殊的产品和服务的例子，软件也不例外。
如果我们想一想应用程序中很难与同等（高）质量相平衡的三个关键因素，它们可能是功能/优雅，加上铁一般的安全，再加上考虑所需的交付速度时的成本效益。现在，最后一个属性无疑是其他两个选项应用得好坏的决定性因素，它可以成为整体质量随着时间推移而下滑的催化剂。
然而，是否所有的软件都需要像休-杰克曼那样表现，或者我们可以用尼古拉斯-凯奇来逃避？这样说吧：如果你能让金刚狼加入你的团队，那么你就给它最好的机会。
马丁-福勒（Martin Fowler）在软件开发中提出了 "高质量是否值得"的问题，他的结论是，不仅 "值得"，而且随着时间的推移，它实际上更便宜。大多数用户不会去看引擎盖下的代码是否一团糟，也不会去看安全是否和其他东西一样重要。然而，那些工具上的人将浪费宝贵的时间重做马虎的代码，以增加更新的功能，或遍历项目的主要部分，以了解发生了什么，或者，最糟糕的情况是：修复一个从AppSec团队反弹回来的漏洞，推迟生产。现在花时间使代码既安全又优质，可以节省很多未来的心痛，更不用说解开执行不力的工作的成本。
熟练的有安全意识的开发人员编写的代码，在功能交付中保留了他们创造性的、解决问题的视野，并考虑消除工程师在其阶段可以控制的常见安全隐患。安全代码在孤立的情况下并不十分有效，这就是为什么 "从左到右 "的概念将有助于支持安全文化成为开发人员的第二天性，建立在他们提供惊人的功能并降低风险的能力中。
从 "左边的左边 "开始是安全用户体验的关键。
长期以来，安全问题一直是软件用户体验中的一个考虑因素，但显然结果是好坏参半。在过去的一年中，安全配置错误占了基于云计算的数据泄露的21%，业余时间的错误，如以明文存储密码，给受影响的公司带来了一些生产力、收入和客户信任的严重损失。
而且，在保护自己的数据方面，用户自己可能是他们自己最大的敌人。太多的人仍在使用 "密码 "作为他们的密码，或在多个敏感账户中使用相同的组合。
我不知道有哪个开发者在被告知他们必须在登录屏幕上工作的时候会拍手叫好，这也难怪：设计一个安全流程是一个微妙的平衡，既要稳健、实用，又要让用户能够以一种对他们有意义的方式来浏览，而且干扰最小。
放置太多复杂的步骤和限制，用户可能会关闭，再也不会回来（这对一个新的应用程序来说是一场灾难），让它变得太混乱，你可能会让支持团队在处理用户试图访问他们的账户的询问时集体偏头痛。如果把它弄得太简单，那么你在安全方面就有点失败了。
一个成功的安全用户体验需要将严密的安全编织到一个有意义的流程中，并以一种不影响软件其他引人注意的方式呈现。你当然可以满足编码安全登录功能的目标，放入各种复杂的密码要求、验证码、小老板和四波僵尸，但如果它是一个完全混乱的、令用户厌恶的东西，它就没有达到目标。
为卓越的软件奠定基础。
作为一名开发人员，我知道我们绝大多数人都对自己的工作感到自豪，并希望做正确的事情。讨厌的曲线球，如时间限制，当前目标的突然变化，或紧急的热修复，会扰乱流程并导致错误，但残酷的事实是，许多软件工程师没有为成功做好准备。
从 "左边开始 "是一个开发者优先的概念，需要企业认真对待提高他们的工程队列的问题。有安全意识的开发人员是物有所值的，以培训的形式提供支持，提供正确的工具，并提供机会让更多有经验的开发人员对其进行指导，这将培养一种环境，使代码以安全第一的心态制作，并以精确和注重细节的方式将软件推向新的水平。
准备好点燃自己身上的安全编码之火了吗？ 迎接挑战.
点击下面的链接，下载本资料的 PDF 文件。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
查看报告预定一个演示
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员，拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中，马蒂亚斯领导了多个应用安全研究项目，并将其转化为商业产品，他拥有超过10项专利。当他离开办公桌时，Matias曾担任高级应用安全培训courses ，并定期在全球会议上发言，包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
这篇文章的一个版本出现在 黑暗阅读.它已被更新并在此转发。
当与开发人员谈论安全问题时，我的一个口号是："唯一优质的代码是安全的代码"。这仍然是事实；当90年代有漏洞的软件在野外出现时，我们可能躲过了灾难，但今天不值得冒险。多年来，许多人努力向开发人员灌输安全意识的心态，在这样做的过程中，希望在涉及到他们的代码的自我assessment ，使安全成为质量的同义词。
经过思考（以及我的同行之间的一些辩论），然而，这也许是过度简化了这个概念。我们完全有可能创造出确实安全的代码，但却显示出新手开发技术的迹象，或其他使其不太理想的问题领域。
我们的行业详细地讨论了 "向左转移 "的概念。在我看来，这都是关于 "开始 "向左移动，使工程组群能够分担安全责任（作为质量的一个方面），并给予他们权力来消除他们（字面上）指尖上的常见漏洞。不过，鉴于目前的这个难题，似乎必须把信封推得更远一点。
具有一定质量水平的代码根据其定义也是安全的，但所有安全的代码不一定是好的质量。从 "左边的左边 "开始，是确保纯安全编码标准的公式吗？
质量差 "的安全代码是什么样子的？
让我们把放大镜放在这个代码片段上。
如果我们从安全的角度来分析这段代码，这段代码确实是安全的，而不是攻击者利用SQL注入漏洞的入口。
这是一个高质量代码的例子吗？很不幸，不是。简单地将参数从int(eger)改为String值，就可以让用户自由输入来操作查询，而数字则不能。这种改变--或者从其他地方胡乱复制和粘贴String sql--立即创造了一个可能存在SQL注入漏洞的环境，以及与之相关的所有风险。
安全措施在这里的范围非常有限，而一个更彻底的（或者，有经验的）开发者可能会采取不同的方法，并考虑低效参数结构的影响。运送这样的代码不仅是糟糕的做法，而且为开发组中的其他人树立了一个坏榜样。
软件的 "三重威胁"。形式、功能、堡垒般的？
娱乐业中的 "三重威胁 "是指能够以同样高的技术水平表演、跳舞和唱歌的人。他们是每次试镜时令人恐惧和羡慕的人，是已经竞争激烈的领域中的独角兽。每个行业都有自己版本的顶级、特殊的产品和服务的例子，软件也不例外。
如果我们想一想应用程序中很难与同等（高）质量相平衡的三个关键因素，它们可能是功能/优雅，加上铁一般的安全，再加上考虑所需的交付速度时的成本效益。现在，最后一个属性无疑是其他两个选项应用得好坏的决定性因素，它可以成为整体质量随着时间推移而下滑的催化剂。
然而，是否所有的软件都需要像休-杰克曼那样表现，或者我们可以用尼古拉斯-凯奇来逃避？这样说吧：如果你能让金刚狼加入你的团队，那么你就给它最好的机会。
马丁-福勒（Martin Fowler）在软件开发中提出了 "高质量是否值得"的问题，他的结论是，不仅 "值得"，而且随着时间的推移，它实际上更便宜。大多数用户不会去看引擎盖下的代码是否一团糟，也不会去看安全是否和其他东西一样重要。然而，那些工具上的人将浪费宝贵的时间重做马虎的代码，以增加更新的功能，或遍历项目的主要部分，以了解发生了什么，或者，最糟糕的情况是：修复一个从AppSec团队反弹回来的漏洞，推迟生产。现在花时间使代码既安全又优质，可以节省很多未来的心痛，更不用说解开执行不力的工作的成本。
熟练的有安全意识的开发人员编写的代码，在功能交付中保留了他们创造性的、解决问题的视野，并考虑消除工程师在其阶段可以控制的常见安全隐患。安全代码在孤立的情况下并不十分有效，这就是为什么 "从左到右 "的概念将有助于支持安全文化成为开发人员的第二天性，建立在他们提供惊人的功能并降低风险的能力中。
从 "左边的左边 "开始是安全用户体验的关键。
长期以来，安全问题一直是软件用户体验中的一个考虑因素，但显然结果是好坏参半。在过去的一年中，安全配置错误占了基于云计算的数据泄露的21%，业余时间的错误，如以明文存储密码，给受影响的公司带来了一些生产力、收入和客户信任的严重损失。
而且，在保护自己的数据方面，用户自己可能是他们自己最大的敌人。太多的人仍在使用 "密码 "作为他们的密码，或在多个敏感账户中使用相同的组合。
我不知道有哪个开发者在被告知他们必须在登录屏幕上工作的时候会拍手叫好，这也难怪：设计一个安全流程是一个微妙的平衡，既要稳健、实用，又要让用户能够以一种对他们有意义的方式来浏览，而且干扰最小。
放置太多复杂的步骤和限制，用户可能会关闭，再也不会回来（这对一个新的应用程序来说是一场灾难），让它变得太混乱，你可能会让支持团队在处理用户试图访问他们的账户的询问时集体偏头痛。如果把它弄得太简单，那么你在安全方面就有点失败了。
一个成功的安全用户体验需要将严密的安全编织到一个有意义的流程中，并以一种不影响软件其他引人注意的方式呈现。你当然可以满足编码安全登录功能的目标，放入各种复杂的密码要求、验证码、小老板和四波僵尸，但如果它是一个完全混乱的、令用户厌恶的东西，它就没有达到目标。
为卓越的软件奠定基础。
作为一名开发人员，我知道我们绝大多数人都对自己的工作感到自豪，并希望做正确的事情。讨厌的曲线球，如时间限制，当前目标的突然变化，或紧急的热修复，会扰乱流程并导致错误，但残酷的事实是，许多软件工程师没有为成功做好准备。
从 "左边开始 "是一个开发者优先的概念，需要企业认真对待提高他们的工程队列的问题。有安全意识的开发人员是物有所值的，以培训的形式提供支持，提供正确的工具，并提供机会让更多有经验的开发人员对其进行指导，这将培养一种环境，使代码以安全第一的心态制作，并以精确和注重细节的方式将软件推向新的水平。
准备好点燃自己身上的安全编码之火了吗？ 迎接挑战.
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示下载资源
安全代码培训主题和内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
%20(1).avif)
资源
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
