Apakah Kode Buatan AI Benar-benar Aman? Tanya Jawab untuk Builder

Saya mendapatkan versi pertanyaan ini di hampir setiap panggilan onboarding, biasanya diucapkan dengan hati-hati, seolah-olah orang yang bertanya setengah berharap dibujuk untuk berhenti khawatir. Mereka seharusnya tidak dibujuk untuk itu. Keamanan adalah salah satu dari sedikit area di mana kadar kewaspadaan yang sehat memang tepat, baik kode itu ditulis oleh manusia maupun model. Berikut adalah pertanyaan-pertanyaan yang benar-benar saya terima, dijawab selangsung mungkin.

Apakah kode yang ditulis AI kurang aman dibanding kode yang ditulis manusia?

Rata-rata, dan jika dibiarkan tanpa pengecekan, ya — sedikit lebih rentan. Sebuah studi Stanford dari beberapa tahun lalu (Perry et al., sering disebut sebagai tinjauan nyata pertama soal ini) menemukan bahwa developer yang menggunakan asisten pengkodean AI menghasilkan kode yang kurang aman dibanding kelompok kontrol — dan, ini bagian yang seharusnya lebih mengkhawatirkan, mereka menilai kode mereka sendiri lebih aman dari kenyataannya. Rasa percaya diri meningkat sementara kualitas menurun. Pemindaian keamanan kode GenAI dari Veracode yang lebih baru juga memberikan angka kasarnya: sekitar 4 dari 10 sampel kode buatan AI yang mereka uji memperkenalkan setidaknya satu celah yang bisa dieksploitasi, biasanya hal yang sepele seperti pemeriksaan input yang hilang atau default yang lemah. Semua ini bukan berarti kode buatan AI pasti buruk. Artinya, kode buatan AI yang tidak direview membawa risiko yang sama dengan kode manusia yang tidak direview, dan bagian "tidak direview" itulah tempat bahaya sesungguhnya berada. Model yang menulis dengan cepat dan tidak pernah diperiksa akan mengirimkan kesalahan yang sama seperti yang dilakukan developer junior di sore hari Jumat — hanya saja lebih cepat, dan lebih banyak.

Apa yang terjadi pada API key dan secret saya?

Ini satu hal yang benar-benar membuat saya sulit tidur, karena ini adalah kesalahan yang tidak terlihat sampai akhirnya terlihat. Pola kegagalannya tidak dramatis — tidak ada server yang dibobol seperti di film peretas. Ini soal sebuah key yang ditempelkan ke chat, digemakan kembali ke dalam file yang dihasilkan, di-commit, dan diam-diam tersimpan dalam bentuk plaintext di repo enam bulan kemudian saat seseorang menjalankan pemindai secret karena penasaran. Di platform ini, secret tidak pernah berada di source kode yang dihasilkan sama sekali — mereka disuntikkan saat runtime dari penyimpanan terenkripsi, dibatasi ke tenant Anda, dan agen build diinstruksikan untuk mereferensikannya berdasarkan nama, bukan nilai. Tapi jika Anda membangun di tempat lain, atau menempelkan kredensial langsung ke jendela chat dengan alat apa pun, anggap saja teks itu sekarang menjadi bagian dari log yang berkaitan dengan training di suatu tempat, kecuali penyedianya secara eksplisit menyatakan sebaliknya. Rotasi apa pun yang pernah Anda ketik ke kotak chat, sebagai prinsip, pada hari yang sama saat Anda selesai menguji.

Bisakah seseorang meretas situs saya lewat prompt, seperti serangan prompt injection?

Dua hal berbeda sering disamakan di sini, dan perbedaannya penting. Prompt injection terhadap pembangun — seseorang yang mengelabui AI yang membangun aplikasi Anda untuk melakukan sesuatu yang tidak Anda minta — adalah risiko nyata dan telah diteliti, dan itulah sebabnya agen build berjalan dengan izin tool yang dibatasi, bukan akses shell secara penuh, dan mengapa apa pun yang menyentuh filesystem atau pipeline deploy Anda melalui log aksi eksplisit yang bisa Anda audit setelahnya. Prompt injection terhadap aplikasi yang Anda luncurkan adalah masalah terpisah yang hanya berlaku jika aplikasi Anda sendiri menyematkan LLM saat runtime — chatbot dukungan, fitur pencarian AI, dan semacamnya. Jika ya, perlakukan teks apa pun yang bisa diketik pengguna sebagai input yang tidak tepercaya bagi model itu, sama seperti Anda memperlakukannya sebagai input tidak tepercaya untuk query SQL. Aturannya lama, yang baru hanya sistem mana yang mengurai string tersebut.

Apakah pembangun memeriksa kerentanan pada kodenya sendiri sebelum meluncurkannya?

Pemeriksaan otomatis menangkap hal-hal yang membosankan dan sering terjadi secara andal: secret yang di-hardcode, autentikasi yang hilang di endpoint yang jelas membutuhkannya, SQL yang dibangun dengan penggabungan string alih-alih parameter, dependency dengan CVE yang diketahui. Yang tidak tertangkap dengan baik adalah cacat logika bisnis — jenis di mana setiap baris kode secara individu baik-baik saja dan kerentanannya ada di celah antara dua fitur yang tidak pernah dipikirkan orang untuk diperiksa bersama. Kode diskon yang bisa ditumpuk tanpa batas dengan bonus referral. Alur reset password yang membocorkan apakah suatu email ada dalam sistem. Itu semua membutuhkan seseorang yang memahami fungsi aplikasi, bukan hanya apa yang dilakukan kode, dan belum ada pemindai — baik AI maupun lainnya — yang bisa menemukannya secara andal. Review otomatis adalah lantai dasar, bukan batas atas.

