Lebih dari 100.000 repositori terinfeksi ditemukan di GitHub

 (apiiro.com)
1 poin oleh GN⁺ 2024-03-01 | 1 komentar | Bagikan ke WhatsApp
  • Kampanye repo confusion (kebingungan repositori) yang dimulai pada pertengahan 2023 kembali meluas, dan lebih dari 100.000 repositori berisi payload berbahaya serupa terdeteksi di GitHub
  • Penyerang membuat salinan berbahaya yang mirip dengan repositori sah untuk memancing kekeliruan developer, lalu menggabungkan kloning, penyisipan loader, pengunggahan ulang, fork massal, dan promosi terselubung
  • Saat repositori berbahaya dijalankan, kode Python dan biner diunduh setelah obfuscation 7 tahap dibuka, lalu data sensitif seperti informasi login, kata sandi browser, dan cookie dicuri
  • Meski GitHub menghapus sebagian besar fork secara otomatis, repositori yang lolos deteksi dan unggahan manual tetap bertahan; bahkan jika hanya 1% yang bertahan, ribuan repositori berbahaya tetap ada
  • Alur serangan bergeser dari paket berbahaya PyPI ke repositori GitHub, sehingga software supply chain di luar package manager juga menjadi permukaan serangan langsung

Cara kerja serangan repo confusion

  • Repo confusion mirip dengan dependency confusion karena sama-sama membuat pengguna mengunduh repositori berbahaya alih-alih repositori sah
  • Perbedaannya ada pada titik yang dieksploitasi
    • dependency confusion memanfaatkan cara kerja package manager
    • repo confusion bergantung pada situasi ketika manusia salah memilih repositori yang tampak mirip
  • Kampanye ini meningkatkan peluang infeksi dengan menyebarkan repositori berbahaya secara massal di GitHub
    • Mengkloning repositori yang sudah ada seperti TwitterFollowBot, WhatsappBOT, discord-boost-tool, Twitch-Follow-Bot
    • Menyisipkan malware loader ke dalam salinannya
    • Mengunggahnya kembali ke GitHub dengan nama yang sama
    • Melakukan fork otomatis ribuan kali untuk tiap repositori
    • Mempromosikannya secara terselubung di forum, Discord, dan tempat lain

Alur setelah repositori berbahaya dijalankan

  • Saat pengguna memakai repositori berbahaya, payload tersembunyi membuka obfuscation 7 tahap
  • Setelah itu, kode Python berbahaya dan file executable biner diambil
  • Kode berbahaya terutama berbasis versi modifikasi dari BlackCap-Grabber
  • Target pengumpulan mencakup kredensial login berbagai aplikasi, kata sandi dan cookie browser, serta data rahasia lainnya
  • Data yang dicuri dikirim ke server C&C (command-and-control) milik penyerang, lalu aktivitas berbahaya tambahan berlanjut
  • Analisis kode terkait dapat dilihat di technical analysis dari Trend Micro

Penghapusan otomatis GitHub dan repositori yang tersisa

  • GitHub mengidentifikasi otomatisasi dan dengan cepat menghapus sebagian besar repositori hasil fork
  • Namun, deteksi otomatis melewatkan banyak repositori, dan repositori yang diunggah secara manual tetap bertahan
  • Karena rantai serangan ini terotomatisasi dalam skala besar, meski hanya 1% yang tersisa, jumlahnya tetap menjadi ribuan repositori berbahaya
  • Dengan mencari 🔥 2024 language:python di GitHub, Anda dapat melihat sebagian repositori yang saat ini sedang menyebar
  • Jika repositori yang telah dihapus ikut dihitung, skala totalnya mencapai jutaan
    • Penghapusan biasanya terjadi beberapa jam setelah pengunggahan, sehingga sulit didokumentasikan
    • Banyak repositori asli tetap ada, dan penghapusan terutama menargetkan fork bomb
    • Sebagai contoh, daftar repositori Mattia69 menampilkan ribuan fork pada ringkasannya, tetapi tidak muncul di detail fork
  • Sebagian pengguna yang tidak menyadari repositori tersebut berbahaya ikut melakukan fork, sehingga muncul efek jaringan social engineering sekunder

