Because severity is usually a general measure (eg, to use an example from application security: XSS is usually a sev:med), but priority can be subject to a bunch of forces not known to the person who found the bug. You might find eg an exploitable dangerouslySetInnerHTML, but if that’s on a separate domain (in the authn and the origin sense), in some back-office page somewhere, it may not be particularly exploitable, the impact of exploitation may not be particularly high, and so may justify a lower priority. Meanwhile, lack of CSRF protection on an endpoint that half the internet is engaged with may be a higher priority, even though CSRF is typically lower sev.
Maybe the page with the bad bug is getting shut down next month anyway and we’re just accelerating that instead. Doesn’t make the bug any less bad: definitely makes fixing it less of a priority.
(In hindsight I should have used SSRF or SQLi or RCE as examples of the former style bug and XSS as the lower severity of the two to emphasize the difference.)
Well, good, but if customer impact is the only metric that counts, what relevance does severity have?
If you find a RCE vulnerability that never affects your customer, and how much it affects your customer is the only metric by which bugs are prioritized, what relevant information does severity add?
Either it affects your customer, in which case you prioritize a bug's fix by its severity (i.e. simply by how much it affects your customer), or it doesn't affect your customer, in which case you prioritize is by... how much it affects your customer. Either way, you end up prioritizing bugs just by customer impact, which is either measured by the bug's severity (if it affects a customer), or zero (if it doesn't, regardless of severity).
Just to be clear, I am absolutely not arguing that severity shouldn't be tracked, I'm arguing against the idea that purely functional customer requirements should be the only criteria used for prioritizing bugfixes and development tasks.
It's certainly true that "your job is not to build the perfect/best product, it's to build the one your client want and is willing to pay money for", as the parent mentioned. But it's also your responsibility to do the building in a sustainable manner.
Decoupling severity from priority is a great way to run a codebase into the ground. RCEs that are unexploitable today will be expoitable five years from now, after sufficient requirement changes accrue -- and at some point in the future, you're going to have to deal with five years' worth of previously unexploitable RCEs that you have to fix yesterday.
Edit: I've worked for several years on two codebases where customer impact has been the primary metric used for bug prioritization for 15+ years and 7+ years respectively. Both were absolute catastrophes. You could literally crash devices by blowing hot air on them (literally, there was an out-of-bounds access bug in the code that handled overheating alerts and they crashed after a few alerts). An entire team was there just to put out fires, virtually all of which were known bugs that had at one point been deferred because they had "no customer impact" -- until they did.
It's been a very useful experience. Disentangling these things is a very useful skill to have for an expensive, and highly sought-after on the market.
You need both because severity and priority aren't necessarily set by the same people who have the same information. They're (of course) not completely orthogonal: generally there's a 1:1 map between severities and priorities. I think we're in violent agreement: severity is also a close proxy for how much I think you should care about something. (We don't assign severities to hardening tasks, since they're, well, hardening, not bugs--but there are plenty of hardening tasks that I think are more important than vulnerabilities and should be prioritized sooner. E.g. "unencrypted EBS volume" is a finding I will totally let you ignore, but I will also be on your case every day if you're not using aws-vault.)
So, to rephrase: you need both precisely because that's often the way you can even start having the prioritization conversation.
We're in perfectly peaceful agreement, it's not even violent :-). As I mentioned in my post above:
> Just to be clear, I am absolutely not arguing that severity shouldn't be tracked, I'm arguing against the idea that purely functional customer requirements should be the only criteria used for prioritizing bugfixes and development tasks.
Maybe the page with the bad bug is getting shut down next month anyway and we’re just accelerating that instead. Doesn’t make the bug any less bad: definitely makes fixing it less of a priority.
(In hindsight I should have used SSRF or SQLi or RCE as examples of the former style bug and XSS as the lower severity of the two to emphasize the difference.)