Kebocoran token atau secret di repo GitHub, pipeline CI/CD, atau artifact build adalah salah satu insiden paling “sunyi” tapi paling mahal. Ia sering tidak terlihat seperti serangan klasik (tidak ada malware, tidak ada pop-up), tetapi dampaknya bisa berupa pengambilalihan cloud account, penyalahgunaan API berbayar, hingga akses persisten ke sistem internal lewat integrasi.
Artikel ini adalah playbook ringkas untuk SOC/Blue Team: apa yang harus dilakukan dalam 60 menit pertama, apa yang harus dirotasi, bagaimana berburu indikator penyalahgunaan, dan kontrol pencegahannya. Fokusnya enterprise-ready—bukan sekadar “hapus secret dari repo”.
Kenapa kebocoran secret termasuk insiden supply chain?
Karena jalurnya melewati rantai pengembangan dan distribusi software: repo, pipeline build, registry, dan integrasi pihak ketiga. Begitu secret keluar, penyerang tidak harus menyerang endpoint Anda; mereka cukup memakai kredensial yang valid untuk “masuk lewat pintu depan” (API, cloud console, SaaS). Banyak organisasi baru sadar setelah ada tagihan cloud melonjak atau muncul aktivitas API yang aneh.
Skenario paling umum (yang sering terjadi di lapangan)
- API key tersimpan di file konfigurasi (mis.
.env, YAML) lalu ikut ter-commit. - Token CI/CD (runner token, deploy key) bocor lewat log pipeline atau artifact.
- Credentials cloud (AWS access key, Azure service principal secret) tertanam di skrip otomatisasi.
- Webhook/Slack token yang memberi akses ke channel atau workflow internal.
- Personal access token developer yang punya akses luas ke repo dan package registry.
Triage 0–60 menit (apa yang harus dilakukan dulu)
- Konfirmasi scope kebocoran: secret apa, ada di repo mana, sejak commit mana, apakah repo public/di-fork, apakah artifact/log pipeline terekspos.
- Anggap sudah disalahgunakan jika secret pernah berada di public repo atau log yang bisa diakses pihak luar. Jangan menunggu bukti eksploitasi.
- Rotasi / revoke segera secret yang bocor. Prioritaskan yang berdampak langsung ke produksi (cloud/IAM, database, payment, deploy keys).
- Freeze jalur deploy sementara jika secret terkait pipeline release/production deployment untuk mencegah supply chain tampering.
- Mulai koleksi bukti: simpan hash commit, waktu push, siapa yang push, build log, dan akses audit terkait (cloud/SaaS).
Rotasi yang benar: jangan cuma “ganti key”
Rotasi yang efektif butuh dua hal: (1) key baru terpasang di semua tempat yang memerlukan, (2) key lama benar-benar tidak bisa dipakai lagi.
- Revoke key lama (bukan sekadar “create new key”).
- Batasi blast radius dengan prinsip least privilege: kalau key lama terlalu luas, perbaiki policy saat membuat key baru.
- Periksa turunan secret: token refresh, session token, deploy key, atau credential yang dihasilkan dari secret utama.
- Audit integrasi (GitHub Apps, webhook, CI runner, package registry) yang mungkin memakai secret yang sama.
Hunting: indikator penyalahgunaan yang paling bernilai
Setelah rotasi, pekerjaan SOC belum selesai. Anda perlu mencari apakah secret sempat dipakai sebelum dicabut.
- Cloud audit logs: login dari ASN/geo aneh, pemanggilan API yang tidak biasa, pembuatan IAM user/keys baru, perubahan security group, pembuatan access policy berisiko.
- CI/CD logs: job yang tidak dikenal, perubahan runner, pipeline yang berjalan di luar jam normal, artifact baru yang tidak sesuai.
- GitHub audit log: cloning masif, token usage, creation of new deploy keys, perubahan branch protection, penambahan collaborator.
- Billing/quotas: lonjakan penggunaan API atau cloud resource (mining, data exfil).
Containment lanjutan (kalau ada sinyal kompromi)
- Isolasi workload terkait (VM/container) bila ada indikasi eksekusi perintah atau backdoor.
- Reset credential yang terkait (DB password, service account, OAuth client secret).
- Review integritas pipeline: pastikan script build/release tidak dimodifikasi.
- Jika ada akses ke data sensitif, mulai proses incident response formal (timeline, stakeholder, notifikasi internal).
Checklist mitigasi (pencegahan berulang)
- Aktifkan secret scanning dan blok push yang mengandung pola secret
- Terapkan pre-commit hooks untuk deteksi secret sebelum commit
- Gunakan OIDC / short-lived credentials untuk CI/CD (hindari long-lived keys)
- Batasi akses token (scope minimal, expiry ketat, rotate berkala)
- Jangan simpan secret di repo; pakai vault/secret manager
- Matikan logging yang berpotensi menampilkan secret (masking di CI)
- Perketat branch protection dan review untuk perubahan pipeline
- Monitoring outbound + alert untuk API calls berisiko
Penutup
Leak secret adalah jenis insiden yang menuntut respons cepat dan disiplin. Kuncinya: revoke + rotate dengan benar, lakukan hunting berbasis log, lalu perbaiki kontrol di repo dan pipeline agar kejadian tidak berulang. Jika Anda ingin, saya bisa bantu susun versi yang lebih spesifik untuk stack Anda (GitHub Actions/GitLab CI/Jenkins + cloud yang dipakai) agar checklist-nya langsung “plug and play”.