Add a cooldown period for dependabot

[OyvindLGjesdal]

GitHub issue resolved #

I thought maybe it would be useful to hold dependency updates a short period before opening them using cooldowns.

https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference#cooldown-

Some relevant info from the the reference:

The cooldown option is only available for version updates, not security updates.

group/applies-to: default value is: version-updates which I guess is all updates, and the security-updates is the subset which are marked as security-related.

Dependabot checks for updates according to the defined schedule.interval settings.
Dependabot checks for any cooldown settings.
If a dependency’s new release falls within its cooldown period, Dependabot skips updating the version for that dependency.
Dependencies without a cooldown period, or those past their cooldown period, are updated to the latest version as per the configured versioning-strategy setting.
After a cooldown ends for a dependency, Dependabot resumes updating the dependency following the standard update strategy defined in dependabot.yml.

Pull request Description:

Adds a cooldown period for opening dependabot pull requests to allow time for version update incidents to surface. Searched apache org and the usual configuration when configured seems to be in the interval between 4-7 days.

https://github.com/search?q=org%3Aapache+cooldown++path%3A.github&type=code

---

• Tests are included.
• Documentation change and updates are provided for the Apache Jena website
• Commits have been squashed to remove intermediate development commit messages.
• Key commit messages start with the issue number (GH-xxxx)

By submitting this pull request, I acknowledge that I am making a contribution to the Apache Software Foundation under the terms and conditions of the Contributor's Agreement.

---

See the Apache Jena "Contributing" guide.

[rvesse]

Given the current state of supply chain security and pervasive ongoing threats, e.g. see the recent Trivy Action attack that was used to pivot to publishing malicious npm packages, I would tend to be against any delays in receiving notifications about dependency updates.

It looks like security updates are triggered only when publicly disclosed vulnerabilities (CVEs or GH Advisories) are published so if a package developer doesn't disclose vulnerabilities in a timely fashion (or gets the version metadata wrong) there's a window where we could have a vulnerable dependency that we're not being told to update.

I get that frequent Dependabot PRs are draining, especially in an ecosystem like JS which has huge dependency trees, but not sure delaying them is a good choice.

[OyvindLGjesdal]

I was thinking about the trivy incident when creating this PR and that adding a grace period gives time for malicious packages to be discovered, before updating to them. The grace period also as you said has the negative that it could delay a merge of an important PR, if it's not marked as a CVE or GH yet.

For Trivy the malicious packages included the docker registries, the vs-code plugin, the github-action, and also apt.

It is something we have discussed at daytime-job, in regards to how to deal with new packages being poisoned.

Stepsecurity introduced a similar check for npm https://www.stepsecurity.io/blog/introducing-the-npm-package-cooldown-check with a default wait period of 2 days, so maybe 7 days is too much, combined with weekly schedules (monday by default). (Could potentially be 14 days)

[OyvindLGjesdal]

yarn also added an option for guarding against new versions: https://yarnpkg.com/configuration/yarnrc#npmMinimalAgeGate where the example is set to 3 days

If a package version is newer than the minimal age gate, it will not be considered for installation. This can be used to reduce the likelihood of installing compromised packages, or to avoid relying on packages that could still be unpublished (e.g. the npm registry has specific rules for packages less than 3 days old).