Verifikasi identitas developer untuk Git, commit, dan rilis adalah cara memastikan bahwa perubahan kode dan artefak rilis benar-benar berasal dari orang yang berwenang, bukan hanya dari akun yang kebetulan punya akses. Untuk tim engineering, ini bukan sekadar fitur keamanan tambahan; ini adalah kontrol integritas supply chain yang membantu mencegah spoofing identitas, penyalahgunaan akses, dan kesalahan operasional saat melakukan release.

Panduan ini membahas alur yang bisa langsung diterapkan pada tim kecil hingga menengah: memilih mekanisme signing, menetapkan daftar fingerprint tepercaya, mengaktifkan proteksi branch, memverifikasi commit dan tag di CI, mengelola rotasi kunci, onboarding perangkat baru, dan menangani kasus saat kunci hilang atau developer keluar. Pendekatannya terinspirasi dari praktik developer verification yang mengutamakan identitas kunci, bukan sekadar identitas akun.

Mengapa verifikasi identitas developer perlu dipisahkan dari akun Git hosting

Akun di Git hosting seperti GitHub, GitLab, atau Forgejo penting untuk autentikasi dan otorisasi, tetapi akun saja tidak cukup untuk menjamin asal-usul sebuah commit. Ada beberapa alasan:

  • Nama dan email pada commit mudah dipalsukan. Tanpa signature, siapa pun bisa membuat commit dengan author yang tampak sah.
  • Akun bisa diambil alih. Jika akun hosting disusupi, penyerang dapat membuka pull request atau mendorong perubahan jika kontrol lain longgar.
  • Rilis butuh bukti asal yang lebih kuat. Tag rilis, changelog, atau artefak build sebaiknya dapat ditelusuri ke kunci yang sudah disetujui tim.

Karena itu, identitas developer sebaiknya diikat ke kunci kriptografi yang diverifikasi dan didaftarkan secara eksplisit. Akun hosting tetap dipakai untuk akses, tetapi keputusan kepercayaan untuk merge atau release bergantung pada signature dan fingerprint yang valid.

Model operasional yang direkomendasikan

Model yang paling praktis untuk banyak tim adalah sebagai berikut:

  1. Setiap developer memiliki kunci signing pribadi.
  2. Tim menyimpan daftar fingerprint kunci yang diotorisasi dalam repositori terpisah atau direktori khusus yang dilindungi.
  3. Commit ke branch sensitif dan semua tag rilis harus signed.
  4. CI memverifikasi bahwa commit atau tag ditandatangani oleh fingerprint yang ada dalam allowlist.
  5. Rotasi, revokasi, dan offboarding diatur dengan prosedur tertulis.

Pemisahan antara identity registry dan repositori kode penting agar perubahan daftar kunci sendiri dapat diaudit dengan ketat. Tim kecil bisa menyimpan file allowlist di repositori utama selama branch yang memuatnya diproteksi dan perubahannya wajib direview oleh lebih dari satu maintainer.

Memilih mekanisme signing: GPG vs SSH signing vs Sigstore

GPG

Kelebihan:

  • Paling matang untuk signed commit dan especially signed tag.
  • Konsep fingerprint, subkey, expiry, dan revocation sudah mapan.
  • Cocok bila tim ingin kontrol penuh tanpa bergantung pada layanan eksternal.

Kekurangan:

  • UX sering dianggap rumit, terutama saat setup awal dan manajemen keyring.
  • Distribusi public key dan verifikasi trust sering membingungkan bagi tim yang belum terbiasa.

Kapan dipilih: jika tim butuh model verifikasi yang stabil, dapat diaudit, dan tidak keberatan dengan sedikit kompleksitas operasional.

SSH signing

Kelebihan:

  • Lebih mudah diadopsi karena banyak developer sudah punya SSH key.
  • Konfigurasi Git cenderung lebih sederhana daripada GPG.
  • Cocok untuk tim yang ingin mulai cepat dengan friksi rendah.

Kekurangan:

  • Ekosistem verifikasi dan kebiasaan operasional belum setua GPG.
  • Tim perlu disiplin memisahkan SSH key untuk autentikasi akses dan key untuk signing, agar blast radius lebih terkendali.

Kapan dipilih: jika target utama adalah adopsi cepat dan tim sudah terbiasa mengelola SSH key dengan baik.

Sigstore

