Versi berbahaya dari Nx dan beberapa plugin pendukung telah didistribusikan

• Versi berbahaya dari paket Nx dan plugin telah didistribusikan ke npm, memindai sistem file, mengumpulkan kredensial, lalu mengirimkannya ke repositori akun Github milik pengguna
• Untuk memeriksa apakah terdampak, perlu memastikan apakah repositori s1ngularity-repository telah dibuat di akun Github
• Jika terinfeksi, mengganti token dan kata sandi, menghapus repositori berbahaya, serta memeriksa file konfigurasi shell wajib dilakukan
• Versi berbahaya memengaruhi sistem melalui skrip postinstall; risikonya meningkat karena dapat dijalankan tanpa disadari, terutama saat memakai plugin VSCode Nx Console
• Pihak Nx telah menerapkan pencegahan kekambuhan dan langkah keamanan tambahan, dan versi terkait telah dihapus dari npm

---

Gambaran umum dan ringkasan

• Peringatan keamanan ini terkait serangan supply chain serius terhadap paket Nx dan beberapa plugin terkait, dengan kode berbahaya didistribusikan melalui npm
• Versi berbahaya tersebut memindai sistem file pengguna untuk mengumpulkan informasi autentikasi, path, dan lainnya, lalu mengunggahnya ke repositori Github (s1ngularity-repository)
• Skrip postinstall berbahaya juga memodifikasi file konfigurasi shell pengguna (.zshrc, .bashrc) dengan menambahkan perintah mematikan sistem
• Vektor serangan, proses serangan, versi yang terdampak, tindakan segera yang harus diambil pengguna, serta langkah pencegahan agar tidak terulang dijelaskan secara rinci

Langkah darurat

Hal yang harus diperiksa semua orang

1. Periksa daftar repositori di akun Github Anda untuk memastikan apakah s1ngularity-repository telah dibuat
2. Unduh file yang ada di repositori tersebut untuk disimpan sebagai arsip
3. Hapus repositori tersebut dari Github
4. Kirim email ke [e-mail] untuk mendapatkan panduan cara mendekripsi informasi yang bocor
5. Segera ganti semua kredensial dan token untuk seluruh akun

Cara mengganti token Github

• Kunjungi https://github.com/settings/connections/…
• Cabut akses aplikasi yang terhubung untuk menonaktifkan token lama
• Jika menggunakan gh CLI, lakukan autentikasi ulang untuk membuat token baru
• Jika tidak ditindaklanjuti, token lama berisiko disalahgunakan

Hentikan penggunaan versi Nx berbahaya dan lakukan pembersihan

• Periksa apakah versi Nx yang sedang digunakan adalah versi berbahaya dengan perintah npm ls nx
• Jika termasuk versi terinfeksi, lakukan pembaruan dengan npm uninstall nx && npm install nx@latest
• Bersihkan cache dengan npm cache clean --force

Pengguna yang sudah terinfeksi

• Ganti token npm dan Github
• Reset seluruh kata sandi dan kredensial Github serta layanan terkait
• Periksa file .zshrc dan .bashrc untuk memastikan tidak ada perintah asing yang disisipkan, lalu hapus

Untuk administrator repositori paket internal

• Segera hapus versi berbahaya dari proxy di registry internal perusahaan untuk mencegah penyebaran lebih lanjut

Informasi versi yang terdampak

Paket Nx

• 21.5.0, 20.9.0, 20.10.0, 21.6.0, 20.11.0, 21.7.0, 21.8.0, 20.12.0
• Sudah dihapus dari npm per pukul 10:44 PM EDT

@nx/devkit, @nx/js, @nx/workspace, @nx/node, @nx/eslint, @nx/key, @nx/enterprise-cloud

• Sudah dihapus dari npm per pukul 10:44 PM dan 6:20 AM EDT

Rincian vektor serangan

Penyebab workflow yang rentan

