Sebuah aplikasi dapat melewati code review, pengujian fungsional, vulnerability assessment, bahkan penetration testing tanpa temuan kritis. Hasil tersebut tentu memberikan keyakinan bahwa aplikasi telah memiliki tingkat keamanan yang memadai.

Namun, masih ada satu pertanyaan yang sering tidak diajukan: apakah aplikasi yang masuk ke production benar-benar berasal dari kode dan proses yang telah diperiksa?

Di antara source code dan aplikasi yang digunakan pengguna terdapat rangkaian proses yang semakin kompleks. Kode harus melewati repository, dependency manager, build server, compiler, CI/CD pipeline, artifact registry, hingga mekanisme deployment. Setiap tahapan dapat mengubah, menambahkan, atau mengganti komponen di dalam aplikasi.

Artinya, kode yang aman tidak selalu menghasilkan artefak yang dapat dipercaya.

Perusahaan mungkin telah menguji aplikasi yang benar, tetapi kemudian merilis artefak yang berbeda. Tim keamanan mungkin telah memeriksa source code, tetapi tidak mengetahui bahwa pipeline mengambil dependency baru saat proses build berlangsung. Pengembang mungkin tidak mengubah fitur apa pun, tetapi kredensial build server telah disalahgunakan untuk menyisipkan perintah berbahaya.

Inilah alasan keamanan proses build aplikasi perlu menjadi perhatian manajemen, bukan hanya urusan teknis tim DevOps.

Perusahaan Terlalu Sering Menilai Produk Akhir

Keamanan aplikasi umumnya dinilai dari apa yang terlihat pada produk akhir. Tim melakukan pengujian terhadap halaman web, API, aplikasi mobile, server, konfigurasi cloud, dan mekanisme autentikasi.

Pendekatan tersebut penting, tetapi belum mencakup seluruh jalur produksi perangkat lunak.

Aplikasi yang berjalan di production bukanlah source code dalam bentuk aslinya. Ia merupakan hasil dari serangkaian proses otomatis yang mengambil kode, memasukkan library, menjalankan script, membuat binary atau container image, menyimpan artefak, lalu mendistribusikannya ke lingkungan operasional.

Jika salah satu proses tersebut dimanipulasi, hasil akhirnya dapat berubah meskipun source code utama tetap terlihat bersih.

Masalah ini semakin besar ketika perusahaan menggunakan otomatisasi secara luas. Kecepatan delivery meningkat, tetapi otoritas yang diberikan kepada pipeline juga bertambah. Pipeline modern tidak hanya menjalankan pengujian. Ia dapat membaca repository, mengakses secrets, terhubung ke cloud, membuat image, membuka koneksi ke server, dan melakukan deployment tanpa interaksi manusia.

Dengan kewenangan sebesar itu, pipeline pada dasarnya telah menjadi sistem produksi perangkat lunak.

Sayangnya, banyak organisasi masih memperlakukannya sebagai alat bantu teknis.

Build Pipeline Bukan Sekadar Mesin Otomatisasi

Keamanan CI/CD pipeline sering dibahas sebagai persoalan konfigurasi. Padahal, risikonya lebih luas daripada kesalahan pada satu file YAML atau kegagalan mengatur akses repository.

Pipeline merupakan penghubung antara proses pengembangan dan lingkungan operasional. Ketika jalur tersebut dikuasai penyerang, mereka tidak harus menyerang aplikasi dari luar. Mereka dapat memengaruhi aplikasi sebelum aplikasi tersebut sampai kepada pengguna.

Ini merupakan posisi yang sangat menguntungkan bagi penyerang.

Alih-alih mencari celah pada firewall atau mengeksploitasi endpoint aplikasi, penyerang dapat menargetkan build runner, mencuri token deployment, mengganti package, memodifikasi script, atau menyisipkan perubahan pada artefak yang dipercaya oleh perusahaan.

