从 "左边的左边 "开始。安全的代码总是高质量的代码吗？
这篇文章的一个版本出现在 黑暗阅读.它已被更新并在此转发。
当与开发人员谈论安全问题时，我的一个口号是："唯一优质的代码是安全的代码"。这仍然是事实；当90年代有漏洞的软件在野外出现时，我们可能躲过了灾难，但今天不值得冒险。多年来，许多人努力向开发人员灌输安全意识的心态，在这样做的过程中，希望在涉及到他们的代码的自我assessment ，使安全成为质量的同义词。
经过思考（以及我的同行之间的一些辩论），然而，这也许是过度简化了这个概念。我们完全有可能创造出确实安全的代码，但却显示出新手开发技术的迹象，或其他使其不太理想的问题领域。
我们的行业详细地讨论了 "向左转移 "的概念。在我看来，这都是关于 "开始 "向左移动，使工程组群能够分担安全责任（作为质量的一个方面），并给予他们权力来消除他们（字面上）指尖上的常见漏洞。不过，鉴于目前的这个难题，似乎必须把信封推得更远一点。
具有一定质量水平的代码根据其定义也是安全的，但所有安全的代码不一定是好的质量。从 "左边的左边 "开始，是确保纯安全编码标准的公式吗？
质量差 "的安全代码是什么样子的？
让我们把放大镜放在这个代码片段上。
如果我们从安全的角度来分析这段代码，这段代码确实是安全的，而不是攻击者利用SQL注入漏洞的入口。
这是一个高质量代码的例子吗？很不幸，不是。简单地将参数从int(eger)改为String值，就可以让用户自由输入来操作查询，而数字则不能。这种改变--或者从其他地方胡乱复制和粘贴String sql--立即创造了一个可能存在SQL注入漏洞的环境，以及与之相关的所有风险。
安全措施在这里的范围非常有限，而一个更彻底的（或者，有经验的）开发者可能会采取不同的方法，并考虑低效参数结构的影响。运送这样的代码不仅是糟糕的做法，而且为开发组中的其他人树立了一个坏榜样。
软件的 "三重威胁"。形式、功能、堡垒般的？
娱乐业中的 "三重威胁 "是指能够以同样高的技术水平表演、跳舞和唱歌的人。他们是每次试镜时令人恐惧和羡慕的人，是已经竞争激烈的领域中的独角兽。每个行业都有自己版本的顶级、特殊的产品和服务的例子，软件也不例外。
如果我们想一想应用程序中很难与同等（高）质量相平衡的三个关键因素，它们可能是功能/优雅，加上铁一般的安全，再加上考虑所需的交付速度时的成本效益。现在，最后一个属性无疑是其他两个选项应用得好坏的决定性因素，它可以成为整体质量随着时间推移而下滑的催化剂。
然而，是否所有的软件都需要像休-杰克曼那样表现，或者我们可以用尼古拉斯-凯奇来逃避？这样说吧：如果你能让金刚狼加入你的团队，那么你就给它最好的机会。
马丁-福勒（Martin Fowler）在软件开发中提出了 "高质量是否值得"的问题，他的结论是，不仅 "值得"，而且随着时间的推移，它实际上更便宜。大多数用户不会去看引擎盖下的代码是否一团糟，也不会去看安全是否和其他东西一样重要。然而，那些工具上的人将浪费宝贵的时间重做马虎的代码，以增加更新的功能，或遍历项目的主要部分，以了解发生了什么，或者，最糟糕的情况是：修复一个从AppSec团队反弹回来的漏洞，推迟生产。现在花时间使代码既安全又优质，可以节省很多未来的心痛，更不用说解开执行不力的工作的成本。
熟练的有安全意识的开发人员编写的代码，在功能交付中保留了他们创造性的、解决问题的视野，并考虑消除工程师在其阶段可以控制的常见安全隐患。安全代码在孤立的情况下并不十分有效，这就是为什么 "从左到右 "的概念将有助于支持安全文化成为开发人员的第二天性，建立在他们提供惊人的功能并降低风险的能力中。
从 "左边的左边 "开始是安全用户体验的关键。
长期以来，安全问题一直是软件用户体验中的一个考虑因素，但显然结果是好坏参半。在过去的一年中，安全配置错误占了基于云计算的数据泄露的21%，业余时间的错误，如以明文存储密码，给受影响的公司带来了一些生产力、收入和客户信任的严重损失。
而且，在保护自己的数据方面，用户自己可能是他们自己最大的敌人。太多的人仍在使用 "密码 "作为他们的密码，或在多个敏感账户中使用相同的组合。
我不知道有哪个开发者在被告知他们必须在登录屏幕上工作的时候会拍手叫好，这也难怪：设计一个安全流程是一个微妙的平衡，既要稳健、实用，又要让用户能够以一种对他们有意义的方式来浏览，而且干扰最小。
放置太多复杂的步骤和限制，用户可能会关闭，再也不会回来（这对一个新的应用程序来说是一场灾难），让它变得太混乱，你可能会让支持团队在处理用户试图访问他们的账户的询问时集体偏头痛。如果把它弄得太简单，那么你在安全方面就有点失败了。
一个成功的安全用户体验需要将严密的安全编织到一个有意义的流程中，并以一种不影响软件其他引人注意的方式呈现。你当然可以满足编码安全登录功能的目标，放入各种复杂的密码要求、验证码、小老板和四波僵尸，但如果它是一个完全混乱的、令用户厌恶的东西，它就没有达到目标。
为卓越的软件奠定基础。
作为一名开发人员，我知道我们绝大多数人都对自己的工作感到自豪，并希望做正确的事情。讨厌的曲线球，如时间限制，当前目标的突然变化，或紧急的热修复，会扰乱流程并导致错误，但残酷的事实是，许多软件工程师没有为成功做好准备。
从 "左边开始 "是一个开发者优先的概念，需要企业认真对待提高他们的工程队列的问题。有安全意识的开发人员是物有所值的，以培训的形式提供支持，提供正确的工具，并提供机会让更多有经验的开发人员对其进行指导，这将培养一种环境，使代码以安全第一的心态制作，并以精确和注重细节的方式将软件推向新的水平。
准备好点燃自己身上的安全编码之火了吗？ 迎接挑战.
马蒂亚斯-马杜博士
马蒂亚斯是一名研究员和开发人员，拥有超过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%，业余时间的错误，如以明文存储密码，给受影响的公司带来了一些生产力、收入和客户信任的严重损失。
而且，在保护自己的数据方面，用户自己可能是他们自己最大的敌人。太多的人仍在使用 "密码 "作为他们的密码，或在多个敏感账户中使用相同的组合。
我不知道有哪个开发者在被告知他们必须在登录屏幕上工作的时候会拍手叫好，这也难怪：设计一个安全流程是一个微妙的平衡，既要稳健、实用，又要让用户能够以一种对他们有意义的方式来浏览，而且干扰最小。
放置太多复杂的步骤和限制，用户可能会关闭，再也不会回来（这对一个新的应用程序来说是一场灾难），让它变得太混乱，你可能会让支持团队在处理用户试图访问他们的账户的询问时集体偏头痛。如果把它弄得太简单，那么你在安全方面就有点失败了。
一个成功的安全用户体验需要将严密的安全编织到一个有意义的流程中，并以一种不影响软件其他引人注意的方式呈现。你当然可以满足编码安全登录功能的目标，放入各种复杂的密码要求、验证码、小老板和四波僵尸，但如果它是一个完全混乱的、令用户厌恶的东西，它就没有达到目标。
为卓越的软件奠定基础。
作为一名开发人员，我知道我们绝大多数人都对自己的工作感到自豪，并希望做正确的事情。讨厌的曲线球，如时间限制，当前目标的突然变化，或紧急的热修复，会扰乱流程并导致错误，但残酷的事实是，许多软件工程师没有为成功做好准备。
从 "左边开始 "是一个开发者优先的概念，需要企业认真对待提高他们的工程队列的问题。有安全意识的开发人员是物有所值的，以培训的形式提供支持，提供正确的工具，并提供机会让更多有经验的开发人员对其进行指导，这将培养一种环境，使代码以安全第一的心态制作，并以精确和注重细节的方式将软件推向新的水平。
准备好点燃自己身上的安全编码之火了吗？ 迎接挑战.
