Ringkasan

Guardian adalah lapisan monitoring yang dibangun sebagai respons atas kampanye supply-chain nyata (Oktober 2026) yang menanam execution hook dorman dan payload terselubung ke repositori saya lewat penulisan ulang riwayat git — commit kembar yang membawa pesan, tanggal, dan author asli di atas tree yang berbeda. Ia menjawab satu wawasan struktural: apa pun yang tersimpan di dalam repo korban bisa dinetralkan oleh kredensial yang sama yang menginfeksinya. Proteksi branch, workflow, script revert — semuanya bisa diedit di dalam repo. Karena itu penjaganya hidup di luar radius ledakan, dan PAT-nya baca-saja.

Arsitektur & Alur

guardian-sweep.yml (repo guardian, publik = menit Actions gratis)
  • cron ×4/jam (:02 :17 :32 :47 — slot redundan; GitHub menjatuhkan
    run terjadwal saat beban tinggi) + workflow_dispatch
  • mendaftar repo via fine-grained read-only PAT, scan tiap branch
  • temuan → GitHub issue + notifikasi Telegram
  • dedup issue: komentar pada issue IOC terbuka <90 menit

malware-guard.yml (per-repo, repo privat tanpa rencana ruleset)
  • on push: scan tree → verdict != clean → force-revert branch
    ke SHA pra-push via GITHUB_TOKEN ephemeral (tak ada yang bisa dicuri)

rulesets (repo publik): required_signatures + non_fast_forward + deletion
guardian-dispatcher (Cloudflare Worker): heartbeat eksternal
guardian-webhook (Cloudflare Worker): webhook terverifikasi HMAC → scan → revert

Temuan → issue → Telegram, ujung ke ujung: saat sweep mendeteksi artefak, ia membuka GitHub issue di repo guardian dengan kelas temuan dan ref yang terdampak — nama repo disamarkan sebagai R-<8hex> (sha256(nama+salt), di-resolve lokal via map turunan karena salt tak pernah meninggalkan mesin) — dan mengirim pesan Telegram ke grup privat via bot API dengan nama repo asli beserta path artefaknya. Temuan dobel dalam 90 menit menjadi komentar pada issue terbuka, bukan spam baru.

Deteksi dua tahap menjaga pemakaian API tetap waras: tahap 1 memilih kandidat dari tree API (path + size, satu panggilan per branch) — kebijakan kehadiran untuk .vscode/* dan public/fonts/*, permukaan eksekusi, pola font palsu cocok-nama pada ukuran berapa pun (payload .orc 29KB pernah lolos dari gerbang 10KB naif); tahap 2 mengambil dan mengadopsi konten dengan marker dua-kondisi. Setiap kegagalan fetch adalah SCAN-ERROR, tidak pernah verdict bersih — satu run yang kena throttle pernah melaporkan 134 ref terinfeksi sebagai bersih dengan gagal diam-diam; kelas keheningan itu dihilangkan dari desain.

Scheduler yang berhenti secara diam: setelah kampanye, scheduler GitHub Actions mulai menjatuhkan cron native repo itu (dugaan abuse-flag akun; workflow_dispatch tetap jalan). Perbaikannya guardian-dispatcher — Cloudflare Worker pada cron */20 yang memeriksa run sweep terakhir via API publik (tanpa token) dan mendispatch hanya saat basi (>45 menit), menjadikannya idempoten dengan cron native: siapa pun yang menyala duluan menang, tak ada sweep ganda. guardian-webhook menutup jalur push: webhook repo → verifikasi HMAC → scan IOC → force-revert + Telegram, hidup di luar semua repo dengan token Contents-RW yang sengaja tanpa scope workflow.

Batasan Platform yang Dipelajari (cara keras)

• Branch ruleset: repo publik di plan apa pun; repo privat butuh Pro/Team — kegagalan dilaporkan, tidak fatal (guard in-repo menutup celahnya)
• Path blocking server-side (file_path_restriction): hanya repo org di plan berbayar — kontrol kompensasinya kecepatan deteksi (≤ ~1 jam)
• Commit via REST Contents-API tidak bertanda tangan — workflow yang commit via API harus hidup di repo tanpa required_signatures (alasan ruleset guardian sendiri mengomisinya)
• if: pada langkah force-revert harus menyertakan always() — langkah scan exit 1 saat deteksi, dan GitHub melewati langkah bergantung saat merah

Lapisan-Lapisannya Hari Ini