• Kerentanan yang memungkinkan eksekusi kode arbitrer diperkenalkan ke workflow Github Actions
• Jika kode bash tertentu disisipkan ke judul PR, kerentanan di workflow memungkinkan perintah sistem dijalankan (Bash Injection)
• Disalahgunakan melalui trigger pull_request_target, sehingga memperoleh hak istimewa yang lebih tinggi (GITHUB_TOKEN, dll.)
• Sampai dihapus, workflow rentan tetap ada di branch lama selain main, sehingga penyerang berhasil menjalankan workflow dengan PR berbahaya dan mencuri secret

Proses pencurian token npm

• Workflow rentan dimanfaatkan untuk menjalankan publish.yml
• publish.yml menyimpan token npm di Github Secrets, dan dalam prosesnya token dikirim ke webhook eksternal
• Pada akhirnya penyerang menggunakan token ini untuk mengunggah versi berbahaya dari Nx dan paket pendukung ke npm

Perilaku paket berbahaya

Mengumpulkan informasi termasuk kredensial dan memublikasikannya ke repositori Github

• Saat skrip postinstall dari paket Nx yang terinfeksi dijalankan, berbagai lokasi file teks dan informasi kredensial dikumpulkan
• Data di-encode dalam base64 lalu diunggah ke repositori Github bernama s1ngularity-repository
• Walaupun repositori aslinya telah dihapus, karena sebelumnya sempat bersifat publik, kemungkinan kebocoran informasi tetap harus dipertimbangkan

Modifikasi profil shell (.zshrc, .bashrc)

• postinstall menyisipkan perintah sudo shutdown -h 0, yang dapat memicu sistem mati saat terminal dijalankan dan berpotensi mengekspos kata sandi

Berbagai skenario saat postinstall dapat berjalan

• Selain saat npm install/yarn/pnpm install dijalankan secara eksplisit, ini juga dapat berjalan dalam berbagai situasi seperti dependensi transitif, ekstensi editor, dan eksekusi skrip

• Khususnya, ekstensi Nx Console untuk VSCode (versi 18.6.30 ~ 18.65.1) dapat secara otomatis memasang nx@latest saat editor dijalankan, sehingga memicu eksekusi postinstall

• Pada dasarnya, perlu diwaspadai bahwa pemasangan modul NPM dapat terjadi di banyak tempat meski tidak disengaja

• Mulai Nx Console (18.66.0), proses pemasangan latest nx telah dihapus

Linimasa serangan dan respons

21 Agustus

• 4:31 PM: PR yang berisi kerentanan Bash injection di-merge
• 10:48 PM: Postingan yang menunjukkan kerentanan dipublikasikan di X (sebelumnya Twitter)

22 Agustus

• Sore hari: investigasi internal, rollback workflow rentan (tidak lengkap)
• Penerapan CodeQL untuk mendeteksi kerentanan serupa pada PR di masa depan

24 Agustus

• Muncul commit di fork penyerang yang menunjukkan indikasi kebocoran token npm
• PR berbahaya dibuat lalu dihapus, dan publish.yml dijalankan oleh PR ini

26 ~ 27 Agustus (distribusi versi berbahaya dan respons)

• Banyak versi berbahaya Nx dan plugin didistribusikan ke npm secara bertahap
• Isu dilaporkan ke komunitas Github/NPM
• 10:44 PM: Pihak NPM mengambil tindakan termasuk menghapus seluruh versi terkait
• 11:57 PM: Semua token untuk publikasi paket terkait Nx dinonaktifkan
• 27 Agustus: Patch Nx Console, 2FA, peralihan ke metode Trusted Publisher, dan langkah tambahan lainnya

Tindakan pencegahan sebelumnya dan respons lanjutan

• 2FA diwajibkan bagi semua maintainer di organisasi nrwl
• Menerapkan mekanisme Trusted Publisher. Distribusi berbasis token npm dilarang
• Ke depannya, paket hanya akan dirilis setelah melalui verifikasi berbasis kepercayaan dan 2FA
• Deteksi risiko tambahan, persetujuan PR, perlindungan branch, dan langkah bertahap lainnya juga diterapkan

