Pipeline yang selesai lebih cepat sering dianggap sebagai tanda bahwa proses pengembangan telah semakin efisien. Durasi build menurun, penggunaan runner lebih hemat, dan developer tidak perlu menunggu terlalu lama untuk memperoleh hasil pengujian.

Namun, pipeline yang cepat belum tentu menghasilkan artefak baru.

Sebagian dependency, file hasil kompilasi, container layer, atau output generator mungkin berasal dari cache yang dibuat beberapa hari sebelumnya. Selama cache key dinilai cocok, pipeline dapat memulihkan hasil lama dan melanjutkan proses seolah-olah semua komponen baru saja dibangun.

Di sinilah efisiensi berubah menjadi keputusan keamanan. Setiap cache hit sebenarnya merupakan keputusan untuk mempercayai pekerjaan sebelumnya tanpa mengulang seluruh proses yang semestinya membuktikan integritas hasil build.

Status Berhasil Tidak Selalu Berarti Semuanya Dikerjakan Ulang

Status hijau pada pipeline hanya menunjukkan bahwa serangkaian instruksi telah selesai tanpa menghasilkan kesalahan yang dianggap fatal. Status tersebut tidak otomatis membuktikan bahwa semua tahap benar-benar dijalankan dari awal.

Pada pipeline yang menggunakan cache CI/CD, beberapa pekerjaan dapat dilewati karena output sebelumnya dianggap masih berlaku. Mekanisme ini memang dirancang untuk mempercepat proses yang berulang.

Masalah muncul ketika pipeline tidak mampu membedakan antara hasil yang masih relevan dan artefak yang seharusnya tidak lagi dipercaya.

Perubahan source code mungkin telah terdeteksi, tetapi perubahan konfigurasi build tidak ikut diperhitungkan. Dependency lockfile mungkin menjadi bagian dari cache key, sedangkan versi compiler, base image, aturan keamanan, atau file workflow tidak disertakan.

Akibatnya, pipeline terlihat baru dari sisi waktu eksekusi, tetapi sebagian isinya masih berasal dari kondisi lama.

Cache Hit Merupakan Keputusan untuk Mempercayai Masa Lalu

Cache CI/CD umumnya diperlakukan sebagai persoalan performa. Padahal, dari sisi keamanan, cache merupakan lapisan kepercayaan.

Ketika sebuah cache dipulihkan, pipeline secara tidak langsung membuat beberapa asumsi:

• input yang memengaruhi hasil belum berubah;
• isi cache berasal dari proses yang tepercaya;
• komponen di dalamnya belum dimanipulasi;
• hasil lama masih sesuai dengan source code terbaru;
• kontrol keamanan sebelumnya masih relevan;
• cache tidak dibuat oleh workflow dengan tingkat kepercayaan lebih rendah.

Jika salah satu asumsi tersebut tidak benar, pipeline dapat menghasilkan artefak yang berbeda dari hasil yang seharusnya dibuat melalui clean build.

Risiko ini semakin besar ketika cache memuat file yang akan dieksekusi, dikompilasi, dikemas, ditandatangani, atau langsung dimasukkan ke dalam artefak production.

Tidak Semua Cache Memiliki Risiko yang Sama

Cache dependency biasanya menyimpan package yang sebelumnya telah diunduh. Tujuannya agar pipeline tidak selalu mengambil package yang sama dari registry.

Build cache dapat menyimpan object file, hasil kompilasi sebagian, atau output antara. Container layer cache digunakan untuk menghindari pembangunan ulang layer yang dianggap tidak berubah.

Selain itu, pipeline dapat menyimpan toolchain, plugin, generated code, bundle aplikasi, file konfigurasi, atau aset yang dihasilkan oleh proses sebelumnya.

Setiap jenis cache memiliki tingkat risiko berbeda.

Cache berisi salinan package yang masih divalidasi sebelum digunakan memiliki risiko lebih rendah daripada cache yang berisi binary siap dijalankan. Begitu pula, cache kompilasi yang tetap diperiksa akan berbeda risikonya dengan output build yang langsung dipindahkan ke artifact repository.

Batas antara cache dan artefak rilis dapat menjadi kabur ketika keduanya disimpan, dipanggil, dan digunakan melalui mekanisme yang hampir sama.

