Haruskah kerentanan yang terdeteksi dalam komitmen lama diperbaiki?

Salah satu proyek saya di GitHub telah menerima peringatan kerentanan, dalam hal ini tingkat keparahan sedang.

Kerentanan telah terdeteksi dalam ketergantungan kode versi lama. Versi saat ini tidak menggunakan ketergantungan ini lagi. Namun demikian, komitmen lama mungkin berpotensi diperiksa dan dijalankan, dan membuka aplikasi untuk mengeksploitasi kerentanan.

Dari perspektif rekayasa perangkat lunak, apakah disarankan untuk kembali dan mengubah komitmen lama, yaitu memperbarui ketergantungan yang sekarang tidak digunakan ke versi yang lebih baru yang berisi perbaikan untuk kerentanan? Atau lebih baik untuk menjaga riwayat komit tetap utuh?

Saya melihat dua opsi yang layak di sini.

Pertama, lepaskan versi tambalan dari versi bermasalah. Misalnya, jika versi yang bermasalah adalah versi 3.3 dan Anda berada di versi 5.1, Anda bisa merilis 3.3.1 yang akan membahas kerentanan. Ini akan memungkinkan pengguna yang tidak dapat memutakhirkan ke versi utama (untuk sejumlah alasan) untuk mendapatkan perbaikan untuk kerentanan.

Kedua, jangan lakukan apa pun. Ini adalah versi lama dari perangkat lunak dan Anda memiliki versi yang lebih baru yang dipertahankan yang tidak memiliki kerentanan. Pengguna yang peduli dengan keamanan harus menjalankan versi yang lebih baru.

Opsi mana yang terbaik? Tergantung. Namun, kembali dan merevisi komitmen lama (penulisan ulang sejarah) tidak masuk akal. Dan untuk beberapa pengguna (terutama di lingkungan yang diatur) akan memiliki banyak masalah dengan ini. Untuk penggunaan luas perangkat lunak Anda, penulisan ulang riwayat harus dihindari.

Mempertimbangkan:

• Seberapa parah kerentanannya?
• Seberapa luaskah versi kerentanan?
• Apakah Anda memiliki kemampuan untuk terus mendukung versi lama - akankah Anda mengelola ini sebagai preseden?

Biasanya sistem kontrol versi digunakan untuk merekam sejarah; memberikan pandangan yang akurat tentang status kode pada waktu tertentu. Hasil dari memeriksa dan membangun versi lama harus versi itu, bug dan semua. Beberapa sistem menyediakan build yang dapat direproduksi : harus dimungkinkan untuk menghasilkan biner yang persis sama dengan build lama.

Sebagian besar sistem kontrol versi tidak memungkinkan penulisan ulang riwayat, kecuali untuk keadaan ekstrem seperti menghapus informasi yang dapat menyebabkan pertanggungjawaban jika diperiksa. Tidak biasa dan sedikit "sesat" bahwa git memungkinkan Anda melakukan ini.

Dokumentasi mengakui ada risiko untuk menulis ulang riwayat .

Selain itu, ini adalah sistem kontrol versi terdistribusi - menulis ulang itu tidak mempengaruhi repositori yang sudah dikloning!

Saya menyarankan untuk tidak melakukan ini kecuali untuk menghapus sesuatu yang baru-baru ini dilakukan yang seharusnya dirahasiakan - data pribadi, kunci enkripsi, hal semacam itu.

Tampaknya bahkan jawaban yang saat ini diterima tidak benar-benar menjawab bagian dari pertanyaan Anda bagaimana menghindari seseorang secara tidak sengaja mengakses komit lama, menggunakan status basis kode yang lebih lama di cabang baru dan karenanya memperkenalkan kerentanan lama lagi.

IMHO satu-satunya cara yang tepat untuk mengatasi ini adalah:

• dengan mendokumentasikan setiap perbaikan bug serta perbaikan kerentanan secara kaku dalam dokumen "catatan rilis" (atau "log perubahan") dari sistem

• dengan memastikan semua pengembang yang mengakses versi kode yang lebih lama pastikan mereka membaca catatan rilis, periksa masalah mana yang telah dipecahkan dalam versi kode yang muncul setelah versi yang akan mereka gunakan

Ketika menggunakan kembali versi yang lebih lama, atau bercabang dari versi yang lebih lama dari basis kode, itu jelas merupakan tanggung jawab para pengembang untuk tidak melakukan hal ini secara membabi buta. Jelas mereka harus memeriksa silang bug dan kerentanan yang sudah diperbaiki, untuk tidak memperkenalkan mereka lagi. Log VCS, bagaimanapun, sebenarnya bukan tempat yang baik untuk menemukan informasi semacam ini, karena biasanya ada semua jenis perubahan yang disebutkan, pada tingkat abstraksi yang terlalu rendah.

Catatan rilis, bagaimanapun, harus mengandung bagian "fitur baru" serta bagian "masalah terpecahkan". Dan yang terakhir harus menjadi tempat pertama untuk memeriksa sebelum bercabang dari versi yang lebih lama.

Katakanlah 3.5 rentan, tetapi 3.6 tidak. Anda bisa menghasilkan 3.5.1 tanpa kerentanan. Tapi itu berhasil dan tidak terlalu berguna, karena orang memperbarui versi mereka atau tidak, jadi tidak mungkin ada orang yang menggunakan 3.5.1.