Kelebihan:

  • Mengurangi beban distribusi kunci statis karena verifikasi bisa dikaitkan dengan identitas dan bukti transparansi.
  • Sangat menarik untuk penandatanganan artefak dan supply-chain attestation.

Kekurangan:

  • Model operasional berbeda dari GPG/SSH dan mungkin lebih kompleks untuk tim kecil bila hanya ingin memverifikasi commit Git.
  • Biasanya lebih cocok bila Anda juga ingin memperkuat pipeline build, provenance, dan artefak rilis, bukan hanya commit signing.

Kapan dipilih: jika kebutuhan Anda sudah meluas ke verifikasi artefak, attestation, dan integrasi supply-chain security yang lebih modern.

Untuk tim kecil-menengah, pilihan praktis biasanya: GPG bila ingin kontrol dan tradisi yang kuat, atau SSH signing bila ingin rollout lebih mudah. Sigstore bisa ditambahkan kemudian untuk artefak rilis.

Struktur kebijakan yang perlu ditetapkan sejak awal

1. Unit identitas yang dipercaya

Tentukan apakah kepercayaan diberikan pada:

  • Fingerprint primary key.
  • Fingerprint subkey tertentu.
  • Kombinasi identitas developer dan daftar kunci aktifnya.

Untuk operasional harian, pendekatan yang umum adalah menyimpan fingerprint kunci signing aktif per developer, plus metadata seperti tanggal berlaku, status, dan kontak verifikasi.

2. Ruang lingkup wajib signing

Tentukan dengan jelas apa yang wajib ditandatangani:

  • Semua commit di branch default.
  • Semua merge commit.
  • Semua tag rilis.
  • Manifest, changelog, atau file metadata release.

Minimal yang direkomendasikan: tag rilis wajib signed dan commit yang masuk ke branch utama wajib berasal dari signature valid.

3. Proses verifikasi awal

Jangan menerima public key hanya dari chat atau email tanpa verifikasi. Lakukan konfirmasi fingerprint melalui kanal kedua, misalnya:

  • Video call singkat.
  • Konfirmasi tatap muka.
  • Pengecekan melalui maintainer yang sudah dipercaya.
  • Dokumen internal yang ditandatangani oleh dua maintainer.

Tujuannya adalah memastikan bahwa fingerprint yang masuk ke allowlist memang milik orang yang benar.

Implementasi signed commit dan tag

Contoh dengan GPG

Konfigurasi dasar Git untuk menandatangani commit dan tag:

git config --global user.name "Nama Developer"
git config --global user.email "[email protected]"
git config --global user.signingkey ABCD1234EF567890
git config --global commit.gpgsign true
git config --global tag.gpgSign true

Untuk membuat tag rilis yang signed:

git tag -s v1.4.0 -m "Release v1.4.0"
git push origin v1.4.0

Verifikasi lokal:

git log --show-signature -1
git tag -v v1.4.0

Mengapa ini bekerja: Git menyimpan signature bersama objek commit atau tag. Saat diverifikasi, Git memeriksa apakah isi objek cocok dengan signature dan apakah public key yang sesuai tersedia untuk memvalidasinya.

Contoh dengan SSH signing

Git juga dapat menggunakan SSH key untuk signing. Konfigurasi dasarnya mirip:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgSign true

Untuk verifikasi yang konsisten, tim perlu memiliki file allowlist penanda tangan, misalnya berbasis fingerprint atau public key yang diotorisasi. Cara detailnya bergantung pada tooling yang digunakan di workstation dan CI, tetapi prinsipnya sama: signature valid saja tidak cukup; penandatangan juga harus ada dalam daftar yang dipercaya tim.

Aturan praktis untuk semua metode

  • Gunakan kunci signing terpisah dari kunci untuk login server atau akses repositori bila memungkinkan.
  • Gunakan passphrase yang kuat dan simpan private key di perangkat yang diamankan.
  • Jika tersedia, pertimbangkan hardware-backed key atau token keamanan untuk maintainer rilis.
  • Bedakan kunci personal developer dengan kunci otomatisasi CI; jangan campur keduanya.

Membangun registry fingerprint yang bisa diaudit

Banyak tim gagal bukan pada proses signing, tetapi pada pengelolaan daftar kunci yang dipercaya. Solusinya adalah membuat registry yang sederhana namun eksplisit.

Format registry yang disarankan