Artefak Lama Dapat Dipercaya sebagai Hasil Build Baru

Artefak lama tidak selalu muncul karena serangan. Kesalahan konfigurasi sederhana juga dapat membuat cache bertahan lebih lama daripada semestinya.

Salah satu penyebabnya adalah cache key yang terlalu umum. Sebuah cache mungkin hanya dibedakan berdasarkan nama branch atau sistem operasi, tanpa mempertimbangkan seluruh input yang memengaruhi hasil build.

Penggunaan restore key yang terlalu luas juga dapat membuat pipeline memilih cache yang hanya memiliki kecocokan sebagian. Ketika cache spesifik tidak ditemukan, pipeline mengambil versi terdekat yang tersedia.

Secara operasional, proses tersebut membantu mencegah cache miss. Namun, dari sisi keamanan, kecocokan sebagian belum tentu cukup untuk membuktikan bahwa isi cache sesuai dengan kebutuhan build terbaru.

Beberapa kondisi yang dapat menyebabkan artefak lama digunakan kembali meliputi:

• dependency lockfile berubah tetapi cache tidak diperbarui;
• versi runtime atau compiler tidak menjadi bagian dari cache key;
• file konfigurasi build berubah tanpa memicu invalidasi;
• security rules diperbarui tetapi hasil analisis lama tetap digunakan;
• container base image berubah dengan tag yang sama;
• output kompilasi disimpan bersama cache dependency;
• perubahan source code tidak memengaruhi identitas cache;
• cache digunakan bersama oleh beberapa branch;
• pipeline melakukan rollback tanpa membedakan cache setiap versi;
• generated code tidak dibuat ulang setelah spesifikasi berubah.

Dalam kondisi tersebut, nama rilis dapat berubah, tetapi bagian tertentu dari artefak masih berasal dari build sebelumnya.

Cache Dapat Membuat Kontrol Keamanan Tidak Dijalankan Kembali

Cache tidak otomatis melewati kontrol keamanan. Risiko muncul ketika workflow menggunakan cache hit sebagai alasan untuk tidak menjalankan kembali proses tertentu.

Sebagai contoh, pipeline dapat melewati instalasi dependency karena folder package telah tersedia. Jika tidak ada validasi tambahan, pipeline mungkin tidak memeriksa apakah isi folder tersebut masih sesuai dengan lockfile.

Hal serupa dapat terjadi pada proses kompilasi, pengujian, pembuatan Software Bill of Materials, atau security scanning. Pipeline mungkin menganggap hasil lama tetap berlaku hanya karena file yang dibutuhkan ditemukan dalam cache.

Kontrol yang berpotensi terdampak antara lain:

• validasi checksum dependency;
• Software Composition Analysis;
• Static Application Security Testing;
• secret scanning;
• pemeriksaan lisensi;
• kompilasi ulang;
• unit testing;
• integration testing;
• pembuatan SBOM;
• pemindaian container;
• penandatanganan artefak;
• pemeriksaan konfigurasi keamanan.

Hasil pengujian lama tidak selalu dapat diwariskan kepada artefak baru. Perubahan kecil pada konfigurasi, lingkungan, dependency, atau toolchain dapat mengubah hasil akhirnya.

Oleh karena itu, cache boleh mengurangi pekerjaan komputasi, tetapi tidak boleh menghilangkan kewajiban untuk memvalidasi artefak yang benar-benar akan dirilis.

Stale Cache dan Cache Poisoning Bukan Risiko yang Sama

Stale cache terjadi ketika cache berisi data atau artefak yang sudah tidak sesuai dengan kondisi terbaru. Penyebabnya dapat berupa cache key yang tidak lengkap, mekanisme invalidasi yang lemah, atau pemeliharaan cache yang tidak konsisten.

Dampaknya dapat berupa penggunaan dependency lama, hilangnya patch keamanan, munculnya kembali kerentanan yang telah diperbaiki, atau perbedaan antara source code dan binary yang dirilis.

Sementara itu, cache poisoning melibatkan upaya memasukkan konten tidak sah ke dalam cache agar kemudian dipercaya oleh workflow lain.

