Add Support For Outdated Dependency Version Identification

[stevespringett]

This enhancement may supercede or replace #46, and may provide some visibility into #8.

Just like projects and components have findings for identified vulnerabilities, this enhancement will add support for detecting older versions of dependencies and apply a risk rating to that as well.

Add support for popular ecosystems that use a package manager and which can be accessed via a REST API without having to support the native tool.

Java / Maven Central

• http://search.maven.org/#api
• http://search.maven.org/solrsearch/select?q=g:%22us.springett%22+AND+a:%22alpine%22&rows=1&wt=json

Ruby / RubyGems

• http://guides.rubygems.org/rubygems-org-api/
• Note: Respect rate limits

Node.js / NPM

• https://registry.npmjs.org/bootstrap/
• https://registry.npmjs.org/-/package/bootstrap/dist-tags

PHP Composer

• https://packagist.org/apidoc

The detection of outdated versions should occur similar to that of vulnerability detection. Upon the initial creation of a new component, perform a check. Then, every 24 hours perform a recheck for each component based on the ecosystem it belongs / use purl for identification.

[stevespringett]

Question for the community: Dependency-Track v3.1 (or 3.2) will have the ability to identify out-of-date components using Maven Central, NPM, and RubyGems as sources of truth. The idea is to highlight potential risk of using out-of-date components with the assignment of a risk score.

Currently Inherited Risk Score (IRS) is calculated by:
((critical * 10) + (high * 5) + (medium * 3) + (low * 1))

Where the number of critical, high, medium, and low severity vulnerabilities are weighted.

What is the ideal algorithm for calculating a risk score for out-of-date components? Should they be part of IRS? Should the risk metrics be separate? What type of visualization would you like to see for this data? Please share your thoughts.

[stevespringett]

At this point, ruby, npm, and maven resolution all work as designed. The latest version of components are being documented based on the ecosystem, component group and name.

UI metaphors do not yet exist, nor do metrics for calculating risk.

[eoftedal]

I would like to see it separate or policy based
(Policy: specify a weight)

[stevespringett]

The UI (and REST resources) now provide easy ways to determine if a component is up-to-date or not. This feature requires accurate PackageURLs for components needing to be tracked. Closing. Add support for configurable policies in a future release. #83

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.