Mengamankan Ephemeral CI Runners dari Supply Chain Drift

Pendahuluan

Ephemeral runner sering dipasarkan seolah-olah otomatis lebih aman karena umurnya singkat. Dalam praktik production, asumsi itu terlalu optimistis. Runner yang hidup hanya beberapa menit tetap bisa memegang akses ke source code, artifact registry, secret manager, dan jalur deploy. Jika satu job dikompromikan, attacker tidak perlu menetap lama. Cukup satu eksekusi yang sukses untuk mencuri token, memodifikasi artifact, atau menyisipkan perubahan pada chain of trust pipeline.

Topik ini menjadi semakin penting pada 2024 sampai 2026 karena supply chain attack makin sering menyasar workflow automation, dependency distribution, dan Git-based delivery path. Build pipeline sekarang bukan hanya tempat kompilasi. Ia adalah control plane perubahan. Ketika control plane ini longgar, impact-nya bisa langsung mencapai production.

Konsep Utama

Ephemeral tidak sama dengan low-risk

Runner yang dihapus setelah job selesai memang mengurangi persistence. Namun ia tidak mengurangi privilege selama job berjalan. Jika identity runner dapat membaca secret, menulis image, dan memicu deploy, compromise singkat tetap cukup untuk menghasilkan dampak besar.

Supply chain drift sering datang dari langkah yang terlihat normal

Masalah tidak selalu berupa malware yang jelas. Lebih sering bentuknya adalah:

• action pihak ketiga dipanggil lewat tag mutable
• dependency build diunduh dari internet tanpa pinning
• artifact dipromosikan tanpa provenance yang cukup
• shared cache mewariskan state dari job sebelumnya

Semua ini terlihat seperti praktik biasa sampai ada satu perubahan kecil yang sulit direkonstruksi.

Identity job harus terikat konteks, bukan disimpan statis

Model yang sehat adalah menukar identity workflow menjadi credential sementara dengan scope sempit. Runner tidak perlu membawa secret cloud jangka panjang hanya untuk melakukan satu tindakan yang sebenarnya bisa dibatasi per repo, per branch, atau per environment.

Arsitektur / Cara Kerja

Desain runner yang lebih aman biasanya mencakup lapisan berikut:

1. orchestrator CI yang membuat runner on-demand
2. runner image immutable yang dikontrol platform team
3. workload identity federation ke cloud atau secret broker
4. egress policy yang sempit
5. artifact signing dan provenance verification
6. teardown yang membersihkan workspace dan cache sensitif

Kuncinya adalah memperlakukan runner sebagai compute sementara yang tetap perlu dicurigai. Trust tidak diletakkan pada mesin, tetapi pada policy eksternal yang mengatur apa yang boleh dilakukan runner tersebut.

Bootstrap runner harus dapat diprediksi

Jika runner image berubah terlalu sering atau dependency bootstrap diambil dari internet saat job start, chain of trust menjadi kabur. Lebih sehat jika base image runner di-hardening, dipublish lewat jalur yang diaudit, dan diperbarui melalui proses yang jelas.

Egress control sering lebih bernilai daripada scanner tambahan

Banyak organisasi menambah scanner di pipeline tetapi tetap membiarkan runner mengakses internet luas. Padahal pada banyak skenario compromise, masalah utama bukan kurangnya scanning, melainkan mudahnya exfiltration dan command-and-control.

Studi Kasus / Masalah Nyata

Action dipanggil lewat tag mutable

Workflow terlihat rapi karena memakai v1 atau stable, tetapi itu bukan trust boundary. Ketika upstream berubah, pipeline kita ikut berubah tanpa ada perubahan di repo sendiri. Dalam incident review, pola ini sangat sulit dijelaskan ke stakeholder karena tidak tampak seperti modifikasi langsung pada source code.

Build dan deploy memakai credential yang sama

Ini masih sering ditemukan. Satu identity dipakai untuk checkout, push artifact, dan deploy ke production. Akibatnya, compromise pada langkah awal pipeline langsung memiliki jalur ke langkah akhir. Pemisahan control plane praktis hilang.

Shared cache menjadi jalur kontaminasi

Ephemeral runner sering tetap bergantung pada cache demi performa. Jika cache tidak diisolasi dengan baik, job yang tercemar dapat meninggalkan dependency, credential residue, atau artifact antara yang dipakai ulang oleh job lain.

Secret bocor lewat log dan artifact

Credential yang tidak di-rotate cepat atau env var yang tercetak dalam debug output masih menjadi sumber kebocoran yang sangat umum. Ketika runner dianggap sementara, tim sering lalai terhadap persistence sekunder seperti log, artifact, atau cache.

Best Practices

Gunakan workload identity, bukan secret jangka panjang

Runner sebaiknya memperoleh credential singkat umur berdasarkan konteks workflow. Scope yang sehat biasanya dibatasi oleh:

• repo
• branch atau ref
• environment
• jenis tindakan seperti read, write, atau deploy

Pisahkan identity build, sign, dan deploy

Artifact yang berhasil dibangun tidak otomatis layak dipromosikan. Jalur sign dan jalur deploy perlu identity yang berbeda, approval yang berbeda, dan log yang berbeda.

Pin dependency dan action yang kritis

Untuk dependency supply chain yang penting, pakai commit SHA, checksum, atau mirror internal. Ini memang menambah friction, tetapi jauh lebih murah daripada menjelaskan ke manajemen kenapa artifact sah ternyata dibangun dari jalur yang berubah diam-diam.

Verifikasi provenance sebelum promotion

Pertanyaan utamanya bukan “artifact ini ada?” tetapi “artifact ini dibangun dari repo mana, workflow mana, identitas mana, dan revision mana?”

Audit teardown runner

Jangan hanya percaya bahwa runner “otomatis hilang”. Pastikan workspace, temporary file, credential cache, dan volume tambahan benar-benar dibersihkan.

Kesalahan Umum

• menganggap ephemeral runner otomatis aman
• memakai secret cloud jangka panjang di CI/CD
• mencampur identity build dan deploy
• membiarkan action dipanggil lewat tag mutable
• mengoptimalkan cache tanpa mendefinisikan trust boundary
• mengabaikan egress control karena dianggap merepotkan

Kesimpulan

Ephemeral CI runner baru memberi manfaat keamanan jika diikat pada identity yang singkat umur, egress yang sempit, bootstrap yang immutable, dan artifact trust yang dapat diverifikasi. Jika tidak, ia hanya menjadi mesin sementara yang membawa privilege besar. Pada production pipeline, tujuan utama bukan membuat runner terlihat modern, melainkan memastikan satu compromise singkat tidak cukup untuk mengubah apa yang akhirnya berjalan di production.