如果您是开发人员并且可以访问Ounce Labs，Fortify Software或Veracode等工具，您是否会反对您撰写的代码公开提供的指标？如果您反对，那么您在这方面有更多的透明度会让您感到更舒服吗？
如果指标是公开的，您认为这会产生积极的副作用，鼓励开发人员花更多时间学习secure coding技术吗？是否有更好的方法鼓励开发人员花时间学习secure coding给出相互竞争的问题？
答案 0 :(得分：1)
我认为访问工具不一定是问题所在。从您的个人资料的外观来看，我们处于类似的位置。我负责构建相当大的客户端 - 服务器解决方案。我们的代码库中的安全问题是安全实践的结果，而不是“在雷达上”。它们因功能集和其他面向客户的错误修复而受到冲击。
我们目前正在研究如何保护我们的代码库，管理企业级别的安全角色以及因市场需求而产生的所有好处。我认为有一种方法来衡量代码库中的风险级别非常重要。这就是工具发挥作用的地方 - 它们提供报告并可用于显示改进。开发人员喜欢可衡量的进步并减少分析工具从一个版本到另一个版本发现的安全风险的数量，这是非常可测量的。
我认为他们提供的工具和报告可能会有所帮助，实际上起着非常关键的作用。但是，直到有人（管理层，市场，等等）对关闭安全漏洞提出一些价值并要求重复使用工具来显示评估风险的降低，开发人员不会过度对安全相关的编程感兴趣。当你看到所有其他非常酷的嗖嗖声时，真的不是那么有趣。您可能希望在几周前check out this related thread或从去年十月开始even this one。
更糟糕的是，安全问题只对今天的极少量软件产生了影响。话虽如此，如果我们更加注重安全性，那么 The Field 报告的大量缺陷就不会发生;换句话说，它们是安全缺陷，即使它们被报告是因为它们引起了其他问题。这是我认为在修复安全缺陷时我们实际上可以获得最大收益的地方。我想知道是否有人做过一项研究，检查在进行安全评估和修复之前和之后的错误报告率。我的直觉告诉我，报告的缺陷率应该降低 - 即“更安全的软件”==“更高质量的软件”。这足够漫无边际......
答案 1 :(得分：0)
我认为任何衡量标准都存在高度怀疑的所有常见原因。安全指标可能会用作FUD。您还需要知道适当性。例如，与不受信任的代码相关的缺陷与不受信任的代码无关。
有两个重要问题，IMO：它有漏洞吗？这有多明显？
（另一个问题是：为什么你没有在链接中明确链接到某个本地组？）