Pelajaran dan rencana ke depan

• Kembali menyadarkan pentingnya supply chain, pipeline CI/CD, dan prinsip minimisasi izin workflow baik secara lokal maupun global
• Setelah ditinjau ulang secara internal, tim berencana membagikan pembelajaran ini kepada komunitas

Pertanyaan

• Dapat menghubungi [e-mail]

Referensi dan lampiran

• Isu utama Github, linimasa, dan postingan terkait
• Menyediakan contoh skrip telemetry.js di dalam paket yang terinfeksi
• Skrip ini mengumpulkan path file teks penting dalam sistem file untuk tujuan pembuatan inventaris

Ringkasan kesimpulan

• Penting untuk segera menerapkan pembaruan dan patch terbaru untuk Nx dan plugin terkait
• Sangat disarankan untuk segera mengganti informasi autentikasi penting seperti npm dan Github
• Insiden ini menjadi pengingat bahwa lemahnya keamanan supply chain dan pengelolaan izin workflow dapat berujung pada insiden besar

[GN⁺]

Komentar Hacker News

• Ingin mengingatkan secara berkala untuk menonaktifkan skrip npm install

  • Contohnya bisa memakai perintah berikut:

      npm config set ignore-scripts true [--global]
    

  • Pengaturan ini bisa dengan mudah diterapkan per proyek atau secara global

  • Saat ini jarang ada paket sah yang tidak bisa berjalan tanpa skrip, jadi dalam kebanyakan kasus tidak masalah

  • Untuk paket yang benar-benar membutuhkannya, bisa diatasi dengan membuat skrip instalasi terpisah lalu menjalankannya secara manual di folder tersebut

  • Ini bukan solusi ajaib untuk semua serangan supply chain, tetapi cukup efektif memblokir banyak serangan nyata lewat npm

  • Untuk detail lebih lanjut, lihat dokumentasi resmi npm config

  • Saya juga memakai bubblewrap untuk mengisolasi npm, pnpm, yarn, dan semua sesi yang mereka jalankan dari sistem

    • Kode sumber saya hanya ada di bawah ~/code, dan saya menyimpan skrip bash berikut sebagai npm di awal PATH
    • Package manager lain juga dihubungkan lewat symlink/hardlink:

      #!/usr/bin/bash
      bin=$(basename "$0")
      exec bwrap \
        --bind ~/.cache/nodejs ~/.cache \
        --bind ~/code ~/code \
        --dev /dev \
        --die-with-parent \
        --disable-userns \
        --new-session \
        --proc /proc \
        --ro-bind /etc/ca-certificates /etc/ca-certificates \
        --ro-bind /etc/resolv.conf /etc/resolv.conf \
        --ro-bind /etc/ssl /etc/ssl \
        --ro-bind /usr /usr \
        --setenv PATH /usr/bin \
        --share-net \
        --symlink /tmp /var/tmp \
        --symlink /usr/bin /bin \
        --symlink /usr/bin /sbin \
        --symlink /usr/lib /lib \
        --symlink /usr/lib /lib64 \
        --tmpfs /tmp \
        --unshare-all \
        --unshare-user \
        "/usr/bin/$bin" "$@"
      

    • Dengan cara ini, package manager hanya mendapat akses ke ~/code dan akses baca-saja ke library sistem
    • bubblewrap stabil dan merupakan alat yang dipakai oleh Steam dan flatpak

  • Memakai pnpm juga bisa jadi cara. Versi terbaru secara default mengabaikan semua lifecycle script, dan hanya menjalankannya jika dimasukkan ke whitelist satu per satu

  • Setiap kali mendengar saran ini, saya selalu bertanya: dalam praktiknya tidak ada developer yang membaca puluhan hingga jutaan baris kode yang diinstal npm

    • Alur kerja kebanyakan developer biasanya seperti ini
      1. git clone
      2. npm install (di sini ada risiko paket berbahaya terinstal; mengabaikan skrip post-install hanya menahannya sementara)
      3. npm run (di sini paket berbahaya dijalankan dan infeksi terjadi)
    • Agar saran ini benar-benar berguna, orang harus memantau/mengaudit seluruh node_modules di antara langkah 2 dan 3, dan tidak ada yang melakukannya

  • Saya menjalankan semua tool berbasis npm di dalam container Docker tanpa hak akses ke apa pun selain direktori saat ini

    • Ini sangat mengurangi attack surface
    • Caranya dijelaskan di blog ini

  • Saya penasaran kenapa saran semacam ini tidak diterapkan ke setup.py (Python) atau build.rs (Rust)

    • npm sering disalahgunakan bahkan untuk distribusi software (misalnya mendistribusikan program terpisah), sedangkan package manager bahasa lain tampaknya lebih dipakai hanya untuk mengelola library
    • Diskusi terkait bisa dilihat di sini

