Not as a metric, but it basically becomes one, like with Fedramp.
You need to fix also moderate/low CVEs within a certain time frame.
So CVE count becomes relevant, because the target is zero, although it doesn't mandate "zero CVEs" but that's finally what the desired outcome is.
It's basically unrealistic to ignore that number, because it's unlikely that you have a steady 1000 CVEs (that are being continuously fixed and new ones discovered), but more like "a few exceptions".
PCI doesn’t mention cve by name but does require vulnerability accounting and requires action if they are found, the action required driven by severity. I could see a (poor) control being written around keeping counts down.
I've met good auditors. I mean, I've met terrible auditors too, but the good ones stick in my mind more because they ask insightful questions about my software or sometimes software in general. It's a problem that this is often seen as a box ticking exercise, done right it can be a really great opportunity to improve but so often instead the priority is to get the paperwork done and too bad if you achieved nothing by it.
If we're talking about actual auditors, not tech consultants who call themselves auditors but people actually trained as auditors, I'd take it as a bad sign if they asked a bunch of specific unbidden questions about software details. That's not the job.
You need to fix also moderate/low CVEs within a certain time frame.
So CVE count becomes relevant, because the target is zero, although it doesn't mandate "zero CVEs" but that's finally what the desired outcome is.
It's basically unrealistic to ignore that number, because it's unlikely that you have a steady 1000 CVEs (that are being continuously fixed and new ones discovered), but more like "a few exceptions".