Serangan semacam ini berbahaya karena aktivitasnya dapat terlihat seperti bagian dari proses pengembangan normal. Build tetap berhasil. Pengujian otomatis tetap lulus. Deployment tidak menampilkan error. Aplikasi juga dapat berfungsi seperti biasa.

Kode berbahaya tidak selalu dirancang untuk merusak fungsi utama. Ia dapat beroperasi diam-diam untuk mencuri kredensial, membuka akses tambahan, mengirim data, atau menunggu instruksi berikutnya.

Keberhasilan proses build akhirnya menciptakan rasa aman yang keliru.

Kode yang Bersih Dapat Menghasilkan Artefak yang Tercemar

Salah satu kesalahpahaman terbesar dalam keamanan software adalah anggapan bahwa source code merupakan satu-satunya sumber kebenaran.

Pada praktiknya, isi aplikasi tidak hanya ditentukan oleh kode yang ditulis tim internal. Aplikasi juga bergantung pada library, package, base image, plugin, compiler, script, dan perangkat build lainnya.

Komponen tersebut dapat berubah ketika proses build berjalan.

Dependency Dapat Berubah Tanpa Perubahan Kode Utama

Banyak proyek mengambil dependency secara otomatis dari public registry. Jika versi komponen tidak dikunci secara konsisten, dua proses build dari source code yang sama dapat menghasilkan artefak berbeda.

Perubahan ini tidak selalu berbahaya. Namun, organisasi tetap menghadapi masalah mendasar: mereka tidak sepenuhnya mengendalikan komponen yang masuk ke aplikasi.

Risiko meningkat ketika akun pengelola package diretas, package populer diambil alih, atau penyerang menerbitkan komponen dengan nama yang menyerupai dependency resmi. Dependency transitif juga dapat membawa komponen tambahan yang tidak pernah dipilih secara langsung oleh tim pengembang.

Dalam kondisi tersebut, source code internal dapat tetap bersih. Komponen berbahaya justru masuk ketika pipeline mengunduh kebutuhan build.

Daftar dependency saja belum cukup. Perusahaan perlu mengetahui versi, sumber, checksum, hubungan antarkomponen, dan kebijakan perubahan yang berlaku.

Script Pipeline Dapat Diubah Menjadi Jalur Eksekusi

File konfigurasi CI/CD sering dianggap sebagai bagian pendukung proyek. Akibatnya, perubahan pada file tersebut tidak selalu mendapat pengawasan yang sama ketatnya dengan perubahan kode aplikasi.

Padahal, script pipeline dapat menjalankan perintah dengan akses yang luas.

Perubahan kecil dapat memerintahkan runner untuk mengunduh file eksternal, membaca environment variable, menyalin kredensial, mengganti hasil build, atau mengirim artefak ke lokasi lain.

Serangan terhadap pipeline tidak harus menyentuh fitur aplikasi. Penyerang cukup memanipulasi instruksi yang mengatur bagaimana aplikasi dibangun.

Situasi ini menjadi semakin berisiko ketika perubahan konfigurasi dapat dilakukan tanpa code review, branch protection, atau persetujuan dari pihak lain.

Build Runner Sering Memiliki Hak Akses Berlebihan

Build runner membutuhkan akses agar dapat menjalankan tugasnya. Ia mungkin perlu membaca repository, mengambil package, mengunggah container image, mengakses secret manager, atau mengirim aplikasi ke server.

Masalah muncul ketika semua kebutuhan tersebut dipenuhi dengan satu identitas berhak akses luas.

Runner yang disusupi kemudian dapat menjadi pintu masuk menuju berbagai sistem sekaligus. Token repository dapat digunakan untuk mengubah kode. Kredensial cloud dapat membuka akses ke infrastruktur. Deployment key dapat memberikan kendali terhadap server production.

Risiko menjadi lebih besar pada runner yang digunakan berulang kali. File, token, cache, atau artefak dari satu pekerjaan dapat tertinggal dan diakses oleh proses berikutnya.

