BrassCoders menemui rahsia yang dikodkan secara keras (hard-coded secrets) dalam dua daripada lima belas skrip Python yang dijana oleh AI yang mereka periksa, mendedahkan risiko nyata bagi pembangun yang menyalin dan menampal kod terus daripada output model bahasa besar. Penemuan ini menunjukkan bahawa satu kunci atau kata laluan yang salah letak boleh mengubah petikan kod yang berguna menjadi kebocoran kredential merentasi persekitaran kawalan versi dan pengeluaran.
Apa yang didedahkan oleh ujian tersebut
Skrip pertama, token_check.py, dihasilkan daripada arahan (prompt) yang meminta fungsi untuk menandatangani token sesi dan menyertakan “contoh yang boleh digunakan.” Untuk menjadikan kod tersebut boleh dijalankan, model tersebut memasukkan kunci menandatangani HMAC secara literal terus ke dalam fail sumber.
- Masalah: Kunci rahsia berada di dalam pangkalan kod.
- Risiko: Sesiapa sahaja yang mempunyai akses baca ke repositori boleh melihat kunci tersebut, dan sebarang deployment yang menarik fail tersebut akan mewarisi rahsia itu.
- Akibat: Penyerang yang memperoleh kunci tersebut boleh memalsukan token sesi yang sah, sekali gus memintas pemeriksaan pengesahan.
Skrip kedua, email_sender.py, menjawab permintaan untuk fungsi yang menghantar e-mel melalui SMTP. Model tersebut sekali lagi membekalkan kata laluan secara literal supaya contoh tersebut dapat berfungsi dengan segera.
- Masalah: Kata laluan muncul sebagai rentetan teks biasa (plain-text string) dalam panggilan fungsi.
- Risiko: Menukar kata laluan memerlukan perubahan kod dan deployment baharu, dan kredential tersebut tersebar ke setiap persekitaran yang menggunakan fail itu.
- Akibat: Kata laluan boleh dituai daripada kawalan sumber, log, atau pakej yang telah dikompilasi, memberikan akses tanpa kebenaran kepada pihak lawan ke pelayan e-mel.
Mengapa AI mengeluarkan rahsia
Model bahasa besar menjana teks dengan melengkapkan arahan (prompt). Apabila pengguna meminta “contoh yang boleh digunakan,” model mentafsirkan itu sebagai “kod yang berjalan tanpa persediaan tambahan.” Oleh itu, ia mengisi nilai yang hilang—kunci API, kata laluan, token—dengan pengganti (placeholder) yang munasabah. Model tidak mempunyai kesedaran tentang amalan terbaik pengurusan rahsia melainkan arahan tersebut menyebutnya secara eksplisit.
Analisis Veracode baru-baru ini terhadap kod yang dijana AI mendapati bahawa 45% daripada petikan kod mengandungi sekurang-kurangnya satu kerentanan yang disenaraikan dalam OWASP Top 10, dengan pendedahan kredential mewakili bahagian yang besar. Statistik ini menekankan bahawa masalah ini bukan terpencil kepada beberapa kes luar biasa sahaja; ia adalah hasil sampingan sistemik daripada cara model-model ini dilatih dan diberi arahan.
Langkah mitigasi yang boleh diambil oleh pembangun sekarang
Pertahanan yang paling mudah adalah dengan memastikan sebarang rahsia tidak berada di dalam fail kod itu sendiri. Pemboleh ubah persekitaran (environment variables) adalah kaedah yang paling biasa dan tidak bergantung pada bahasa pengaturcaraan (language-agnostic):
# token_check.py – secure version
import os
import hmac
import hashlib
SECRET_KEY = os.environ["HMAC_SECRET_KEY"]
def sign_token(data: bytes) -> str:
return hmac.new(SECRET_KEY.encode(), data, hashlib.sha256).hexdigest()
# email_sender.py – secure version
import os
import smtplib
smtp_password = os.environ["SMTP_PASSWORD"]
server = smtplib.SMTP("smtp.example.com", 587)
server.starttls()
server.login("noreply@example.com", smtp_password)
Menggunakan os.environ menarik nilai daripada persekitaran masa larian (runtime environment), mengekalkannya di luar kawalan versi dan membolehkan penggiliran (rotation) tanpa menyentuh fail sumber. Corak yang sama berfungsi dengan fail konfigurasi yang dikecualikan daripada komit, perkhidmatan pengurusan rahsia, atau rahsia yang diuruskan melalui orkestrasi kontena.
Langkah keselamatan tambahan
- Semakan kod (Code reviews) yang menandakan rentetan literal yang sepadan dengan corak rahsia biasa (contohnya, urutan alfanumerik yang panjang).
- Alatan analisis statik yang dilaraskan untuk mengesan kredential yang dikodkan secara keras dalam fail yang baru ditambah.
- Kejuruteraan arahan (Prompt engineering): minta model secara eksplisit untuk “menggunakan pemboleh ubah persekitaran untuk semua rahsia” atau “abaikan kredential sebenar.”
- Pemeriksaan linting pasca-penjanaan (Post-generation linting): jalankan skrip pantas yang mencari literal yang mencurigakan sebelum menyalin kod ke dalam projek.
Hujah balas: Adakah ini bermakna kod AI tidak selamat?
Kehadiran rahsia yang dikodkan secara keras tidak bermakna kod yang dijana AI secara universal tidak selamat. Dalam banyak kes, model menghasilkan logik yang bersih dan berstruktur baik yang boleh mempercepatkan pembangunan. Risiko muncul apabila pembangun menganggap output tersebut sedia untuk pengeluaran (production-ready) tanpa audit keselamatan. Anggaplah AI sebagai pembantu draf, bukan pengganti kepada amalan keselamatan yang telah ditetapkan.
Apa yang perlu diperhatikan seterusnya
- Kemas kini alatan: Platform AI mula menyertakan penapis keselamatan yang menggantikan rahsia dengan pengganti (placeholder). Memantau perubahan tersebut boleh mengurangkan pendedahan.
- Peralihan polisi: Organisasi mungkin memformalkan garis panduan untuk pengekodan berbantuan AI, mewajibkan semakan pengurusan rahsia sebagai sebahagian daripada saluran paip (pipeline) CI.
- Corak komuniti: Apabila pembangun berkongsi lebih banyak “arahan selamat (secure prompts),” templat amalan terbaik boleh menjadi output lalai untuk tugas biasa seperti menandatangani token atau penghantaran e-mel.
Rumusan: AI boleh menghasilkan kod yang berfungsi dalam masa beberapa saat, tetapi melainkan pembangun menguatkuasakan disiplin pengurusan rahsia, kemudahan ini datang dengan kos tersembunyi—kredensial yang terdedah yang boleh menjejaskan keseluruhan sistem. Anggap setiap petikan kod sebagai draf, buang sebarang maklumat rahsia yang ditulis secara langsung, dan masukkan maklumat tersebut melalui pemboleh ubah persekitaran atau vault khas sebelum melakukan commit.