Serangan dapat dimulai dari workflow dengan tingkat kepercayaan rendah, misalnya proses yang dipicu oleh pull request eksternal. Jika workflow tersebut dapat menulis ke cache yang nantinya dipulihkan oleh pipeline utama, penyerang berpotensi menanam file berbahaya.

Ketika pipeline dengan izin lebih tinggi menggunakan cache tersebut, konten buatan penyerang dapat dieksekusi dalam lingkungan yang memiliki akses ke token, secret, artifact repository, atau sistem deployment.

Pemisahan antara stale cache dan cache poisoning diperlukan agar perusahaan dapat memilih tindakan yang tepat. Stale cache membutuhkan perbaikan mekanisme invalidasi, sedangkan cache poisoning juga memerlukan pembatasan akses dan pemisahan tingkat kepercayaan.

Pull Request Tidak Tepercaya Dapat Menjadi Titik Masuk

Pull request merupakan bagian penting dalam kolaborasi pengembangan. Namun, kode dari kontributor eksternal tetap harus diperlakukan sebagai input yang tidak tepercaya.

Skenario risiko dapat dimulai ketika pull request menjalankan workflow yang memproses kode dari luar. Kode tersebut kemudian memiliki kesempatan untuk memengaruhi file pada direktori yang akan disimpan sebagai cache.

Jika workflow memiliki izin menulis cache dengan scope yang terlalu luas, cache tercemar dapat disimpan menggunakan key yang kemungkinan dicari oleh pipeline lain.

Pada eksekusi berikutnya, workflow pada branch utama memulihkan cache tersebut. File di dalamnya kemudian dapat digunakan selama proses build atau dijalankan sebagai bagian dari toolchain.

Dokumentasi resmi GitHub Actions memperingatkan bahwa isi cache tidak selalu ditandatangani atau diverifikasi. File yang dipulihkan juga dapat mengubah bagian pipeline yang kemudian dieksekusi.

Karena itu, workflow dari sumber tidak tepercaya sebaiknya tidak memiliki kemampuan menulis cache yang digunakan oleh proses rilis. Akses baca dan tulis perlu dibedakan berdasarkan tingkat kepercayaan setiap workflow.

Penelitian Menunjukkan Cache Membutuhkan Pemeliharaan

Cache sering diterapkan sekali, kemudian dibiarkan berjalan sebagai bagian permanen dari pipeline.

Penelitian terhadap lebih dari 500.000 proses build pada proyek yang menggunakan Travis CI menunjukkan bahwa caching tidak selalu memberikan manfaat yang sama bagi setiap proyek. Penelitian tersebut juga menemukan persoalan berupa cache yang rusak, kedaluwarsa, atau membutuhkan pemeliharaan berulang.

Temuan ini memperlihatkan bahwa cache bukan konfigurasi yang dapat dibiarkan tanpa evaluasi.

Semakin kompleks dependency, toolchain, dan alur deployment, semakin banyak pula kondisi yang seharusnya memicu pembaruan cache. Jika aturan tersebut tidak mengikuti perkembangan sistem, cache dapat berubah dari mekanisme optimasi menjadi sumber inkonsistensi.

Pipeline Hijau Belum Membuktikan Hubungan dengan Source Code

Artefak yang layak dirilis seharusnya dapat ditelusuri kembali ke source code, konfigurasi, dependency, dan proses build yang membentuknya.

Hubungan tersebut menjadi sulit dibuktikan apabila sebagian output berasal dari cache yang identitasnya terlalu umum.

Perusahaan perlu mengetahui:

• source commit yang digunakan;
• dependency dan lockfile yang berlaku;
• versi runtime dan compiler;
• konfigurasi build;
• container base image;
• workflow yang dijalankan;
• kontrol keamanan yang diterapkan;
• hasil pengujian yang berkaitan dengan artefak;
• identitas proses yang menghasilkan artefak;
• waktu serta lingkungan build.

Tanpa informasi tersebut, perusahaan hanya mengetahui bahwa sebuah file tersedia. Perusahaan belum tentu dapat membuktikan bahwa file tersebut benar-benar berasal dari source code terbaru dan melewati kontrol keamanan yang berlaku.

Cache Tidak Boleh Menjadi Sumber Kebenaran untuk Rilis

