Repository Security Checklist

Dua belas chapter sebelumnya memasang pagar satu per satu: kredensial yang aman, token yang berumur pendek, riwayat yang bersih, tanda tangan yang terverifikasi, izin yang sempit. Masalahnya, pagar itu melapuk diam-diam — orang keluar tim tapi tokennya hidup, konfigurasi bergeser, berkas rahasia menyusup lewat commit yang terburu-buru. Keamanan repository bukan keadaan yang dicapai sekali, melainkan rutinitas yang diperiksa berulang. Chapter penutup ini merangkai seluruh pembahasan menjadi satu checklist audit yang dikelompokkan per pilar — setiap item disertai cara mengeceknya dari terminal dan fitur platformnya — lalu mengujinya tuntas pada repository sandbox yang nyata.

Enam Pilar Pemeriksaan #

Audit yang ringkas menanyakan enam kelompok pertanyaan berikut — masing-masing sudah dibedah tuntas di chapter rujukannya:

Pilar	Pertanyaan kunci	Rujukan
AKSES	siapa punya akses, dan masih perlukah?	Least Privilege
BRANCH	apakah main terproteksi dan review wajib?	Protected Branches
KREDENSIAL	apa yang tersimpan di mana, dan berumur berapa lama?	Credential Helper
SECRET	apakah riwayat bersih dari kredensial?	Secret dalam Riwayat Git
SIGNATURE	apakah commit dan tag terverifikasi?	Signed Commits
BACKUP	apakah ada cadangan bila server hilang?	Backup Repository

AKSES #

Pemeriksaan akses membandingkan dua daftar: penulis yang pernah menyentuh riwayat, versus orang yang masih memegang kunci hari ini.

Item	Cara cek lokal	Fitur platform
daftar penulis riwayat	`git log --pretty=format:'%an <%ae>' \| sort -u`	halaman Collaborators / Members
permission masih dibutuhkan	—	permission level per kolaborator
token dan deploy key yang menganggur	—	daftar token + deploy keys + waktu pemakaian terakhir
2FA aktif untuk semua anggota	—	halaman keamanan akun dan organisasi

Kolom “cara cek lokal” kosong berarti pemeriksaannya memang hanya ada di sisi platform — Least Privilege menjelaskan cara membaca halaman-halamannya dan aturan level terendah yang menyelesaikan pekerjaan.

BRANCH #

Proteksi branch bekerja di sisi server, sehingga tidak terbaca dari clone — yang bisa diperiksa lokal hanya jejaknya: workflow yang menuntut review meninggalkan commit merge pada setiap pull request yang masuk.

Item	Cara cek lokal	Fitur platform
review pernah terjadi	`git log --merges --oneline`	branch protection: require pull request
main tidak bisa ditimpa	—	branch protection: larang force-push
pemilik berkas jelas	—	CODEOWNERS

Bila git log --merges kosong pada repo yang ramai commit, itu pertanyaan — apakah semua orang mendorong langsung ke main? Mekanisme pagarnya dibedah di Protected Branches .

KREDENSIAL #

Semua kredensial yang menempel pada clone diperiksa dari berkas konfigurasi dan remote-nya.

Item	Cara cek lokal	Fitur platform
URL remote bebas token	`git remote -v` dan `cat .git/config`	—
helper yang aktif aman	`git config --local --list`	—
umur dan scope token	—	daftar token dengan waktu pemakaian terakhir

URL ber-token di .git/config adalah pola yang paling sering lolos — Keamanan Credential membuktikan betapa mudah token tersembunyi di sana; Mengelola Token mengatur umur, scope, dan rotasinya.

SECRET #

Pemeriksaan cepat bisa lokal; pemindaian menyeluruh membutuhkan alat khusus.

Item	Cara cek lokal	Fitur platform
berkas rahasia di riwayat	`git log --all --oneline -- .env`	secret scanning
nilai rahasia di riwayat	`git log --all -S <nilai> --oneline`	push protection
pola lintas seluruh riwayat	`gitleaks detect --source .`	secret scanning

gitleaks memindai seluruh riwayat dengan basis pola kunci API yang dikenal — alatnya ada di gitleaks dan sandbox sengaja tidak memasangnya, jadi perintahnya cukup dicatat tanpa keluaran. Secret dalam Riwayat Git menjelaskan batas secret scanning platform; bila secret terbukti pernah masuk, urutan responsnya rotasi dulu lalu membersihkan riwayat .

SIGNATURE #

Kolom %G? pada git log merangkum status tanda tangan seluruh riwayat dalam satu perintah.

Item	Cara cek lokal	Fitur platform
commit bertanda tangan valid	`git log --pretty=format:'%h %G? %an %s'`	lencana Verified
detail verifikasi satu commit	`git log --show-signature -1`	—
tag rilis terverifikasi	`git tag -v <tag>`	—

Nilai G berarti valid, N berarti tanpa tanda tangan, B rusak, U tak bisa dicek — penegasannya ada di Signed Commits , alat GPG dan SSH-nya di GPG Signing dan SSH Signing .

BACKUP #

Cadangan adalah satu-satunya pilar yang dites dengan skenario terburuk: server platform hilang beserta seluruh riwayatnya.

Item	Cara cek lokal	Fitur platform
bundle cadangan masih utuh	`git bundle verify <berkas>.bundle`	—
mirror terbaru tersedia	`ls -l <direktori-mirror>`	—
objek LFS ikut tercadangkan	`git lfs ls-files`	—
jadwal cadangan berjalan	`crontab -l`	—