Timeline perkembangan kampanye

  • Mei 2023: Phylum melaporkan paket berbahaya yang diunggah ke PyPI
    • Paket-paket ini berisi bagian awal dari payload saat ini
    • Penyebarannya terjadi melalui pemanggilan os.system("pip install package") yang ditanamkan pada fork repositori GitHub populer seperti chatgpt-api
  • Juli–Agustus 2023: Sejumlah repositori berbahaya diunggah ke GitHub dan mengirimkan payload secara langsung, alih-alih mengambil paket PyPI
    • Ini adalah perubahan setelah PyPI menghapus paket berbahaya dan perhatian komunitas keamanan meningkat
    • Aliakbar Zahravi dan Peter Girnus dari Trend Micro menerbitkan analisis teknis
  • November 2023–sekarang: Lebih dari 100.000 repositori berisi payload berbahaya serupa telah terdeteksi, dan jumlahnya terus bertambah
  • Alasan metode ini menguntungkan penyerang cukup jelas
    • Skala GitHub sangat besar, sehingga instance massal pun relatif kecil dan sulit dideteksi
    • Tidak seperti sebelumnya, package manager tidak terlibat sehingga tidak ada nama paket berbahaya eksplisit yang tertinggal sebagai indikator
    • Repositori target berada di ceruk kecil dan kurang populer, sehingga developer lebih mudah keliru mengkloning repositori tiruan berbahaya

Perpindahan dari package manager ke SCM

  • Perpindahan dari paket berbahaya PyPI ke repositori berbahaya GitHub sejalan dengan tren yang terlihat di berbagai package manager dan platform SCM
  • Ketika komunitas keamanan lebih berfokus pada package manager, jalur serangan bergeser ke tempat lain
  • GitHub dan platform serupa memudahkan pembuatan akun dan repositori secara otomatis, serta menyediakan API yang nyaman dan rate limit longgar yang mudah dilewati
  • Karena bisa bersembunyi di antara begitu banyak repositori, SCM menjadi target yang cocok untuk menginfeksi software supply chain secara diam-diam
  • Kampanye dependency confusion, kode berbahaya di package registry, dan penyebaran kode berbahaya melalui SCM menunjukkan bahwa meski ada banyak alat dan mekanisme keamanan, keamanan software supply chain tetap rentan

