Pembaruan dependensi yang dikerjakan manual selalu kalah cepat dibandingkan aliran advisory keamanan yang terbit tanpa jadwal. Otomatisasi membalik kondisi tersebut dengan menjadikan pembaruan sebagai rutinitas pipeline, yaitu alat seperti Dependabot dan Renovate membuka pull request pembaruan secara terjadwal, lengkap dengan catatan perubahan dan hasil pengujian. Topik ini melanjutkan penguncian versi pada topik Risiko Dependensi di modul Miskonfigurasi dan Supply Chain dengan langkah berikutnya, yaitu konfigurasi kedua alat tersebut dan simulasi tahap pipeline yang menentukan tindakan setiap pembaruan. Setelah topik ini diselesaikan, pembaruan patch dapat digabung tanpa sentuhan manual, sedangkan pembaruan minor dan major sampai ke meja tinjauan.
Pembaruan kecil yang berkelanjutan#
Jarak antara advisory keamanan dan pembaruan yang benar-benar terpasang menentukan lamanya aplikasi terpapar. Penumpukan pembaruan setahun sekali menghasilkan perubahan besar yang sulit ditinjau dan berisiko merusak banyak hal sekaligus, sedangkan pembaruan kecil yang berkelanjutan menjaga setiap lompatan versi tetap dapat dipahami. Kebiasaan ini menopang kategori A03:2025 Software Supply Chain Failures pada OWASP Top 10:2025, karena komponen yang tertinggal jauh adalah bentuk kegagalan rantai pasok yang paling umum.
Dependabot dan Renovate bekerja dengan pola yang sama, yaitu membandingkan berkas dependensi dan berkas lock dengan daftar versi terbaru, lalu membuka satu pull request untuk setiap pembaruan atau kelompok pembaruan. Pengujian pipeline berjalan atas setiap pull request tersebut, sehingga keputusan penggabungan berdiri di atas hasil pengujian, bukan atas keberanian. Penguatan pipeline CI/CD terhadap serangan pipeline dibahas pada jalur CI/CD, sedangkan topik ini menempatkan pembaruan dependensi sebagai salah satu tahapnya.
Konfigurasi Dependabot dan Renovate#
Kedua alat membaca konfigurasinya dari repositori, yaitu .github/dependabot.yml untuk Dependabot dan renovate.json pada akar repositori untuk Renovate. Berkas berikut memuat konfigurasi awal Dependabot yang memadai untuk aplikasi Python.
# Konfigurasi Dependabot. Tempat resminya adalah .github/dependabot.yml
# pada akar repositori.
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
groups:
pembaruan-lancar:
update-types:
- "minor"
- "patch"
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"Bagian package-ecosystem menyatakan jenis pengelola paketnya, bagian directory menunjuk lokasi berkas dependensi, dan schedule menetapkan frekuensi pemeriksaan. Kelompok groups menyatukan pembaruan minor dan patch ke dalam satu pull request agar daftar antrean tidak menumpuk, sedangkan pembaruan major tetap dibuka satu per satu karena risikonya berbeda. Entri github-actions memperluas pembaruan ke versi action yang digunakan pipeline.
Konfigurasi Renovate berikut menghasilkan perilaku yang serupa, dengan gaya penulisannya sendiri.
{
"extends": ["config:recommended"],
"rangeStrategy": "pin",
"timezone": "Asia/Jakarta",
"schedule": ["before 7am on monday"],
"packageRules": [
{
"matchUpdateTypes": ["patch"],
"automerge": true
}
]
}Kunci rangeStrategy bernilai pin selaras dengan penguncian versi pada topik Risiko Dependensi, sehingga setiap pembaruan menulis versi persis baru ke berkas dependensi. Jadwal before 7am on monday mengumpulkan pembaruan pada waktu yang dapat diprediksi, dan packageRules menyalakan penggabungan otomatis hanya untuk kenaikan patch. Memilih salah satu alat lebih penting daripada menentukan alat mana yang dipilih, karena keduanya memenuhi kebutuhan yang sama.
Simulasi tahap pembaruan#
Pull request pembaruan yang dibuka alat tetap memerlukan keputusan, dan keputusan itu dapat dirumuskan sebagai aturan yang deterministik. Skrip berikut mensimulasikan satu tahap pipeline yang membaca daftar dependensi terkunci, mencocokkannya dengan umpan versi terbaru lokal, lalu menetapkan tindakannya, yaitu gabung otomatis untuk kenaikan patch dan tinjau manual untuk minor atau major. Simpan kedua berkas berikut dalam satu folder, lalu jalankan dengan perintah python3 tahap-pembaruan.py.
# daftar dependensi terkunci aplikasi catatan
klien-http-mini==1.2.0
parsir-xml==2.5.0
toko-session==0.9.4
util-waktu==1.4.2
gaya-tampilan==3.1.2"""Simulasi tahap pipeline pembaruan dependensi.
Skrip membaca daftar dependensi terkunci, membandingkannya dengan umpan
versi terbaru lokal, lalu menentukan tindakan untuk setiap pembaruan:
gabung otomatis untuk kenaikan patch dan tinjau untuk minor atau major.
Seluruh nama paket dan nomor versi bersifat fiktif agar hasilnya dapat
direproduksi.
"""
def angka_versi(teks):
return tuple(int(bagian) for bagian in teks.split("."))
def jenis_kenaikan(lama, baru):
if baru[0] > lama[0]:
return "major"
if baru[1] > lama[1]:
return "minor"
return "patch"
def tindakan(jenis):
if jenis == "patch":
return "gabung otomatis setelah pengujian lulus"
return "tinjau manual sebelum digabung"
# Umpan versi terbaru lokal: data fiktif untuk latihan ini.
UMBAN_VERSI = {
"klien-http-mini": "1.2.3",
"parsir-xml": "2.5.0",
"toko-session": "1.1.0",
"util-waktu": "1.4.2",
"gaya-tampilan": "3.2.0",
}
def utama():
berkas = "dependensi.txt"
print(f"== tahap pembaruan dependensi: {berkas} ==")
print(f"{'paket':<17}{'terpasang':<10}{'terbaru':<8}{'jenis':<7}tindakan")
jumlah = 0
total = 0
with open(berkas, encoding="utf-8") as sumber:
for baris in sumber:
baris = baris.strip()
if not baris or baris.startswith("#"):
continue
total += 1
nama, versi = (bagian.strip() for bagian in baris.split("==", 1))
terbaru = UMBAN_VERSI[nama]
if angka_versi(versi) >= angka_versi(terbaru):
print(f"{nama:<17}{versi:<10}{terbaru:<8}- sudah terbaru")
continue
jenis = jenis_kenaikan(angka_versi(versi), angka_versi(terbaru))
jumlah += 1
print(f"{nama:<17}{versi:<10}{terbaru:<8}{jenis:<7}{tindakan(jenis)}")
print(f"== {jumlah} pembaruan diusulkan dari {total} dependensi ==")
utama()== tahap pembaruan dependensi: dependensi.txt ==
paket terpasang terbaru jenis tindakan
klien-http-mini 1.2.0 1.2.3 patch gabung otomatis setelah pengujian lulus
parsir-xml 2.5.0 2.5.0 - sudah terbaru
toko-session 0.9.4 1.1.0 major tinjau manual sebelum digabung
util-waktu 1.4.2 1.4.2 - sudah terbaru
gaya-tampilan 3.1.2 3.2.0 minor tinjau manual sebelum digabung
== 3 pembaruan diusulkan dari 5 dependensi ==Baris klien-http-mini naik dari 1.2.0 ke 1.2.3, dan karena perubahannya berupa patch, tindakannya adalah gabung otomatis setelah pengujian lulus. Baris toko-session melompat dari 0.9.4 ke 1.1.0 dan melintasi batas major, sehingga diberi tindakan tinjau manual meskipun nomor perbaikan kerentanannya tercantum pada advisory. Baris parsir-xml dan util-waktu tidak menghasilkan usulan apa pun karena versinya sudah paling baru, sedangkan gaya-tampilan naik minor dan tetap memerlukan tinjauan atas catatan perubahannya.
Pembagian tindakan berdasarkan jenis kenaikan memperlihatkan pembagian kerja yang sehat, yaitu mesin menangani kasus yang berulang dan berisiko rendah, sedangkan manusia menangani kasus yang membawa perubahan perilaku.
Penggabungan otomatis yang berpagar#
Penggabungan otomatis baru aman bila pagarnya jelas. Pagar pertama adalah jenis kenaikan, dan hanya patch yang boleh lewat tanpa tinjauan manusia. Pagar kedua adalah hasil pengujian, karena pull request yang menggagalkan pengujian tidak pernah digabung meskipun jenisnya patch. Pagar ketiga adalah cakupan berkas, yaitu pembaruan yang hanya menyunting berkas dependensi dan berkas lock, sedangkan perubahan kode lain pada pull request yang sama menahan penggabungannya.
SBOM yang dibahas pada topik Risiko Dependensi ikut terjaga oleh rutinitas ini. Setiap pembaruan melewati tinjauan yang sama dan berkas lock selalu mencerminkan versi yang terpasang, sehingga inventaris bahan tidak pernah tertinggal jauh dari kenyataan. Alurnya berjalan dua arah, yaitu SBOM membantu menilai dampak advisory baru, dan pembaruan berkelanjutan menjaga SBOM tetap dapat dipercaya.
Tinjauan untuk pembaruan minor dan major juga dapat diringankan tanpa dihilangkan. Pembacaan catatan perubahan, pengujian tambahan pada area yang menyentuh paketnya, dan penjadwalan penggabungan pada awal pekan adalah cara murah untuk menambah rasa aman. Apabila satu paket terbukti merusak pengujian setiap kali diperbarui, pengalaman itu dicatat pada konfigurasi alat agar pembaruan paket tersebut selalu melewati tinjauan yang lebih teliti.
Kesalahan umum#
Kesalahan berikut sering muncul saat pembaruan dependensi diautomatisasi.
- Mengaktifkan penggabungan otomatis untuk semua jenis pembaruan. Kenaikan major membawa perubahan perilaku yang dapat merusak fitur, sehingga jenis itu selalu melewati tinjauan.
- Membisukan notifikasi pembaruan karena antreannya ramai. Pull request yang menumpuk berbulan-bulan sama risikonya dengan pembaruan manual yang jarang, hanya dengan tambahan rasa aman palsu.
- Menyalakan otomatisasi sebelum pengujian dapat dipercaya. Penggabungan otomatis di atas pengujian yang tidak menyeluruh hanya mempercepat masuknya versi yang rusak.
- Menggabungkan pembaruan tanpa memperbarui berkas lock. Versi yang terpasang dan deklarasinya kembali berbeda, sehingga SBOM kehilangan keandalannya.
Ringkasan#
- Dependabot dan Renovate membuka pull request pembaruan secara terjadwal, sehingga jarak antara advisory dan versi terpasang menjadi pendek.
- Aturan tindakan yang deterministik membagi pekerjaan, yaitu patch digabung otomatis setelah pengujian lulus, sedangkan minor dan major melewati tinjauan.
- Penggabungan otomatis berdiri di atas pagar berupa jenis kenaikan, hasil pengujian, dan cakupan berkas, sedangkan berkas lock yang terbarui menjaga SBOM tetap dapat dipercaya.
Referensi#
- Dependabot documentation — GitHub Docs — Dokumentasi konfigurasi Dependabot beserta opsi jadwal, ekosistem, dan pengelompokan pembaruan.
- Renovate documentation — Renovate — Dokumentasi konfigurasi Renovate, termasuk rangeStrategy, jadwal, dan packageRules.
- A03:2025 Software Supply Chain Failures — OWASP Top 10 — Kategori OWASP Top 10:2025 yang menaungi komponen tertinggal dan kegagalan rantai pasok perangkat lunak.