Pipeline yang terlihat efisien secara operasional dapat menyimpan jalur serangan yang tidak pernah diperhitungkan.

Artefak Dapat Berubah Setelah Pengujian

Perusahaan mungkin menjalankan pengujian terhadap satu artefak, tetapi melakukan deployment terhadap artefak lain.

Hal ini dapat terjadi ketika aplikasi dibangun ulang setelah pengujian, file dipindahkan secara manual, image dengan tag yang sama ditimpa, atau artifact registry tidak menerapkan mekanisme immutable storage.

Dalam proses manual, risiko tersebut semakin sulit dilacak. File dapat dikirim melalui email, aplikasi percakapan, penyimpanan bersama, atau perangkat lokal pengembang.

Ketika tidak ada hash, tanda tangan digital, dan rekam jejak yang dapat diverifikasi, perusahaan tidak memiliki bukti kuat bahwa aplikasi yang dirilis adalah aplikasi yang sama dengan yang telah diuji.

Build Berhasil Tidak Berarti Build Dapat Dipercaya

Sebagian besar organisasi menilai pipeline berdasarkan indikator operasional:

• proses build selesai;
• seluruh automated test lulus;
• deployment tidak mengalami kegagalan;
• aplikasi dapat diakses;
• release selesai sesuai jadwal.

Indikator tersebut hanya menunjukkan bahwa pipeline bekerja. Ia belum membuktikan bahwa pipeline bekerja melalui proses yang sah.

Kepercayaan membutuhkan bukti yang lebih kuat.

Perusahaan harus dapat menjelaskan kode mana yang digunakan, siapa yang memulai build, perangkat apa yang menjalankannya, dependency mana yang dimasukkan, dan artefak apa yang akhirnya dikirim ke production.

Tanpa informasi tersebut, proses build hanya dipercaya berdasarkan asumsi.

Pertanyaan yang perlu diajukan bukan sekadar “Apakah build berhasil?”, tetapi juga:

• Apakah build hanya dapat dijalankan dari branch yang disetujui?
• Apakah perubahan pipeline wajib melalui review?
• Apakah artefak dapat ditelusuri kembali ke commit tertentu?
• Apakah perangkat build telah divalidasi?
• Apakah identitas yang menjalankan deployment dapat diverifikasi?
• Apakah artefak yang dirilis sama dengan artefak yang telah diuji?
• Apakah satu orang dapat mengubah kode sekaligus mengirimkannya ke production?

Pertanyaan tersebut memperlihatkan bahwa keamanan build bukan hanya persoalan tool. Ia juga menyangkut kontrol akses, pemisahan tanggung jawab, tata kelola, dan kemampuan audit.

Menambahkan Scanner Belum Menyelesaikan Masalah

Ketika membangun DevSecOps, banyak perusahaan memulai dengan menambahkan berbagai alat keamanan ke dalam pipeline.

SAST digunakan untuk menganalisis source code. Software composition analysis memeriksa dependency. Secret scanner mencari kredensial yang tersimpan dalam repository. Container scanner mengidentifikasi kerentanan pada image.

Seluruh kontrol tersebut penting. Namun, tidak satu pun secara otomatis membuktikan integritas proses build.

Scanner dapat menemukan package yang memiliki kerentanan. Scanner belum tentu mengetahui bahwa konfigurasi pipeline telah diubah oleh akun yang diretas.

Scanner dapat memeriksa container image. Scanner belum tentu membuktikan bahwa image yang masuk ke production merupakan image yang sama dengan hasil pemeriksaan.

Scanner dapat mendeteksi secret pada source code. Scanner belum tentu mencegah runner menggunakan kredensial dengan hak akses berlebihan.

Karena itu, organisasi perlu membedakan dua tujuan keamanan.

Tujuan pertama adalah menemukan kerentanan di dalam aplikasi dan komponennya. Tujuan kedua adalah membuktikan bahwa aplikasi diproduksi melalui proses yang sah, konsisten, dan tidak dimanipulasi.

