Is the distinction between "public exploit" and "private exploit" significant to anyone's decision process?

[ahouseholder]

This thread is prompted by an in-house conversation about whether Exploitation:PoC is valid when an exploit is exclusive to one or more paywalled tools but not in any of the free/public ones. I wanted to open it up to the community to get a broader set of opinions.

As written, I think the answer is that we intended Exploitation:PoC to be about public, open, effectively free to acquire, exploits. See also #352 (update PoC name to Public PoC) and #353 (update PoC description) for an issue to clarify this.

However, it begs the question of whether there exist relevant decision processes that make a distinction between the states of the world where:

• PoC is accurate (public, open, "free")
• PoC isn't accurate but no attacks have been reported/observed (the exploit is paywalled but known to be available to subscribers)
• Active is accurate as written

It's the middle one vs the ones on either side that I'm asking about. If there's no significant difference in outcomes then maybe it's not worth worrying about. What I'd be interested in is examples of decision processes where the "private poc" option was the decisive factor in some decision: what decision, context, stakeholder role(s), etc. does this show up for?

Given the similarity between SSVC's Exploitation and CVSSv4's Exploit Maturity, I wonder if this had been considered in the CVSS discussions and if there was rationale for leaving it out.

[j---]

There are more variations on the possible state of the world than this, I expect.

But narrowly, my intent is that any privately held exploit code is "unreported."

I think that makes the "state of exploitation" decision point not useful for, for example, a bug bounty program trying to classify the sophistication of a submitted vul finding. Zerodium clearly has some criteria in mind for that (https://zerodium.com/program.html), though, and how it influences payouts, and I don't think we want to get into that scope without already being in conversation with a bug bounty platform. So just saying I think the scope of state of exploitation is restricted to PSIRTs triaging internally, CSIRTs, and deployers.

So is the question here that if a CSIRT buys a subscription to an expensive pen testing tool suite and sees a PoC for a CVE in that tool suite, they want a way to escalate their community's response? I suspect if that pen testing suite has the CVE in an automated attack chain, if you look for IDS signatures against that attack and install them in your infrastructure you will get the evidence you need to go to Attacked pretty quickly.

CVSS lumps these differently than SSVC.
CVSS puts "Active" as active exploitation or a module in pen testing tools (it doesn't say public or private, though the example is a public one, Metasploit).
CVSS v3 had a "proof of concept" option within "Exploit Code Maturity" that basically meant private PoC. This metric group in CVSS v3 had more considerations that would apply to the bug bounty payoff sort of consideration. Is there actually code or not is one of the options -- privately held, just reported to you the vendor, not in an exploit kit or anything. This is more used in determining whether or not there is a vulnerability during initial analysis, not in triaging attention to mitigation deployments.

CVSSv4 seems to move away from this. But in CVSS v4, the inclusion of modules that can exploit the CVE in a private pen testing tool kit meet the "active" definition. It's only a gap in SSVC.

But given that https://www.coresecurity.com/core-labs/exploits exists as a public list of the CVEs that CORE, for example, has in it's private pen testing product, I think this point is moot. Since that list is public, if someone wants to, they can just say that anything on that list counts as public PoC in the same way as metasploit does.

I think that would turn this into a data mapping question, rather than a decision point design question? Which feels right to me.

[ahouseholder]

I think that would turn this into a data mapping question, rather than a decision point design question? Which feels right to me.

Agreed. I think given #442 we can set this aside for now, always ok to reopen an issue if we want to make a more specific change later.