Satu jebakan penting: git clone --mirror dan git bundle menyalin objek Git, tetapi bukan objek Git LFS — repository ber-LFS butuh git lfs fetch --all tambahan; bila git lfs ls-files kosong, cadangan biasa memang cukup. Cara kerja mirror dan bundle dibedah di Backup Repository .

Latihan: Audit Mini di Sandbox #

Enam pilar di atas sekarang dijalankan pada latihan-audit — repository sandbox berisi satu commit dan satu tag rilis yang keduanya bertanda tangan. Audit dibuka dari berkas yang paling sering menyimpan kejutan:

bash

cat .git/config

ini
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[user]
	name = Budi Santoso
	email = [email protected]
	signingkey = A2D50BF118FC146C
[remote "origin"]
	url = ../latihan-audit.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
	remote = origin
	merge = refs/heads/main

ID kunci dan hash pada keluaran audit ini berbeda di mesin pembaca. Konfigurasi ini lolos dua pemeriksaan sekaligus: url remote bersih dari token, dan signingkey terpasang — tanda penandatanganan aktif. Pemeriksaan kredensial berlanjut ke daftar remote:

bash

git remote -v

text

origin  ../latihan-audit.git (fetch)
origin  ../latihan-audit.git (push)

Pilar SIGNATURE diperiksa dua tingkat — ringkasan seluruh riwayat, lalu detail commit dan tag:

bash
git log --pretty=format:'%h %G? %an %s'

text

f9f1369 G Budi Santoso Commit awal proyek

bash

git log --show-signature -1

text
commit f9f1369fbb5b2aad11c3d3efef82cb9dcefd8fdf
gpg: Signature made Tue Oct 13 21:59:05 2026 WIB
gpg:                using RSA key A0299D959A5667633CC8060CA2D50BF118FC146C
gpg: Good signature from "Budi Santoso <[email protected]>" [ultimate]
Author: Budi Santoso <[email protected]>
Date:   Tue Oct 13 21:59:05 2026 +0700

    Commit awal proyek

bash

git tag -v v1.0.0

text
gpg: Signature made Tue Oct 13 21:59:05 2026 WIB
gpg:                using RSA key A0299D959A5667633CC8060CA2D50BF118FC146C
gpg: Good signature from "Budi Santoso <[email protected]>" [ultimate]
object f9f1369fbb5b2aad11c3d3efef82cb9dcefd8fdf
type commit
tag v1.0.0
tagger Budi Santoso <[email protected]> 1791903545 +0700

Rilis 1.0.0

Waktu pada keluaran gpg menyesuaikan jam pembuatan kunci di mesin masing-masing. Empat pemeriksaan cepat menutup pilar AKSES, BRANCH, dan SECRET — daftar penulis, jejak review, berkas .env, dan LFS:

bash
git log --pretty=format:'%an <%ae>' | sort -u
git log --merges --oneline
git log --all --oneline -- .env
git lfs ls-files

text

Budi Santoso <[email protected]>

text

Tiga keluaran kosong terakhir justru hasil yang dibaca: tidak ada jejak merge, tidak ada .env di riwayat mana pun, dan tidak ada berkas LFS. Yang pertama jadi catatan — pada repo riil yang ramai, keluaran git log --merges yang kosong patut dicurigai: review mungkin memang tidak pernah diwajibkan, dan itu temuan untuk pilar BRANCH. Terakhir, pilar BACKUP diuji dengan membuat dan memverifikasi bundle:

bash

git bundle create ../cadangan-audit.bundle --all
git bundle verify ../cadangan-audit.bundle

text
../cadangan-audit.bundle is okay
The bundle contains these 4 refs:
f9f1369fbb5b2aad11c3d3efef82cb9dcefd8fdf refs/heads/main
f9f1369fbb5b2aad11c3d3efef82cb9dcefd8fdf refs/remotes/origin/main
4c81e4da693291c4938e91d037f0d8e4a5119e53 refs/tags/v1.0.0
f9f1369fbb5b2aad11c3d3efef82cb9dcefd8fdf HEAD
The bundle records a complete history.
The bundle uses this hash algorithm: sha1

Baris is okay dan records a complete history menutup pilar terakhir: cadangan ada, utuh, dan memuat seluruh ref — --all ikut membawa remote-tracking dan tag.

Rekap Hasil Audit #

Pilar	Hasil pada latihan	Tindak lanjut
AKSES	satu penulis tercatat	cocokkan dengan halaman Collaborators di platform
BRANCH	tanpa jejak review — temuan	aktifkan proteksi main dan review wajib
KREDENSIAL	config dan remote bersih	periksa umur token di halaman pengaturan
SECRET	`.env` tidak ada di riwayat	jalankan gitleaks untuk pola yang lebih luas
SIGNATURE	commit dan tag `G` + Good signature	pertahankan; pastikan kunci terdaftar di platform
BACKUP	bundle terverifikasi utuh	jadwalkan mirror/bundle secara rutin

Hasil latihan menunjukkan pola audit yang sehat: sebagian besar pilar lolos, satu menemukan celah nyata, dan tiap baris diakhiri tindak lanjut — checklist yang tidak menghasilkan tindakan hanyalah formalitas.

Checklist ini bekerja sejauh dijalankan manusia yang disiplin — dan disiplin justru yang paling mudah lupa saat tengah malam menjelang rilis. Kabar baiknya: sebagian besar pemeriksaan di atas bisa dipindahkan ke mesin yang tidak pernah lupa — hook yang menolak commit ber-secret sebelum terjadi, server yang menolak push yang tak bertanda tangan, CI yang menjalankan audit tiap malam. Pemindahan itulah pokok bahasan Section berikutnya: Hooks dan Otomasi .