Cache dan artefak rilis memiliki tujuan berbeda.

Cache digunakan untuk efisiensi dan pada dasarnya dapat dihapus atau dibuat ulang. Artefak rilis merupakan produk yang akan diterapkan ke production atau diserahkan kepada pengguna.

Karena itu, artefak rilis memerlukan kontrol yang lebih kuat, seperti checksum, identitas versi, digital signature, provenance, serta pembatasan akses.

Cache tidak seharusnya langsung diperlakukan sebagai bukti bahwa proses build telah selesai dengan benar. Jika output dari cache akan menjadi bagian dari rilis, output tersebut tetap perlu diperiksa sebagai komponen dari artefak akhir.

OWASP memasukkan improper artifact integrity validation sebagai salah satu risiko utama pada lingkungan CI/CD. Kegagalan memvalidasi integritas dapat membuat artefak yang telah diubah atau digantikan tetap bergerak melalui pipeline hingga mencapai production.

Cache Key Harus Mengikuti Seluruh Input yang Berpengaruh

Cache key tidak cukup hanya dibuat unik. Identitas tersebut harus berubah ketika input yang memengaruhi hasil atau keamanan turut berubah.

Beberapa elemen yang dapat dipertimbangkan meliputi:

• operating system;
• arsitektur runner;
• dependency lockfile;
• versi runtime;
• versi compiler;
• konfigurasi build;
• file workflow;
• security rules;
• source commit;
• versi generator;
• container base image digest;
• environment target.

Tidak semua elemen harus dimasukkan ke dalam satu key. Desainnya perlu disesuaikan dengan jenis cache dan cara cache digunakan.

Dependency cache dapat menggunakan identitas berbeda dari build cache. Cache untuk pengujian juga sebaiknya dipisahkan dari cache yang digunakan dalam proses rilis.

Tujuannya bukan membuat cache selalu berubah, melainkan memastikan bahwa cache tidak digunakan ketika asumsi yang mendasarinya sudah tidak berlaku.

Hasil yang Dipulihkan Tetap Harus Divalidasi

Pipeline perlu memperlakukan cache sebagai input yang harus diperiksa, bukan hasil yang otomatis dapat dipercaya.

Beberapa langkah yang dapat diterapkan antara lain:

• memvalidasi checksum setelah cache dipulihkan;
• mencocokkan dependency dengan lockfile;
• memeriksa usia dan sumber cache;
• menjalankan security scanning pada artefak akhir;
• membuat SBOM dari artefak yang benar-benar dirilis;
• mencocokkan binary dengan source commit;
• menggunakan digital signature;
• menyimpan build attestation;
• memverifikasi provenance sebelum deployment;
• menjalankan clean build secara berkala.

SLSA menekankan pentingnya provenance untuk menjelaskan bagaimana, kapan, dan melalui proses apa suatu artefak dibangun. Informasi ini membantu perusahaan memverifikasi hubungan antara source code dan hasil build.

Provenance tidak menggantikan pengujian keamanan. Namun, keberadaannya membantu mencegah pipeline memercayai artefak hanya berdasarkan nama file, tag, atau lokasi penyimpanan.

Hak Menulis Cache Perlu Dibatasi

Pihak yang dapat membaca cache belum tentu harus memiliki kemampuan menulis cache.

Prinsip least privilege perlu diterapkan pada workflow, runner, token, serta sistem penyimpanan cache. Workflow dari pull request eksternal dapat diberikan akses read-only atau cache terpisah agar tidak memengaruhi branch utama.

Beberapa pengendalian yang dapat diterapkan meliputi:

• hanya workflow tepercaya yang dapat menulis cache utama;
• memisahkan cache berdasarkan branch;
• membatasi cache berdasarkan environment;
• menggunakan cache khusus untuk pull request eksternal;
• melarang penyimpanan credential dan token;
• membatasi permission token pipeline;
• menghindari restore key yang terlalu luas;
• memisahkan cache development dan release;
• mencatat sumber, usia, dan identitas cache;
• mengaudit perubahan konfigurasi cache.

Pipeline juga perlu mencatat cache mana yang digunakan dalam setiap proses build. Informasi tersebut akan sangat membantu ketika terjadi insiden atau ketika perusahaan harus menelusuri asal artefak bermasalah.