Keduanya saling melengkapi, tetapi tidak dapat saling menggantikan.

Setiap Artefak Seharusnya Memiliki Riwayat Asal

Di banyak industri, perusahaan tidak akan menerima komponen penting tanpa mengetahui produsen, bahan, nomor produksi, dan jalur distribusinya.

Standar yang sama seharusnya diterapkan pada perangkat lunak.

Artefak aplikasi perlu memiliki informasi asal yang dapat diverifikasi. Informasi tersebut dapat mencakup repository sumber, commit yang digunakan, identitas pembuat build, waktu pembuatan, konfigurasi, dependency, perangkat build, hash, serta persetujuan sebelum release.

Konsep ini dikenal sebagai software provenance.

Provenance membantu perusahaan menjawab bukan hanya apa yang terdapat di dalam aplikasi, tetapi juga bagaimana aplikasi tersebut dihasilkan.

Ketika terjadi insiden, informasi tersebut sangat penting. Tim dapat menelusuri kapan artefak dibuat, komponen apa yang digunakan, pipeline mana yang menjalankannya, dan apakah artefak lain mungkin terdampak.

Tanpa provenance, investigasi akan bergantung pada asumsi, catatan manual, dan ingatan orang yang terlibat.

SBOM Penting, tetapi Bukan Jawaban Tunggal

Software Bill of Materials atau SBOM semakin banyak digunakan untuk mencatat komponen yang terdapat di dalam aplikasi.

SBOM membantu organisasi mengetahui library, package, dan dependency yang digunakan. Informasi tersebut sangat berguna ketika muncul kerentanan baru pada komponen tertentu.

Namun, SBOM tidak menjawab seluruh persoalan keamanan software supply chain.

Daftar komponen belum tentu membuktikan bahwa proses build tidak dimanipulasi. SBOM juga tidak selalu menunjukkan apakah identitas pembuat build sah, apakah script pipeline telah diubah, atau apakah artefak diganti setelah pengujian.

Dengan kata lain, SBOM menjelaskan isi aplikasi. Provenance menjelaskan bagaimana aplikasi tersebut lahir.

Keduanya perlu digunakan bersama dengan kontrol akses, artifact signing, immutable repository, pengelolaan dependency, dan verifikasi sebelum deployment.

Kepercayaan Harus Dibangun dalam Beberapa Lapisan

Tidak ada satu alat yang dapat menjamin keamanan proses build aplikasi. Kepercayaan harus dibentuk melalui beberapa lapisan kontrol yang saling mendukung.

Lindungi Sumber Perubahan

Repository harus dilindungi melalui autentikasi multifaktor, branch protection, mandatory review, dan pembatasan hak administrator.

File pipeline perlu diperlakukan sebagai kode sensitif. Setiap perubahan terhadap konfigurasi build dan deployment harus melalui review yang memadai.

Direct push menuju branch utama atau production sebaiknya dibatasi. Perubahan darurat tetap harus memiliki catatan, alasan, dan evaluasi setelah pelaksanaan.

Pisahkan Identitas Manusia dan Mesin

Pipeline tidak seharusnya menggunakan akun personal atau kredensial bersama.

Setiap layanan perlu memiliki identitas tersendiri dengan hak akses minimum. Kredensial sebaiknya berumur pendek, dapat dirotasi, dan disimpan dalam secret manager.

Akses untuk membaca repository tidak otomatis harus memiliki kewenangan melakukan deployment. Demikian pula, sistem yang mengunggah artefak tidak selalu membutuhkan akses administratif terhadap seluruh registry.

Pemisahan tersebut memperkecil dampak ketika satu identitas disalahgunakan.

Isolasi Lingkungan Build

Lingkungan build idealnya dibuat bersih untuk setiap pekerjaan dan dihapus setelah proses selesai.

Ephemeral runner dapat mengurangi risiko sisa file, token, cache, atau proses berbahaya dari pekerjaan sebelumnya. Runner untuk proyek sensitif juga sebaiknya dipisahkan dari proyek dengan tingkat kepercayaan lebih rendah.

