Gerbang Redaksi Mekanis Sebelum Publish
Style guide kepotong diam-diam di 9000 karakter. Solusinya bukan niat baik, tapi gerbang mekanis yang menyaring IP dan token di artefak final.
Ringkasan
Style guide ternyata kepotong di 9000 karakter, jadi aturan redaksi pencegah bocor IP dan kredensial nggak pernah nyampe ke model. Solusinya: guide di-load utuh plus gerbang mekanis check_redaction di verify yang nge-scan semua IP dan token di artikel final. Pelajarannya, validasi artefaknya bukan niat penulisnya, soalnya false positive cuma makan lima menit, kebocoran yang keindeks itu permanen.
Pas ngerapikan style layer pipeline artikel kemarin, saya nemu potongan yang bikin berhenti ngopi: system prompt di salah satu engine dipotong mentah di 9000 karakter, sementara style guide udah tumbuh lebih panjang dari itu. Artinya ada bagian guide yang nggak pernah sampai ke model penulis. Yang kebagian potong bukan sembarang bagian: aturan redaksi, persis bagian yang nyegah bocornya IP dan kredensial.
Solusi di commit kemarin dua lapis. Pertama, guide di-load utuh di kedua engine, nggak ada lagi slice diam-diam. Kedua, yang lebih penting: verifikasi artikel dapat gerbang mekanis baru, check_redaction, yang jalan di cmd_verify. Logikanya sederhana. Prompt bisa kepotong, bisa di-ignore model, bisa ketimpa revisi. Artefak final yang mau di-publish nggak bisa negosiasi.
Kenapa ini nggak bisa diasuh niat baik
Cheat sheet OWASP soal secrets management masih perlu ngingetin hal yang kedengarannya klasik: banyak organisasi masih naruh kredensial langsung di source code dalam bentuk plaintext [3]. Github membangun secret scanning yang mindai seluruh riwayat Git dengan alasan yang sama, kredensial yang ke-commit jadi target akses nggak sah [2]. Kalau repo privat aja bisa bocor lewat riwayat commit, artikel blog yang sekali terindeks mesin pencari jeleknya jauh lebih permanen. Nggak ada rotate credential buat paragraf yang udah tayang. Tool sekelas gitleaks ngoding prinsip ini sampai ke exit code: 0 berarti nggak ada kebocoran, 1 berarti ada kebocoran atau error [4].
Makanya saya nggak percaya sama kesepakatan "nanti diinget-inget aja pas nulis". Gate harus mekanis, fail-level, dan nyamber seluruh konten, termasuk code block. Kebocoran di dalam fence ya tetap kebocoran; scanner yang nge-skip code block cuma bikin rasa aman palsu.
Aturan yang saya pasang
Untuk alamat IPv4, gerbangnya pakai allowlist: satu-satunya IP yang boleh muncul di artikel adalah tiga blok dokumentasi dari RFC 5737, yaitu 192.0.2.0/24, 198.51.100.0/24, dan 203.0.113.0/24 [1]. RFC-nya sendiri bilang blok-blok ini semestinya nggak pernah muncul di internet publik [1], jadi mereka ideal buat contoh: realistis secara format, mustahil tabrakan sama server siapa pun.
Untuk token, deteksinya prefix-based dan absolut: pola AKIA, ghp_, sk-, dan xox langsung gagal tanpa pengecualian apa pun. Ini keputusan yang agak kejam, karena contoh key di dokumentasi resmi AWS pun bakal kena. Saya biarkan begitu. Prefix itu struktur, bukan nilai, dan struktur nggak butuh konteks buat dinilai. Pola sk- juga saya prilebar sampai nangkep hyphen, biar format kunci baru kayak sk-proj- nggak lolos gara-gara tanda hubung.
Satu-satunya kompromi ada di heuristic assignment kayak password = "...". Di situ placeholder eksplisit dikecualikan: nilai yang pakai penanda jelas kayak <DB_PASSWORD> atau YOUR_ lolos, nilai asal 8 karakter ke atas gagal. Tanpa pengecualian ini, gate-nya bakal rewel ke contoh sendiri terus, dan gate yang terlalu rewel pasti dimatiin orangnya. Itu lebih bahaya daripada komprominya.
Cek sendiri, jangan percaya
Inti gerbangnya sekecil ini:
import re
IP_RE = re.compile(r"\b(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\b")
ALLOWED = ("192.0.2.", "198.51.100.", "203.0.113.")
def ip_aman(text: str) -> bool:
return all(ip.startswith(ALLOWED) for ip in IP_RE.findall(text))
assert ip_aman("ping 192.0.2.55")
assert ip_aman("backup ke 198.51.100.7")Jalanin itu, duanya lolos. Sekarang ganti string-nya sama alamat server kantor kamu, assert-nya langsung meledak. Persis itu yang gerbang lakukan tiap kali verify: bandingin semua IP yang ketemu sama tiga prefix dokumentasi, satu aja di luar berarti gagal.
Selftest di commit-nya lebih galak lagi, dan galaknya memang disengaja: IP pribadi harus gagal, tiga blok TEST-NET harus lolos, PAT GitHub panjang 36 karakter harus gagal, placeholder <YOUR_API_KEY> justru harusnya dilewatin, dan assignment password berisi string asal-asalan harus kejatpin. Salah satu aja yang balik arah, verify-nya berhenti sebelum ada yang sempat publish.
Trade-off yang saya terima jelas: kadang ada false positive, contoh yang sah ikut ketangkap. Tapi biaya false positive cuma lima menit ganti ke rentang dokumentasi. Biaya false negative adalah topologi internal yang kebaca selamanya di arsip. Nggak sulit milih.
Kalau kamu punya pipeline publishing apa pun, prinsip yang bisa dibawa: validasi artefak finalnya, bukan niat penulisnya. Sistem yang rewel di awal itu murah. Kebocoran yang udah terindeks nggak punya harga pembandingnya.