Repositori yang jarang disentuh masih boleh mengandungi kod untuk aplikasi yang sedang digunakan. Mulai 8 Disember 2026, GitHub akan mematikan amaran Dependabot bagi kebanyakan repositori yang tidak menunjukkan aktiviti selama setahun.
Perubahan yang diumumkan pada 10 November ini memberi sebab kepada pasukan pembangunan untuk menyemak semula projek lama, khususnya apabila kodnya masih digunakan oleh pelanggan atau sistem dalaman.
GitHub menyatakan bahawa amaran Dependabot sedia ada bagi repositori yang terjejas akan diarkibkan dan boleh dipulihkan. Menurut syarikat itu, perubahan ini bertujuan membantu mengekalkan kelajuan dan kebolehpercayaan Dependabot untuk repositori yang sedang dibangunkan ketika jumlah penemuan kerentanan dan amaran meningkat.
Dependabot menghasilkan amaran apabila ia mengesan kebergantungan yang mempunyai kerentanan dalam repositori. Kebergantungan ialah komponen perisian yang digunakan oleh sesuatu projek, seperti pustaka untuk pengesahan pengguna atau pemprosesan data. Amaran memberi pasukan peluang menyiasat sama ada versi yang digunakan perlu dikemas kini atau ditangani dengan cara lain.
Pengumuman ini menerangkan perubahan yang akan bermula pada Disember; ia tidak bermakna semua repositori yang kelihatan lama telah kehilangan amaran hari ini.
Sumber: Dependabot alerts will pause on inactive repositories; Configuring Dependabot alerts.
GitHub mengira push ke mana-mana branch atau tag, penciptaan repositori, dan pengaktifan amaran Dependabot sebagai aktiviti. Jika amaran telah dimatikan di bawah perubahan ini, sebarang push akan mengaktifkannya semula. Amaran yang diarkibkan akan dipulihkan dan kiraan satu tahun bermula semula.
Terdapat pengecualian. GitHub menyatakan bahawa amaran tidak akan dimatikan bagi repositori yang mempunyai konfigurasi keselamatan yang dikuatkuasakan untuk mengaktifkan Dependabot alerts. Repositori dalam perusahaan dengan polisi yang tidak membenarkan pentadbir repositori menghidupkan atau mematikan amaran juga dikecualikan.
Perubahan ini meliputi semua pelan di GitHub.com dan GitHub Enterprise Cloud dengan data residency. GitHub Enterprise Server tidak termasuk dalam perubahan tersebut. Organisasi perlu menyemak konfigurasi dan polisi sebenar mereka sebelum menganggap sesuatu repositori mendapat pengecualian.
Sumber: Dependabot alerts will pause on inactive repositories.
Dokumentasi GitHub menerangkan satu lagi mekanisme yang boleh menjeda Dependabot updates apabila pull request Dependabot dibiarkan tanpa interaksi. Dalam keadaan itu, Dependabot boleh berhenti membuka pull request kemas kini versi dan keselamatan sehingga penyelenggara kembali berinteraksi dengannya.
Mekanisme pull request itu mempunyai syarat dan cara penyambungan semula tersendiri. Oleh itu, apabila menyemak projek, lihat kedua-dua status amaran dan keadaan pull request Dependabot. Amaran membantu mengenal pasti masalah pada kebergantungan; pull request kemas kini pula ialah cadangan perubahan yang masih memerlukan semakan dan ujian sebelum digabungkan.
Sumber: Configuring Dependabot alerts; Dependabot update pull requests no longer generated.
Menurut panduan GitHub, tetapan repositori boleh ditemui melalui Settings, kemudian Advanced Security di bawah bahagian Security and quality. Di situ, pengguna yang mempunyai akses sesuai boleh menyemak dan mengaktifkan Dependabot alerts. Pemilik organisasi juga boleh mengurus ciri tersebut untuk repositori yang layak pada peringkat organisasi.
Jika amaran dijeda di bawah perubahan baharu ini, GitHub menyatakan bahawa ia juga boleh diaktifkan semula melalui tetapan repositori. Selepas pemulihan, semak senarai amaran yang tersedia dan tentukan siapa yang bertanggungjawab menyiasatnya. Mengaktifkan amaran tidak dengan sendirinya membaiki kebergantungan yang terjejas.
Semak juga penerima pemberitahuan. Dokumentasi GitHub menerangkan bahawa pengguna dengan kebenaran write, maintain atau admin dimaklumkan secara lalai tentang amaran baharu, dan akses kepada amaran boleh diberikan kepada individu atau pasukan tambahan.
Sumber: Dependabot alerts will pause on inactive repositories; Configuring Dependabot alerts.
Bagi agensi pembangunan, pekerja bebas dan pasukan IT tempatan, mulakan dengan senarai repositori yang menyokong aplikasi sebenar. Contohnya, portal pelanggan mungkin jarang menerima perubahan kod kerana fungsinya stabil, tetapi masih bergantung pada pakej yang memerlukan perhatian keselamatan. Bandingkan senarai repositori dengan aplikasi yang sedang digunakan dan rekod pemilik sistem.
Seterusnya, tetapkan seorang pemilik atau pasukan bagi setiap projek yang masih penting. Semak status amaran, polisi organisasi dan pull request yang tertangguh. Untuk projek yang perlu terus dipantau, pertimbangkan konfigurasi yang sesuai dengan keperluan organisasi; jangan bergantung pada push kosong semata-mata sebagai proses keselamatan.
Apabila amaran muncul, rekodkan pakej serta versi yang terlibat, nilai sama ada aplikasi menggunakannya dan uji pembaikan dalam persekitaran yang sesuai. Bagi projek pelanggan, persetujuan tentang siapa memantau, menguji dan memasang kemas kini juga membantu mengelakkan amaran terbiar selepas projek diserahkan.
Disediakan secara automatik dengan bantuan AI berdasarkan sumber yang dipautkan. Semakan sumber: 2026-11-11. Gambar utama ialah ilustrasi janaan AI, bukan foto peristiwa sebenar.