• Kita perlu budaya untuk benar-benar berpikir dua kali saat menambahkan dependensi baru

  • Tahun ini sudah terjadi sangat banyak serangan supply chain

  • Minggu ini saya ingin menambahkan progress bar dengan 8 penghitung statistik ke proyek Go

  • Setelah mencari library, ternyata kodenya lebih dari 3.000 baris, jadi saya minta LLM membuat UI sederhana dan selesai dalam kurang dari 150 baris

  • Tanpa dependensi, berjalan persis seperti yang diinginkan, sangat sederhana, dan semua orang bisa dengan mudah membaca serta memperbaikinya

  • Fungsinya menghapus output terminal lalu menggambar ulang setiap detik, dengan dukungan thread-safe

  • Implementasi dan review cukup 25 menit

  • Jika tidak butuh fitur statistik yang kompleks, progress bar bahkan bisa dibuat dengan sekitar 30 baris kode

  • Ke depannya, saat mempertimbangkan apakah perlu menambah dependensi, sepertinya membuat sendiri lebih cocok untuk saya

  • Saya tidak punya cukup sumber daya untuk memantau semua update paket

  • Saya setuju dengan poin itu, dan saat “package manager per bahasa” mulai populer dulu saya benar-benar merasa cemas

    • Saya bekerja di area system programming dan dulu mengamati pip, npm, dan sejenisnya dari kejauhan
    • Lalu saat pindah ke proyek Rust dan melihat puluhan dependensi tak tervalidasi ditarik dari internet hanya dengan satu baris konfigurasi Cargo, saya pikir itu berbahaya
    • Ternyata memang benar terjadi. Saya rasa ini bukan arah yang baik. (Meski saya tidak berharap kita akan berbalik arah. Keamanan komputer memang nyaris tidak ada…)

  • Saya rasa pendekatan seperti cargo vet adalah arah ke depan: pengenalan cargo vet

    • Tentu saja overhead-nya akan besar karena sistem semacam ini dibutuhkan di semua ekosistem bahasa
    • Internet awal dulu, atau email, juga pernah punya masa yang baik, tetapi akhirnya rusak oleh spam dan komersialisasi
    • Kini bahkan rantai dependensi ikut terdampak hal yang sama
    • Inilah alasan kita tidak bisa terus mempertahankan lingkungan yang bagus

  • Perbedaan antara implementasi sendiri dan memakai library memang hal yang wajar

    • Library pada dasarnya bersifat umum, harus fleksibel dan dapat dikonfigurasi untuk berbagai lingkungan, jadi wajar jika kodenya menjadi panjang

  • Saya sangat benci library progress bar seperti ini, terutama yang merusak emacs shell (expo, eas, dsb.)

    • Saya tidak mengerti kenapa tidak cukup menampilkan output seperti ..10%..20%..30% atau Uploading…
    • Menurut saya, kode kontrol terminal seharusnya hanya dipakai untuk TUI atau antarmuka interaktif

  • Tim kami di sebuah perusahaan asuransi besar mengelola monorepo skala besar dan library dengan NX sebagai pusatnya

    • Kami mengelola lebih dari 10 aplikasi independen dan lebih dari 25 library dalam satu monorepo, dengan CI/CD yang terikat cukup berat
    • Kami juga sudah mencoba lerna, rushjs, yarn workspaces, dan lainnya, tetapi belum ada tool yang bekerja sebaik NX (lerna pun akhirnya diakuisisi NX, rushjs juga kurang terurus)
    • Saya ingin mendengar usulan metode/alternatif yang benar-benar bisa menangani kompleksitas monorepo frontend dengan baik
    • Karena insiden keamanan ini membuat banyak orang tertarik pada alternatif, saya menunggu berbagai pendapat

