Hi, I want to start a discussion about our dependency upgrade policy for
active development.

Our current dependency upgrade (mostly for Java, but Python should be
included too) is a bit spontaneous. People find that a dependency has a new
version available and we just do the upgrade.

This raises concerns about potential supply chain attacks. We already
established a few sets of rules (including pinning the github action
versions) to avoid the supply chain attack, but manually upgrading the
dependency version too eagerly could also be risky.

It normally takes time for a bad release to be recognized, so I think we
should set a buffer time before upgrading to the latest version. For
example, we can wait a week or two after the latest release before we set
our development dependency to it. This could reduce the possibility of
being impacted by malicious releases, or just give them enough time to fix
their own severe bugs.

The cost for this policy is very low - it barely impacts us if we can’t use
the “latest” version of dependencies.

Of course, there should be exceptions when dependency upgrades include
security fixes for known vulnerabilities; we should upgrade as fast as
possible.

Tian

Reply via email to