- Introduced 'show-patched-versions' input in action.yml to control visibility of patched versions in vulnerability summaries.
- Updated default configuration and related functions to handle the new option.
- Enhanced tests to verify behavior with and without the patched version column.
* Initial plan
* Initial plan for adding patched versions to vulnerability summary
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Add patched version column to vulnerability summary table
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Optimize API calls to use Set and Promise.all for better performance
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Remove type assertions and optimize ecosystem lookups with normalization
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Extract patch version type checking into helper function for clarity
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Support multiple version ranges per package in advisory lookup
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
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Fix first_patched_version extraction to handle string format
The GitHub Advisory API returns first_patched_version as a simple string
(e.g., "112.0.0"), not an object with an identifier field. Updated
extractPatchVersionId to handle string format primarily while maintaining
backward compatibility with object format.
- Fixed extractPatchVersionId to check for string first
- Updated test mocks to match actual API response format
- Added specific test for RestSharp GHSA-4rr6-2v9v-wcpc case
- Verified with actual API responses from multiple advisories
Fixes issue where patched versions were showing as "N/A" instead of
the actual version number.
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Rebuild dist with patched version fix
The previous fix to extractPatchVersionId wasn't deployed because the dist/
folder (compiled JavaScript) wasn't rebuilt. This commit rebuilds and packages
the action with npm run build && npm run package to include the fix.
Changes in dist/:
- Updated extractPatchVersionId to handle string format first
- Includes all async vulnerability summary logic with API calls
- Properly extracts patched versions from GitHub Advisory API
This should resolve the issue where patched versions showed as "N/A" in
actual GitHub Actions runs.
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Add comprehensive debug logging for patch version lookup
Added detailed debug logging to help troubleshoot patch version issues:
- 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
This will make it much easier to diagnose issues in GitHub Actions debug mode.
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
The allow-licenses list is expected (and documented) to be a list of
SPDX license IDs (LicenseRefs are also valid). If someone puts an
expression in the list (e.g. "GPL-3.0-only OR MIT"), it should be
discarded so that the whole list does not become invalid.
Fixes#907
When using the `allow-dependencies-licenses` option, the packages listed
there should be allowed even if they have no license. This wasn't
working because the filtering for allowed dependencies was done
specifically on the list of packages that had licenses, leaving a
separate list (unfiltered) for packages with no licenses. With this
change, we filter out any changes for packages that have been allowed
_before_ we retrieve licenses.
Fixes#889
ClearlyDefined uses the string `OTHER` for the declared license when
a human has reviewed `NOASSERTION` text and found it to be a valid
license, but one without an SPDX identifier. `OTHER`, unlike
`NOASSERTION`, is not valid. With this change, when `OTHER` appears
in a license string, we'll replace it with
`LicenseRef-clearlydefined-OTHER`, which _is_ valid and will allow
the expressions to parse.
There are many packages that are dual-licensed, offering a choice
of licenses (e.g. `MIT OR Apache-2.0`). There are some that include
code from multiple sources and require multiple licenses
(e.g. `MIT AND Apache-2.0`). There are also complex combinations that
can exist for a variety of reasons, such as
`MIT AND (Apache-2.0 OR BSD-3-Clause)`.
The most straightforward approach to handle these is to have an
allow list. As long as the licenses on the allow list can satisfy
the license expression of the package in question, it should pass.
To implement this, I the newest release of spdx-satisfies
which changed the interface to be exactly as described
`satisfies(license, allowList)` (see
https://github.com/jslicense/spdx-satisfies.js/pull/17).
Fixes https://github.com/actions/dependency-review-action/issues/263
This change updates license validation to support full SPDX expressions
(such as 'EPL-1.0 AND LGPL-2.1') in both allow-lists and deny-lists. This
enables the action to correctly validate packages that declare multiple
licenses using SPDX conjunctions like AND/OR, which are common in complex
open-source projects.
Previously, only simple license identifiers were supported, which caused
multi-licensed packages to be improperly flagged as invalid even when
they matched the intent of the allow-list.
The new logic uses `spdx.satisfies()` to evaluate whether a package’s
declared license satisfies any expression in the allow/deny list, and
comprehensive tests have been added to verify behavior for various SPDX
combinations.
This improves compatibility with projects using compound SPDX license
expressions and ensures more accurate license policy enforcement.
