Investigate adding vulnerable software versions to module metadata

[dwelch-r7]

Summary

Let's investigate the work required to add the vulnerable software versions modules use in their check methods (and elsewhere) into the module metadata and how we can utilise that to enhance things like the MCP server.

Basic example

In the metadata section of a module we could have a section like

VulnerableVersions => [
    {'min': 1.2.3, max: '1.2.5'},
    {'min': 2.2.3, max: '2.2.9'} # Optional have multiple ranges
]

Motivation

We can have generic vulnerability checks if we can get the version number reducing duplicate code across modules and then we'd have the metadata available for other use cases such as the RPC and MCP server and search

[kx7m2qd]

I can take this on if nobody's already working on it.

Rough idea for the metadata:

VulnerableVersions' => [
  { 'min' => '1.2.3', 'max' => '1.2.5' },
  { 'min' => '2.2.3', 'max' => '2.2.9' }
]

For accessing it, probably worth following the same pattern being discussed for VulnerableEnvironment over in #21625 an accessor like #vulnerable_versions off module_info instead of calling send directly. module_info.rb already has the merge_* normalization stuff, so I'd wrap this in a Struct with some basic validation rather than passing raw hashes around.

Then a shared helper like version_vulnerable?(detected_version) modules can call from check instead of everyone rolling their own comparison logic.

RPC/MCP exposure once the metadata exists seems like a natural follow-up PR rather than doing it all at once.

Is the Struct approach the right direction here, or is there a pattern you'd rather I follow? Can start with a PoC on one module first if that's easier to review.

[dwelch-r7]

@kx7m2qd No one is working on this just yet but we need to spend a bit more time to flesh this out before we can really have anyone working on it since it will have aspects that need to integrate with the paid product, this was more so just a placeholder so we didn't forget about it

[kx7m2qd]

Got it, thanks for the context makes sense given the paid product overlap. I'll keep an eye on this one for whenever it's ready to be picked up. Happy to help flesh out the design/RFC side too if that's useful before it gets to implementation.

In the meantime, if there's anything else open that could use a hand bug fixes, smaller feature work, anything happy to help out. Let me know if something comes to mind.