openssh漏洞修复风险
当静态代码分析工具识别生产代码中的错误时，组织可以采用两种方法。 明智的做法是让一两个软件开发人员解决问题并立即实施错误修复。 另一种选择是组建软件团队，讨论不解决问题的相对风险，然后选择不对该问题采取任何措施，因为这样做带来的回报与风险不相称。 您会惊讶于团队经常选择后一种方法。
风险评估的危险
Checkmarx应用程序安全策略全球总监Matt Rose说：“许多组织都有有效的过程来识别问题，但没有补救过程。” “组织在风险方面做了很多签名。 他们没有说“让我们来补救”，而是说“这种情况实际发生的可能性是什么？””
令人遗憾的是， 基于云的，基于DevOps的开发的趋势并没有扭转这种趋势，即倾向于风险评估而不是问题修复。 任何拥护DevOps并实施持续交付系统的团队的目标都是消除尽可能多的手动流程。 该过程的很大一部分是将软件质量和静态代码分析工具集成到持续集成服务器的构建过程中。 但是仅使过程自动化是不够的。 罗斯说：“很多时候人们只是在自动化，而实际上并没有进行补救。”
错误修复的好处
有非常令人信服的理由要通过实施错误修复来正确保护您的应用程序。 最明显的是，您的代码几乎没有可识别的问题，从而减少了对软件质量工具的抱怨。 “错误是关键的还是非关键的都没有关系。 一个bug就是一个bug就是一个bug。 如果您不对它采取行动，它就不会消失。”
“许多组织都有有效的过程来识别问题，但没有补救过程。 组织在风险方面做了很多签名。” -Matt玫瑰的应用安全策略在全球总监Checkmarx 。
另一个好处是，解决问题和编码错误修复的过程实际上是一种教育经验。 开发人员可以了解问题，意识到给定的代码段可能是如何造成漏洞的，然后他们就有机会重新编写给定的函数，从而消除了问题。 “研究应用程序中存在的真实漏洞，将教会您如何一遍又一遍地避免犯同样的错误。”
因此，跳过风险评估。 如果您的代码有问题，请实施错误修复。 那将完全消除风险。
您可以在Twitter上关注Checkmarx： @checkmarx 您也可以关注Cameron McKenzie： @cameronmcnz
openssh漏洞修复风险
5576
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
