🌱 New check: Mean time to update dependencies

[AdamKorcz]

What kind of change does this PR introduce?

New check

This PR adds a new check with 3 underlying probes to scorecard. The check is an implementation of #2458. In essence, the check works like this:

1. First, it collects a list of all the project's direct dependencies at the time of checking.
2. Then, it calls deps.dev for a list of releases of each dependency.
3. Then, the check assesses whether each dependency is the latest available version according to deps.dev.
4. With the dependencies that are not the latest available version, the check assesses how much time has passed between the release date of the version that the project uses and the release date of the version right after the project uses. For example, if a project uses 1.2.3, and 1.2.4 was available 100 days ago, the check will record 100 days, even though 1.2.5 is the newest available. This is a design part on my end.
5. Finally, the check creates an average of the dependencies that are not the latest available version and scores accordingly.

As such, the check considers the negative findings in a project - the dependencies that have not been updated to its latest version - and the check can be considered one that reports how old a project's dependencies are rather than providing a full picture of how quickly a project updates its dependencies.

A few notes on implementation details:

1. The check relies heavily on osv-scalibr and the deps.dev API which means that any shortcomings in these two libraries will have direct impact on the check. The most significant shortcoming I have found is that the check doesn't always process all dependencies that it finds in a dependency manifest. I haven't debugged this extensively. At the same time, osv-scalibr and deps.dev seem like great sources for this check, and a few edge cases shouldn't in my opinion prevent us from using them. Even if the check doesn't process all dependencies, it is still useful by assessing the majority of a projects dependencies. Initially, I was working with distinct parsers for different lock file types, but this is in my opinion not the way to go. osv-scalibr provides a lot of value out of the box, and given that it is a fairly new library, I think it is fair to expect that it will continue its development.
2. The check only considers direct dependencies. This is a design decision as I don't see a point in evaluating transitive dependencies; The goal of the check is to determine a project's maintenance practices - not to find old dependencies. As such, I have made the decision to give maintainers as much control I could over their score; by only considering direct dependencies, maintainers can simply update their dependencies. If we were to consider transitive dependencies too, maintainers are at the mercy of their direct dependencies to keep their dependencies up to date.

• PR title follows the guidelines defined in our pull request documentation

• Tests for the changes have been added (for bug fixes/features)

Which issue(s) this PR fixes

Fixes #2458

Special notes for your reviewer

I would recommend reading the documentation in the .yml and .yaml files in this PR and testing the check with go run main.go --repo=github.com/owner/repo --checks=MTTUDependencies before reviewing the code.

Does this PR introduce a user-facing change?

For user-facing changes, please add a concise, human-readable release note to
the release-note

(In particular, describe what changes users might need to make in their
application as a result of this pull request.)

[codecov]

Codecov Report

❌ Patch coverage is 80.65173% with 95 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.42%. Comparing base (353ed60) to head (7a015f1).
⚠️ Report is 285 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4868      +/-   ##
==========================================
+ Coverage   66.80%   68.42%   +1.62%     
==========================================
  Files         230      259      +29     
  Lines       16602    16147     -455     
==========================================
- Hits        11091    11049      -42     
+ Misses       4808     4214     -594     
- Partials      703      884     +181     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[spencerschrock]

osv-scalibr and deps.dev seem like great sources for this check

Agreed. Seems like a good usage of existing libraries to do the heavy lifting for us.

If we were to consider transitive dependencies too, maintainers are at the mercy of their direct dependencies to keep their dependencies up to date

Also agree generally.

As such, the check considers the negative findings in a project - the dependencies that have not been updated to its latest version - and the check can be considered one that reports how old a project's dependencies are rather than providing a full picture of how quickly a project updates its dependencies.

Any idea how major versions work with scalibr parsing or version reporting from deps dev? These might be heavier lifts than a minor/patch update.

One reservation with this check is it might encourage upgrade churn for the purpose of churn. But this puts it in a similar boat as the dependency upgrade tool check. For these situational checks, I think we benefit from having the customizability in place and considering what runs by default.

[martincostello]

Something to consider for .NET if it isn't accounted for already, is that libraries may match the dependencies for different target frameworks to the specific major version they target to maximise compatibility.

For example, if a library targets net8.0, net9.0 and net10.0, it may depend on System.Text.Json 8.0.x, 9.0.x and 10.0.x respectively for those target frameworks.

In that scenario, I wouldn't expect a library to be marked down for using 8.0.x and 9.0.x when a 10.0.x is available.

Microsoft will still support the latest patch version of each major version during their support lifetime (which overlap).

For a specific example, if a project was using System.Text.Json@8.0.6, which is the most up-to-date version for .NET 8, it shouldn't be penalised for not using System.Text.Json@9.0.0 which was released on 2024-11-12 (394 days ago as of writing).

---

Separately, there's also the question of whether a library that "pins" a version because it wants to maintain compatibility and leave what the specific version used at runtime is to the consuming application should be penalised for doing so. The example of that would be similar to above, except 8.0.0, 9.0.0 and 10.0.0 would be used indefinitely (unless there was a specific security patch to adopt). That would mean that within 100 days of a major release of .NET (typically ~around the 4th patch, e.g. 10.0.4 assuming a monthly patch release cadence), the dependency would be flagged for the remanining 20 (STS)/32(LTS) months of the major release's support lifetime.