Checklist hardening repo OSS bukan hanya soal mencegah kebocoran token di GitHub. Untuk proyek open source yang juga menjalankan panel admin, API, dokumentasi, demo publik, atau upload aset, permukaan serangan biasanya berada di luar repositori itu sendiri: session maintainer, secret CI/CD, webhook, bucket file, dependency, dan jalur abuse ketika proyek mendadak viral atau ditinggal maintainer.

Konteks repo OSS populer yang tiba-tiba diarsipkan adalah pengingat bahwa risiko terbesar sering bersifat operasional: akses masih aktif, token tidak dirotasi, demo tetap online tanpa pengawasan, dan pipeline deployment tetap bisa dipicu. Artikel ini fokus pada checklist yang bisa langsung dipakai oleh maintainer dan tim internal, bukan pada beritanya.

Model ancaman yang relevan untuk repo OSS

Sebelum masuk ke checklist, tentukan dulu aset yang benar-benar perlu dilindungi. Banyak tim terlalu fokus pada source code, padahal penyerang justru mengejar kredensial dan service yang mengelilinginya.

Aset yang biasanya luput

  • Akun maintainer: GitHub/GitLab, registry paket, cloud, DNS, provider email, platform observability.
  • Admin panel internal: dashboard support, moderation, feature flag, billing, analytics, CMS docs.
  • API dan webhook: endpoint publik, callback dari payment, Git provider, chatops, issue automation.
  • Demo dan playground: endpoint yang sengaja dibuka ke publik namun sering memakai kredensial backend.
  • Asset upload: image, attachment issue, import file, plugin, template.
  • CI/CD: runner, deploy key, secret environment, publish token registry, bot release.

Skenario serangan yang realistis

  • Maintainer kehilangan akses ke perangkat atau akunnya diambil alih karena MFA lemah.
  • Secret bocor lewat log CI, issue template, screenshot, atau file konfigurasi demo.
  • Session admin bertahan terlalu lama dan dipakai ulang setelah perangkat kompromi.
  • Upload file dipakai untuk menyimpan malware, melakukan XSS, atau menimbulkan biaya storage.
  • Webhook palsu memicu deploy, sinkronisasi data, atau otomasi destructive.
  • Proyek viral menyebabkan scraping, signup abuse, spam, dan lonjakan biaya pada demo/API.
  • Repo ditinggal maintainer tetapi token publish dan automation masih aktif.

Checklist hardening repo OSS yang wajib diprioritaskan

1. Auth untuk maintainer: kecilkan blast radius

Jangan mengandalkan satu akun super-admin untuk semua hal. Pisahkan akses berdasarkan fungsi dan gunakan identitas organisasi, bukan akun pribadi, untuk resource penting.

  • Wajibkan MFA untuk semua maintainer, termasuk akses ke SCM, cloud, registry paket, DNS, dan email domain proyek.
  • Gunakan role terpisah: maintainer kode, approver release, admin cloud, admin DNS, operator support.
  • Hindari shared account. Jika harus berbagi akses darurat, pakai mekanisme break-glass dengan audit.
  • Batasi personal access token: scope minimum, masa berlaku pendek, dan nama token yang jelas.
  • Review akses berkala, terutama setelah perpindahan tim, contributor sementara, atau vendor selesai bekerja.

Mengapa ini efektif? Karena kompromi pada satu akun tidak otomatis berarti kompromi penuh pada semua sistem. Banyak insiden OSS membesar karena orang yang bisa merge kode juga bisa publish paket, mengubah DNS, dan membaca seluruh secret deployment.

Contoh kebijakan maintainer

Setiap maintainer wajib memakai MFA. Akses ke registry paket dan deployment production hanya diberikan melalui role terpisah. Personal token harus memiliki masa berlaku dan scope minimum. Akses contributor sementara dievaluasi ulang maksimal 7 hari setelah tugas selesai.