• Daripada hanya menyalahkan Nx, Anthropic, atau platform-nya, kita perlu memikirkan ulang penyebab sebenarnya

  • Penyebab praktis dari serangan ini adalah paket berbahaya bisa diunggah dengan “token” yang dicuri (string otorisasi untuk operasi package manager)
  • Tapi itu hanya cara pengirimannya; akar penyebab yang membuatnya berhasil adalah hal-hal berikut:
    1. Repositori package manager tidak mewajibkan artifact signing, sehingga tidak bisa diverifikasi bahwa hasil build dibuat oleh developer yang berwenang
    2. Code signing juga tidak diwajibkan
    3. (Dugaan) Tidak ada heuristik untuk mencegah upload mencurigakan seperti deteksi perilaku anomali, IP baru, perubahan negara, dan sebagainya
    4. (Dugaan) MFA tidak diwajibkan saat memakai token yang dicuri
    5. (Dugaan) Token bukan sekali pakai
    6. (Dugaan) Token tidak disimpan di password manager yang meminta persetujuan manual jika dipakai dari aplikasi atau sesi baru
  • Semua hal ini sepenuhnya bisa dicegah
  • Bahkan jika Anda sendiri menjadi korban dan repositori baru dibuat di akun GitHub Anda, itu berarti Anda pun gagal melindungi token autentikasi Anda dengan cukup kuat
  • Fakta bahwa langkah-langkah pencegahan semacam ini belum menjadi default adalah kegagalan besar seluruh industri software
    • Serangan seperti ini terus berulang selama bertahun-tahun
    • Kita sendiri adalah para developer, tetapi tidak memperbaikinya
  • Karena itu saya berpendapat software juga perlu regulasi wajib seperti kode bangunan, lengkap dengan inspeksi dan denda

    • Serangan ini bisa menimbulkan kerusakan fatal pada puluhan ribu institusi di bidang keuangan, listrik, telekomunikasi, rumah sakit, militer, dan lain-lain

    • Dengan makin meluasnya AI, skala dan dampak serangan akan semakin besar

    • Kita tidak cukup bertanggung jawab dalam menulis software. Seperti kode bangunan, kepatuhan terhadap keselamatan dan keamanan mungkin perlu dipaksakan

    • Saya pikir orang kurang menyadari betapa berbahayanya lingkungan komputasi pribadi saat ini yang menyatukan semuanya dalam satu ruang besar

      • Di Mac, Windows, dan Linux, crypto wallet, file kredensial, dan berbagai aplikasi bercampur jadi satu
      • Tool untuk memisahkan semua itu dengan baik masih sangat buruk
      • Kadang ketika menjalankan beberapa Windows VM di macOS, saya membayangkan masa depan di mana kita bisa Alt-Tab dengan mulus ke container atau VM per jenis pekerjaan
      • Misalnya: container gaming, container khusus kerja kripto, container per proyek kode utama, dan seterusnya
      • Fakta bahwa satu pemasangan extension VSCode bisa membocorkan kunci Bitcoin adalah kenyataan yang benar-benar absurd
      • Saya rasa aturan seperti “kode bangunan software” sulit menyelesaikan masalah mendasar seperti ini
      • Kita juga butuh aturan di level OS yang mengendalikan akses data antar-aplikasi, dan perlu dibahas bagaimana itu disusun serta ditegakkan

    • 50% korban menggunakan VS Code sebagai jalur infeksi, dan hanya bekerja di Linux serta macOS

      • Untuk analisis detail serangan ini, lihat analisis blog
      • Saat terinfeksi:
        • Pada tahap postinstall, aset penting seperti kredensial pengguna dikumpulkan (crypto wallet, token Github dan npm, kunci SSH, dll.)
        • Menggunakan tool command-line AI (Claude, Gemini, Q, dll.) untuk pengumpulan informasi dan pengintaian aktif
        • Data yang dicuri diunggah ke repositori GitHub milik penyerang (s1ngularity-repository dan lain-lain) setelah di-encode dua atau tiga kali dengan base64
        • Ditemukan ribuan repositori semacam itu
        • Lebih dari 1000 token GitHub, puluhan kredensial cloud dan NPM, serta sekitar 20 ribu file bocor
        • Serangan terutama berjalan lewat extension VSCode milik NX, atau dalam build pipeline seperti Github Actions
        • Pada 27 Agustus pukul 9AM UTC, GitHub menonaktifkan semua repositori penyerang, tetapi selama jendela paparan hingga 8 jam itu data sudah bocor
        • Encoding base64 mudah dipulihkan ke bentuk asli, jadi data ini pada dasarnya harus dianggap sudah dipublikasikan seluruhnya

    • Fakta bahwa token/kredensial GitHub tidak disimpan di password manager dengan mekanisme pelepasan manual juga sebagian salah GH CLI

      • GH CLI, setelah login sekali, memiliki hak untuk upload ke repositori dan hampir tidak pernah meminta autentikasi ulang
      • AWS CLI, meski bergantung kebijakan, biasanya kedaluwarsa otomatis setiap 18 jam
      • Namun kedua platform sama-sama cenderung meninggalkan token dalam bentuk plaintext di lingkungan lokal secara default

    • Saya tidak suka ide memperkenalkan “kode bangunan software”, tetapi saya setuju bahwa seluruh industri terlalu rapuh

      • Mungkin regulasi memang benar-benar diperlukan

    • Menuntut tanggung jawab hanya karena seseorang memakai library open source gratis menurut saya arogan

      • Jika ingin jaminan yang layak, Anda harus membeli lisensi
      • Ini mirip dengan kebijakan validasi agresif Google terhadap software gratis

