GitHub merilis workflow dependency lockfiles dalam public preview pada 14 Oktober 2026. Fitur ini dirancang untuk menjaga agar GitHub Actions menjalankan kode yang sudah ditinjau, bukan kode baru yang kebetulan ditunjuk oleh tag atau branch yang sama ketika workflow berjalan.
Masalahnya cukup sederhana. Banyak workflow menulis dependensi seperti uses: actions/checkout@v4 atau memakai branch tertentu. GitHub Actions kemudian menyelesaikan referensi itu ke commit yang ditunjuk pada saat eksekusi. Jika tag dipindahkan atau branch berubah setelah review, workflow berikutnya bisa menjalankan kode berbeda tanpa ada perubahan pada file workflow di repositori.
GitHub menyebut kondisi ini sebagai salah satu risiko pada rantai pasok CI/CD. Jika akun pemelihara action diambil alih dan tag diarahkan ke commit berbahaya, repositori pengguna dapat mengeksekusi kode tersebut pada run berikutnya. Lockfile tidak membuat action otomatis aman, tetapi membuat perubahan kode yang akan dijalankan menjadi lebih terlihat dan dapat diaudit.
Satu lockfile untuk action dan dependensi turunannya
Lockfile dibuat sebagai .github/workflows/actions.lock. GitHub menyediakan ekstensi GitHub CLI dari repositori github/gh-actions-lock; perintah yang dipakai untuk membuat dan memperbarui lockfile adalah gh actions-lock. Ekstensi itu memindai workflow, lalu mencatat commit yang menjadi tujuan setiap action, dependensi transistif yang dipakai action, serta reusable workflow yang relevan.
Setelah sebuah workflow diikutkan ke lockfile, setiap dependensinya harus memiliki entri yang sesuai. Ketika workflow berjalan, GitHub Actions memakai commit yang tercatat di lockfile, meskipun tag atau branch pada repositori sumber sudah bergerak. Lockfile juga menyimpan identitas numerik pemilik dan repositori sumber. Catatan ini membantu GitHub memeriksa bahwa nama repositori masih menunjuk ke proyek yang sama, bukan ke repositori lain yang kebetulan memakai jalur serupa.
Pendekatan ini berbeda dari kebiasaan lama yang meminta pengembang menulis full commit SHA langsung di setiap baris uses. GitHub mengatakan repositori yang mengadopsi lockfile tidak lagi perlu melakukan pinning SHA di file workflow. Lockfile juga mencakup dependensi transistif dan memisahkan referensi yang nyaman dibaca manusia dari commit yang benar-benar dieksekusi.
Dependabot ikut menjaga lockfile
Fitur ini tidak berhenti pada pembuatan file pertama. Jika Dependabot membuat pull request untuk memperbarui versi action yang sudah diikutkan ke lockfile, GitHub mengatakan entri lockfile yang sesuai akan dibuat ulang dalam pull request yang sama. Dengan begitu, referensi versi dan commit terkunci tidak mudah tertinggal satu sama lain.
GitHub juga menyediakan perintah untuk memeriksa lockfile tanpa mengubah berkas. Pemeriksaan ini bisa ditempatkan dalam CI agar pull request dengan lockfile kedaluwarsa gagal sebelum digabungkan. GitHub menyarankan agar perubahan pada lockfile diperlakukan seperti perubahan dependensi lain: review commit yang berubah, periksa identitas repositori, dan jangan mengedit lockfile secara manual.
Enaknya tidak harus langsung menerapkan ke semua workflow
Adopsi dapat dilakukan bertahap. Pemilik repositori bisa mengikutkan satu workflow terlebih dahulu, kemudian memperluas cakupan setelah proses pembaruan dan review berjalan. GitHub juga membuka Require lockfile policy dalam public preview. Administrator enterprise, organisasi, atau repositori dapat menggunakan kebijakan itu untuk mewajibkan workflow tertentu memiliki lockfile.
Dokumentasi GitHub menyarankan masa pilot sebelum kebijakan diaktifkan secara penuh. Alasannya praktis: lockfile yang tidak diperbarui akan membuat workflow gagal, sehingga tim perlu menyiapkan otomatisasi pembaruan dan jalur review. Salah satu pola yang direkomendasikan adalah menjalankan perintah pembaruan ketika file di .github/workflows/ berubah, lalu menjalankan pemeriksaan khusus pada pull request.
Ini bukan pengganti audit action
Lockfile mengurangi risiko perubahan diam-diam, tetapi tidak menjawab pertanyaan apakah commit yang dikunci memang aman. Action yang berbahaya sejak awal akan tetap berbahaya setelah dipin. Begitu pula lockfile tidak menggantikan pembatasan permission GITHUB_TOKEN, review kode action, branch protection, atau kebijakan siapa yang boleh menjalankan workflow.
Nilai utamanya ada pada jejak perubahan. Jika commit dalam lockfile berganti, perubahan itu bisa dibaca, disetujui, atau ditolak secara eksplisit. Untuk tim yang menjalankan build, deployment, atau pemindaian keamanan melalui GitHub Actions, perbedaan antara “tag yang bisa bergerak” dan “commit yang direview” adalah perbedaan kecil di konfigurasi dengan konsekuensi besar saat rantai pasok sedang diserang.
Workflow dependency lockfiles masih berstatus public preview dan tersedia untuk GitHub Enterprise Cloud serta GitHub Enterprise Cloud dengan data residency. Tim yang ingin mencobanya perlu memasang ekstensi dari repositori tersebut, menjalankan gh actions-lock, membuat lockfile, meninjau diff, lalu menguji proses pembaruannya sebelum menyalakan enforcement.