Anti-pattern umum

  • Satu akun founder menjadi admin untuk GitHub, npm, cloud, DNS, dan email.
  • Token bot tanpa expiry yang dipakai lintas repo dan lintas environment.
  • Machine user tanpa dokumentasi pemilik dan tujuan penggunaan.

2. Session management untuk panel admin dan tools internal

Jika proyek Anda punya panel admin, dashboard docs, atau backend operasi, session harus diperlakukan sebagai kredensial hidup. Banyak tim sudah menerapkan login aman, tetapi session-nya terlalu permisif.

  • Gunakan cookie yang aman: HttpOnly, Secure, dan SameSite sesuai kebutuhan aplikasi.
  • Rotasi session setelah login dan perubahan privilege untuk mencegah session fixation.
  • Terapkan idle timeout dan absolute timeout pada sesi admin.
  • Invalidasi session saat password berubah, MFA di-reset, atau user dihapus dari role admin.
  • Batasi session paralel untuk akun sensitif jika sesuai model operasi tim.
  • Catat event penting: login sukses/gagal, reset MFA, perubahan role, revoke token, perubahan secret.

Trade-off: session yang terlalu pendek memang mengganggu operasional. Namun untuk admin panel, friction moderat biasanya layak dibanding risiko takeover.

# Contoh prinsip konfigurasi session admin (pseudocode)
session.cookie.http_only = true
session.cookie.secure = true
session.cookie.same_site = "Lax"
session.rotate_on_login = true
session.idle_timeout_minutes = 30
session.absolute_timeout_hours = 12
session.invalidate_on_password_change = true

Kesalahan yang sering terjadi

  • Menyimpan token admin di localStorage untuk SPA tanpa mitigasi XSS yang kuat.
  • Tidak membedakan session user biasa dan session admin.
  • Logout hanya menghapus cookie di browser tetapi session server tetap valid.

3. Rotasi secret: anggap secret pasti akan bocor

Secret yang tidak pernah dirotasi pada akhirnya menjadi utang keamanan. Tujuan rotasi bukan sekadar kepatuhan, tetapi memperpendek jendela eksploitasi saat kebocoran terjadi.

  • Inventarisasi secret: API key, deploy key, webhook secret, token bot, service account, credential database, signing key.
  • Klasifikasikan berdasarkan dampak: production write access, read-only, sandbox, publik terbatas.
  • Gunakan mekanisme distribusi yang terpusat daripada file .env yang disalin manual ke banyak server.
  • Dukung dual-secret window bila memungkinkan, agar rotasi tidak memutus trafik.
  • Rotasi setelah insiden operasional: maintainer keluar, log bocor, repo menjadi publik, runner CI disusupi, demo di-takeover.

Praktik implementasi yang masuk akal

  1. Beri nama setiap secret dengan owner dan tujuan penggunaan.
  2. Pastikan secret tidak muncul di log aplikasi dan output CI.
  3. Siapkan runbook rotasi untuk tiap kelas secret.
  4. Uji rotasi di environment non-production sebelum mewajibkan di production.
# Contoh inventory secret yang sederhana
SECRET_NAME=github-release-bot-token
OWNER=platform-team
USED_BY=release-workflow
SCOPE=publish-release-only
ROTATION_PERIOD=90d
LAST_ROTATED=2026-05-01
BREAK_GLASS=no

Anti-pattern umum

  • Satu secret dipakai untuk demo, staging, dan production.
  • Secret registry paket disimpan di repo fork atau pada self-hosted runner tanpa isolasi.
  • Webhook secret tidak pernah diganti karena takut memutus integrasi.

4. Validasi input: jangan percaya issue form, docs, demo, atau admin internal