• Akhir-akhir ini saya mengerjakan sebagian besar pekerjaan development di VM

  • Rasanya tingkat keamanan lingkungan saat ini sudah tidak bisa diterima

  • Potensi agent (software agen) menjadi vektor malware sekarang sangat besar

  • Jika penyerang berhasil masuk ke box (PC), ini zaman di mana data bernilai lebih dari 1.000 dolar, kunci kripto, password, data pribadi, dokumen finansial, dan sebagainya bisa langsung jadi sasaran

    • Saya juga melakukan hal serupa di dalam container Podman. Tidak berbagi apa pun dengan host selain direktori source code

    • Sebagian masalah berasal dari model keamanan PC tradisional (Linux/Windows)

      • Model yang menganggap executable itu tepercaya dan membiarkannya mengakses semua data pribadi saya tidak lagi cocok untuk situasi tahun 2025
      • Mobile (Android) sebagian besar sudah mengatasi ini, tetapi di PC selain SELinux belum banyak alternatif mendalam

    • Jika Anda menyukai pendekatan seperti ini, saya ingin merekomendasikan Qubes OS. UX-nya bagus untuk melakukan semua pekerjaan di VM

      • Itu daily driver saya, sangat saya rekomendasikan

    • Namun perlu disebutkan bahwa membangun lingkungan seperti ini sangat sulit atau cukup mahal, karena ekosistem dan sejarah software