Bagaimana dengan package pihak ketiga yang diinstalnya — apakah itu risiko rantai pasok (supply-chain)?

Ya, dan sejujurnya ini risiko dunia nyata yang lebih besar dibanding kode buatan AI itu sendiri. Sebagian besar aplikasi 80-95%-nya adalah dependency dilihat dari jumlah baris; kode yang ditulis pembangun hanyalah lapisan tipis di atas npm, PyPI, atau ekosistem apa pun yang digunakan stack tersebut. Package yang berbahaya atau dibajak dapat membahayakan Anda terlepas dari siapa atau apa yang menulis kode penghubung di sekitarnya — lihat insiden event-stream dan colors.js untuk bagaimana itu terjadi di dunia nyata. Mitigasinya membosankan tapi efektif: kunci versi (pin) alih-alih mengikuti versi terbaru, pilih package dengan riwayat pemeliharaan nyata dibanding yang baru dirilis minggu lalu, dan jalankan audit dependency (`npm audit`, `pip-audit`, atau apa pun yang sesuai dengan stack Anda) sebagai kebiasaan rutin, bukan langkah sekali sebelum peluncuran.

Siapa yang bertanggung jawab jika terjadi pelanggaran keamanan?

Andalah — secara hukum, hampir selalu, jika itu aplikasi Anda dan data pelanggan Anda. Ini mengejutkan orang-orang yang berasumsi bahwa "AI yang menulisnya" memindahkan tanggung jawab ke tempat lain. Tidak, sama seperti mempekerjakan kontraktor tidak memindahkan tanggung jawab atas pelanggaran kode bangunan dari pemilik properti. Platform memikul tanggung jawab atas infrastruktur yang mereka kendalikan: bagaimana secret disimpan, bagaimana data tenant diisolasi, apakah lapisan hosting itu sendiri telah di-patch. Tapi logika aplikasi yang Anda spesifikasikan, data yang Anda pilih untuk dikumpulkan, dan syarat yang Anda tawarkan kepada pengguna Anda adalah milik Anda. Jika Anda menangani sesuatu yang sensitif — detail pembayaran, informasi kesehatan, apa pun di bawah GDPR atau CCPA — bacalah perjanjian pemrosesan data yang sebenarnya dari platform apa pun yang Anda gunakan alih-alih berasumsi bahwa "dibangun oleh AI" berarti ada lapisan perlindungan hukum tambahan. Tidak ada.

Seorang founder pernah memberi tahu saya, sebagian bercanda, bahwa dia lebih memercayai kode AI dibanding kodenya sendiri karena "setidaknya AI tidak lelah pukul 2 pagi." Mungkin. Tapi manusia yang lelah biasanya tahu bahwa mereka lelah. AI tidak tahu bahwa dia baru saja membuat kesalahan, dan dia akan memberi tahu Anda bahwa kodenya sudah selesai dengan nada percaya diri yang persis sama, entah kodenya sempurna atau penuh lubang. Kepercayaan diri bukan sinyal keamanan, dari sumber mana pun.

Haruskah saya membayar untuk audit keamanan sungguhan sebelum meluncurkan?

Jika Anda menerima pembayaran, menyimpan apa pun yang akan disebut PII oleh regulator, atau membangun untuk pelanggan bisnis yang tetap akan meminta laporan SOC 2 — ya, dan jangan biarkan biaya menghalangi Anda. Audit terfokus pada aplikasi kecil berkisar dari beberapa ratus hingga ribuan dolar tergantung cakupannya, yang murah dibanding surat pemberitahuan pelanggaran data. Jika Anda membangun proyek hobi, alat internal, atau sesuatu tanpa data pengguna nyata yang dipertaruhkan, audit berbayar berlebihan; jalankan saja lapisan gratis dan murah — pemindaian dependency, penelusuran manual setiap batas autentikasi (bisakah pengguna A melihat data pengguna B dengan mengubah URL?), dan sepasang mata manusia kedua untuk apa pun yang menyentuh uang atau password.

Apa kesalahan keamanan paling umum yang dilakukan orang, dan kapan itu terjadi?

Bukan saat peluncuran — tiga bulan setelahnya, ketika aplikasi sudah berjalan dan tidak ada lagi yang memperhatikannya. Ini soal route admin yang dibiarkan tanpa perlindungan karena hanya pernah diuji oleh orang yang membangunnya, login sebagai dirinya sendiri. Ini soal endpoint debug yang mengembalikan stack trace lengkap di production. Ini soal password default pada database yang seharusnya "hanya untuk testing" dan tidak pernah dirotasi. Tidak ada satu pun dari ini yang eksotis. Semuanya setara dengan meninggalkan kunci cadangan di bawah keset karena Anda terburu-buru suatu kali dan kemudian lupa itu ada di sana. Perbaikannya bukan alat yang lebih baik, tapi kebiasaan lima menit: sebulan sekali, lihat aplikasi Anda seperti seorang penyerang selama lima menit sebelum Anda melihatnya seperti pembangun yang bangga.