OSS sering punya banyak jalur input: issue template, feedback form docs, API demo, import config, markdown rendering, dan upload metadata. Semua input harus divalidasi di server, meskipun UI sudah membatasi format.

  • Validasi tipe, panjang, format, dan enum secara eksplisit.
  • Gunakan allowlist untuk field yang diketahui, bukan sekadar menolak karakter tertentu.
  • Normalisasi input bila diperlukan, misalnya trimming, canonicalization path, dan decoding yang konsisten.
  • Sanitasi output saat merender HTML/Markdown untuk mencegah XSS.
  • Gunakan query terparameterisasi dan hindari membangun query atau perintah shell dari input mentah.
// Contoh validasi webhook/body request (Node.js pseudocode)
function validatePayload(body) {
  if (typeof body !== 'object' || body === null) throw new Error('invalid body');
  if (typeof body.event !== 'string') throw new Error('invalid event');
  if (!['release.created', 'issue.opened'].includes(body.event)) {
    throw new Error('unsupported event');
  }
  if (typeof body.timestamp !== 'number') throw new Error('invalid timestamp');
}

Mengapa ini penting untuk OSS? Karena endpoint yang tampak sepele seperti preview markdown, import contoh konfigurasi, atau contact form docs sering menjadi jalur awal eksploitasi.

5. Upload aman untuk demo, docs, dan admin panel

Upload file adalah salah satu area paling sering diremehkan. Bahaya utamanya bukan hanya malware, tetapi juga XSS dari file aktif, file bomb, penyalahgunaan storage, dan kebocoran file privat.

  • Periksa tipe file secara server-side, jangan hanya percaya extension atau header dari browser.
  • Beri nama file baru secara acak atau berbasis ID internal, jangan pakai nama asli sebagai path penyimpanan.
  • Simpan di luar document root bila file tidak perlu dieksekusi publik.
  • Set content-type dan content-disposition secara aman saat file disajikan kembali.
  • Batasi ukuran, jumlah, dan frekuensi upload.
  • Pertimbangkan scanning untuk file berisiko tinggi atau pipeline moderation asinkron.
  • Jangan izinkan file aktif seperti HTML/SVG/script jika tidak benar-benar diperlukan.

Anti-pattern upload

  • Menyimpan file user dengan URL publik permanen tanpa expiry untuk dokumen sensitif.
  • Mengizinkan SVG upload ke area yang akan dirender langsung di browser.
  • Memvalidasi file hanya berdasarkan Content-Type dari request.

6. Rate limit dan abuse control untuk API, docs, dan demo

Saat proyek mendadak viral, ancamannya bukan hanya DDoS. Yang lebih sering adalah scraping agresif, brute force ringan, spam signup, abuse endpoint mahal, dan lonjakan background job.

  • Terapkan rate limit berlapis: per IP, per akun, per token, per route, dan per aksi mahal.
  • Pisahkan limit antara login, reset password, upload, search, dan endpoint inference/demo yang mahal.
  • Gunakan kuota atau budget untuk endpoint yang memicu biaya nyata.
  • Tambahkan circuit breaker operasional untuk mematikan fitur non-esensial saat lonjakan.
  • Berikan respons yang konsisten agar penyerang tidak bisa meng-enumerasi akun dari pesan error.
# Contoh kebijakan rate limit tingkat tinggi
POST /login           -> limit ketat per IP + per akun
POST /password-reset  -> limit ketat + cooldown
POST /upload          -> limit per akun + ukuran total harian
POST /demo/run        -> limit per IP/token + concurrency cap
GET  /search          -> limit moderat + cache

Trade-off: rate limit terlalu agresif bisa memblokir pengguna sah di balik NAT atau jaringan kantor. Karena itu, log keputusan limit dan sediakan mekanisme override terbatas.

7. Lindungi webhook dan token otomasi