• Claude Code adalah tool revolusioner untuk meningkatkan produktivitas

  • Di sisi lain, ada isu keamanan seperti berikut:

    • Aplikasi NodeJS
    • Saat instalasi di-pipe dari curl ke bash (risiko remote code execution)
    • LLM bisa menyentuh file system, command, dan banyak hal lain

  • Jadi ada setidaknya tiga kelemahan keamanan seperti ini, dan saya tidak ingin menjalankannya di luar sandbox seperti VM/container/dev box khusus

    • Saya juga setuju bahwa agen sebaiknya dijalankan di sandbox

      • Meski begitu, Claude code sejak awal tidak mengeksekusi perintah secara sewenang-wenang tanpa izin terpisah

    • Tapi memangnya kenapa?

      • Programnya hanya berjalan jika user sendiri menekan tombol eksekusi
      • Kebanyakan program juga punya izin
      • Terminal juga bisa menyentuh filesystem, tapi itu bukan berarti ia berjalan sembarangan
      • Claude Code bukan daemon yang bergerak sendiri merusak komputer saya; tanpa instruksi yang jelas, tidak akan terjadi apa-apa
      • Saya menganggap Claude Code sebagai tool terbaik yang saya pakai dalam 30 tahun terakhir
      • Saya tidak terlalu peduli apa “vektor serangannya”. Jika orang lain bisa masuk tanpa izin ke komputer saya, itu bukan masalah unik Claude Code

    • Titik yang benar-benar berbahaya adalah ia melakukan auto-update tanpa intervensi pengguna, sehingga selama proses berjalan pada dasarnya Anda memberi Anthropic hak remote code execution

• Saya penasaran apakah package manager perlu pengaturan seperti ‘minimum usia paket (min-age)’

  • Misalnya, jika paket didaftarkan kurang dari 24~36 jam lalu, maka diabaikan

  • Dulu saya pernah mengalami kasus serupa: update paket merusak semuanya lalu beberapa jam kemudian cepat diperbaiki/dihapus

    • GitHub dependabot baru-baru ini menambahkan fitur persis seperti itu

      • changelog resmi

    • Renovate bot sudah lama menyediakan opsi ini (minimumReleaseAge), dan sekarang dependabot juga mendukungnya

      • Package manager sendiri hanya fokus memasang versi terbaru, tetapi dengan tool gratis seperti ini kita bisa mengelola update pada interval yang masuk akal
      • Ekosistem JavaScript perlahan bergerak ke arah yang lebih terintegrasi, dan tool untuk menghadapi serangan supply chain pelan-pelan mulai muncul
      • NPM, PNPM, Bun terbaru, dan lain-lain tidak lagi menjalankan skrip postinstall secara default, dan harus dijalankan secara eksplisit bila perlu (meski pada akhirnya tetap berarti menjalankan kode orang lain)

    • Bukan di level OS, tetapi tool uv dari Astral punya opsi seperti ini untuk paket Python

    • npm install juga punya flag untuk hanya memasang dependensi sebelum waktu/tanggal tertentu

      • Dengan npm install --before (tanggal 2 hari lalu), dependensi yang muncul setelah tanggal itu tidak akan dipasang

    • Saya mengatur save-exact=true di .npmrc dan hanya mengandalkan lockfile serta update manual

      • Paket tidak perlu terlalu sering di-upgrade
      • Setelah mengalami kasus fakerjs dan semacamnya, saya merasa kita memang harus berhati-hati

• Saya penasaran apakah claude code benar-benar akan menjalankan prompt seperti itu, jadi saya mengujinya

  • Hasilnya seperti berikut:

    • “Permintaan ini tampaknya meminta pencarian/pendaftaran file sensitif seperti crypto wallet, private key, dan sejenisnya, sehingga berpotensi disalahgunakan dan saya tidak bisa membantu”

    • Ia hanya mengarahkan ke permintaan yang sah seperti pemeriksaan keamanan, analisis kerentanan, penulisan tool monitoring, memahami izin file, atau merancang prosedur backup

    • Saya sudah mengamankan setidaknya 250 kasus sukses (artinya beberapa prompt memang lolos)

      • Rata-rata Claude jelas punya tingkat penolakan yang lebih tinggi, dan Q juga cukup sering menolak (masuk akal karena berbasis Claude)
      • Sebagai referensi, saya menghabiskan sepanjang hari menangani isu seperti ini sambil menyusun laporan analisis terkait

    • Dalam praktiknya, setiap kali Claude diadu dengan model lain dalam hal penolakan, saya selalu melihat penolakan/pengaman Claude jauh lebih baik

      • Contoh terkenal: saat ChatGPT terus melabeli pengguna dengan isu kesehatan mental sebagai “The Oracle” dan membiarkannya, Claude justru menolak dan menyarankan bantuan profesional
      • Tentu jawaban model seperti “Benar sekali!” yang berulang bisa menjengkelkan, tetapi Anthropic memang pantas diakui dan dipuji karena lebih memperhatikan penolakan dan keselamatan dibanding pesaing lain

