Feat: Add Patched Version to Vulnerabilities summary

[felickz]

Adds Patched Version to the Vulnerabilities to provide developers with some actionable feedback as to what can be done to resolve blocking PRs (implements #1041)

• Add patched version column to vulnerability summary table (Opt in currently)
• Extract patch version type checking into helper function for clarity
• Support multiple version ranges per package in advisory lookup
• Optimize API calls to use Set and Promise.all for better performance
• Guard as a Cloud only feature - no advisory database API call is available to GitHub Enterprise Server

Handle scenarios where the same package has multiple vulnerable version ranges with different patched versions (e.g., GHSA-gwq6-fmvp-qp68 with .NET packages).

• Store all vulnerability entries with version ranges, not just one per ecosystem
• Implement version range matching to select correct patch version
• Match package by ecosystem, name, AND version range
• Add comprehensive test for multi-range scenario

Added detailed debug logging to help troubleshoot patch version issues: Add comprehensive debug logging for patch version lookup

• Log when fetching advisory data from API
• Log number of vulnerability entries found
• Log each patch info entry added with details
• Log when no patch version is found
• Log during lookup phase with package details
• Log when patch version is found vs not found
• Log available entries when no match is found

To test:

      - name: 'Dependency Review - felickz patched version testing'
        uses: actions/dependency-review-action@539c79be65db3311f1eac7aa4a8d31840f738971 #aka forks-felickz:main   
        with:
          comment-summary-in-pr: always          

[Copilot]

Pull request overview

Adds “Patched Version” to the Vulnerabilities summary by looking up advisory patch data from the GitHub Advisories API and selecting the correct patched version for each vulnerable package/version (including cases with multiple vulnerable ranges).

Changes:

• Fetch advisory vulnerability entries in parallel and map them to a per-advisory patch lookup.
• Add “Patched Version” as a new column in the vulnerabilities summary table.
• Add Jest tests for patched-version rendering and multi-range advisory scenarios.

Reviewed changes

Copilot reviewed 4 out of 7 changed files in this pull request and generated 4 comments.

File	Description
src/summary.ts	Fetches advisory data, computes patched version per vulnerability, and renders the new “Patched Version” column.
src/main.ts	Awaits the now-async vulnerabilities summary renderer.
scripts/create_summary.ts	Awaits the now-async vulnerabilities summary renderer in the script entrypoint.
tests/summary.test.ts	Mocks the advisory API and adds tests for patched-version behavior (including multi-range and a real-world NuGet example).

Comments suppressed due to low confidence (1)

src/summary.ts:272

• Filtering vulnerableChanges for every manifest makes this O(M*N). Since this PR already touches related code and imports helpers from ./utils, it would be more efficient to pre-group once (e.g., build a Map<manifest, Changes> up front) and iterate the grouped results.

  for (const manifest of manifests) {
    for (const change of vulnerableChanges.filter(
      pkg => pkg.manifest === manifest
    )) {

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 8 changed files in this pull request and generated 11 comments.

Comments suppressed due to low confidence (2)

src/summary.ts:272

• rows is allocated once outside the for (const manifest of manifests) loop and never cleared, so the table for the 2nd (and later) manifests will include rows from earlier manifests. Move const rows: SummaryTableRow[] = [] inside the manifest loop (or reset it at the start of each manifest) so each manifest table only contains its own rows.

  for (const manifest of manifests) {
    for (const change of vulnerableChanges.filter(
      pkg => pkg.manifest === manifest
    )) {

src/summary.ts:339

• rows is allocated once outside the for (const manifest of manifests) loop and never cleared, so the table for the 2nd (and later) manifests will include rows from earlier manifests. Move const rows: SummaryTableRow[] = [] inside the manifest loop (or reset it at the start of each manifest) so each manifest table only contains its own rows.

    core.summary.addHeading(`<em>${manifest}</em>`, 4).addTable([
      [
        {data: 'Name', header: true},
        {data: 'Version', header: true},
        {data: 'Vulnerability', header: true},
        {data: 'Severity', header: true},
        {data: 'Patched Version', header: true}
      ],
      ...rows
    ])
  }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 8 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 8 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ahpook]

Nice addition @felickz - this looks very thorough and i appreciate all the test coverage. I think you need to drop the dist/* files from your branch though as they will be generated upon release, and unfortunately introduce unresolvable merge conflicts if they're still in the PR. I am working on a patch release right now, and I think this would go nicely with a couple of other PRs in a new feature release (v4.9), up next.

[ahpook]

Re-ping on this @felickz - would love to get this in, could you please drop the dist/* files from your branch to avoid merge conflicts?

[ahpook]

Nice @felickz , thanks for adding this behind a config option. I think that reduces the risk of merging and makes this a very clean addition. We can look at making show_patched_versions: true the default on a future major-version release.

[ahpook]

Great, thanks for bearing with all the back and forth on this!