Webhook dan bot token sering menjadi pintu belakang karena dianggap bagian internal. Padahal endpoint-nya biasanya publik dan dipanggil otomatis tanpa pengawasan manusia.

  • Verifikasi signature webhook dengan secret bersama.
  • Validasi timestamp atau nonce untuk mengurangi replay attack jika mekanisme penyedia mendukungnya.
  • Bandingkan signature secara constant-time untuk menghindari side-channel sederhana.
  • Batasi aksi webhook pada event yang benar-benar dibutuhkan.
  • Jangan beri token bot akses lebih luas daripada operasi yang diotomasi.
  • Log ID event dan tolak event duplikat bila integrasi berisiko replay.
// Verifikasi signature webhook (pseudocode)
const expected = hmacSHA256(rawBody, WEBHOOK_SECRET)
if (!constantTimeEqual(expected, request.headers['x-signature'])) {
  return 401
}
if (isReplay(request.headers['x-event-id'])) {
  return 409
}

Kesalahan umum

  • Menggunakan endpoint webhook yang sama untuk banyak integrasi dengan secret yang sama.
  • Meneruskan payload webhook langsung ke shell script.
  • Menaruh token bot ke environment semua job CI, termasuk job read-only.

Dependency, supply chain, dan akses CI/CD

Audit dependency: fokus pada jalur eksekusi nyata

Audit dependency tidak cukup dilakukan sekali. Untuk repo OSS, risiko terbesar sering datang dari package yang dipakai oleh tooling release, docs build, script migration, atau demo backend.

  • Bedakan dependency runtime, build, dan tooling.
  • Pin atau kunci versi sesuai mekanisme ekosistem Anda agar build reproduktif.
  • Tinjau package baru sebelum ditambahkan, terutama yang menjalankan post-install script atau punya hak akses luas.
  • Hapus dependency yatim yang sudah tidak dipakai.
  • Audit transitive dependency jika package tersebut menyentuh parsing, auth, upload, atau network.

Limitasi: scanner otomatis membantu menemukan CVE yang diketahui, tetapi tidak akan selalu menangkap paket berbahaya, konfigurasi buruk, atau risiko operasional pada script release.

CI/CD: treat pipeline as production access

Jika pipeline bisa publish paket, deploy docs, atau memutar secret cloud, maka compromise CI/CD hampir setara dengan compromise production.

  • Kurangi secret di pipeline dan pisahkan per workflow.
  • Jangan expose secret ke job dari fork atau workflow yang dipicu input tidak tepercaya.
  • Gunakan environment protection untuk langkah deploy/release yang sensitif.
  • Batasi self-hosted runner dan pisahkan dari workload umum jika runner punya akses jaringan internal.
  • Review permission default token dan turunkan ke hak minimum.
  • Log artifact dan provenance bila tooling Anda mendukungnya.

Anti-pattern CI/CD

  • Workflow lint dari pull request eksternal memiliki akses publish token.
  • Self-hosted runner dipakai bersama untuk build publik dan job deployment internal.
  • Artifact release dibuat dari mesin maintainer lokal tanpa jejak audit.

Abuse prevention saat proyek mendadak viral atau ditinggal maintainer

Ketika repo OSS tiba-tiba ramai, masalah yang muncul bukan hanya skalabilitas. Tim kecil biasanya kewalahan secara operasional, dan celah keamanan muncul karena semua sistem tetap terbuka sementara pengawasan menurun.

Langkah mitigasi cepat saat trafik melonjak

  • Nonaktifkan atau batasi demo mahal sebelum biaya tidak terkendali.
  • Ubah mode pendaftaran menjadi invite-only atau approval untuk area sensitif.
  • Naikkan level proteksi pada login, upload, dan reset password.
  • Aktifkan cache dan antrian untuk endpoint baca dan proses non-kritis.
  • Pisahkan domain publik dan admin agar mitigasi tidak mengganggu operasi internal.

Jika proyek ditinggal maintainer atau diarsipkan

  • Revoke semua akses yang tidak wajib lebih dulu: deploy token, bot token, webhook, credential demo.
  • Pasang banner status di docs/demo bahwa layanan terbatas atau tidak lagi dipelihara.
  • Freeze release automation dan minta approval manual untuk setiap perubahan kritis.
  • Alihkan domain atau matikan endpoint write jika tidak ada lagi tim yang memantau abuse.
  • Backup artifact penting, daftar secret, dan ownership akun agar transisi tidak kacau.