Indikator untuk memeriksa infeksi

  • Cari pola berikut dalam kode Python, lalu investigasi item yang cocok
    • exec(Fernet
    • exec(requests
    • exec(__import
    • exec(bytes
    • exec("""\nimport
    • exec(compile
    • __import__("builtins").exec(
  • Periksa apakah ada repositori terkait otomasi platform sosial, bot, atau game di lingkungan lokal, lalu hapus
  • Jika benar-benar perlu menggunakannya, pasang ulang dengan memverifikasi sumbernya secara cermat atau jalankan di sandbox
  • Jika ada kemungkinan Anda pernah mengkloning repositori jenis ini, anggap cookie, kredensial, dan kunci berikut telah dicuri, lalu lakukan respons yang sesuai
    • Browser: layanan keuangan, layanan email, layanan kripto, Amazon, eBay, AliExpress, Facebook, Instagram, Twitter, Youtube, Discord, TikTok, Telegram, Twitch, Steam, Yahoo, ExpressVPN, Spotify, layanan streaming
    • Aplikasi: Exodus, Atomic Wallet, Guarda, Coinomi, Ethereum
  • Daftar lengkap checksum file sulit ditangani secara praktis, tetapi beberapa item umum dapat dilihat di VirusTotal graph
  • Setelah menerima pemberitahuan, Cloudflare menonaktifkan DNS record dari alamat berbahaya yang ditemukan

Pertahanan dan respons

  • GitHub telah diberi tahu dan menghapus sebagian besar repositori berbahaya, tetapi kampanye ini masih berlanjut
  • Serangan yang mencoba menyuntikkan kode berbahaya ke supply chain semakin meluas
  • Ada banyak solusi yang menangkap malware di tingkat sistem dan jaringan, tetapi supply chain masih menjadi permukaan serangan yang besar dan menguntungkan bagi penyerang
  • Jika menemukan repositori berbahaya, terlepas dari apakah itu bagian dari kampanye ini atau bukan, Anda dapat melaporkannya melalui abuse or spam report GitHub
  • Apiiro membangun sistem deteksi kode berbahaya yang memantau codebase terhubung
    • Analisis kode berbasis LLM
    • Penguraian kode menjadi grafik alur eksekusi lengkap
    • Mesin heuristik
    • Decoding, dekripsi, dan deobfuscation dinamis
  • Tanpa memantau payload berbahaya yang disisipkan, keamanan organisasi akan bergantung pada kemampuan developer untuk tidak memilih repositori keliru yang hampir identik, tidak adanya kesalahan konfigurasi CI/CD sama sekali, dan kode pihak ketiga yang 100% aman
  • Diperlukan pendekatan yang melampaui deteksi dan inventarisasi kerentanan biasa, untuk mengungkap generasi berikutnya dari risiko software supply chain dan aplikasi

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-01
Komentar Hacker News

  • Selain peringatan umum bahwa kode yang diambil dari repositori publik atau sumber eksternal harus diwaspadai dan pohon dependensi diverifikasi, saya penasaran apa dampaknya terhadap LLM dan alat otomasi yang dilatih dengan konten tersebut jika ada kode berbahaya dalam jumlah besar di repositori publik
    Sepertinya ada kemungkinan bagian berbahaya ikut terselip secara kebetulan saat alat seperti Copilot membuat jawaban kode yang panjang
    Hal seperti kerentanan injeksi sederhana sudah sering terlihat

    • Dibanding backdoor masuk secara kebetulan ke keluaran LLM, saya lebih khawatir badan intelijen menanamkan backdoor ke keluaran LLM
      Mungkin belum sekarang, tetapi dalam beberapa tahun ke depan rasanya sangat mungkin
    • LLM tampaknya bukan hanya menempelkan kode rentan yang ada di data masukan, tetapi juga akan menciptakan kerentanan baru sendiri
      AI tidak memberi jaminan apa pun soal akurasi
    • Saya baru saja mengunggah isu terkait LLM tentang pembajakan bot konversi safetensors milik Hugging Face: https://news.ycombinator.com/item?id=39549482
      Ditunjukkan bahwa penyerang dapat mengambil alih bot layanan yang terhubung dengan Hugging Face Safetensors Conversion Space, sebuah layanan populer untuk mengonversi model machine learning yang tidak aman dalam ekosistem menjadi versi yang lebih aman
    • Risikonya memang ada, tetapi mirip dengan risiko masuknya kode rentan yang disalin dari suatu tempat ketika kita menerima PR rekan tanpa peninjauan
      Jika memakai LLM, kita harus menginvestasikan lebih banyak upaya dalam code review, dan menurut saya trade-off itu sepadan
    • Jumlah sampel yang terdeteksi dalam kampanye ini sangat besar, jadi risikonya lebih realistis daripada yang diperkirakan
      Namun agar benar-benar berujung pada insiden nyata, biasanya ada dua penghalang: generator menerima instruksi internal untuk menghindari kode semacam itu, dan karena karakteristik LLM, kecil kemungkinan ia mengulang alamat penyerang sebenarnya secara persis
      Meski begitu, berbagai vektor serangan seperti bind shell, denial of service, dan eksfiltrasi di lapangan tetap ada

  • GitHub gagal dengan cara yang mirip dengan kegagalan Usenet
    Siapa pun bisa membuat repositori, dan tidak ada yang membedakan repositori resmi dari repositori spam
    Seperti Amazon yang menargetkan menjadi “toko untuk segala hal” lalu terkena kenyataan bahwa “90% dari segala hal adalah sampah” hingga menjadi toko yang sebagian besar berisi sampah, GitHub juga harus menentukan apakah produknya adalah “repositori untuk semua orang” atau “kode yang dapat dipercaya”
    Misalnya, untuk PG JDBC resmi pun tampaknya tidak ada unsur yang tidak bisa direplikasi oleh spammer; bagaimana kita bisa percaya bahwa ini bukan repositori terinfeksi: https://github.com/pgjdbc

    • GitHub tampaknya sudah memilih repositori untuk semua orang ketika pertama kali memulai perusahaan 16 tahun lalu
    • Kalau ini pustaka Java, biasanya orang akan mengunduhnya dari Maven Central, bukan dari GitHub
      Sonatype mensyaratkan bukti kepemilikan domain terbalik yang digunakan pada groupId, dan dalam kasus ini adalah org.postgresql
      Caranya ada di sini: https://central.sonatype.org/faq/how-to-set-txt-record/
      Jika ingin lebih yakin, semua artefak yang dipublikasikan ke Maven Central ditandatangani, jadi tanda tangan GPG juga bisa diperiksa, tetapi kekurangannya adalah Anda harus mendapatkan kunci yang dipakai Postgres untuk tanda tangan melalui jalur yang independen dari Sonatype
      Untuk PG, pencarian cepat tidak menemukan kuncinya
    • Sepertinya orang belum benar-benar merasakan betapa kecilnya angka ini
      GitHub memiliki sekitar 500 juta repositori, jadi angka ini sebenarnya cukup baik
    • Lebih dari 100 ribu repositori terinfeksi memang tidak bagus, tetapi itu bukan berarti GitHub gagal
      Developer yang akan memakai repositori terinfeksi pasti bisa menemukan banyak cara lain untuk membuat produk yang tidak aman sekalipun repositori seperti itu tidak ada di GitHub
    • Jika membuktikan kepemilikan domain, halaman organisasi bisa mendapatkan badge terverifikasi, dan itu dapat cukup meningkatkan tingkat kepercayaan
      Organisasi yang dijadikan contoh tampaknya hanya belum melakukannya

  • Masalah rantai pasok benar-benar bikin pusing
    Saya tidak menargetkan rilis npm secara langsung, tetapi saya membuat rilis npm untuk memantau proyek peramban web virtualisasi ringan bernama BrowserBox dengan menggunakan socket.dev
    Proyek ini juga punya sekitar 800 dependensi jika menghitung seluruh subdependensi, dan hanya memakai 19 dependensi tingkat atas; untuk ukuran seluruh stack, ini tergolong relatif ringan
    Sekarang saya sedang mempertimbangkan untuk membuat snapshot semua 800 dependensi itu ke namespace @browserbox di npm, lalu melacak dan menambal kerentanan yang ditemukan
    Kedengarannya gila, tetapi begitulah situasinya sekarang, dan setidaknya dengan begitu kami bisa menjamin sendiri kerentanan rantai pasok di sisi Node/JS dalam standar keamanan perusahaan
    https://socket.dev
    https://github.com/BrowserBox/BrowserBox

    • Saya tidak tahu seberapa banyak fungsi serupa yang ada di npm, tetapi crates.io dan cargo memiliki alat untuk memeriksa CVE pada pohon dependensi di pipeline, seperti cargo audit dan cargo deny
      Karena lock file mempertahankan sha256 seluruh pohon, meskipun repositori diretas, tidak perlu melakukan mirroring untuk mencegah perubahan
      Mengunci ke versi yang tertinggal beberapa bulan dari yang terbaru tampaknya menjadi keseimbangan yang tepat: menghindari CVE baru tanpa terjebak pada versi yang terlalu lama sehingga harus melakukan perbaikan besar sekaligus
      Jumlah unduhan tampaknya metrik yang lumayan jika dibandingkan dengan dependensi tingkat atas untuk tujuan serupa, tetapi itu penilaian subjektif
      Austral memberi izin granular pada dependensi melalui tipe linear
      Misalnya, library grafis tidak perlu I/O file, dan library pengiriman jaringan tidak perlu akses mikrofon
      Ini hanya mitigasi, tetapi saya ingin melihatnya juga di bahasa lain
    • Ungkapan “hanya sekitar 800 dependensi” agak bikin merinding
      Sekitar 10 tahun lalu, setelah pindah dari .NET ke Java, saya terkejut karena waktu yang dihabiskan untuk neraka dependensi meningkat tajam; sekarang, baik di proyek Java maupun Python, waktu yang tersedot untuk pembaruan kerentanan dan masalah dependensi sangat menakutkan
      Sepertinya alasan masalah ini lebih ringan di .NET adalah karena adopsi manajemen paket otomatis relatif terlambat dan NuGet juga masih cukup muda, sehingga saat itu banyak proyek belum mengadopsinya dan budaya menghindari pohon dependensi transitif raksasa masih kuat
      Masalah terbaru Boeing juga tampak serupa
      Selama beberapa dekade terakhir, mereka semakin banyak menyerahkan produksi ke pemasok eksternal dan berfokus pada optimasi biaya, sehingga manajemen rantai pasok makin sulit; dalam gambaran besar, ini mirip dengan budaya rantai pasok dalam rekayasa perangkat lunak modern
      Saat saya bekerja di perusahaan finansial yang melarang package manager karena alasan keamanan rantai pasok, manajemen dependensi justru paling tidak merepotkan dan masalah kualitas juga paling sedikit
      Ada kelebihan pada kode yang tidak akan pernah berubah kecuali Anda mengubahnya secara eksplisit
      Banyak bagian yang biasanya orang ambil dari paket juga kami implementasikan sendiri; karena hanya melakukan yang diperlukan dan menerapkan standar kode yang lebih tinggi, kode itu lebih mudah dipahami, di-debug, dan diperbaiki
      Biaya penulisan awal adalah biaya sekali saja dan dapat diamortisasi dengan baik, tetapi biaya berulang untuk menangani kode yang mencoba melakukan segalanya untuk semua orang dalam jangka panjang menjadi lebih besar dan biasanya menumpuk
      “Simple Made Easy” dari Rich Hickey menunjukkan fenomena ini dengan baik: sederhana dan mudah itu berbeda, dan opsi yang sederhana mungkin terlihat lebih sulit di awal, tetapi ketika efek sekundernya menumpuk, dalam jangka panjang justru menjadi lebih mudah

  • Saya sudah menyadari hal seperti ini saat kebetulan melihat repositori yang mirip
    Dari dulu saya memang tidak menjalankan sembarang kode repositori, tetapi sekarang bahkan jika saya memercayai repositori dan pemiliknya, saya tetap menyalakan VM sandbox
    Sepertinya pengembang masa kini harus benar-benar memisahkan lingkungan kerja, hobi, dan pribadi setidaknya menjadi tiga lingkungan

    • Pernyataan bahwa pengembang harus memisahkan lingkungan kerja, hobi, dan pribadi itu sendiri menunjukkan bahwa kompleksitas kehidupan digital sudah membesar sampai membuat kita meragukan apakah ini berkelanjutan dalam jangka panjang
    • Setiap tahun Qubes terasa makin masuk akal sebagai pilihan
    • Saya juga sekarang melakukan ini bukan hanya karena potensi perangkat lunak berbahaya
      Ada proyek yang meski tidak berbahaya, secara desain ceroboh atau ditulis dengan bodoh
      Program yang saya jalankan beberapa waktu lalu menambahkan 3 baris ke ~/.bashrc sebelum saya meminta melakukan apa pun, dan saya baru menyadarinya beberapa hari kemudian
      Saya tidak mengerti pengembang macam apa yang menganggap itu ide bagus, jadi sekarang setiap kali menjalankan kode eksternal saya memakai sandbox
    • Kedengarannya seperti alasan bagus untuk memakai Qubes OS, tempat semuanya secara default berjalan di VM
      Itu OS harian saya
    • Menurut saya tidak mencampur lingkungan kerja dan pribadi itu dasar banget
      Memangnya benar-benar ada pemberi kerja yang mengizinkan hal seperti ini?

  • Saya penasaran alat apa yang dipakai di tempat kerja untuk menghindari masalah seperti ini, dan apakah kalian puas dengan konfigurasi saat ini
    Kami sedang mengembangkan SDK dengan jumlah unduhan mingguan yang besar bersama tim yang cukup kecil, dan sudah mengevaluasi solusi berbasis snyk, aikido.dev, renovate, dan lainnya, tetapi belum jelas apakah itu membantu untuk masalah seperti ini
    Karena tim kami masih kecil, menangani alat dengan banyak false positive seperti snyk juga terasa membebani

    • Alih-alih memakai repositori GitHub secara langsung, kami memakai paket publik dari repositori paket umum seperti NuGet, PyPI, dan npm, lalu menempatkan Repository dan Firewall dari Sonatype sebagai proksi antara kami dan repositori paket
      Sonatype menganalisis semua paket dan menambahkan berbagai metadata, lalu kami mendefinisikan kebijakan yang bisa dipakai di Firewall untuk menyaring sisanya
      Ini hanya berlaku untuk dependensi publik, tetapi setelah dipakai beberapa tahun hasilnya cukup baik
      Sejauh ini belum ada masalah malware, paket dengan kerentanan yang sudah diketahui tidak bisa masuk ke codebase, dan kami menerima notifikasi jika ditemukan kerentanan pada paket yang sedang dipakai
    • Di tempat kerja kami memakai Semgrep Supply Chain dan cukup puas
      Kerentanan supply chain yang ditemukan dibagi menjadi reachable, unreachable, dan undecided, sehingga triase jadi jauh lebih mudah, dan waktu untuk mengevaluasi kerentanan baru berkurang banyak
    • Sepertinya di sub-thread ini malware dan kerentanan banyak tercampur-aduk
      Vendor yang disebutkan bukan mendeteksi kode berbahaya, melainkan hanya kerentanan
      Sekalipun deteksi kerentanannya bagus, Anda tetap tidak terlindungi dari kode berbahaya yang disisipkan ke codebase
    • Kami sedang membuat Packj, alat open source untuk mendeteksi paket PyPI/NPM/Ruby/PHP/Maven/Rust yang berisiko, seperti paket yang secara publik berbahaya, paket yang terbengkalai, dan paket typosquatting
      Alat ini melakukan analisis statis, dinamis, dan metadata, serta memeriksa lebih dari 40 atribut seperti eksekusi shell, penggunaan kunci SSH, komunikasi jaringan, penggunaan decode+eval, dan menandai paket berisiko
      https://github.com/ossillate-inc/packj
    • Trivy layak dilihat
      Sejauh ini bekerja cukup baik
      https://trivy.dev/

  • Saya penasaran apakah praktik mengambil skrip instalasi shell dengan curl lalu menjalankannya dengan sudo akan segera berakhir
    Cara seperti “untuk menginstal perangkat lunak kami, jalankan curl [https://somesite/install.sh](<https://somesite/install.sh>;)' | sudo sh” tampaknya sangat cocok dengan kode terinfeksi yang disebutkan di artikel

    • Sebagai penulis studi ini, saya bisa mengonfirmasi
      Sistem kami mencantumkan sekitar 100 pola seperti yang disebutkan setiap minggu, dan sekitar 3% di antaranya berbahaya
      Saya ingin melihat praktik ini berakhir
    • Sayangnya npm i juga memiliki izin yang sama
      Di antara alat pengunduhan dependensi yang umum saat ini, sejauh yang saya tahu hanya go get yang tidak menjalankan kode berbahaya pada saat instalasi atau build
      Setidaknya, agar ledakannya terkotak-kotak, kita membutuhkan alat yang lebih baik untuk bekerja di sandbox
      Cara ChromeOS “mesin virtual bisa membuka jendela Wayland di desktop utama” itu rapi, tetapi terakhir kali saya melihatnya, kodenya tidak terlalu bersih atau mudah digunakan ulang
    • Untuk contoh seperti ini sebaiknya gunakan example.com
      Domain itu dicadangkan untuk tujuan tersebut: https://www.rfc-editor.org/rfc/rfc2606.html#section-3
    • Itu tidak jauh lebih buruk daripada alternatif realistis seperti “tambahkan repositori untuk distro dan percayai”, “unduh .deb/.rpm/installer”, atau yang terburuk, “percayai paket yang dikemas pihak ketiga, bukan penerbitnya”

  • Di npm, eksekusi malware bisa dimitigasi dengan --ignore-scripts
    https://blog.uirig.com/getting-rid-of-npm-scripts

    • Sebagai gantinya, kode berbahaya yang diunduh bisa berjalan di lingkungan produksi
      Kalau beruntung, mungkin ia berperilaku aneh di CI sehingga bisa tertangkap
      Solusi sebenarnya adalah sistem reputasi seperti https://github.com/crev-dev/cargo-crev, tetapi sayangnya hampir tidak digunakan
    • Dari sudut pandang keamanan, itu seharusnya menjadi default
      Catatan bahwa Makefile diperlukan juga patut diperhatikan

  • Seiring makin seringnya laporan seperti ini muncul, selama beberapa bulan terakhir saya sedikit demi sedikit memperbaiki keamanan lingkungan pengembangan
    Saya memakai dev containers VSCode untuk pengembangan: https://code.visualstudio.com/docs/devcontainers/create-dev-...
    Setelah dibuat sekali, cukup mudah dipakai meski tidak punya banyak pengetahuan Docker, dan bagus untuk menjalankan aplikasi web/konsol, tetapi hal seperti Flutter atau Electron terasa sulit
    Untuk proyek kecil, saya juga sudah terbiasa dengan GitHub Codespaces: https://github.com/codespaces
    Dulu pernah ada live coding saat wawancara untuk memodifikasi proyek Node sederhana; kalau sekarang, dalam situasi seperti itu saya rasa saya pasti akan memakai container atau Codespaces: https://www.welivesecurity.com/en/eset-research/lazarus-luri...
    Untuk praktik terbaik npm, Node, dan Docker, saya rutin membaca panduan OWASP, lalu menerapkannya seperti memakai image Docker sekecil mungkin dan tag image yang eksplisit: https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker...
    Untuk paket npm/python, sebelum instalasi saya memeriksa akses variabel lingkungan, panggilan jaringan, serangan rantai pasok, perubahan kepemilikan kode baru-baru ini, dan sebagainya lewat socket.dev; seperti yang direkomendasikan OWASP, skrip postinstall juga bisa dinonaktifkan secara global: https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_...

  • Ada kasus kurang dari setahun lalu dengan repositori yang berisi virus trojan horse: https://github.com/orgs/community/discussions/63603

    • Repositori itu mengklaim dirinya sebagai pencuri kata sandi, dan jika setelah diunduh serta diekstrak ternyata mencuri informasi pribadi dan file, saya tidak melihat apa masalahnya
      Artinya, ia bekerja persis seperti yang diklaim repositori tersebut

  • Sekadar menandai bahwa sebuah repositori adalah repositori resmi pun sudah bisa menarik perhatian sampai batas tertentu

    • Nantinya GitHub mungkin mulai menjual centang biru itu
      Memangnya apa yang mungkin terjadi /s
      Meski begitu, saya setuju bahwa GitHub perlu menunjukkan dengan lebih baik repositori mana yang merupakan repositori resmi sebuah proyek