Belajar Git - Keamanan Repository & Branch Protection Rules

#Pendahuluan

Di episode 12 kita belajar mengelola pekerjaan dengan GitHub Issues. Kini bayangkan tim kalian besar: puluhan developer bisa push ke main dan beberapa di antaranya lupa menulis deskripsi PR atau menaruh password di file konfigurasi. Tanpa keamanan yang disepakati, satu commit saja bisa menghancurkan produksi atau membocorkan kredensial perusahaan.

Episode ini membahas dua sisi keamanan repository: menegakkan aturan lewat Branch Protection Rules sehingga kode tidak sembarangan masuk ke main, dan mencegah serta menangani kebocoran secret — API key, private key, atau database credential — menggunakan GitHub Secret Scanning dan Dependabot Alerts. Di akhir, kita bahas langkah darurat jika secret sudah terlanjur ter-commit.

#Bahaya Secret Leakage

Secret adalah informasi yang memberi akses: API key, token, private key SSH, username dan password database, hingga kredensial cloud. Begitu sebuah secret masuk ke commit dan ter-push, ia tersimpan selamanya di history Git — bahkan jika file-nya dihapus pada commit berikutnya, secret itu tetap bisa ditemukan di history oleh siapa pun yang punya akses repository.

Bahayanya berlipat di repository publik: attacker dan bot scanner terus memindai GitHub untuk pola secret. Sekali tertangkap, akun cloud, database, atau layanan lain bisa dikendalikan orang lain — sering dalam hitungan menit. Karena itu secret leakage bukan "masalah kecil yang bisa dibersihkan nanti", melainkan insiden yang wajib ditangani serius.

#Mencegah Secret Masuk ke Commit

Aturan pertama dan termurah adalah pencegahan: jangan pernah menulis secret di file yang di-track Git. Gunakan file .env yang ada di .gitignore, dan masukkan nilai rahasia lewat environment variable saat deployment.

Contoh file env yang aman

# .env.local — tidak boleh di-commit
 
DATABASE_URL=postgres://user:pass@db.example.com:5432/app
 
API_KEY=sk_live_1234567890abcdef

Pastikan .gitignore memuat entri berikut sebelum git add .:

Mengabaikan file env

# .gitignore
.env
.env.local
.env.production

#GitHub Secret Scanning & Dependabot Alerts

Meski sudah berhati-hati, manusia tetap bisa salah. GitHub menyediakan dua lapisan pertahanan otomatis:

Secret Scanning — memindai repository (dan riwayat commit) untuk pola secret dari ribuan penyedia: AWS, Google Cloud, GitHub tokens, Stripe, dan banyak lagi. Saat ditemukan, GitHub memberi peringatan, dan untuk beberapa penyedia langsung memberi tahu pemilik secret agar di-revoke. Aktifkan di Settings → Code security and analysis → Secret scanning.

Dependabot Alerts — memantau dependency yang dipakai repository dan memperingatkan bila ada CVE (kerentanan yang diketahui). Dependabot bahkan bisa membuat Pull Request perbaikan secara otomatis lewat Dependabot security updates.

Dependabot: cek npm setiap hari

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 5

Workflow ini berada di .github/dependabot.yml. Dengan konfigurasi sederhana ini, Dependabot mengecek dependency setiap hari dan membuka PR versi terbaru.

#Branch Protection Rules

Branch Protection Rules adalah kebijakan yang mewajibkan kondisi tertentu sebelum commit bisa masuk ke sebuah branch — paling umum diterapkan pada main. Atur lewat Settings → Branches → Add branch protection rule, lalu masukkan nama branch seperti main.

Opsi kunci yang wajib kalian kenal:

Require a pull request before merging — semua perubahan harus lewat PR, dan butuh review yang disetujui.
Require status checks to pass — CI/CD (misal lint dan test) harus hijau sebelum merge.
Require signed commits — commit harus ditandatangani dengan GPG atau SSH key untuk memastikan identitas penulis.

Dengan kombinasi ketiganya, tidak ada kode yang masuk main tanpa PR, tanpa CI hijau, dan tanpa identitas terverifikasi — gerbang kualitas dan keamanan sekaligus.

Workflow CI yang diharuskan sebagai status check

name: CI
on: [push, pull_request]
jobs:
  lint-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: bun install --frozen-lockfile
      - run: bun run lint
      - run: bun run test

Commit yang ditandatangani bisa diverifikasi dari terminal:

Verifikasi tanda tangan commit

git verify-commit HEAD
git log --show-signature -3

Note

Branch protection diterapkan per branch dengan pola nama, jadi kalian bisa membuat aturan berbeda untuk main (ketat), staging (sedang), dan feature/* (longgar). Mulailah dari yang paling penting: main.

#Langkah Darurat jika Secret Terlanjur Ter-commit

Tenang, ikuti urutan ini. Yang paling penting bukan menghapus history — tapi mencabut akses secret tersebut secepatnya.

Warning

Jangan mencoba "membersihkan" secret hanya dengan git reset --hard lalu force push. git reset --hard menghancurkan perubahan dan tidak menghapus secret dari history yang sudah ter-push — secret tetap ada di commit lama, di clone rekan kerja, dan di cache GitHub. Rotate secret dulu, baru bersihkan history.

Urutan tindakan darurat:

Rotate atau revoke secret di penyedianya (misal regenerate API key di AWS, reset password database). Ini satu-satunya langkah yang benar-benar menetralkan kebocoran.
Hapus secret dari file dan tambahkan file tersebut ke .gitignore.
Bersihkan history dengan git filter-repo (penerus filter-branch yang lebih aman dan cepat) atau BFG.
Push ulang dengan koordinasi tim — ini termasuk kategori force push yang perlu izin.
Ajak semua orang yang pernah clone untuk melakukan hard reset ke commit terbaru.

Hapus file env dari seluruh history

git filter-repo --invert-paths --path .env.local
git remote add origin <URL-repository>
git push --force origin main

Catatan: git filter-repo menghapus konfigurasi remote — karena itu remote ditambahkan lagi setelahnya.

Tip

Secret Scanning akan menandai secret yang pernah terdeteksi bahkan setelah dihapus dari file. Setelah rotate dan bersihkan history, pastikan status secret di Security → Secret scanning sudah di-revoke — hanya revoke yang benar-benar menutup risiko.

#Penutup

Episode ini menutup celah keamanan terbesar sebuah repository: menegakkan aturan lewat Branch Protection Rules dengan require PR, status checks, dan signed commits; memahami bahaya API key, private key, dan database credential yang ter-commit; mencegah kebocoran dengan .gitignore; memanfaatkan GitHub Secret Scanning dan Dependabot Alerts; serta menangani insiden dengan rotate secret sebelum membersihkan history.

Poin yang harus kalian bawa:

Branch protection pada main mewajibkan PR, status checks hijau, dan commit yang ditandatangani.
Secret yang ter-push tersimpan permanen di history — pencegahan lebih baik daripada pembersihan.
Secret Scanning dan Dependabot Alerts adalah lapisan pertahanan otomatis GitHub.
Saat secret bocor: rotate dulu, baru bersihkan history dengan git filter-repo.
git reset --hard menghancurkan perubahan dan tidak menghapus secret dari remote.

Keamanan membereskan masa depan; episode berikutnya membereskan masa lalu. Di episode 14 kita membahas Penjelajahan Waktu & Pembatalan Perubahan (Undoing Changes) — git restore, git revert, dan git reset beserta kapan masing-masing aman dipakai. Sampai jumpa di episode 14!