00:00:00Ini serius dan bukan lelucon, beberapa jam terakhir terasa berat, karena telah terjadi
00:00:06serangan rantai pasokan besar-besaran pada Axios, ya, Axios yang memiliki lebih dari 80 juta unduhan
00:00:14setiap minggunya.
00:00:15Sekarang, hal pertama yang harus dilakukan.
00:00:18Agar Anda bisa memeriksa apakah Anda terdampak, saya lampirkan tautan ke sebuah artikel, dan
00:00:23saya akan membagikan detail lebih lanjut sebentar lagi, tetapi ini penting, agar Anda bisa memeriksa apakah
00:00:27Anda telah terdampak, Anda harus mengikuti tautan di bawah ini dan menjalankan perintah yang ada di sana
00:00:32untuk sistem operasi Anda, Mac OS, Linux, Windows, semuanya terdampak.
00:00:37Anda harus menjalankan perintah-perintah ini jika Anda terdampak.
00:00:40Dan terutama jika langkah-langkah di sini menunjukkan bahwa sistem Anda telah disusupi, Anda perlu
00:00:49merotasi rahasia Anda, mengganti kata sandi, menganggap kredensial Anda, kunci API di
00:00:55sistem Anda, semua yang ada di sistem Anda, telah dicuri.
00:01:00Anggap kata sandi Anda dicuri, ganti semuanya, nonaktifkan kunci API, ini sangat penting.
00:01:07Nah, apa sebenarnya yang terjadi?
00:01:09Axios, jelas merupakan pustaka JavaScript yang sangat populer, pustaka yang dapat digunakan untuk mengirim permintaan HTTP
00:01:17dari, misalnya, aplikasi React ke API backend.
00:01:22Ini sangat sering digunakan, seperti yang Anda lihat, dan beberapa kode berbahaya telah disuntikkan ke dalam
00:01:28pustaka ini.
00:01:29Sekarang, ini tidak berarti bahwa situs web yang menggunakan pustaka tersebut telah terdampak.
00:01:36Ini justru berarti bahwa sistem tempat Anda menginstal pustaka tersebut, MacBook Anda, PC
00:01:41Anda, atau mungkin VPS tempat Anda membangun situs web, itulah yang telah disusupi.
00:01:50Jika Anda menjalankan npm install, bun install, npm update, bun update, atau semacamnya dalam beberapa
00:01:57jam terakhir, ada bahaya besar bahwa Anda telah terdampak.
00:02:00Sekali lagi, saya membagikan pengecekan yang harus Anda jalankan untuk memeriksa apakah Anda terdampak.
00:02:05Lalu, bagaimana sebenarnya semua ini terjadi dan apa sebenarnya serangan rantai pasokan itu?
00:02:10Saya juga akan membagikan, omong-omong, bagaimana Anda dapat mengamankan diri dari serangan seperti ini di masa depan.
00:02:15Tapi pertama-tama, mari kita pahami apa yang sebenarnya terjadi dan apa itu serangan rantai pasokan.
00:02:20Serangan rantai pasokan hanyalah sebuah serangan yang tidak menargetkan kode aplikasi Anda.
00:02:24Penyerang tidak mencoba menyusup langsung ke sistem atau basis kode Anda.
00:02:31Sebaliknya, mereka memanfaatkan fakta bahwa kode aplikasi Anda biasanya memiliki dependensi, yang sendirinya
00:02:37memiliki dependensi.
00:02:38Jadi Anda memiliki rantai dependensi itu dan serangan tersebut menargetkan rantai dependensi ini.
00:02:45Jadi itu terjadi di hulu dari kode Anda.
00:02:48Jadi salah satu dependensi ini memiliki beberapa kode berbahaya karena serangan di mana kode itu
00:02:54disuntikkan ke dalamnya, bukan karena pemeliharanya mencoba menyerang Anda.
00:02:58Tetapi sebaliknya, misalnya, seperti dalam kasus ini, akun seorang pemelihara disusupi
00:03:03dan penyerang menggunakan itu untuk kemudian menyuntikkan kode berbahaya ke dalam suatu pustaka, ke dalam suatu paket,
00:03:10yang mungkin kemudian digunakan oleh paket lain dan kode Anda mungkin kemudian menggunakan paket tersebut yang
00:03:16menggunakan paket berbahaya, atau mungkin kode aplikasi Anda secara langsung menarik dependensi berbahaya tersebut.
00:03:23Apapun itu, salah satu dependensi Anda sekarang tiba-tiba membawa beberapa kode berbahaya.
00:03:28Dan saat Anda menjalankan npm install atau semacamnya, atau Anda memperbarui, paket tersebut akan
00:03:36terunduh ke sistem Anda, yang berbahaya itu, yang terdampak itu, dan kemudian ia dapat mengeksekusi
00:03:41kode berbahaya di sistem Anda, biasanya dengan bantuan skrip pasca-instalasi.
00:03:47Jadi jika Anda belum tahu, npm memiliki mekanisme skrip ini.
00:03:56Kita semua menggunakannya dalam proyek kita, misalnya, untuk memulai server pengembangan, untuk membangun proyek kita,
00:04:01untuk menjalankan tes, dan hal-hal semacam itu.
00:04:04Dan secara khusus ada juga skrip pasca-instalasi, yang mungkin tidak Anda gunakan saat
00:04:11Anda membangun aplikasi React, misalnya, tetapi sering digunakan oleh pustaka atau mungkin tidak sering,
00:04:17tetapi mungkin digunakan untuk menjalankan beberapa kode di sistem Anda setelah Anda menginstal pustaka tersebut, biasanya bukan
00:04:23untuk melakukan sesuatu yang jahat atau buruk, tetapi misalnya, untuk mengompilasi beberapa kode, membuat biner yang
00:04:31mungkin dibutuhkan oleh pustaka tersebut, menyiapkan sistem Anda dalam bentuk apa pun sehingga ia benar-benar dapat
00:04:36menggunakan pustaka yang baru saja Anda unduh.
00:04:40Itulah ide di balik skrip pasca-instalasi.
00:04:42Ini memungkinkan sebuah paket untuk menentukan beberapa kode yang harus dieksekusi setelah paket tersebut diinstal
00:04:49melalui npm install, misalnya, dan itulah yang biasanya dimanfaatkan dalam
00:04:55serangan rantai pasokan.
00:04:57Penyerang menyuntikkan beberapa kode berbahaya ke dalam paket yang pada dasarnya adalah skrip pasca-instalasi
00:05:04yang dieksekusi secara otomatis setelah paket yang terinfeksi diinstal.
00:05:10Biasanya kode tersebut disamarkan (obfuscated) agar tidak mudah dibaca.
00:05:14Bisa berupa pengkodean base64 sehingga pemindai yang memindai paket untuk kode berbahaya mungkin
00:05:20tidak mendeteksinya dan atau kode berbahaya tersebut mungkin diunduh.
00:05:24Jadi skrip pasca-instalasi, seperti dalam kasus serangan Axios di sini, sebenarnya tidak secara langsung
00:05:30berisi kode berbahaya.
00:05:32Sebaliknya, ia menghubungi server dan mengunduh kode dari sana.
00:05:36Itulah yang terjadi di sini.
00:05:37Dan kami memiliki laporan terperinci tentang apa sebenarnya yang terjadi selama serangan itu.
00:05:41Anda dapat menemukannya terlampir jika ingin membaca semua detailnya, tetapi di sana kami pada dasarnya
00:05:45mengetahui bahwa dua versi paket Axios, 1.14.1 dan 0.30.4 terdampak, telah disusupi
00:05:57pada akhirnya dan itu dilakukan oleh penyerang yang mendapatkan akses ke akun salah satu
00:06:02pemelihara paket Axios dan mereka menggunakan akun tersebut untuk menerbitkan versi baru dari paket Axios
00:06:08yang berisi dependensi yang pada gilirannya berisi skrip pasca-instalasi tersebut.
00:06:14Jadi bahkan bukan paket Axios itu sendiri yang berisi skrip pasca-instalasi tersebut, melainkan
00:06:19paket lain, paket plaincryptojs, yang dibuat oleh penyerang,
00:06:25yang tujuan utamanya adalah memiliki skrip pasca-instalasi yang mengunduh dan menjalankan beberapa kode
00:06:31berbahaya.
00:06:32Jadi paket Axios disusupi dengan menambahkan plaincryptojs sebagai dependensi ke Axios.
00:06:39Itu adalah paket yang jahat.
00:06:40Paket ini tidak memiliki tujuan lain selain mengunduh kode berbahaya itu dan hanya dengan menambahkan
00:06:46dependensi ini ke Axios, serangan tersebut pada dasarnya selesai.
00:06:52Paket ini tidak diimpor ke dalam kode sumber Axios di mana pun.
00:06:56Ia hanya memiliki skrip pasca-instalasi ini dan itu saja.
00:06:59Seperti yang disebutkan, ia kemudian dapat mengunduh dan menjalankan kode di MacOS, Windows, dan Linux untuk
00:07:05kemudian melakukan apa?
00:07:06Yah, mencuri banyak hal.
00:07:08Jadi jika sistem Anda terdampak, seperti yang saya sebutkan di awal, kredensial, kunci API, token kripto,
00:07:14semua hal menyenangkan itu dikumpulkan dan dikirim keluar (exfiltrated) oleh trojan yang diunduh oleh skrip
00:07:21pasca-instalasi tersebut.
00:07:22Begitulah cara serangan itu bekerja.
00:07:24Begitulah cara serangan serupa bekerja di masa lalu.
00:07:29Sekarang yang menarik, yah, oh, omong-omong, serangan ini dimulai sekitar tengah malam,
00:07:36tepat setelah tengah malam UTC hari ini, beberapa jam yang lalu.
00:07:40Ini berlangsung selama beberapa jam dan kedua versi Axios 1.14.1 dan 0.30.4 terdampak dalam waktu
00:07:5040 menit, tepatnya 39 menit.
00:07:53Jadi ini adalah serangan yang sangat terorganisir dan terencana.
00:07:56Jelas pembuatan paket tambahan ini terjadi, saya rasa 18 jam sebelum serangan
00:08:03dimulai.
00:08:04Itu sangat terorganisir dan terencana.
00:08:06Nah, yang agak aneh di sini adalah NPM memiliki mekanisme yang disebut Trusted Publishing, yang
00:08:14dapat digunakan oleh pemelihara paket.
00:08:17Dan idenya di sini adalah untuk membatasi proses penerbitan versi baru dari suatu paket ke proses
00:08:26yang ditentukan dengan jelas di mana secara khusus Anda harus membangun dan menerbitkan versi baru melalui
00:08:32salah satu penyedia CI/CD yang didukung dengan pengaturan tertentu yang harus Anda lalui.
00:08:38Dan idenya di sini adalah bahwa meskipun kredensial akun NPM Anda dicuri, secara teori,
00:08:46penyerang tidak dapat menerbitkan versi baru dari paket Anda dari mesin mereka karena mereka
00:08:51perlu melalui proses tersebut.
00:08:52Sekarang Anda bisa berargumen bahwa jika akun GitHub seorang pemelihara disusupi, maka mungkin
00:08:59versi berbahaya dapat dikirim ke GitHub, memicu alur kerja penerapan di sini dan oleh karena itu
00:09:06kode berbahaya tersebut diterbitkan melalui proses Trusted Publishing tersebut.
00:09:11Namun menurut laporan keamanan di sini, bukan itu yang terjadi di sini.
00:09:16Karena tim Axios menggunakan proses Trusted Publishing ini untuk cabang 1.x, bukan
00:09:21untuk cabang 0.30, tetapi untuk cabang 1.x.
00:09:26Tetapi menurut laporan ini, tidak ada komit atau serangan di repositori GitHub Axios.
00:09:33Jadi tidak ada pengiriman (push) ke GitHub dengan versi Axios yang telah disusupi tersebut.
00:09:40Jadi proses Trusted Publishing seharusnya tidak terpicu.
00:09:44Sebaliknya, laporan ini menyatakan bahwa penyerang pasti telah memperoleh token akses NPM klasik
00:09:50berumur panjang untuk menerbitkan versi Axios yang berbahaya atau yang telah disusupi ini karena
00:09:56rilis tersebut hanya ada di NPM, tidak di GitHub.
00:10:01Mungkin ini salah.
00:10:02Mungkin serangannya melalui GitHub.
00:10:05Namun jika ini benar, saya tidak jelas bagaimana tepatnya itu bekerja karena secara teori,
00:10:11cara penerbitan ini seharusnya tidak dimungkinkan saat Trusted Publishing diaktifkan.
00:10:15Tidak yakin apakah ini semacam kerentanan keamanan atau masalah dengan NPM di sini.
00:10:20Bahwa beberapa token berumur panjang yang ada masih bisa digunakan bahkan dengan Trusted Publishing
00:10:26dinyalakan.
00:10:27Itu adalah sesuatu yang tidak bisa saya temukan bagaimana tepatnya hal itu bisa terjadi.
00:10:32Dan ada utas di sini, masalah GitHub pada pustaka Axios tempat serangan ini
00:10:39dilaporkan.
00:10:40Omong-omong, catatan tambahan, lebih banyak masalah seperti itu telah dibuat dan dihapus oleh pemelihara
00:10:45yang disusupi, oleh akun pemelihara yang disusupi.
00:10:48Utas ini, masalah ini selamat dan serangan tersebut akhirnya dihentikan.
00:10:52Mereka mendapatkan kembali akses ke akun mereka, pemelihara yang terdampak itu.
00:10:56Dan dalam utas itu, dalam masalah itu, pemelihara memposting dan mengatakan bahwa mereka menggunakan Trusted
00:11:03Publishing dan tidak jelas bagaimana tepatnya hal itu bisa terjadi.
00:11:07Ada sebuah teori yang dibagikan.
00:11:09Tetapi pemahaman saya adalah bahwa teori ini tetap akan membutuhkan versi baru yang berbahaya atau disusupi
00:11:16dikirim ke GitHub, tetapi sekali lagi, itu semua tidak jelas.
00:11:20Yang jelas adalah versi yang disusupi telah diterbitkan dan berakhir di NPM dan
00:11:25oleh karena itu dapat diunduh di sistem dan mencuri data di sana.
00:11:29Dan tentu saja dengan lebih dari 80 juta unduhan mingguan, ada banyak kerusakan yang bisa dilakukan dalam
00:11:35beberapa jam.
00:11:37Jelas unduhan tidak didistribusikan secara merata di semua jam dalam sehari, tetapi ini
00:11:44pasti jumlah yang sangat besar dan kita dapat berasumsi bahwa ribuan, puluhan ribu sistem
00:11:51telah terdampak dalam beberapa jam tersebut.
00:11:55Sekarang tentu saja ini bukan serangan rantai pasokan yang pertama.
00:11:59Selama beberapa bulan terakhir kita telah melihat banyak serangan.
00:12:01Satu serangan besar pada akhir tahun lalu, serangan shy hulu di mana beberapa paket
00:12:08dieksekusi di NPM dan itu memiliki pola yang sama, kode berbahaya disuntikkan dan dieksekusi
00:12:16pada sistem yang mengunduh paket-paket yang telah disusupi tersebut dan kemudian kredensial dan hal-hal lain
00:12:21dicuri.
00:12:22Jadi itu adalah satu serangan besar.
00:12:25Dan kemudian hanya beberapa hari yang lalu kita mengalami insiden serupa di ekosistem Python.
00:12:31Jadi tidak terbatas pada JavaScript saja, di mana paket lightllm terdampak.
00:12:37Paket yang sangat populer yang pada akhirnya memudahkan penggunaan penyedia AI melalui satu antarmuka
00:12:43yang nyaman, itu juga mengalami serangan serupa dan terdampak.
00:12:49Dan oleh karena itu tentu saja bukan hanya JavaScript.
00:12:52Dan saya rasa ada beberapa alasan mengapa kita melihat lebih banyak serangan seperti itu terjadi.
00:12:57Karena secara teori, jenis serangan seperti ini bisa saja terjadi dan mungkin memang terjadi di
00:13:03masa lalu juga tetapi jelas sekarang menjadi lebih sering dan saya rasa ada beberapa
00:13:08alasan untuk itu.
00:13:11Sekarang tentu saja salah satu alasan besarnya adalah kita berada di titik waktu di mana lebih banyak kode dari sebelumnya
00:13:17sedang ditulis, dihasilkan.
00:13:19Maksud saya, Anda dapat melihat berbagai metrik.
00:13:22Misalnya saya melihat grafik ini baru-baru ini bahwa jumlah repositori GitHub baru yang
00:13:27sedang dibuat berada pada titik tertinggi sepanjang masa dan tentu saja itu karena AI.
00:13:31Di mana orang-orang mengerjakan proyek, sedang menghasilkan kode.
00:13:35Kita memiliki output kode yang lebih banyak daripada sebelumnya dan tentu saja itu berarti dengan begitu banyak
00:13:42program yang ditulis, begitu banyak kode yang dihasilkan, permukaan serangan menjadi jauh lebih besar.
00:13:47Ada lebih banyak target.
00:13:48Ada lebih banyak orang yang membangun atau menulis kode dan menginstal paket.
00:13:52Jadi ini menjadi lebih menarik dari sebelumnya.
00:13:54Bukannya tidak menarik di masa lalu, tetapi sekarang ada lebih banyak orang dari sebelumnya yang
00:13:59bisa diserang.
00:14:00Jadi itu tentu saja salah satu alasan besarnya.
00:14:03Menjalankan serangan-serangan ini menjadi lebih menarik, tetapi itu bukan satu-satunya.
00:14:07Saya rasa alasan lain tentu saja juga terkait dengan AI bahwa pertama, menjalankan serangan seperti
00:14:15ini dengan bantuan AI mungkin menjadi lebih mudah bagi penyerang karena kode berbahaya tentu saja
00:14:21juga dapat dihasilkan dan ditulis dengan bantuan AI sehingga keterampilan teknis yang dibutuhkan untuk menjalankan
00:14:28serangan semacam itu lebih tersedia daripada di masa lalu menurut saya, meskipun Anda juga bisa membeli skrip
00:14:33atau trojan seperti ini di darknet tetapi tetap saja ini mungkin lebih mudah diakses oleh orang-orang.
00:14:40Tentu saja bukan hanya sisi baik dari AI di mana lebih banyak orang dapat membangun perangkat lunak dan mengubah
00:14:46ide mereka menjadi bisnis atau apa pun, tetapi juga hal-hal buruknya.
00:14:50Lebih banyak orang dapat melakukan hal-hal buruk terkait kode berkat AI, jadi itu adalah salah satu alasannya.
00:14:55Anda juga bisa berargumen bahwa tentu saja para pemelihara paket, pemelihara pustaka dibanjiri
00:15:01dengan permintaan tarik (pull requests).
00:15:02Itu adalah masalah besar lainnya yang kita hadapi akhir-akhir ini bahwa jika Anda adalah seorang pemelihara sumber terbuka, ada
00:15:07lebih banyak permintaan tarik yang masuk daripada sebelumnya sehingga Anda mungkin tidak terlalu berhati-hati dengan apa
00:15:13yang Anda gabungkan.
00:15:14Bukan masalahnya di sini, sekadar memperjelas saja.
00:15:16Dalam serangan Axios di sini jelas itu adalah akun yang disusupi tetapi secara teori Anda bisa
00:15:22berargumen bahwa ada kemungkinan para pemelihara menggabungkan kode berbahaya atau kode
00:15:29yang menginstal dependensi berbahaya ke dalam pustaka mereka karena mereka terlewat atau mungkin
00:15:34karena mereka memiliki proses tinjauan kode yang sepenuhnya otomatis yang tidak mendeteksinya.
00:15:38Mereka hanya mengandalkan AI.
00:15:40Sekali lagi bukan itu yang terjadi di sini tetapi Anda bisa berpikir bahwa ini bisa saja digunakan di masa depan oleh para penyerang
00:15:45bahwa mereka menyuntikkan kode berbahaya ke dalam basis kode karena orang-orang tidak memeriksanya.
00:15:51Selain itu saat Anda menggunakan Cloth code, OpenCloth atau apa pun di sistem Anda untuk melakukan semua
00:15:56jenis pekerjaan untuk Anda tidak hanya membantu Anda mengerjakan perangkat lunak tetapi mungkin hanya mengelola sistem Anda
00:16:01secara keseluruhan tentu saja untuk tugas-tugas tertentu OpenCloth, Cloth code, codecs atau apa pun mereka mungkin memutuskan
00:16:09untuk menulis beberapa skrip dan menjalankan beberapa kode untuk melakukan tugas tertentu yang Anda minta dan
00:16:15kode yang mereka hasilkan mungkin juga bergantung pada dependensi seperti Axios.
00:16:20Jadi sekali lagi permukaan serangan semakin besar, itu argumen pertama saya lagi tetapi di luar
00:16:24sekadar pengembangan perangkat lunak klasik dan untuk semua alasan ini dan mungkin banyak alasan lainnya
00:16:30yang tidak terpikirkan oleh saya di sini serangan-serangan ini menjadi lebih menguntungkan, lebih mudah dilakukan dan lebih
00:16:37menarik untuk dilakukan dan itulah sebabnya saya yakin kita akan melihat lebih banyak serangan ini di masa depan.
00:16:43Sekarang apa yang bisa Anda lakukan untuk mencegah serangan semacam itu untuk melindungi diri Anda sendiri?
00:16:47Satu langkah peningkatan keamanan yang besar, satu hal yang dapat Anda lakukan adalah di semua proyek Anda di mana Anda
00:16:55mengerjakan aplikasi dan sebagainya, saat Anda menggunakan alat seperti pnpm daripada npm untuk mengelola
00:17:02dependensi Anda, Anda dapat menambahkan pengaturan usia rilis minimum (minimum release age) ke file pnpm-workspace.yaml Anda.
00:17:09Bun memiliki fitur serupa, Anda dapat menambahkan file bunfig.toml jika Anda menggunakan bun sebagai manajer paket
00:17:15dan mereka juga memiliki pengaturan usia rilis minimum yang dapat Anda tambahkan di file tersebut. Apa fungsinya?
00:17:21Ini hanya memastikan bahwa kapan pun Anda menginstal paket, bagaimanapun caranya, manajer paket hanya menginstal paket
00:17:27yang setidaknya sudah setua itu atau versi paket yang setidaknya sudah setua itu. Jadi jika sebuah paket
00:17:34disusupi lima jam yang lalu tetapi Anda memiliki aturan yang hanya menginstal versi yang
00:17:39setidaknya berusia tiga hari, Anda seharusnya aman. Itulah idenya dan sayangnya npm sendiri
00:17:46tidak memilikinya sekarang. Sekadar memastikan atau agar ini jelas, kita masih berbicara tentang paket
00:17:51yang dihosting di npm, itu bukan masalahnya, saya berbicara tentang manajer paketnya di sini.
00:17:56Dan Anda tentu saja dapat menggunakan bun atau pnpm untuk mengunduh paket-paket tersebut dari npm dan jika Anda menggunakannya
00:18:03daripada hanya menggunakan alat npm itu sendiri, maka Anda dapat memanfaatkan pengaturan seperti ini
00:18:08yang memberi Anda lapisan keamanan ekstra tersebut karena biasanya di masa lalu serangan-serangan
00:18:14tersebut telah tertangkap dalam beberapa jam. Jadi jika Anda memiliki ambang batas tiga hari misalnya,
00:18:20sebagian besar serangan ini akan sudah tertangkap pada saat itu dan akan berakhir. Ini tidak 100%
00:18:25aman tentu saja, serangan bisa berlangsung lebih lama tetapi ini memberi Anda keuntungan yang jelas dan
00:18:32pasti merupakan hal yang baik untuk dilakukan. Sekarang agar lebih aman, Anda dapat dan harus mempertimbangkan untuk menggunakan
00:18:39solusi seperti Doppler dan ini tidak bersponsor, ini hanya salah satu contoh, ada alternatif lain,
00:18:44saya membangun alternatif saya sendiri yang saya gunakan sendiri yang merupakan layanan atau alat yang
00:18:49mengelola rahasia Anda. Jadi sesuatu seperti kunci API OpenAI Anda, Anda bisa meletakkannya di file
00:18:55.env, tetapi lebih baik menyimpannya secara terenkripsi di dalam atau dengan bantuan layanan seperti Doppler di
00:19:02server mereka atau di atau di-host sendiri di VPS yang Anda miliki dan kemudian Anda menyuntikkannya ke dalam lingkungan
00:19:08untuk aplikasi Anda agar mengetahuinya dan menggunakannya saat dibutuhkan sehingga jika Anda memiliki
00:19:13trojan di sistem Anda yang mungkin mengambil semua file .env Anda dan mengekstrak informasinya,
00:19:20ia tidak menemukan rahasia apa pun di sana. Begitulah idenya. Jadi menyimpan rahasia-rahasia itu
00:19:25bukan dalam file teks di sistem Anda dan file .env hanyalah file teks pada akhirnya tetapi sebaliknya
00:19:32terenkripsi di tempat lain pasti juga sesuatu yang mungkin ingin Anda pertimbangkan untuk dilakukan
00:19:36dan sekali lagi ada solusi yang berbeda di sini tetapi itu adalah sesuatu yang mungkin ingin Anda pertimbangkan
00:19:40dan agar lebih aman lagi tentu saja Anda bisa melakukan outsource lingkungan pengembangan Anda dan
00:19:45tidak memilikinya di MacBook, mesin Anda, PC Anda, melainkan memilikinya di VPS, di Mac Mini
00:19:50yang Anda hubungkan melalui SSH atau semacamnya atau mungkin di dalam kontainer Docker sehingga
00:19:56jika ada kode berbahaya yang dieksekusi di sana, ia hanya berdampak pada kontainer Docker itu,
00:20:02VPS tersebut, dan tidak ke seluruh sistem Anda sehingga ia tidak dapat mengumpulkan semua kata sandi sistem Anda dan hal-hal
00:20:07semacam itu. Sebaliknya ia terisolasi, Anda memiliki radius ledakan yang lebih kecil karena serangan-serangan
00:20:13ini akan terus terjadi jelas, saya cukup yakin kita akan memiliki mekanisme yang lebih baik dan lebih baik
00:20:21untuk mengamankan penerbitan paket dan sebagainya, tetapi tidak akan pernah ada jaminan 100% bahwa
00:20:27serangan semacam itu tidak dapat terjadi dan oleh karena itu Anda sebagai pengguna paket-paket tersebut harus mengamankan
00:20:33sistem Anda dan memiliki beberapa lapisan pertahanan di sana sehingga Anda mengurangi kemungkinan Anda
00:20:39mengunduh versi paket yang telah disusupi dan jika Anda melakukannya, radius ledakannya menjadi lebih kecil.
00:20:45Itulah yang dapat Anda lakukan. Saya akan membagikan lebih banyak tentang hal itu di video mendatang juga di saluran saya yang lain,
00:20:50saluran akademi. Tetapi ya, tetap aman di luar sana, periksa apakah Anda telah terdampak oleh serangan
00:20:55ini dan ya, beberapa jam terakhir terasa berat seperti yang saya sebutkan.