Sollten erkannte Schwachstellen in alten Commits behoben werden?

Eines meiner Projekte auf GitHub hat eine Sicherheitsanfälligkeitswarnung erhalten, in diesem Fall von mittlerer Schwere.

Die Sicherheitsanfälligkeit wurde in Abhängigkeit von einer alten Version des Codes erkannt. Aktuelle Versionen verwenden diese Abhängigkeit nicht mehr. Dennoch können alte Commits möglicherweise ausgecheckt und ausgeführt werden, und die Anwendung zu Taten der Verwundbarkeit eröffnen.

Ist es aus Sicht der Softwareentwicklung ratsam, die alten Commits zu ändern, dh die jetzt nicht verwendete Abhängigkeit auf eine neuere Version zu aktualisieren, die den Fix für die Sicherheitsanfälligkeit enthält? Oder besser, um den Commit-Verlauf intakt zu halten?

Ich sehe hier zwei realisierbare Optionen.

Geben Sie zunächst eine Patch-Version der problematischen Version frei. Wenn die problematische Version beispielsweise Version 3.3 ist und Sie Version 5.1 verwenden, können Sie eine Version 3.3.1 veröffentlichen, mit der die Sicherheitsanfälligkeit behoben werden kann. Auf diese Weise können Benutzer, die (aus einer Reihe von Gründen) kein Upgrade auf Hauptversionen durchführen können, das Update für die Sicherheitsanfälligkeit erhalten.

Zweitens nichts tun. Es ist eine alte Version der Software, und Sie haben neuere Versionen, die beibehalten werden und nicht über die Sicherheitsanfälligkeit verfügen. Benutzer, denen Sicherheit am Herzen liegt, sollten eine neuere Version ausführen.

Welche Option ist am besten? Es hängt davon ab, ob. Es macht jedoch wenig Sinn, zurück zu gehen und alte Commits zu überarbeiten (Geschichte neu zu schreiben). Und für einige Benutzer (insbesondere in einer regulierten Umgebung) wären viele Probleme damit. Für eine weit verbreitete Verwendung Ihrer Software sollte das Umschreiben des Verlaufs vermieden werden.

Erwägen:

• Wie schwerwiegend ist die Sicherheitsanfälligkeit?
• Wie verbreitet ist die Version der Sicherheitsanfälligkeit?
• Haben Sie die Möglichkeit, weiterhin alte Versionen zu unterstützen - werden Sie dies als Präzedenzfall verwalten?

Normalerweise wird ein Versionskontrollsystem verwendet, um den Verlauf aufzuzeichnen. bieten eine genaue Ansicht des Status des Codes zu einem bestimmten Zeitpunkt. Das Ergebnis des Auscheckens und Erstellens einer alten Version sollte diese Version, Fehler und alles sein. Einige Systeme bieten reproduzierbare Builds : Es sollte möglich sein, eine genau identische Binärdatei zu einem alten Build zu generieren.

Die meisten Versionskontrollsysteme erlauben kein Umschreiben des Verlaufs, außer unter extremen Umständen wie dem Löschen von Informationen, die beim Einchecken zu einer Haftung führen können. Es ist ungewöhnlich und ein bisschen "ketzerisch", dass Git dies ermöglicht.

Die Dokumentation gibt zu, dass das Umschreiben des Verlaufs Risiken birgt .

Darüber hinaus handelt es sich um ein verteiltes Versionskontrollsystem - das Umschreiben wirkt sich nicht auf bereits geklonte Repositorys aus!

Ich würde vorschlagen, dies niemals zu tun, es sei denn, es wird etwas entfernt, das kürzlich festgeschrieben wurde und das vertraulich behandelt werden sollte - persönliche Daten, Verschlüsselungsschlüssel, so etwas.

Es scheint, dass selbst die derzeit akzeptierte Antwort den Teil Ihrer Frage nicht wirklich anspricht, wie Sie vermeiden können, dass jemand versehentlich auf ein altes Commit zugreift, diesen älteren Status der Codebasis in einem neuen Zweig verwendet und so erneut eine alte Sicherheitsanfälligkeit einführt.

IMHO ist der einzig richtige Weg, dies zu adressieren:

• indem Sie Fehlerbehebungen sowie Schwachstellenbehebungen streng im Dokument "Versionshinweise" (oder "Änderungsprotokoll") des Systems dokumentieren

• Indem Sie sicherstellen, dass alle Entwickler, die auf ältere Versionen des Codes zugreifen, die Versionshinweise lesen , überprüfen Sie, welche Probleme in der Version des Codes behoben wurden, die nach der Version kam, die sie verwenden werden

Wenn Sie eine ältere Version wiederverwenden oder von einer älteren Version der Codebasis verzweigen, liegt es eindeutig in der Verantwortung der Entwickler, dies nicht blind zu tun. Es ist klar, dass sie die bereits behobenen Fehler und Schwachstellen überprüfen müssen, um sie nicht erneut einzuführen. Das VCS-Protokoll ist jedoch kein wirklich guter Ort, um diese Art von Informationen zu finden, da normalerweise alle Arten von Änderungen auf einer zu niedrigen Abstraktionsebene erwähnt werden.

Versionshinweise sollten jedoch einen Abschnitt "Neue Funktionen" sowie einen Abschnitt "Probleme gelöst" enthalten. Und letzteres sollte der erste Ort sein, den Sie überprüfen müssen, bevor Sie von einer älteren Version verzweigen.

Angenommen, 3.5 ist anfällig, 3.6 jedoch nicht. Sie könnten 3.5.1 ohne die Sicherheitsanfälligkeit erstellen. Aber das ist Arbeit und nicht sehr nützlich, da die Leute entweder ihre Version aktualisieren oder nicht, so dass es unwahrscheinlich ist, dass jemand 3.5.1 verwenden wird.