Clean Build Tetap Diperlukan pada Titik Kritis

Pengamanan cache tidak berarti seluruh proses harus selalu dimulai dari nol. Jika diterapkan dengan benar, caching tetap dapat membantu perusahaan menjaga kecepatan pengembangan.

Namun, clean build perlu diwajibkan pada kondisi tertentu, terutama ketika tingkat risikonya meningkat.

Beberapa kondisi tersebut antara lain:

• rilis menuju production;
• perubahan dependency;
• pembaruan compiler atau toolchain;
• pergantian container base image;
• perubahan konfigurasi keamanan;
• perbaikan kerentanan kritis;
• perubahan file workflow;
• penerbitan artefak untuk pelanggan;
• proses rollback;
• insiden keamanan pada pipeline.

Clean build memberikan titik pembanding untuk memastikan bahwa hasil dari cache tidak berbeda dari hasil yang dibangun ulang melalui lingkungan terkontrol.

Perusahaan juga dapat menjalankan reproducible build secara berkala. Jika dua proses dengan input yang sama menghasilkan output berbeda, terdapat kondisi yang perlu diperiksa lebih lanjut.

Pengujian Keamanan Perlu Memeriksa Pipeline sebagai Satu Sistem

Keamanan CI/CD tidak dapat dinilai hanya dengan membaca source code aplikasi. Pipeline memiliki identitas, credential, storage, runner, plugin, cache, serta hubungan antarsistem yang membentuk attack surface tersendiri.

Pengujian perlu menilai apakah pengguna dengan akses terbatas dapat:

• mengubah konfigurasi workflow;
• menulis ke cache tepercaya;
• memengaruhi cache key;
• menyisipkan file ke direktori cache;
• membaca secret dari cache;
• mengakses artifact repository;
• mengganti artefak setelah pemeriksaan;
• menjalankan kode pada runner berhak akses tinggi;
• memicu deployment tanpa validasi tambahan.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Dalam beberapa kondisi, aplikasi yang diuji tidak memiliki kerentanan kritis pada source code. Namun, proses build dan deployment masih memberikan jalur lain untuk memengaruhi artefak yang akan diterapkan.

Karena itu, keamanan aplikasi dan keamanan pipeline perlu dinilai sebagai satu rangkaian proses.

Kecepatan Tidak Boleh Menggantikan Pembuktian

Cache CI/CD tetap dibutuhkan untuk menjaga pipeline efisien. Tanpa caching, waktu build dapat meningkat, penggunaan infrastruktur menjadi lebih besar, dan feedback kepada developer melambat.

Namun, efisiensi tidak boleh menghilangkan kemampuan perusahaan untuk membuktikan asal dan integritas artefak.

Pipeline yang aman bukan hanya pipeline yang cepat dan berhasil. Pipeline harus mampu menunjukkan bahwa artefak benar-benar berasal dari source code terbaru, menggunakan dependency yang disetujui, melewati kontrol keamanan yang berlaku, serta tidak mengambil hasil lama dari sumber yang tidak dapat dipercaya.

Pertanyaan yang perlu diajukan bukan hanya, “Apakah pipeline berhasil?”

Perusahaan juga perlu bertanya, “Apakah artefak ini benar-benar dibangun kembali, atau hanya terlihat baru karena pipeline memercayai cache lama?”

Evaluasi Keamanan CI/CD Bersama Fourtrezz

Fourtrezz membantu perusahaan mengidentifikasi kerentanan pada aplikasi dan infrastruktur melalui layanan Vulnerability Assessment dan Penetration Testing.

Pengujian dapat dilakukan terhadap aplikasi web, aplikasi desktop, Android, iOS, API, jaringan, dan server. Fourtrezz menyediakan metode penetration testing blackbox maupun greybox, laporan terperinci, rekomendasi perbaikan, pengujian ulang, serta konsultasi untuk membantu perusahaan memahami risiko secara lebih menyeluruh.

Bagi perusahaan yang menggunakan proses pengembangan dan deployment otomatis, evaluasi keamanan dapat membantu menilai apakah konfigurasi aplikasi, API, server, akses, serta komponen pendukungnya membuka jalur serangan yang belum teridentifikasi.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]