Should detected vulnerabilities in old commits be remedied?

Question

One of my projects on GitHub has received a vulnerability alert, in this case of moderate severity.

The vulnerability has been detected in a dependency of an old version of the code. Current versions do not use this dependency anymore. Nevertheless, old commits may potentially be checked out and run, and open up the application to exploits of the vulnerability.

From a software engineering perspective, is it advisable to go back and change the old commits, i.e., update the now unused dependency to a newer version containing the fix to the vulnerability? Or better to keep the commit history intact?

Answer 1

I see two viable options here.

First, release a patch version of the problematic version. For example, if the problematic version is version 3.3 and you're on version 5.1, you can release a 3.3.1 that would address the vulnerability. This would allow users who can't upgrade to major versions (for any number of reasons) to obtain the fix for the vulnerability.

Second, do nothing. It's an old version of the software and you have newer versions that are maintained that do not have the vulnerability. Users who care about security should be running a more recent version.

Which option is best? It depends. However, going back and revising old commits (rewriting history) doesn't make much sense. And for some users (especially in a regulated environment) would have many issues with this. For widespread usage of your software, rewriting history should be avoided.

Consider:

• How severe is the vulnerability?
• How widespread is the version of the vulnerability?
• Do you have the ability to continue to support old versions - will you manage this as a precedent?

Answer 2

Normally a version control system is used to record history; provide an accurate view of the state of the code at a particular time. The result of checking out and building an old version should be that version, bugs and all. Some systems provide reproducible builds: it should be possible to generate an exactly identical binary to an old build.

Most version control systems don't allow rewriting history, except for extreme circumstances like erasing information that might cause liability if checked in. It's unusual and a bit "heretical" that git allows you to do this.

The documentation admits there are risks to rewriting history.

Moreover, it's a distributed version control system - rewriting it does not affect any already cloned repositories!

I would suggest never doing this unless it's to remove something that was recently committed that should have been kept confidential - personal data, encryption keys, that kind of thing.

Answer 3

It seems even the currently accepted answer does not really address the part of your question how to avoid that someone accidentally accesses an old commit, uses that older state of the code base in a new branch and so introduces an old vulnerability again.

IMHO the only way right way to adress this is:

• by documenting any bug fixes as well as vulnerability fixes rigidly in the "release notes" (or "change log") document of the system

• by making sure all devs who access older versions of the code make sure they read the release notes, check which issues have been solved in the version of the code which came after the one they are going to use

When reusing an older version, or branching from an older version of the code base, it is clearly the reponsibility of the devs not to do this blindly. It is clear they must cross-check the already fixed bugs and vulnerabilities, for not introducing them again. The VCS log, however, is not really a good place to find this kind of information, because usually there are all kinds of changes mentioned, on a too low level of abstraction.

Release notes, however, should contain a "new features" section as well as an "issues solved" section. And the latter should be the first place to check before branching from an older version.

Answer 4

Say 3.5 is vulnerable, but 3.6 isn’t. You could produce 3.5.1 without the vulnerability. But that is work and not very useful, because people either update their version or they don’t, so it’s unlikely that anyone will use 3.5.1.