If i calculated all right with the official calculator you are using CVSSv3.0, there is CVSSv3.1 available whichs gives minimal different temporal values (I calculated my values with CVSSv3.1):
base: 6.3
- Stage: 5.4
- Stage: 5.7
- Stage: 5.6
In the company i am working we only rely on the base score to prioritize vulnerability patching, because this value says, how severy the vulnerability is. The problem with the tmeporal score is, that it represents a kind of overall view of vulnerabilities.
So a vulnerability is more critical, if the poc is available and confirmed, than a vulnerability with an unconfirmed poc, because you are not shure, if the poc really works. So if the poc is confirmed it increases the value, the workaround decreases a bit (without workaround it would be 5.9 instead of 5.7, so here you can see how valuable the 'confirmed' is)
The official patch decreases the value, as expected.
The guidance I've been given states that the exploit maturity and report confidence remain unchanged. So according to that and to CVSS, you’d have been safer sitting on yer ass at stage 1 above and doing nothing?
No. From the occicial site:
The Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence in the description of a vulnerability.
It does not lower the criticality of the vulnerability, it rather puts the vulnerability into a context of available pocs and fixes. For me this only makes sense in an overall view of vulnerabilities in the world, but not for a company to prioritize fixing.
As example: if you have a vulnerability which has a confirmed poc and a fix, the temporal score lowers the overall score. It looks like the vulnerability is not that high, but that's only true, if you compare to a similar vulnerability with confirmed poc and without fix. For a company with both vulnerabilities, these are (for me) equal severe, because both have confirmed pocs. The point is, i know that i can install the one fix, but until i install this, it's not better for me that a fix is available. For me it sometimes can be even worse, if a patch is available and do not install, because with a patch it is easier to create a exploit.
If, after you’ve released your patch, exploit maturity and report confidence are meant to drop (to unproven and unknown respectively), that’d make sense as the attackers now have to start from scratch.
No. The vulnerability is existing in a specific version of your software, so the vulnerability still exists in this software version and is fixed in the next. So the exploit maturity etc. remain the same, because these values rely on the old version. In the new version the vulnerability is not existing, so you do not have to reduce any values for this.
To make it clear, the temporal score does not lower the severity of a vulnerability for you, it helps comparing vulnerabilities in general.
Edit:
The score, especially the temp score, is not build for the vendor, instead it is build for the user. Often the score is build with help of the vendor. Of course a vendor can priotize with cvss score, too.
The main thin to your question from the documentation of "report confidence":
The more a vulnerability is validated by the vendor or other reputable sources, the higher the score.
and from the "confirmed" status:
Source code is available to independently verify the assertions of the research, or the author or vendor of the affected code has confirmed the presence of the vulnerability.
The point is, that the "confirmed" state is given, if you can prove it (reproducable), or get it confirmed by the vendor. As a vendor you have the best position to adjust the temp. score, so you should update the official temp. score if you know, that the vulnerability is there and you have a working exploit (leads to E:/F for functional exploit). If the exploit existing
and details are widely available
it leads to E:H (here it means publicaly). But in both cases you have RC:C
