在你的技术栈中，肯定有一款开发者安全工具，它的许可证无人使用。它通过了采购流程，也通过了试点项目。 CISO 签字确认后，六个月过去了，开发人员要么绕过了安全机制，要么关闭了警报，要么继续像往常一样默默工作。这不是培训问题，也不是合规文化问题，而是开发人员安全意识薄弱的问题。这个问题比大多数安全负责人愿意承认的要普遍得多，也更容易预测。
开发者安全采纳的真正含义
开发者安全采纳率是指工具部署后与工具按照设计用途每天使用（无需人为强制执行）之间的差距。 CI 中运行的扫描器 开发者从未打开过的工具会被部署，但并未被采纳。如果一项安全发现仅仅因为前十次都是误报就被直接忽略，那么这项工具也会被部署，但并未被采纳。真正有效的开发者安全采纳方式看起来很平淡：开发者自愿打开工具，根据工具的提示采取行动，而不是寻找绕过它的方法。
这种区别至关重要，因为采购指标和采用指标衡量的是完全不同的事物。安全团队可能报告部署覆盖率达到 100%，而开发人员的安全采用率却接近于零，这两个数字可能同时成立。
为什么传统开发者安全软件难以被广泛使用
大多数开发者安全工具未能被广泛采用的原因都大同小异，几乎所有尝试推广这类工具的组织都会遇到同样的问题：
- 噪音太多，信任太少。 扼杀开发者安全意识的最快方法就是过高的误报率。当开发者追查了三个最终被证实是虚惊一场的发现后，他们就会不再信任第四个，甚至不再关注第五个。
- 它存在于开发者们所不了解的地方。 A dashboard 开发人员必须记住，打开是一个 dashboard 他们会忘记的。需要离开集成开发环境（IDE）、切换上下文、稍后再回来才能修复的安全软件，会错失修复成本最低、最简便的时机。
- 它会指出问题，但不会提出解决方案。 如果发现漏洞只是简单地指出“SQL注入，第42行”，却不解释漏洞利用路径或提供修复方案，那只会给开发者留下额外的作业，而不是提供帮助。这会严重阻碍开发者采取安全措施，因为它把每个漏洞都变成了一个研究项目，而不是一个有效的解决方案。cis离子。
- 它会阻止构建，但不会解释原因。 红色 pipeline 脱离上下文，安全门会被解读为障碍，而非信号。开发者会逐渐将安全门视为需要跨越的障碍，而不是需要听从的指令。
- 它是为审计人员设计的，而不是为开发人员设计的。 主要设计用于生成合规性证据的工具往往会表现出以下特点：冗长的报告、充斥着专业术语的调查结果，没有尝试用实际会根据这些结果采取行动的人的语言来沟通。
安全软件开发人员测试：他们会再次打开它吗？
这里有一个实用的筛选方法，可以在购买任何开发者安全软件之前进行评估：开发者是否会在第二天主动打开它？不是因为策略要求，而是因为它昨天确实提供了有用的信息。大多数无法被开发者广泛采用的安全工具，在第一天就会被这项测试否决，而且在签订合同之前，大家就已经有所察觉。
这些工具具有一些共同的特点。它们存在于编辑器内部，而不是在后台运行。 login他们解释发现问题的方式，就像资深工程师在代码审查中那样，而不是像合规性报告那样。他们会提出具体的修复方案，而不仅仅是诊断结果。更重要的是，他们的判断通常都很准确，因此开发人员无需在信任每一条警报之前都进行反复核查。
真正推动采用的因素是什么？
正确落实开发者安全措施并非在于加强培训或提高强制性要求，而在于少数几个设计要素。cis离子：
- 在开发人员的工作场所与他们见面。 集成开发环境的安全机制， pull request这样就会使用命令行界面 (CLI)。而需要单独目标位置的安全设置则不会。
- 解释清楚，不要只是标记。 如果能将发现的漏洞与对漏洞利用路径的通俗解释结合起来，就能将晦涩难懂的警报转化为开发人员可以理解并立即采取行动的信息。
- 提出解决方案，而不仅仅是问题本身。 自动修复功能可以让开发人员在几秒钟内查看并接受，这比提交错误报告更尊重他们的时间。
- 保持较高的信噪比。 积极的误报过滤并非锦上添花，而是开发者安全措施能否持续到第一个月之后的最重要因素。
- 把宝贵的时间留给真正重要的事情。 Guardrails 每次低严重性发现都会破坏构建，这会让开发人员对大门感到不满。 Guardrails 这种只阻止真正关键且可修复的问题的做法，会训练开发人员信任它。
Xygeni 如何看待开发者安全软件设计
Xygeni IDE 插件 它会在开发者已经工作的地方——集成开发环境（IDE）内运行，持续扫描人工和人工智能生成的代码，无需任何提示。一旦发现漏洞，它会用通俗易懂的语言解释完整的漏洞利用路径，并提供开发者可以查看和应用的修复方案，而不是仅仅依靠CVE编号让开发者自行摸索。
人工智能分类 对所有内容应用相同的误报过滤。 SAST，秘密， IaC此外，恶意软件检测结果会在整个平台上同步更新，因此，在发现问题到达开发者队列之前，就能解决其他地方阻碍开发者采用安全措施的噪音问题。构建 guardrails 在以下方面执行政策 pipeline 严格控制，但要有选择性地阻止真正关键且可修复的问题，而不是把每个发现的问题都视为同样会破坏构建的因素。这种区别能够防止开发人员学会绕过这个限制。
所有这些都无法改变这样一个现实：开发商通常是交易的杠杆，而不是经济上的买家。 enterprise AppSeccis离子。A CISO 签署了合同；工程副总裁关心该工具是否会给团队带来不便。但开发者对安全工具的采纳才是真正能将这种杠杆转化为杠杆的关键：开发者真正使用的工具才能修复真正的漏洞，而他们绕过的工具则无法修复任何漏洞，无论采购订单是谁批准的。
衡量采用率，而不仅仅是部署率
如果你想真实了解组织内部开发人员安全措施的采用情况，部署覆盖率并不是一个合适的指标。更好的指标包括：
- 开发者在未被告知的情况下打开该工具的频率。
- 建议的解决方案中，被采纳的比例是多少？被否决的比例又是多少？
- 关注的是补救时间是否真的在缩短，而不仅仅是调查结果是否被记录在案。
- 无论开发人员是在新项目中主动要求使用该工具，还是等待被告知安装它。
许可证数量可以告诉你你购买了哪些许可证。这些数字可以告诉你开发者是否真正采用了安全措施。
常见问题解答
“开发者安全采纳”是什么意思？
这是安全工具部署到位与实际被开发者按照设计初衷自愿地、日常地、非强制地使用之间的差距。高部署覆盖率和低开发者安全采纳率可能并存，而且这种情况经常发生。
为什么开发人员即使接受过培训仍然会忽视安全工具？
培训并不能解决工具误报过多、游离于开发者工作流程之外或只标记问题而不提供修复方案等问题。这些都是设计问题，而非知识盲点，再多的培训也无法改变这些根本性的缺陷。
影响开发者采用安全措施的最重要因素是什么？
信任信号。一旦开发人员不再相信某个发现的真实性，他们就会停止对所有发现采取行动，包括那些真正重要的发现。积极过滤误报通常是最有效的解决方案。
开发者安全软件与传统应用安全工具有何不同？
最好的开发者安全软件将开发者视为主要用户，而不仅仅是合规性目标：它在 IDE 内部运行，用通俗易懂的语言解释发现的问题，并提出修复方案，而不是生成一份报告供其他人稍后解读。
应该一个 CIS如果工具是开发者购买的，我还会关心开发者是否采用安全措施吗？
是的，直接而言。一款合规覆盖范围广但开发者安全采纳率低的工具实际上并不能降低风险，它只是生成报告而已。风险降低…… CIS只有当开发者使用该工具时，O 的购买行为才会实现。