Perusahaan perlu memvalidasi perangkat build, compiler, interpreter, plugin, dan image dasar yang digunakan. Build server juga harus melalui hardening, patching, logging, dan pemantauan yang memadai.

Kendalikan Dependency

Versi dependency harus dikunci. Penggunaan lockfile, checksum, private registry, dan daftar komponen yang disetujui dapat meningkatkan konsistensi proses build.

Pembaruan komponen sebaiknya tidak langsung masuk ke production hanya karena versi baru tersedia. Tim perlu mengevaluasi sumber, perubahan, reputasi pengelola, serta dampaknya terhadap aplikasi.

Dependency transitif juga harus diperhatikan karena komponen tersebut dapat masuk tanpa dipilih secara langsung oleh developer.

Tandatangani dan Verifikasi Artefak

Artefak yang telah selesai dibangun perlu memiliki hash atau tanda tangan digital. Artifact registry juga perlu menerapkan kontrol akses dan mencegah file yang telah disetujui ditimpa secara sembarangan.

Namun, penandatanganan saja belum cukup.

Deployment harus melakukan verifikasi terhadap tanda tangan tersebut. Tanpa proses verifikasi, signature hanya menjadi catatan yang tidak benar-benar memengaruhi keputusan release.

Production seharusnya hanya menerima artefak dari registry resmi, dibuat oleh identitas tepercaya, dan berasal dari pipeline yang telah disetujui.

Pisahkan Build dari Release

Artefak yang telah diuji tidak seharusnya dibangun ulang sebelum masuk ke production.

Praktik yang lebih aman adalah membangun satu artefak, mengujinya, memberikan persetujuan, lalu mempromosikan artefak yang sama ke lingkungan berikutnya.

Pemisahan tanggung jawab juga diperlukan. Satu pihak sebaiknya tidak memiliki kewenangan tanpa batas untuk mengubah kode, mengubah pipeline, menyetujui perubahan, dan melakukan deployment.

Kontrol ini bukan bertujuan memperlambat development. Tujuannya adalah mengurangi kemungkinan satu akun atau satu kesalahan dapat mengendalikan seluruh jalur release.

Pentest Penting, tetapi Tidak Dapat Berdiri Sendiri

Penetration testing memberikan gambaran realistis mengenai bagaimana aplikasi, API, jaringan, atau infrastruktur dapat diserang. Pengujian ini membantu perusahaan memahami apakah suatu kelemahan benar-benar dapat dimanfaatkan dan apa dampaknya terhadap bisnis.

Namun, penetration testing terhadap aplikasi tidak otomatis memeriksa seluruh proses build.

Ruang lingkup pengujian aplikasi biasanya tidak mencakup repository, build runner, artifact registry, secret management, konfigurasi CI/CD, code signing, provenance, serta kewenangan deployment.

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

Aplikasi dapat memiliki kontrol autentikasi yang baik, validasi input yang memadai, serta konfigurasi server yang kuat. Namun, jalur delivery perangkat lunaknya masih bergantung pada akun bersama, script tanpa review, deployment manual, atau artefak yang tidak dapat diverifikasi.

Karena itu, perusahaan perlu mengombinasikan beberapa bentuk evaluasi, seperti penetration testing, vulnerability assessment, secure code review, CI/CD security assessment, cloud configuration review, serta evaluasi Secure SDLC.

Pengujian terhadap produk akhir perlu dilengkapi dengan penilaian terhadap proses yang menghasilkan produk tersebut.

Tanda Proses Build Belum Dapat Dipercaya

Organisasi perlu waspada ketika menemukan kondisi berikut:

