Ini merupakan episod ketiga dalam siri artikel tentang jenis serangan rantaian bekalan perisian yang paling lazim: serangan yang menyalahgunakan pendaftaran awam sumber terbuka komponen perisian. Selepas menganalisis dalam episod sebelumnya “Anatomi Pakej Berniat Jahat: Apakah Trendnya?"Bagaimana pelaku jahat menyuntik tingkah laku berniat jahat ke dalam komponen baharu atau sedia ada yang diterbitkan, kami bersedia untuk memakai jaket pemadam kebakaran kami dan mengkaji bagaimana kami boleh berjaya menyekat perisian berniat jahat yang disampaikan dengan cara ini, atau secara alternatif, menangani insiden siber yang berpotensi serius kerana kami mengambil pendekatan yang salah."
Kebanyakan profesional yang peka terhadap keselamatan mempunyai idea tentang cara menangani ancaman ini. Kami pernah mendengar pengurus keselamatan berkata tanpa teragak-agak bahawa SCA Alat sudah pun memberitahu anda bila versi pakej itu merupakan perisian hasad. Atau ia bergantung pada komponen perisian yang terkenal dan telah dikaji semula dengan teliti, di mana sebarang perisian hasad akan dikesan dan dialih keluar dengan segera. Ia menggunakan versi minor/tampalan terbuka untuk mendapatkan pembetulan kerentanan secara automatik, dan itulah cara yang betul dan disyorkan untuk mengurangkan risiko ke atas kebergantungan sumber terbuka, mengikut "tampal awal, tampal kerapPrinsip.
Dalam episod ini, kita akan mengulas mengapa idea-idea ini salah, dan bagaimana salah tanggapan sedemikian menyumbang kepada populariti mekanisme serangan ini, dan kepada risiko besar yang dialami oleh organisasi. Kita akan mengakhiri dengan apa yang berkesan, dan usaha serta sumber yang terlibat.
Kesalahan Umum
Semasa perjalanan kami dengan keselamatan perisian, kami melihat teknik serangan berkembang dan pelbagai idea daripada mereka yang mementingkan keselamatan. Organisasi sering salah faham tentang apa yang berkesan terhadap ancaman ini, jadi pertama sekali kami akan mengkaji apa yang tidak berkesan, diringkaskan dalam senarai salah tanggapan berikut, yang tidak menyeluruh.
Salah Tanggapan #1: SCA alat sudah melaporkan komponen berniat jahat
Betul! Tetapi selepas hakikatnya… Apabila mungkin sudah terlambat jika elemen tersebut digunakan dalam binaan perisian, dan pelaku jahat telah pun mendapat tempat dalam pembangun atau CI/CD hos. Rahsia mungkin telah diekstrak, perisian hasad tambahan dimuat turun dan dipasang, dan mungkin musuh bergerak ke sisi dan telah mendapat akses ke tempat lain.
Analisis Komposisi Perisian (SCA) alat direka bentuk untuk mengenal pasti potensi kelemahan yang diketahui. Alat moden melakukan tugas yang hebat dengan menambah nisbah isyarat-bunyi, menentukan sama ada kelemahan itu sebenarnya boleh dicapai atau dieksploitasi. Tetapi ia tidak berguna terhadap perisian hasad baharu. Anggap komponen berniat jahat sebagai kelemahan hari sifar: Hanya apabila kelakuan berniat jahatnya dikesan, komponen tersebut dilaporkan kepada daftar induk, yang selepas semakan oleh pasukan keselamatan disahkan sebagai berniat jahat dan dialih keluar daripada daftar [1].
Pada ketika itu, dunia (termasuk SCAs) tahu bahawa memasang atau menggunakan komponen (atau beberapa versi komponen sedia ada) bukanlah perkara yang baik. Tetapi ini berlaku apabila komponen tidak tersedia daripada pendaftaranMengetahui bahawa saya mempunyai kelemahan dalam komponen pihak ketiga, atau komponen yang dikategorikan sebagai berniat jahat oleh pendaftaran adalah baik, tetapi malangnya SCA atau alat audit biasa tidak membantu dalam konteks ini. Kecuali SCAAlat /audit benar-benar boleh mengetahui terlebih dahulu bahawa komponen itu berniat jahat sebelum ia digunakan di organisasi anda.
Ingat, sebarang penyelesaian terhadap komponen sumber terbuka yang berniat jahat mesti mengesannya dalam perjalanan, antara masa komponen diterbitkan dalam daftar dan masa komponen (versi) pertama kali digunakan di organisasi anda. Dan itu termasuk komponen transitif.
Salah Tanggapan #2: Mengawal skrip pemasangan pada masa binaan menghalang tingkah laku berniat jahat daripada komponen sumber terbuka
Pelbagai pengurus pakej menawarkan keupayaan untuk menjalankan skrip (termasuk dalam komponen tarball [2]), atas sebab-sebab yang sah, seperti menyusun item yang diperlukan pada platform yang berbeza, menjana kod atau menjalankan ujian, dan kita semua harus tahu bahawa ia boleh disalahgunakan oleh pelaku jahat jika skrip berniat jahat disertakan dalam tarball, atau jika penyerang boleh menjalankan skrip berniat jahat dan bukannya skrip yang baik.
Mengetahui perkara ini, kita boleh mengkonfigurasi pengurus pakej untuk mengabaikan skrip. Contohnya, dengan NPM, - Abaikan skrip bendera (atau sifat konfigurasi dalam .npmrc fail) melangkau skrip semasa pemasangan. Ini mungkin menghasilkan beberapa masalah kerana menjalankan skrip adalah perkara biasa dalam banyak ekosistem: Sesetengah pengurus pakej tidak membenarkan pelaksanaan skrip yang dilumpuhkan (petunjuk: gesaan "Pengurus pakej manakah yang tidak membenarkan pelumpuhan pelaksanaan skrip pemasangan?"dalam AI kegemaran anda). Tetapi ini tidak melindungi secara umum (kita perlu menguatkuasakan bahawa konfigurasi langkau nyahdayakan ada di mana-mana).
Dan apabila tingkah laku berniat jahat tidak terletak pada skrip pemasangan tetapi dalam perisian untuk dilaksanakan semasa masa jalan, pilihan ini sahaja tidak melindungi kita.
Salah Tanggapan #3: Penyematan versi menghalang komponen berniat jahat daripada dipasang
Terdapat pertukaran antara menampal awal dan selalunya dengan versi terbuka (membenarkan pengurus pakej memasang kemas kini baharu secara automatik apabila tersedia untuk pembetulan keselamatan) dan penyematan versi (mempunyai semua kebergantungan langsung dan transitif untuk perisian pada versi tetap). Prinsip keselamatan adalah degil dan kadangkala bercanggah, seperti yang berlaku dengan "tampalan awal, tampalan kerap" dan "Penaiktarafan tidak boleh dipandang ringan"Sesetengah pengurus pakej membuat kemas kini automatik dengan julat pelayan dengan cara yang disyorkan. Bagus jika anda juga ingin menerima kemas kini berniat jahat! Ya, komponen mesti dikemas kini untuk menerima pembetulan keselamatan yang menutup kerentanan secepat mungkin, tetapi ... jangan sekali-kali biarkan pengurus pakej melakukan ini secara automatik.
Salah Tanggapan #4: Menggunakan komponen yang dipercayai adalah selamat. Sebarang versi berniat jahat akan segera ditemui, didedahkan dan dialih keluar.
Mengapakah sesuatu komponen dipercayai? Mungkin kerana ia sangat popular, dengan ramai pihak yang mencari kelemahan, sebilangan besar penyumbang untuk penyelenggaraan, dengan pelbagai penyelenggara teras yang menyemak semua dengan tekun. pull requestsRealitinya agak berbeza. Beberapa komponen penting diselenggara oleh pembangun tunggal yang tidak berbayar. Rangka kerja yang digunakan secara meluas telah beberapa penyumbang tetap, dengan bilangan yang semakin berkurangan dengan cepat commits setiap penyelenggara (projek popular mempunyai penyumbang yang panjang yang melakukan beberapa pandu lalu commit dan tidak akan kembali). Dan projek popular dengan seorang penyelenggara tunggal banyak terdapat.
Bayangkan diri anda berkata "Oh, kami menggunakan imej Docker asas Spring Boot / Angular / React / PyTorch / rasmi, jadi risiko yang anda bicarakan agak rendah." Mungkin itu benar, kami, vendor keselamatan, sentiasa membuat perkara yang menakutkan, dan mengganggu pasukan pembangunan untuk mengurangkan risiko yang boleh dipertikaikan adalah karut. Anda mungkin tergoda untuk beralih ke perenggan penerimaan risiko (di bahagian seterusnya) dan selesai semuanya. Malangnya, komponen yang paling popular adalah sasaran pelaku jahat, dan sebagai contoh, yang popular Perpustakaan PyTorch telah diserang pada masa lalu.
"Ditemui, didedahkan, dan dialih keluar dengan segera". Komponen berniat jahat yang baharu mengambil masa berhari-hari untuk dialih keluar daripada daftar awam. Pihak pendaftaran berhati-hati dalam mengalih keluar versi komponen, untuk kebaikan. Pengalaman kami ialah sebaik sahaja dilaporkan daripada pihak kami, masa median untuk pihak pendaftaran mengalih keluar versi yang terjejas ialah 39 jam, lebih daripada satu setengah hari. Terdapat komponen berniat jahat yang seminggu selepas pelaporan awal kami dalam daftar sebelum pengalihan keluar. Dan dalam beberapa kes, komponen tersebut dialih keluar hanya selepas mangsa atau syarikat tindak balas insiden melaporkan insiden yang melibatkan komponen tersebut.
Apa yang TIDAK Berfungsi Terhadap Komponen Berniat Jahat
Sebarang pendekatan yang tidak spesifik akan gagal teruk. Ini sudah pasti, anda tidak menyediakan langkah balas yang berkesan untuk risiko yang berkaitan dengan ancaman ini.
Tradisional SCA Alat ini memberitahu anda tentang perisian hasad yang diketahui tetapi mempunyai tetingkap pendedahan yang besar. Melainkan mereka secara proaktif melakukan pengesanan perisian hasad dengan penyekatan paksa komponen berniat jahat, ia tidak berfungsi terhadap ancaman ini.
Melumpuhkan skrip pemasangan boleh membantu tetapi perlu dikuatkuasakan di mana-mana komponen perlu dipasang. Sama juga dengan penyematan versi, kerana versi tidak boleh disematkan dari keadaan awal yang selamat selama-lamanya.
Menganggap bahawa komponen popular mendapat perhatian yang cukup sehingga tidak boleh disuntik dengan tingkah laku yang tidak diingini dalam serangan rantaian bekalan tanpa pengesanan hampir serta-merta untuk mengelakkan sebarang kerosakan adalah naif dan berisiko. Anda tidak mahu hidup di ambang kehancuran, bukan?
Jika anda berhenti di tahap ini, maka penerimaan risiko adalah satu-satunya perkara yang anda boleh lakukan: Ini adalah satucision yang perlu didokumenkan dalam model ancaman/penilaian risiko anda, termasuk rasional untuk menerima risiko dan potensi implikasinya. Tingkatkan kesedaran dengan menyampaikannya kepada pihak pengurusan dan pihak berkaitan yang lain. Sesetengahnya kontingensi boleh dirancang apabila komponen berniat jahat dipasang atau disertakan dalam perisian anda, tetapi ini sukar kerana penyerang mempunyai banyak laluan untuk diikuti. Butiran serangan rantaian bekalan berdasarkan penggunaan komponen berniat jahat akan mengubah pendedahan awam insiden secara drastik, yang mungkin wajib di bawah rangka kerja kawal selia organisasi anda. Anda juga boleh menangani kawalan pampasan or risiko pemindahan contohnya dengan insurans.
Walau bagaimanapun, terdapat kawalan yang menangani ancaman tersebut dan harus dipertimbangkan jika anda tidak berpuas hati dengan penerimaan risiko. Sila teruskan membaca.
Apakah Fungsinya Menentang Serangan Menggunakan Komponen Berniat Jahat
Pengendalian Versi Pepejal
Penyematan versi dengan bonggol versi terkawal dan termaklum adalah cara yang perlu diambil, untuk mengimbangi keperluan untuk mengalih keluar kelemahan tanpa menerima perisian hasad. Tetapi ingat salah tanggapan #3: Penyematan versi sahaja tidak mencukupi untuk menyekat kod berniat jahat yang datang daripada versi baharu, kerana anda perlu mengemas kini versi pada masa hadapan dalam sebarang kebergantungan langsung atau tidak langsung. Pada masa itu, anda memerlukan bukti yang cukup kukuh bahawa semua versi yang diubah suai tidak mengandungi perisian hasad.
Amaran awal
Satu pendekatan kepada masalah komponen berniat jahat ialah sistem amaran awal (dinamakan di sini sebagai Amaran Awal Perisian Hasad atau MEW), di mana versi baharu yang diterbitkan (untuk komponen baharu atau sedia ada) dianalisis oleh enjin pengesanan, yang apabila bukti yang mencukupi ditemui mungkin mengklasifikasikan versi baharu sebagai berpotensi berniat jahat.
Automasi adalah penting di sini, kerana mustahil untuk menyemak semua komponen baharu secara manual pada kadar penerbitan semasa. Jadi enjin pengesanan perlu menggabungkan pelbagai teknik, mungkin termasuk analisis statik, dinamik dan keupayaan, reputasi pengguna dan bukti yang datang daripada percanggahan antara metadata komponen dan kandungan tarball, atau antara tarball dan repositori sumber tempat komponen tersebut sepatutnya berasal.
Terdapat zon gelap antara masa penerbitan dan apabila enjin menganalisis kandungan komponen, tetapi ia tidak boleh melebihi beberapa minit. Skema ini boleh diubah suai, contohnya dengan menunggu komponen baharu dianalisis sebelum membenarkannya dipasang dan digunakan dalam binaan perisian. pipelines, atau menganalisisnya apabila diperlukan. Komponen pada versi tertentu tidak boleh diubah [3], jadi ia perlu dianalisis sekali sahaja.
Automasi penuh tidak mungkin dilakukan, dan semakan keselamatan untuk komponen yang berpotensi berniat jahat diperlukan. Berhati-hati dengan penyokong penawar digitalAI dan Pembelajaran Mesin tidak cukup dibangunkan untuk mengambil kata terakhir apabila melibatkan pengesahan sama ada komponen yang disyaki mempunyai perisian hasad. Sudah tentu, pembelajaran mesin memainkan peranan penting dalam enjin pengesanan dalam mengklasifikasikan komponen input daripada bukti mentah yang ditangkap, tetapi sebaik sahaja komponen tersebut "dikuarantin", kata terakhir akan dibuat pada semakan manual oleh pasukan keselamatan yang berpengalaman dalam komponen berniat jahat. Ini mengesahkan sebarang potensi perisian hasad atau mengklasifikasikannya semula sebagai selamat. Dan tempoh masa adalah dalam julat jam.
Pendaftaran melaporkan versi/komponen berniat jahat; pendaftaran kemudiannya menjalankan semakannya untuk mengesahkan dan meneruskan pendedahan awam dan penyingkiran daripada pendaftaran. Sesetengah pendaftaran menyimpan pakej pegangan keselamatan. Julat masa di sini ialah hari atau minggu sejak penerbitan, iaitu 'masa tinggal'atau'tingkap pendedahan' untuk kebanyakan komponen berniat jahat.
Adakah mungkin untuk mengetahui sama ada versi komponen berniat jahat?
Jadi untuk amaran awal, kita perlu memberikan jawapan yang memuaskan kepada soalan ini: Bagaimanakah saya boleh tahu bahawa sesebuah perpustakaan atau pakej itu (tidak) berniat jahat? Bagaimanakah cara untuk mengumpulkan bukti yang mencukupi tentang tingkah laku berniat jahat? Mungkin, tetapi sukar, kerana pihak musuh menggunakan banyak kepintaran untuk mengelakkan pengesanan. Terdapat pendekatan yang berbeza, setiap satunya mempunyai kebaikan dan keburukan.
Analisis statik boleh memeriksa semua laluan pelaksanaan, menyemak teknik yang digunakan oleh penyerang tanpa menjalankan komponen, dan melaksanakan tugas prapemprosesan seperti penyahkeliruan atau penyahkodan. Apabila penyerang cuba menyembunyikan kenakalan mereka, percubaan pengeliruan sememangnya bukti perisian hasad (tetapi ambil perhatian bahawa komponen yang sah mengelirukan kod untuk memelihara harta intelek, bercanggah dengan "sumber terbuka"). Hanya sebilangan kecil serangan yang sangat canggih dengan obfuscation yang kuat memerlukan sandboxing, tetapi obfuscation yang kuat sedemikian adalah tanda jelas niat jahat. Sila ambil perhatian bahawa konvensional SAST alat direka bentuk untuk kelemahan yang tidak disengajakan, bukan untuk niat jahat seperti pintu belakang.
Analisis dinamik menjalankan komponen dan memeriksa tindak balas dengan menginstrumenkan masa jalan, biasanya dengan menyediakan persekitaran kotak pasir. Tingkah laku berniat jahat yang dicetuskan dalam keadaan tertentu mungkin terlepas tanpa dikesan: sila ambil perhatian bahawa perisian hasad mungkin menggunakan teknik pengelakan seperti Maya/Pengelarian Kotak Pasir untuk diaktifkan hanya apabila tidak di bawah pengawasan, dan juga merupakan tanda jelas aktiviti berniat jahat untuk mana-mana enjin analisis statik.
Analisis keupayaan mempertimbangkan apa yang dilakukan oleh komponen: di mana ia bersambung, fail mana yang diaksesnya, arahan atau program mana yang dijalankan, terminal atau peranti I/O yang dilakukan, atau panggilan sistem mana yang dipanggil. Cap jari tingkah laku ini boleh dibandingkan (untuk komponen sedia ada) merentasi versi, jadi apabila tingkah laku yang tidak dijangka dikesan, bukti tersebut boleh menimbulkan syak wasangka tentang potensi aktiviti berniat jahat yang disuntik dalam versi baharu. Pendekatan ini mengikuti langkah triaj yang diikuti oleh penganalisis keselamatan apabila berhadapan dengan potensi perisian hasad: pemeriksaan menggunakan tali atau alat yang serupa. Pendekatan ini mengesan tingkah laku berniat jahat tanpa mengira keadaan pencetusan dan berfungsi apabila tiada kod sumber tersedia.
Analisis konteks mengumpul maklumat tentang bagaimana komponen diterbitkan dan oleh siapa. Kempen pelaku jahat sering menggunakan akaun pengguna baharu yang tidak tertakluk kepada sebarang proses pemeriksaan yang ketat. Menjejaki aktiviti lepas mungkin memberi gambaran tentang pengguna asas, kebanyakannya untuk anomali yang mungkin membayangkan potensi kompromi. Reputasi sangat sukar untuk diperoleh dan sangat mudah untuk hilang! Pengguna yang tidak mempunyai aktiviti lepas adalah neutral, tetapi karma mengejar yang jahat. Penggodam, atau pengguna biasa yang kelayakan penerbitannya dicuri harus dijejaki dengan teliti.
Satu lagi maklumat kontekstual ialah sebarang percanggahan antara repositori sumber yang kononnya digunakan untuk mencipta tarball komponen dan kandungan tarball itu sendiri. Dan juga mengikuti amalan baik, seperti mencipta tag atau keluaran dalam repositori sumber yang sepadan dengan versi komponen yang diterbitkan dalam daftar awam. Apabila repositori sumber pada sesuatu commit ditag dengan pelepasan, dan kemudian tiba-tiba satu versi gagal mengikutinya, itu sahaja bukti kukuh bahawa komponen tersebut mungkin tercemar: pelaku jahat mungkin telah menjejaskan akaun yang digunakan untuk menerbitkan komponen tersebut, tetapi tidak mempunyai kebenaran menulis dalam repositori kod sumber). Banyak serangan dikesan secara rutin menggunakan peraturan ini: contohnya, Serangan Lejar dapat dikesan dengan mudah melalui pendekatan ini. Oleh itu, analisis konteks mengenal pasti anomali sedemikian dalam proses penerbitan.
Firewall Kebergantungan
Pendekatan yang berbeza adalah dengan mempunyai senarai putih komponen yang komprehensif untuk semua graf kebergantungan yang digunakan dalam perisian anda, jadi dalam sebarang binaan pipeline jalankan dalam organisasi anda hanya versi komponen yang diluluskan sahaja yang boleh dipasang dan digunakan. "firewall"dikuatkuasakan menggunakan pendaftaran dalaman di mana tarball untuk versi komponen yang dibenarkan dilayan (dicache atau diproksikan). Sila ambil perhatian bahawa sebarang senarai putih tidak akan berfungsi melainkan anda mempunyai teknologi untuk mengklasifikasikan mana-mana versi baharu sebagai agak selamat supaya ia boleh ditambah ke senarai putih.
Sila ambil perhatian bahawa amaran awal (pengesanan pantas secepat mungkin selepas penerbitan versi baharu) perlu digabungkan dengan beberapa cara untuk menggunakan maklumat tersebut secara proaktif bagi menyekat komponen yang mempengaruhi binaan. pipelineatau mesin pembangun [4]Kami menggelarnya sebagai “tembok api kebergantungan": mekanisme kuarantin untuk melindungi binaan automatik daripada pakej berniat jahat. Pakej dalaman dan daftar imej adalah baik untuk melindungi organisasi daripada kejahatan luar, tetapi bukti yang cukup kukuh diperlukan untuk menjadikan kuarantin berkesan.
Sandboxing Masa Larian
Pendekatan alternatif untuk pengesanan pada masa penerbitan adalah dengan menganalisis tingkah laku semasa masa jalan. Ideanya adalah untuk menangkap tingkah laku yang dijangkakan daripada perisian dan mengesan (atau menyekat) sebarang anomali yang ditemui. Tindakan ini mempunyai masalah untuk menginstrumenkan masa jalan untuk pemantauan atau penyekatan, dan ia merupakan idea yang menjanjikan yang akan ditambah kepada senjata mekanisme perlindungan terhadap perosak komponen yang berniat jahat.
Menetapkan Strategi Komprehensif
Strategi yang disyorkan perlu menggabungkan teknik yang berbeza dalam proses pembangunan perisian, mengawal kemas kini versi untuk menyekat komponen berniat jahat yang masuk. Kita mesti mengakomodasi penyematan versi untuk mengelakkan jangkitan automatik dengan mengemas kini versi bagi mendapatkan pembetulan untuk kelemahan yang penting; penilaian yang cepat dan cekap terhadap kebergantungan langsung dan tidak langsung semasa kemas kini versi untuk mempunyai bukti yang mencukupi bahawa ia tidak dipenuhi perisian hasad. Binaan perisian yang bergantung pada komponen berniat jahat yang diketahui mesti disekat. Dan semuanya mesti dikuatkuasakan.
Gunakan penyematan versi, jika boleh, kerana ia menjadikan binaan lebih mudah dihasilkan semula. Penyematan versi dengan bonggol versi yang dikawal dan diluluskan secara manual, dan dibantu oleh teknologi pembantu, harus menilai sama ada kemas kini membawa perisian hasad atau merosakkan perisian, dan menyelaraskan pengemaskinian untuk membetulkan kelemahan dengan mengelakkan jangkitan perisian hasad. Tooling boleh membantu di sini, dengan (1) mengutamakan kelemahan yang benar-benar penting (boleh dicapai dan dieksploitasi, dengan risiko tinggi disasarkan oleh penyerang), (2) memilih versi sasaran yang serasi dengan penggunaan komponen semasa dan tidak merosakkan perisian, (3) memilih versi sasaran yang tidak mengandungi tingkah laku berniat jahat, dan (4) menjadikan kemas kini versi untuk kebergantungan langsung dan tidak langsung mudah, dengan mencadangkan perubahan dalam fail manifes yang boleh diluluskan dengan cepat. Langkah (3) memerlukan maklumat khusus tentang komponen berniat jahat sedekat mungkin dengan masa penerbitannya.
Proses pengemaskinian kebergantungan ini mestilah dikuatkuasakan dan disahkan di semua tempat. Proses ini mesti didokumenkan, dan semua pihak yang terlibat harus dilatih, kerana selalunya pembangunan dan pembinaan/pelaksanaan perisian dieksternalisasikan. CI/CD pipelines perlu diubah suai dengan sewajarnya, jadi automasi tidak membenarkan kebergantungan tidak langsung yang berniat jahat tergelincir ke dalam binaan: guardrails menyekat binaan jika terdapat bukti yang mencukupi tentang potensi perisian hasad dalam kebergantungan adalah cara yang disyorkan.
Jika organisasi anda mempunyai daftar dalaman yang bertindak sebagai proksi keselamatan untuk menyimpan versi komponen yang dibenarkan, anda mesti mendapatkan maklumat tentang komponen berniat jahat (selain kriteria lain) untuk menyemak komponen yang diminta sebelum menambahkannya ke senarai elaun.
Menggunakan perisian sumber terbuka dengan selamat bukanlah mudah, dan faktor perisian hasad mesti diambil kira sepenuhnya, dengan usaha yang sama dilakukan dalam pengendalian kerentanan.
Satu nota terakhir: Asal-usul sumber, dalam bentuk pengesahan perisian, yang dijana pada masa binaan komponen, merupakan satu lagi bahagian penting dalam usaha untuk mengesan artifak (tarball komponen) dengan sumber dan proses binaan yang menghasilkannya. Ambil perhatian bahawa pautan antara snapshot sumber + persekitaran binaan dan artifak perisian yang berkaitan (ditandatangani oleh sistem binaan yang dipercayai) tidak menghalang komponen tersebut daripada mengandungi tingkah laku berniat jahat, tetapi menjadikannya lebih sukar bagi penjahat untuk menyuntik perisian hasad. Dan menjadikan pengesahan asal-usul sebagai keperluan biasa untuk menggunakan komponen sumber terbuka akan mengambil masa yang lama, dan hanya baru-baru ini ditambah ke NPMMenjadikan sistem binaan dan penggunaan yang dipercayai itu kalis gangguan, atau mendayakan pengesanan sebarang gangguan dalam binaan adalah cerita yang berbeza, di luar skop siaran ini.
Bacaan lanjut
Episod seterusnya Pakej Berbahaya Sumber Terbuka: Pendekatan Xygeni akan membentangkan strategi yang kami ikuti di Xygeni untuk kami Amaran Awal Perisian Hasad Sistem (MEW). Versi pakej baharu dalam pakej awam dan daftar imej diimbas dan bukti diperoleh menggunakan gabungan keupayaan statik, dinamik, dan analisis kontekstual. Bukti tersebut, digabungkan dengan reputasi pengguna dan sejarah perubahan dalam repositori kod sumber, membolehkan pengelasan komponen secara automatik sepenuhnya kepada kategori berisiko tinggi dan mungkin berniat jahat. Sistem ini belajar daripada bukti lepas yang dikumpulkan daripada pakej untuk mengurangkan positif palsu ke tahap minimum.
Organisasi yang dilanggan menerima pemberitahuan amaran untuk komponen yang mereka gunakan, secara langsung atau tidak langsung, apabila versi berniat jahat dikategorikan. Kemudian, analisis manual dilakukan oleh penganalisis kami, yang mengesahkan atau menolak pengelasan tersebut. Untuk perisian hasad yang disahkan, pendaftaran awam dimaklumkan supaya ia boleh menjalankan analisisnya sendiri dan biasanya mengalih keluar versi berniat jahat atau mengambil tindakan tambahan, seperti menyekat atau mengalih keluar akaun pengguna yang dimaksudkan.
Kami akan menerangkan bagaimana kami membantu NPM, PyPI, GitHub dan infrastruktur utama lain dalam ekosistem sumber terbuka untuk mengurangkan masa menunggu komponen berniat jahat baharu yang diterbitkan kekal aktif sehingga ia disahkan sebagai perisian hasad dan dialih keluar daripada daftar. Dan bagaimana organisasi boleh mendapat manfaat daripada sistem MEW untuk mendapatkan perlindungan yang lebih baik daripada serangan rantaian bekalan perisian yang melibatkan komponen sumber terbuka.
- [1] Walau bagaimanapun, pengguna komponen perlu menyemak sama ada tarball komponen disimpan dalam cache atau didaftarkan di suatu tempat, contohnya dalam daftar dalaman, supaya penyakit itu dapat dihapuskan.
- [2] Komponen yang dibungkus merangkumi manifes yang mengisytiharkan kandungan dan metadatanya, kod sumber atau kod yang dikompilasi, skrip pemasangan dan item tambahan seperti suit ujian, mengikut format pembungkusan dan biasanya dalam bentuk termampat. Ini dipanggil "tarball komponen".
- [3] Walaupun pelaku berniat jahat boleh mengubah suai komponen yang diterbitkan disebabkan oleh pelanggaran dalam pendaftaran itu sendiri, ringkasan kriptografi biasa boleh mengesan sebarang perubahan dalam tarball selepas analisis dilakukan.
- [4] Ingat bahawa sesetengah komponen berniat jahat berjalan semasa pemasangan, jadi ia boleh menjejaskan nod pembangun yang tanpa sengaja menjalankan "npm install X" dengan X sebagai komponen berniat jahat.
