Allow security advisories file without specifying current package version

[sander102907]

Is your feature request related to a problem? Please describe.

As we are implementing security advisories file for bumping requirements of internal packages, we noticed that the advisories security file works differently than in the v1 task.

In the v2 task, we noticed that you have to specify both the package name and current installed version for it to be considered to be scanned, contrary to the given security advisories example. So for example, a minimal advisories file would look like:

[
  {
    "package": {
      "name": "Contoso.Utils"
      "version": "3.0.0" // <--- !This is required!
    },
    "advisory": {
      "summary": "Contoso.Utils versions before 3.0.1 are vulnerable to input validation issues",
      "identifiers": [
        {
          "type": "CVE",
          "value": "CVE-2023-12345"
        }
      ]
    },
    "vulnerableVersionRange": "< 3.0.1",
    "firstPatchedVersion": {
      "identifier": "3.0.1"
    }
  }
]

If the version is ommitted, or higher or equal than the first patched version, the security vulnerability is filtered by the following function: https://github.com/mburumaxwell/dependabot-azure-devops/blob/075e540e4a34762eb56d86548f326b5e2578c986/packages/paklo/src/github/ghsa.ts#L252-L274

This implies that in the repository that we are scanning with dependabot, we firstly have to check ourselves whether the internal package is used and which version is installed, and use that to build the security adviories file before running dependabot. In the v1 task, we could simply indicate a security advisories file containing all names and vulnerable versions of internal packages and dependabot would figure out the rest (i.e. scan the dependencies of the repository and see which versions are installed and whether they need to be bumped).

Describe the solution you'd like

Could the code be rewritten such that in the new v2 task, you do not have to specify the installed version, but it is determined by dependabot whether the indicated security vulnerability in the file (based on the package name and first patched version) is relevant for the installed dependencies, just like in the v1 task?

Describe alternatives you've considered

No response

Additional context

No response