• aplikasi production dibangun dari laptop developer;
• deployment menggunakan file yang dikirim melalui email atau aplikasi percakapan;
• versi dependency tidak dikunci;
• pipeline dapat diubah tanpa review;
• satu akun digunakan oleh beberapa anggota tim;
• credentials disimpan dalam script atau repository;
• build runner digunakan bersama oleh banyak proyek;
• artefak dengan tag yang sama dapat ditimpa;
• aplikasi dibangun ulang setelah lolos pengujian;
• perusahaan tidak dapat menentukan commit asal aplikasi production;
• vendor hanya menyerahkan binary tanpa bukti proses build;
• tidak ada pemisahan kewenangan antara developer dan pihak yang menyetujui release;
• log pipeline tidak cukup untuk mendukung investigasi;
• deployment production dapat dilakukan dari sumber selain registry resmi.

Tidak semua kondisi tersebut langsung menunjukkan adanya serangan. Namun, masing-masing memperlihatkan bahwa kepercayaan masih bergantung pada kebiasaan dan hubungan personal, bukan pada kontrol yang dapat diverifikasi.

Vendor Aplikasi Juga Harus Dapat Membuktikan Prosesnya

Risiko build tidak hanya berlaku untuk software yang dikembangkan secara internal. Perusahaan juga perlu menilai proses pengembangan vendor.

Vendor tidak cukup hanya menyatakan bahwa aplikasi telah diuji. Mereka perlu mampu menjelaskan bagaimana kode disimpan, bagaimana dependency dikelola, siapa yang dapat mengubah pipeline, bagaimana artefak dibuat, dan bagaimana keamanan data klien dijaga.

Perusahaan sebaiknya meminta bukti yang relevan, seperti:

• dokumentasi Secure SDLC;
• daftar komponen atau SBOM;
• mekanisme review perubahan;
• bukti pengujian keamanan;
• prosedur pengelolaan secrets;
• kontrol akses terhadap repository;
• catatan versi dan release;
• hash atau signature artefak;
• prosedur penanganan kerentanan;
• mekanisme penghapusan akses setelah proyek selesai.

Permintaan tersebut bukan bentuk ketidakpercayaan terhadap vendor. Justru, transparansi proses merupakan dasar hubungan bisnis yang sehat ketika software akan digunakan untuk mengelola data atau aktivitas penting perusahaan.

Keamanan Aplikasi Mencakup Cara Aplikasi Diproduksi

Perusahaan tidak lagi cukup menilai keamanan berdasarkan hasil pemindaian atau satu kali pengujian.

Aplikasi baru layak dipercaya ketika organisasi dapat membuktikan bahwa sumbernya sah, dependency-nya terkendali, perangkat build-nya aman, identitas pembuatnya terverifikasi, dan artefaknya tidak berubah sebelum deployment.

Keamanan proses build aplikasi pada akhirnya merupakan persoalan integritas.

Pertanyaan yang harus dijawab bukan hanya, “Apakah aplikasi ini memiliki celah?”

Pertanyaan yang sama pentingnya adalah, “Dapatkah perusahaan membuktikan bahwa aplikasi ini dibangun melalui proses yang tidak dimanipulasi?”

Tanpa jawaban yang meyakinkan, aplikasi mungkin terlihat aman dari luar, tetapi fondasi kepercayaannya masih rapuh.

Perkuat Keamanan Aplikasi Bersama Fourtrezz

Fourtrezz membantu perusahaan mengevaluasi keamanan aplikasi dan infrastruktur melalui layanan penetration testing, vulnerability assessment, serta pengujian keamanan yang disesuaikan dengan ruang lingkup dan kebutuhan bisnis.

Fourtrezz juga menyediakan layanan IT development berbasis keamanan untuk membantu perusahaan membangun aplikasi yang tidak hanya berfungsi dengan baik, tetapi juga mempertimbangkan keamanan sejak tahap perencanaan, pengembangan, pengujian, hingga implementasi.

Melalui pendekatan yang terukur, perusahaan dapat mengidentifikasi celah teknis, mengevaluasi risiko pada proses pengembangan, dan menyusun prioritas perbaikan yang lebih relevan terhadap kondisi bisnis.

Hubungi Fourtrezz:

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