developers:
  - id: alice
    name: Alice Example
    email: [email protected]
    signing_keys:
      - fingerprint: "ABCD 1234 EFGH 5678 IJKL 9012 MNOP 3456 QRST 7890"
        type: gpg
        status: active
        added_at: "2026-01-10"
        expires_at: "2027-01-10"
  - id: bob
    name: Bob Example
    email: [email protected]
    signing_keys:
      - fingerprint: "SHA256:examplefingerprintforsshkey"
        type: ssh
        status: active
        added_at: "2026-02-01"

Registry ini sebaiknya:

  • Disimpan di repositori yang diproteksi.
  • Perubahannya wajib signed dan direview minimal dua maintainer.
  • Memiliki status seperti active, rotating, revoked, retired.

Mengapa registry penting: hosting platform mungkin menampilkan commit sebagai “verified”, tetapi status itu tidak selalu berarti kunci tersebut sudah disetujui oleh organisasi Anda. Registry internal adalah sumber kebenaran tim.

Proteksi branch dan aturan merge

Verifikasi identitas tidak efektif bila branch sensitif masih bisa dimodifikasi bebas. Terapkan aturan berikut pada branch utama dan branch rilis:

  • Wajib pull request, larang push langsung kecuali akun darurat yang sangat terbatas.
  • Wajib lulus CI verifikasi signature.
  • Wajib review dari maintainer untuk perubahan pada file registry kunci, workflow CI, skrip release, dan konfigurasi deployment.
  • Batasi siapa yang boleh membuat atau mendorong tag rilis.

Jika platform Anda mendukung aturan “require signed commits”, gunakan itu sebagai lapisan awal. Namun jangan hanya mengandalkan fitur bawaan platform, karena definisi “signed” belum tentu sama dengan “signed oleh kunci yang ada di allowlist organisasi”. Tambahkan verifikasi di CI agar kebijakan Anda konsisten dan portabel.

Validasi di CI: apa yang harus diperiksa

CI adalah titik penegakan kebijakan yang paling penting. Validasi minimal yang disarankan:

  1. Commit yang akan di-merge memiliki signature valid.
  2. Fingerprint penandatangan ada dalam registry dan statusnya active atau sesuai kebijakan.
  3. Email atau identitas commit, bila dipakai sebagai metadata tambahan, cocok dengan entri registry.
  4. Tag rilis signed oleh maintainer yang berwenang.
  5. Untuk rilis, commit yang ditag harus sudah lolos pemeriksaan branch protection dan review.

Contoh alur validasi sederhana

Contoh berikut menggunakan shell pseudo-praktis. Implementasi sebenarnya bergantung pada mekanisme signing dan format registry Anda.

# 1. Ambil commit yang relevan
COMMITS=$(git rev-list origin/main..HEAD)

# 2. Verifikasi setiap commit punya signature valid
for c in $COMMITS; do
  git verify-commit "$c" || exit 1

done

# 3. Ekstrak fingerprint signer dari tooling yang dipakai
# 4. Cocokkan fingerprint dengan registry allowlist
# 5. Gagalkan pipeline jika signer tidak terdaftar atau statusnya bukan active

Jika menggunakan GPG, Anda bisa memanfaatkan output dari git verify-commit atau git log --show-signature, lalu memetakan fingerprint ke registry internal. Jika menggunakan SSH signing, gunakan daftar penandatangan yang konsisten antara developer workstation dan runner CI agar hasil verifikasi tidak berbeda.

Pisahkan validasi commit dan validasi release

Jangan gabungkan semua logika dalam satu job besar. Lebih aman bila ada dua tahap:

  • Validation untuk merge: memeriksa semua commit yang masuk ke branch utama.
  • Validation untuk release: memeriksa tag, identitas release maintainer, dan konsistensi commit yang ditandai.

Pemisahan ini memudahkan audit dan troubleshooting. Saat sebuah rilis dipersoalkan, Anda dapat membuktikan siapa yang menandatangani tag dan siapa yang menandatangani perubahan kode yang masuk sebelumnya.

Onboarding perangkat baru tanpa melemahkan keamanan

Salah satu momen paling rawan adalah saat developer mengganti laptop atau menambah workstation baru. Kesalahan umum adalah menyalin private key sembarangan ke banyak perangkat tanpa jejak audit.

Pendekatan yang lebih aman

  • Buat kunci baru per perangkat atau setidaknya per kelas perangkat, lalu daftarkan ke registry.
  • Jika kebijakan tim mengizinkan satu identitas dengan beberapa kunci aktif, tandai masing-masing perangkat dengan metadata yang jelas.
  • Verifikasi fingerprint perangkat baru melalui maintainer sebelum diaktifkan.
  • Cabut atau nonaktifkan kunci perangkat lama saat perangkat dipensiunkan.