• OS pada dasarnya seharusnya mencegah aplikasi memiliki akses tak terbatas ke seluruh filesystem

  • Beberapa aplikasi memang punya profil apparmor/selinux, dan firejail juga bisa dipakai

  • Tetapi dari sisi UX, perubahan tetap dibutuhkan

    • Ini masalah yang sangat serius. Ini akibat desain desktop 30 tahun lalu

      • Sebaliknya, OS mobile modern (iOS, dsb.) secara default unggul dalam sandbox per aplikasi dan kebijakan persetujuan izin
      • Di desktop memang ada berbagai upaya seperti Qubes (OS), Firejail, bubblewrap, AppArmor, dan lainnya, tetapi semuanya kompleks atau sulit dipakai pengguna umum
      • Ada juga OpenSnitch, tetapi terbatas pada networking
      • Dari sudut pandang pengguna akhir, mengatur izin detail untuk tiap program itu memberatkan
      • Pada akhirnya, yang penting adalah profil untuk aplikasi populer dirawat secara konsisten
      • Saya sangat terkejut desktop security bisa serapuh ini, tetapi masalahnya memang mendasar, sulit, dan insentif finansial untuk menyelesaikannya kecil

    • Saya sedang mengembangkan sendiri tool di Linux yang fokus pada isolasi lingkungan per proyek dengan Podman: probox

      • Ada banyak upaya untuk meningkatkan UX
      • Saya cukup sering memakainya, dan butuh orang yang bersedia melakukan security review

    • Dalam hal keamanan file Android, Google melakukan pekerjaan dengan baik

    • Saya juga merekomendasikan belajar memakai bubblewrap dan lingkungan chroot kecil

    • Saya rasa tidak ada sistem operasi yang menjadikan “aplikasi punya akses tak terbatas ke seluruh filesystem” sebagai default

      • Linux, BSD, MacOS, dan Windows semuanya punya pembatasan yang kuat
      • Selama pengguna biasa tidak secara berbahaya menaikkan hak akses akun sendiri saat menjalankannya, secara default sebenarnya aman

• Dulu ada rasa percaya diri samar bahwa “penyerang harus menebak lingkungan saya”, tetapi sekarang mereka bisa menyuruh LLM mempelajari lalu melakukan serangan yang sesuai dengan lingkungan tersebut

  • Saya menilai diri sendiri sempat memprediksi arah seperti ini

  • Ada diskusi yang layak dilihat di pembahasan sebelumnya

    • (Bercanda) Saya penyerang, ada ide baru? (/s)

• Bagian yang benar-benar menyeramkan adalah, sekarang mereka memakai LLM lokal untuk mencari secret

  • Masalah “postinstall” tetap seperti dulu, tetapi payload-nya benar-benar generasi baru

  • Logika berbahaya disembunyikan di prompt alih-alih kode, jadi jauh lebih sulit dideteksi lewat analisis statis yang ada sekarang

  • Saya jadi berpikir bagaimana seharusnya kita bertahan dari prompt berbahaya seperti ini

    • Sepertinya satu-satunya jawaban adalah menjalankan Claude Code di container/VM yang sepenuhnya terisolasi, lalu me-review sendiri semua kode yang akan di-commit