如何对漏洞严重性进行分类以补充我们的优先级分类？

在我目前的工作中，我们有低，中，高优先级的错误。

• 低优先级错误是不会停止发货或对任何用户造成实际麻烦的小错误。
• 中优先级错误会导致一些内部用户麻烦，但有已知的解决方法。
• 高优先级错误是客户会看到的问题，可能会损坏数据或使系统崩溃。

如何对漏洞严重性进行分类以补充我们的优先级分类？

我们根据错误和缺陷的优先​​级和严重性对其进行分类。

优先级指示了修复/纠正问题的紧急程度（紧急，高，中，低，无）。

严重性级别可帮助我们确定缺陷可能造成的损害程度或类型（危险/破坏性，降级且没有解决方法，受影响但存在解决方法，令人讨厌/美观，无影响）。

通常，错误越危险和更具破坏性，优先级越高。但是，不能保证。因此，我们可以将偶尔的bug列为危险和破坏性的错误，但是由于情况的稀有性或修复此错误所需的更改量，理论上它的优先级可能会变得很低。

严重程度实际上取决于您生产的产品类型和业务状况。在我的上一份工作中，我们为大型集装箱/游轮制造了自动驾驶仪，因此我们的严谨性是

• 很高-前方冰山！哦，等等，看起来对船的控制权可能丢失了，或者谁能控制住权可能会造成混淆！有人想出如何使这艘船转身！！！
• 高-顾客接受投诉，游轮转得太快，顾客倒酒。在解决此问题之前，我们无法使用您的东西！
• 中-可以提高客户/现场技术人员的易用性的功能。可以节省人们时间的东西。
• 低-化妆品

我认为，如果您制作的是网络应用，并且业务模型/客户群完全不同，则严重性/优先级的水平将大不相同。最终，这取决于您的客户的期望以及他们对此问题的生气:)

我使用的严重性标准：

• 它是否阻止了用户从程序中获得想要的东西？
• 用户执行典型任务是否可见？
• 它会泄露明智的信息还是允许执行未经授权的操作？

特定漏洞的严重程度是这些问题的综合。

通过烦扰因素对错误进行分类，这会阻止人们购买该软件。不会影响运输或给用户带来实际麻烦的错误，每次我遇到该错误时，都会使我讨厌。最终您失去了一个用户和部分收入。

现在，如果您将这种错误与用户界面结合在一起而进行了更改，而用户界面没有明显的原因并且对用户没有明显的好处，那么您将获得绝对的胜利，这将使人们讨厌您的软件。

不允许这种情况发生。不要附带会导致客户认为您不给****的错误。