proposal: support dependency cooldown in Go tooling

[dbohdan]

Proposal Details

Background

Supply chain attacks on open-source software dependencies have become a regular occurrence. Go already takes measures against supply chain attacks. While Go libraries aren't a common target, this year GitLab detected one attack that involved typosquatting.

The idea of a "dependency cooldown" is to not download dependencies that are too new. The theory behind it is that most supply chain attacks in their active phase are detected quickly, so they are possible to avoid by waiting. The blog post "We should all be using dependency cooldowns" presents empirical evidence in favor of this based on recent (non-Go) attacks.

Proposal

When a cooldown is configured, commands like go get and go mod tidy would only consider dependency versions that are at least N days, weeks, or months old.

This could be controlled with an environment variable:

GOCOOLDOWN=15d go mod tidy

With this setting, Go would skip any dependency versions published less than 15 days ago when resolving dependencies.

Alternatives

The primary alternative is to use external tools like Dependabot that already support this.

Open questions

The design naturally invites questions about scope:

1. Should this apply to all dependencies equally?
2. Should the cooldown interval be set in the development environment or in go.mod?

[gabyhelp]

Related Issues

• proposal: package tools #37166 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

This is probably something best left to external tools which can combine multiple information feeds to make a decision for upgrades. Note that in Go there isn't a great source of when a package is published since there's not a registry you publish to.
Also, the design of MVS means it should be rare for you to be running the latest versions of deep dependencies, which is where a lot of these attacks are from.

[dbohdan]

This is fair enough. It may warrant a new external CLI tool in addition to bots. It could wrap the go command and offer a pre-commit check that uses external data to warn about new dependencies.

[Jorropo]

I think this is a fair thing to discuss, even tho we will follow go.mod & go.sum when possible,
I believe go mod tidy or go get could benefit from such flag.

How would the implementation work tho ?
If let's say for git tags we could use the timestamp in the tag but then an attacker could just back-date them.

What if go.mod is newer than the cooldown ?
Let's say a coworker update a lib to something released 3 days ago ?