你的组织真的做好了DevSec的准备吗？对它进行测试。
我们在2020年刚刚过半，但我们已经在创造一个严峻的数据泄露记录，与2019年上半年相比，被盗数据增加了273%。这些天，问有多少数据还没有被盗更准确。随着COVID-19大流行等世界性事件的发生，这些攻击的频率和效力只会增加，目标越来越脆弱。
这是我们都知道的事情：安全不再是可有可无的，我们的重点必须是先发制人的打击。要做到这一点，SDLC中的每个人都必须具有安全意识，尤其是开发人员。这是DevSecOps的 "DevSec"部分，是一种理想的软件开发方法论的气候，但许多组织并没有做好充分准备来有效地执行这一点。
考虑到你的组织，在你的角色背景下思考这些问题。在接受DevSec测试时，它的表现会如何？
DevSec Self-Assessment: 你的SDLC花园准备好绽放安全意识的工程师了吗？
一系列的网络安全风险因素可能会让普通的CISO夜不能寐，但令人担忧的现实是，虽然许多公司将安全作为优先事项，但他们的内部方法可能不够强大，无法减轻潜在的灾难（或者，至少是AppSec团队的巨大麻烦和软件的延迟发货）。
DevSecOps可能是当前安全涅槃的状态，但很少有公司采用这种方法。如果你还处于敏捷期--甚至是瀑布期--那么安全往往还被认为是专家的领域，他们与流程相距甚远，在SDLC的后期才被激活，突然出现的热修复破坏了开发者的一天。在这样的环境中，要推动开发安全文化是很有挑战性的：开发人员喜欢并优先考虑功能建设，他们根本没有足够的安全实践经验，无法将其视为一个理想的提高技能的途径。事实上，他们与安全的接触点可能是沮丧和消极的。这种情况必须迅速得到纠正，以便为参与软件开发过程的每个人灌输一种思想前卫的方法。- 当涉及到威胁建模时，你的组织还在追赶吗？
这是一个令人清醒的统计数字，60%的中小企业在成功的网络攻击后六个月内就会倒闭，就像其他灾难一样，如果没有足够的规划，影响会更大。
威胁建模是安全最佳实践的一个重要元素，允许AppSec专业人士评估攻击面的全部范围并构建适当的防御、反措施和规划。在完全接受DevSecOps的公司中，安全在CI/CD管道的早期就已启用，其方式不会像过去那样拖累生产。安全、安全编码和持续交付都是流程的一部分，开发团队被赋予了所需的资源和机会，成为引擎的主要组成部分，吐出无懈可击的代码。 - 开发经理是否优先考虑安全最佳实践？
无论他们是否愿意，开发经理都是他们团队的榜样。而且，这不仅仅是文化和氛围的问题，比如穿人字拖去办公室或者他们如何 "向上管理"。他们的工作重点将不可避免地被他们的团队成员所吸收，如果安全不是关键目标的一部分，或者在培训和支持方面没有计划，那么他们下面的工程师就会错过，而企业的风险将比它应该的更大。
根据我的经验，让一个人越位的最快方法是告诉他们必须做一些与他们目前的方法不一样的事情，而不告诉他们为什么。
被告知 "改变 "意味着以前的方法是错误的，而在许多情况下，这只是一个改进，希望以后能让事情变得更容易和更有效。要真正接受DevSec运动，首先需要给开发人员一个关心安全的理由--毕竟，在大多数组织中，它在很大程度上仍然是 "别人的问题"（即AppSec向导被锁在另一个房间里，很远很远）。
如果安全不是一个共同的责任，DevSecOps就不会发挥作用。开发人员需要正确的工具、支持和培训来完成他们的工作......而这需要时间来推出和完善整体安全计划的一部分。最糟糕的方法是使人不知所措和疏远的方法，当开发人员有太多竞争性的优先事项，而没有人帮助他们管理这些优先事项而不使自己发疯时，就会出现这种情况。这是一个文化转变，而且不是一蹴而就的。- 你是否依靠少数神奇的安全独角兽来承担许多任务？
安全专业人员是非常短缺的，我们需要的人数远远超过目前的水平。这是一个既定事实，但有越来越多的开发人员转向更注重安全的角色。通常情况下，他们的头衔可能是 "安全工程师 "或 "DevOps工程师"（慢慢地，我们会看到这个头衔演变成DevSecOps工程师，如果幸运的话！）。一个有枪的DevOps工程师能够为几乎任何应用程序开发功能，同时使用真正的CI/CD管道进行部署。他们做的都是端到端的工作，而且通常具有健康的安全意识。从这个意义上说，他们是一种神奇的人，因此也是罕见的。
然而，一些公司犯了一个错误，那就是雇用这些专业工程师，把他们塞进一个团队，并期望他们在开发过程的每个阶段都能解决所有的安全问题，而这就是万能的了。让你的DevSecOps魔术师负担过重，你就会在你开始的地方结束--运送不安全的代码，而没有检查、平衡和安全精度，他们首先被雇用来执行。最重要的是，开发团队要提高技能，并在一个积极的安全环境中得到培养，这样他们就有能力以一种有意义的方式分担负担。
找到你想在你的组织中看到的变化。
如果你将强大的培训作为安全计划的一部分，你会在你的开发团队中发现一些隐藏的宝石。这些人，尽管他们在日常工作中可能有任何负面的经历，但他们对安全编码和安全最佳实践有一定的热情。这些人是团队中安全卫士的主要候选人；他们是安全和工程之间的联系点，为其他人树立了一个很好的榜样，保持了较高的意识，并有助于参与计划。他们的人际交往能力也是非常重要的，可以将安全的喜悦传播到更远的地方，并向管理层和安全团队倡导开发者的需求。
"这对我有什么好处？"对话是一个积极的进步。
即使是最崇高的人类，也需要一些 "胡萝卜 "来让他们涉足不熟悉的领域，或者一个可能没有最令人愉快的学习曲线的活动。
从 "开发 "到 "DevSec "的飞跃，对开发者的职业生涯是一个巨大的推动。有安全意识的开发人员已经努力理解安全，在他们可以控制的领域承担起安全责任，并在操作中理解到只有安全的代码才是高质量的代码。一般来说，开发人员希望改进，解决新问题，并创造令人羡慕的功能，帮助他们在同行中脱颖而出。给他们提供一条达到更高水平的软件开发的途径，这是一个双赢的局面。
建立你的开发安全梦之队永远不会太晚。
如果你管理开发人员，领导一个AppSec意识团队，或者你是众多努力设计安全计划策略的人之一，现在是比 "左移 "更好的时候了。有了正确的培训、工具和环境，你可以为开发者创造一个安全孵化器，为所有各方带来巨大的红利。如果这份清单强调了一些需要改进的地方，那么你就有了一个很好的机会，为你的组织准备一个由DevSec领导的工程部门，可以从SDLC的一开始就减少风险。
马蒂亚斯-马杜博士
马蒂亚斯是一名研究员和开发人员，拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中，马蒂亚斯领导了多个应用安全研究项目，并将其转化为商业产品，他拥有超过10项专利。当他离开办公桌时，Matias曾担任高级应用安全培训courses ，并定期在全球会议上发言，包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
在博客上深入了解我们最新的安全编码见解。
我们广泛的资源库旨在增强人类对安全编码技术提升的方法。
获取关于开发者驱动的安全的最新研究
我们广泛的资源库充满了有用的资源，从白皮书到网络研讨会，让你开始使用开发者驱动的安全编码。现在就去探索它。
你的组织真的做好了DevSec的准备吗？对它进行测试。
我们在2020年刚刚过半，但我们已经在创造一个严峻的数据泄露记录，与2019年上半年相比，被盗数据增加了273%。这些天，问有多少数据还没有被盗更准确。随着COVID-19大流行等世界性事件的发生，这些攻击的频率和效力只会增加，目标越来越脆弱。
这是我们都知道的事情：安全不再是可有可无的，我们的重点必须是先发制人的打击。要做到这一点，SDLC中的每个人都必须具有安全意识，尤其是开发人员。这是DevSecOps的 "DevSec"部分，是一种理想的软件开发方法论的气候，但许多组织并没有做好充分准备来有效地执行这一点。
考虑到你的组织，在你的角色背景下思考这些问题。在接受DevSec测试时，它的表现会如何？
DevSec Self-Assessment: 你的SDLC花园准备好绽放安全意识的工程师了吗？
一系列的网络安全风险因素可能会让普通的CISO夜不能寐，但令人担忧的现实是，虽然许多公司将安全作为优先事项，但他们的内部方法可能不够强大，无法减轻潜在的灾难（或者，至少是AppSec团队的巨大麻烦和软件的延迟发货）。
DevSecOps可能是当前安全涅槃的状态，但很少有公司采用这种方法。如果你还处于敏捷期--甚至是瀑布期--那么安全往往还被认为是专家的领域，他们与流程相距甚远，在SDLC的后期才被激活，突然出现的热修复破坏了开发者的一天。在这样的环境中，要推动开发安全文化是很有挑战性的：开发人员喜欢并优先考虑功能建设，他们根本没有足够的安全实践经验，无法将其视为一个理想的提高技能的途径。事实上，他们与安全的接触点可能是沮丧和消极的。这种情况必须迅速得到纠正，以便为参与软件开发过程的每个人灌输一种思想前卫的方法。- 当涉及到威胁建模时，你的组织还在追赶吗？
这是一个令人清醒的统计数字，60%的中小企业在成功的网络攻击后六个月内就会倒闭，就像其他灾难一样，如果没有足够的规划，影响会更大。
威胁建模是安全最佳实践的一个重要元素，允许AppSec专业人士评估攻击面的全部范围并构建适当的防御、反措施和规划。在完全接受DevSecOps的公司中，安全在CI/CD管道的早期就已启用，其方式不会像过去那样拖累生产。安全、安全编码和持续交付都是流程的一部分，开发团队被赋予了所需的资源和机会，成为引擎的主要组成部分，吐出无懈可击的代码。 - 开发经理是否优先考虑安全最佳实践？
无论他们是否愿意，开发经理都是他们团队的榜样。而且，这不仅仅是文化和氛围的问题，比如穿人字拖去办公室或者他们如何 "向上管理"。他们的工作重点将不可避免地被他们的团队成员所吸收，如果安全不是关键目标的一部分，或者在培训和支持方面没有计划，那么他们下面的工程师就会错过，而企业的风险将比它应该的更大。
根据我的经验，让一个人越位的最快方法是告诉他们必须做一些与他们目前的方法不一样的事情，而不告诉他们为什么。
被告知 "改变 "意味着以前的方法是错误的，而在许多情况下，这只是一个改进，希望以后能让事情变得更容易和更有效。要真正接受DevSec运动，首先需要给开发人员一个关心安全的理由--毕竟，在大多数组织中，它在很大程度上仍然是 "别人的问题"（即AppSec向导被锁在另一个房间里，很远很远）。
如果安全不是一个共同的责任，DevSecOps就不会发挥作用。开发人员需要正确的工具、支持和培训来完成他们的工作......而这需要时间来推出和完善整体安全计划的一部分。最糟糕的方法是使人不知所措和疏远的方法，当开发人员有太多竞争性的优先事项，而没有人帮助他们管理这些优先事项而不使自己发疯时，就会出现这种情况。这是一个文化转变，而且不是一蹴而就的。- 你是否依靠少数神奇的安全独角兽来承担许多任务？
安全专业人员是非常短缺的，我们需要的人数远远超过目前的水平。这是一个既定事实，但有越来越多的开发人员转向更注重安全的角色。通常情况下，他们的头衔可能是 "安全工程师 "或 "DevOps工程师"（慢慢地，我们会看到这个头衔演变成DevSecOps工程师，如果幸运的话！）。一个有枪的DevOps工程师能够为几乎任何应用程序开发功能，同时使用真正的CI/CD管道进行部署。他们做的都是端到端的工作，而且通常具有健康的安全意识。从这个意义上说，他们是一种神奇的人，因此也是罕见的。
然而，一些公司犯了一个错误，那就是雇用这些专业工程师，把他们塞进一个团队，并期望他们在开发过程的每个阶段都能解决所有的安全问题，而这就是万能的了。让你的DevSecOps魔术师负担过重，你就会在你开始的地方结束--运送不安全的代码，而没有检查、平衡和安全精度，他们首先被雇用来执行。最重要的是，开发团队要提高技能，并在一个积极的安全环境中得到培养，这样他们就有能力以一种有意义的方式分担负担。
找到你想在你的组织中看到的变化。
如果你将强大的培训作为安全计划的一部分，你会在你的开发团队中发现一些隐藏的宝石。这些人，尽管他们在日常工作中可能有任何负面的经历，但他们对安全编码和安全最佳实践有一定的热情。这些人是团队中安全卫士的主要候选人；他们是安全和工程之间的联系点，为其他人树立了一个很好的榜样，保持了较高的意识，并有助于参与计划。他们的人际交往能力也是非常重要的，可以将安全的喜悦传播到更远的地方，并向管理层和安全团队倡导开发者的需求。
"这对我有什么好处？"对话是一个积极的进步。
即使是最崇高的人类，也需要一些 "胡萝卜 "来让他们涉足不熟悉的领域，或者一个可能没有最令人愉快的学习曲线的活动。
从 "开发 "到 "DevSec "的飞跃，对开发者的职业生涯是一个巨大的推动。有安全意识的开发人员已经努力理解安全，在他们可以控制的领域承担起安全责任，并在操作中理解到只有安全的代码才是高质量的代码。一般来说，开发人员希望改进，解决新问题，并创造令人羡慕的功能，帮助他们在同行中脱颖而出。给他们提供一条达到更高水平的软件开发的途径，这是一个双赢的局面。
建立你的开发安全梦之队永远不会太晚。
如果你管理开发人员，领导一个AppSec意识团队，或者你是众多努力设计安全计划策略的人之一，现在是比 "左移 "更好的时候了。有了正确的培训、工具和环境，你可以为开发者创造一个安全孵化器，为所有各方带来巨大的红利。如果这份清单强调了一些需要改进的地方，那么你就有了一个很好的机会，为你的组织准备一个由DevSec领导的工程部门，可以从SDLC的一开始就减少风险。