Prinsip praktis: bila tidak ada orang yang secara aktif memonitor sebuah service publik, service itu sebaiknya tidak menerima input write dari internet.

Urutan prioritas implementasi 30/60/90 hari

30 hari pertama: kurangi risiko paling besar

  1. Wajibkan MFA untuk semua maintainer dan audit akses organisasi.
  2. Inventarisasi semua secret, token bot, webhook, deploy key, dan akun layanan.
  3. Rotasi secret berisiko tinggi, terutama publish token, cloud credential, dan webhook secret.
  4. Batasi permission token CI/CD dan pastikan secret tidak tersedia untuk workflow dari fork.
  5. Pasang rate limit pada login, reset password, upload, dan endpoint demo mahal.
  6. Perketat session admin: rotate on login, timeout, revoke on privilege change.
  7. Matikan fitur publik yang tidak dimonitor atau tidak punya owner jelas.

60 hari: perkuat kontrol dan observability

  1. Terapkan role-based access yang lebih ketat untuk maintainer dan operator.
  2. Tambahkan validasi input terpusat untuk endpoint penting.
  3. Perbaiki alur upload file: rename file, batas ukuran, content serving aman, scanning bila perlu.
  4. Verifikasi signature webhook dan tambahkan proteksi replay jika relevan.
  5. Audit dependency runtime dan tooling release/docs/demo.
  6. Tambahkan log audit untuk login admin, perubahan role, revoke token, dan deploy.

90 hari: buat sistem tahan terhadap kekurangan maintainer

  1. Dokumentasikan runbook incident response, rotasi secret, dan shutdown mode untuk demo/API.
  2. Siapkan break-glass access yang diaudit, bukan akun bersama informal.
  3. Terapkan review akses berkala dan owner untuk setiap service publik.
  4. Pisahkan environment demo, staging, dan production secara tegas.
  5. Uji skenario maintainer unavailable: siapa yang revoke token, mematikan webhook, dan menghentikan publish.

Checklist ringkas yang bisa langsung dipakai

  • MFA aktif di SCM, cloud, registry, DNS, email.
  • Role maintainer dipisah dari role deploy/publish/admin cloud.
  • Session admin memakai cookie aman, rotasi session, timeout, dan revocation.
  • Semua secret terinventarisasi, punya owner, scope minimum, dan jadwal rotasi.
  • Webhook diverifikasi dengan signature dan, bila memungkinkan, proteksi replay.
  • Upload file divalidasi server-side, dibatasi ukuran/frekuensi, dan tidak menyajikan file aktif mentah.
  • Rate limit diterapkan per route penting dan endpoint mahal punya budget limit.
  • Dependency runtime, tooling release, docs, dan demo diaudit secara berkala.
  • CI/CD tidak membocorkan secret ke job tak tepercaya dan permission token diperkecil.
  • Ada mode darurat untuk mematikan demo, endpoint write, atau release automation saat abuse.

Penutup

Checklist hardening repo OSS yang efektif tidak berhenti pada secret scanning di repository. Fokus utamanya adalah memastikan bahwa akun maintainer, session admin, token otomasi, upload file, pipeline deploy, dan layanan publik tetap aman ketika proyek mendadak ramai, tim kecil kewalahan, atau maintainer tidak lagi aktif.

Jika Anda harus memilih sedikit hal untuk dikerjakan minggu ini, mulai dari tiga yang paling berdampak: MFA maintainer, rotasi secret berisiko tinggi, dan rate limit pada endpoint yang paling mudah disalahgunakan. Tiga kontrol ini tidak menyelesaikan semuanya, tetapi paling sering menurunkan blast radius secara nyata.