Trade-off-nya jelas: semakin banyak kunci, semakin besar overhead administrasi. Namun pendekatan ini mengurangi dampak jika satu laptop hilang atau satu private key bocor.

Yang sebaiknya dihindari

  • Mengunggah private key ke penyimpanan cloud pribadi tanpa kontrol ketat.
  • Menggunakan key yang sama untuk signing Git, SSH ke server produksi, dan tugas lain.
  • Mengaktifkan perangkat baru tanpa pencatatan di registry.

Rotasi kunci: lakukan terencana, jangan menunggu insiden

Rotasi kunci diperlukan saat mendekati masa kedaluwarsa, saat upgrade kebijakan keamanan, atau saat ada dugaan kompromi. Agar rotasi tidak mengganggu delivery, gunakan periode transisi.

Prosedur rotasi yang praktis

  1. Buat kunci baru dan verifikasi fingerprint melalui proses normal.
  2. Tambahkan ke registry dengan status active atau rotating.
  3. Umumkan periode overlap, misalnya dua minggu, di mana kunci lama dan baru sama-sama diterima.
  4. Pastikan developer menandatangani commit baru dengan kunci baru.
  5. Setelah periode overlap selesai, ubah kunci lama menjadi retired atau revoked sesuai kondisi.

Mengapa overlap membantu: CI, workstation, dan cache runner tidak selalu sinkron seketika. Periode transisi mencegah merge atau release gagal hanya karena propagasi konfigurasi belum lengkap.

Perbedaan retired dan revoked

  • Retired: kunci tidak lagi dipakai untuk signing baru, tetapi riwayat lama masih dianggap sah.
  • Revoked: ada alasan keamanan atau administratif kuat untuk menandai kunci tidak lagi tepercaya sejak kondisi tertentu.

Jangan mencampur dua status ini. Revocation punya implikasi audit yang berbeda dengan pensiun biasa.

Saat kunci hilang, diduga bocor, atau developer keluar

Kunci hilang atau perangkat dicuri

Jika private key diduga tidak lagi berada di bawah kendali developer:

  1. Ubah status kunci menjadi revoked atau suspended sesuai model kebijakan Anda.
  2. Hentikan penerimaan commit dan tag baru dari kunci tersebut di CI.
  3. Audit commit atau tag terbaru yang menggunakan kunci itu, terutama jika waktunya berdekatan dengan insiden.
  4. Terbitkan kunci baru melalui proses onboarding yang dipercepat tetapi tetap diverifikasi.

Kesalahan umum di sini adalah hanya mencabut akses akun, tetapi lupa bahwa kunci signing lama masih lolos verifikasi internal.

Developer keluar dari tim

Offboarding sebaiknya mencakup dua jalur terpisah:

  • Akses: cabut akses ke hosting, CI, secret manager, dan infrastruktur.
  • Kepercayaan identitas: ubah status semua kunci signing miliknya menjadi retired atau revoked sesuai kebutuhan.

Untuk histori, commit lama tidak perlu diubah. Yang penting adalah mencegah penggunaan kunci itu untuk perubahan baru. Pastikan juga maintainer release yang keluar tidak lagi dapat membuat tag rilis yang diterima pipeline.

Kebijakan untuk tag rilis dan artefak

Tag rilis adalah titik kontrol yang paling penting karena sering menjadi referensi build resmi. Praktik minimal yang disarankan:

  • Semua tag rilis harus annotated dan signed.
  • Hanya maintainer tertentu yang boleh membuat rilis.
  • CI release memverifikasi tag signer terhadap daftar maintainer rilis, bukan sekadar daftar developer umum.
  • Artefak build harus ditautkan ke commit dan tag yang diverifikasi.

Jika kebutuhan supply-chain Anda lebih tinggi, tambahkan penandatanganan artefak dan provenance di luar Git, misalnya dengan Sigstore atau mekanisme serupa. Ini berguna karena signed tag membuktikan asal metadata Git, tetapi tidak otomatis membuktikan bahwa file biner yang diunduh benar-benar hasil dari pipeline yang dimaksud.

