Component version can't be compared to affected range of GLAD advisories
Problem to solve
In some cases it's not possible to determine if the version of a project dependency is in the affected range of an advisory published on GLAD.
- The version is unknown.
- The version is invalid.
- Parsing the version or comparing it to the range fails.
- The "version" is a branch, like
dev-master
or1.5.x
. - The version is ambiguous. It doesn't follow the specifications of the language or package manager, and proceeding with strict comparison rules might not give the correct answer. For instance,
20241502
seems to be a timestamp, and so it shouldn't compared to2
, for instance. - The versions being compared (i.e. in the affected range and in the project dependency) only differ by the git commit they reference. For instance, without accessing the git repo we can't tell if
1.0.0-master.c9f1ed4
matches<1.0.0-master.c910c4d
. See gitlab-org/ruby/gems/semver_dialects!38 (diffs, comment 1778866540) -
-number
is being compared to.number
in a syntax where they're equivalent (Maven), but usage shows that they're not. Example:3.2-32-1a7dede
shouldn't be strictly compared to3.2.1
. See gitlab-org/ruby/gems/semver_dialects!36 (diffs, comment 1785072461)
Proposal
TBD
Proposal A
-
When the "version" isn't comparable, warn users during SBOM ingestion, and skip the component when doing scans. Examples: no version, invalid version, or version branch. The UX is TBD.
-
When the major, minor, and patch numbers can be compared but a prerelease tag/identifier can't, err on the side of caution: mark the dependency as affected, and communicate to users that this is a partial match. The UX is TBD.
Proposal B
- When a version can't be compared to the affected, always mark it as affected.
- Communicate a confident level to users through the UI.
- If the "version" isn't comparable at all, the confidence is low.
- If the version can be partially compared (i.e. x.y.z is in range but prerelease identifiers might not be), then the confidence is medium.
- If the version can be compared and it's in range, then the confidence is high.
Proposal C
Document the current behavior, and add a warning to the docs.
Proposal D
Do whatever is need to accurately classify the dependency. For instance, get the exact git commit referenced in the lock file, get the ones of the affected and/or fixed versions, and see how they're related. This seems complex and expensive though.