New VersionDistance policy to check and report outdated components

[walterdeboer]

I'm working on a new VersionDistance policy to check and report outdated components (#2537) I'd like some feedback or second thoughts on this. My aim is to report outdated components, meaning components with a newer (stable, see #2501) version available.

I first compute the version distance between the current and latest version, e.g. current = 1.0.0, latest = 2.1.1 => version distance is 1.?.?. Question marks for the minor and patch numbers, since they don't mean anything when the major version already differs. So the distance between 2.1.1 and 2.2.2 is 0.1.?, skipping only the patch number since the major numbers are the same.

When the version distance is know, it can be compared with a version distance in a policy: "greater than 1.?.?" would report al components having updates available of at least two major numbers.

I'm having doubts on how intuitive this is? How could it be improved? The VersionDistance concept is not a defacto standard. Does something like this excists already I don't know of? How do other SCA tools handle this? Do others see the need for this policy? Or is it already supported in another way?

See #2537

N.B. it also supports epoch numbers for linux packages, but lets leave that out for now

[syalioune]

Hello @walterdeboer

I'm not aware of any norms around semver arithmetics and I find it quite comprehensive. I can also see the use case for this kind of policy.

However, the most important thing will be UX on the frontend. I don't think using directly the 1.?.? syntax will do it.
I suggest a condition form with four controls :

• Subject type (select input) : Version distance
• Operator (select input) : >, <, = , >=, <=
• Version segment (select input) : major, minor, patch
• distance (numerical input) : user supplied

It can then be translated automatically to the syntax you propose.

[walterdeboer]

Thanks! I didn't give the UX much thought, but that makes sence. I'll dive into that next.

I'was also thinking of combining the VersionDistances, eg 1:1:0.0 meaning one epoch difference or one major difference, but this would not make sense in the UX I guess...

I'll have a look at the frontend code first :-)

[stevespringett]

Most ecosystems do not use semver. Even node.js has their own specific version of semver they use and is recognized by PURL VERS as a unique versioning system.

We also need to take into consideration that sometimes a version distance will not make sense due to marketing teams making up versions as they go along. For example, Windows 95 vs Windows 11 where 11 is newer than 95.

[syalioune]

This policy evaluator could maybe perform a precheck and only operate on components having a proper semver scheme ?
Naming the policy subject Semver version distance could also disambiguate

[walterdeboer]

Thanks for your thoughts and considerations!

Calculating a version distance also works on non-semver versions most of the time. The difference between 1.2.3.4.5.Final and 1.2.3.7.8.Release is also 0.0.0, it just ignores the extra parts. The problem starts when alphanumeric charachters are used in the version, e.g. 2.1a. This will throw a NumberFormatException, and the Policy will report nothing.

NPM also knows of version ranges, but I asume the SBOM contains the actual version used in the release, instead of the possible range at compile time. When this is true, I don't see any problems here.

Windows 95 is a false positive, but also Microsoft uses sensible version schemes under the hood.

False positives will only result in higher versions not being reported. I think this does not outweght the benifits gained by reporting the latest versions for all other components. I guess it'll work 95% of the time. When false positives is not an option, then restricting it to semver will certainly work

[walterdeboer]

It would also be possible to check the repository type first and deside on the version distance strategy from there

[walterdeboer]

If updated the frontend code so you can try it:
DependencyTrack/frontend#432

It needs:
#2537

Current violations for the frontend:

Work in progress...