Kesalahan umum yang sering terjadi

  • Menganggap verified badge di platform sudah cukup. Badge platform tidak menggantikan allowlist internal.
  • Tidak memproteksi file kebijakan. Registry kunci, workflow CI, dan skrip release harus dijaga lebih ketat dari kode biasa.
  • Hanya mewajibkan signed commits, tanpa verifikasi signer. Ini membuka peluang kunci asing yang valid tetapi tidak diotorisasi.
  • Tidak menguji skenario rotasi dan revocation. Kebijakan terlihat bagus di dokumen, tetapi gagal saat insiden nyata.
  • Mengizinkan squash atau rebase otomatis tanpa memahami efeknya. Pastikan kebijakan merge tidak menghapus jejak signature yang ingin Anda pertahankan atau setidaknya gantikan dengan signature merge yang valid sesuai aturan tim.

Tips debugging saat verifikasi gagal

Commit bertanda tangan, tetapi CI menolaknya

  • Periksa apakah fingerprint signer ada di registry dan statusnya masih aktif.
  • Periksa apakah CI menggunakan keyring atau allowlist terbaru.
  • Pastikan format fingerprint yang dibandingkan konsisten, misalnya dengan atau tanpa spasi, atau bentuk hash yang berbeda.

Verifikasi lokal berhasil, tetapi gagal di runner

  • Runner mungkin belum memuat public key atau file allowed signers yang sama.
  • Clock skew, cache konfigurasi lama, atau checkout dangkal kadang mempersulit analisis tag dan ancestry commit.
  • Pastikan pipeline benar-benar mengambil objek tag, bukan hanya commit hasil dereference.

Tag rilis gagal diverifikasi

  • Pastikan tag adalah annotated signed tag, bukan lightweight tag.
  • Pastikan kunci penandatangan tag masuk kategori maintainer rilis.
  • Periksa apakah proses release dibuat oleh bot yang tidak semestinya memakai identitas manusia.

Checklist rollout bertahap untuk tim kecil-menengah

Tahap 1: fondasi

  • Pilih satu metode utama: GPG atau SSH signing.
  • Tentukan maintainer rilis dan daftar developer aktif.
  • Buat registry fingerprint yang diproteksi.
  • Dokumentasikan proses verifikasi fingerprint awal.

Tahap 2: enforcement ringan

  • Aktifkan signed commit secara sukarela di semua workstation.
  • Wajibkan signed tag untuk semua rilis baru.
  • Tambahkan job CI yang hanya memberi peringatan jika signer belum terdaftar.

Tahap 3: enforcement branch utama

  • Aktifkan branch protection dan wajib pull request.
  • Ubah job CI verifikasi menjadi blocking untuk branch utama.
  • Batasi perubahan registry, workflow CI, dan skrip release ke reviewer tertentu.

Tahap 4: kebijakan matang

  • Terapkan rotasi berkala untuk maintainer kritis.
  • Gunakan kunci terpisah untuk signing dan akses.
  • Dokumentasikan runbook insiden untuk key loss, compromise, dan offboarding.
  • Pertimbangkan signing artefak rilis dan provenance tambahan.

Rekomendasi implementasi yang realistis

Jika Anda memulai dari nol, pendekatan yang seimbang biasanya seperti ini:

  • Git commit dan tag: gunakan GPG atau SSH signing.
  • Sumber kepercayaan: registry fingerprint internal yang direview maintainer.
  • Enforcement: branch protection + CI verification.
  • Release: hanya signed annotated tag dari maintainer rilis.
  • Operasional: prosedur rotasi, onboarding perangkat baru, dan offboarding yang tertulis.

Poin terpentingnya adalah konsistensi. Sistem yang sedikit lebih sederhana tetapi dijalankan disiplin jauh lebih baik daripada desain sangat canggih yang sulit diadopsi, sering di-bypass, atau tidak dipahami anggota tim.

Penutup

Verifikasi identitas developer untuk Git, commit, dan rilis sebaiknya dipandang sebagai bagian dari kontrol perubahan, bukan fitur tambahan yang berdiri sendiri. Signed commit dan signed tag memberi bukti kriptografis, tetapi bukti itu baru bermakna bila diikat ke fingerprint yang diverifikasi, diproteksi lewat branch policy, dan ditegakkan konsisten di CI.

Mulailah dari hal yang paling memberi dampak: signed tag rilis, allowlist fingerprint, dan validasi CI. Setelah itu, perluas ke semua commit penting, rotasi kunci, onboarding perangkat baru, dan signing artefak. Dengan alur ini, tim Anda punya fondasi yang lebih kuat untuk audit, respons insiden, dan integritas rilis jangka panjang.