បីដងក្នុងរយៈពេលប្រាំបីខែ សៀវភៅណែនាំអំពីមេរោគ NPM ដូចគ្នាដំណើរការ។ អ្នកវាយប្រហារផ្សេងៗគ្នា កញ្ចប់ផ្សេងៗគ្នា យន្តការដូចគ្នា និងចន្លោះពេលដូចគ្នារវាងការបោះពុម្ពផ្សាយ និងការរកឃើញ ដែលធ្វើឱ្យមេរោគនីមួយៗអាចធ្វើទៅបាន។ ប្រសិនបើអ្នកកំពុងសួរថាមេរោគ NPM ជាអ្វី ហើយហេតុអ្វីបានជាគំរូនេះបន្តធ្វើម្តងទៀតជំនួសឱ្យការជួសជុល នេះគឺជាចម្លើយដ៏ស្មោះត្រង់ ឧប្បត្តិហេតុ យន្តការ និងចន្លោះប្រហោងមួយដែលសូម្បីតែក្របខ័ណ្ឌការពារដ៏រឹងមាំក៏នៅតែបើកចំហ។
តើមេរោគ Worm npm ជាអ្វី?
មេរោគ npm គឺជាបំណែកនៃកូដព្យាបាទដែលបានបោះពុម្ពផ្សាយទៅក្នុងបញ្ជីឈ្មោះ npm ដែលរីករាលដាលដោយស្វ័យប្រវត្តិទៅកាន់កញ្ចប់ផ្សេងទៀតនៅពេលដែលវាដំណើរការ ជាធម្មតាដោយការលួចយកព័ត៌មានបញ្ជាក់អត្តសញ្ញាណបោះពុម្ពផ្សាយរបស់អ្នកថែទាំ ហើយប្រើប្រាស់វាដើម្បីចាក់ payload ដូចគ្នាទៅក្នុងកញ្ចប់នីមួយៗដែលអ្នកថែទាំគ្រប់គ្រង។ វាជា "មេរោគ" ក្នុងន័យបុរាណ៖ វាមិនរង់ចាំនរណាម្នាក់ដំឡើងវាដោយចេតនាទេ វារីករាលដាលដោយខ្លួនឯង ពីកញ្ចប់មួយទៅកញ្ចប់មួយ ពីគណនីមួយទៅគណនីមួយ ក្នុងល្បឿនម៉ាស៊ីន។
ការរីករាលដាលដោយខ្លួនឯងនោះគឺជាអ្វីដែលបំបែកឧប្បត្តិហេតុដង្កូវ npm ពីកញ្ចប់ព្យាបាទធម្មតា។ កញ្ចប់អាក្រក់តែមួយគឺជាម្ជុលនៅក្នុងគំនរចំបើង។ ដង្កូវ npm ប្រែក្លាយអ្នកថែទាំដែលរងការសម្របសម្រួលទាំងអស់ទៅជាចំណុចចែកចាយថ្មី ហើយគំនរចំបើងចាប់ផ្តើមបង្កើតម្ជុលផ្ទាល់ខ្លួនរបស់វា។
ឧប្បត្តិហេតុដង្កូវ npm ដ៏ធំបំផុតរហូតមកដល់ពេលនេះ
ឆ្នាំមុនបានផ្តល់ឱ្យគំរូដង្កូវ npm នូវការសាកល្បងពិភពលោកពិតចំនួនបីដង ដែលនីមួយៗមានប្រសិទ្ធភាពជាងឆ្នាំមុន៖
- សៃ-ហ៊ូលូដ (ខែកញ្ញា ឆ្នាំ២០២៥)។ មេរោគ npm ដែលរីករាលដាលដោយខ្លួនឯងដំបូងគេបង្អស់ដែលបានកត់ត្រាទុក។ វាបានធ្វើឱ្យខូចដល់ព័ត៌មានសម្ងាត់របស់អ្នកថែទាំ បន្ទាប់មកបានប្រើប្រាស់វាដើម្បីបោះពុម្ពផ្សាយកំណែព្យាបាទនៃកញ្ចប់នីមួយៗដែលស្ថិតនៅក្រោមការគ្រប់គ្រងរបស់អ្នកថែទាំនោះ ដោយប្រែក្លាយអ្នកអភិវឌ្ឍន៍ខ្លួនឯងទៅជាយន្តការចែកចាយសម្រាប់ដំណាក់កាលបន្ទាប់នៃមេរោគ។
- អាកស៊ីអូស (ខែមីនា ឆ្នាំ២០២៦)។ មេរោគរដ្ឋដែលលាក់នៅក្នុងកញ្ចប់មួយទាញប្រហែល 100 លានដងក្នុងមួយសប្តាហ៍។ មិនមែនជាដង្កូវក្នុងន័យសាយភាយយ៉ាងតឹងរ៉ឹងទេ ប៉ុន្តែជាភស្តុតាងដែលបង្ហាញថាគំរូទុកចិត្តប្រព័ន្ធអេកូឡូស៊ី npm ដូចគ្នាដែល Shai-Hulud បានកេងប្រវ័ញ្ចអាចផ្ទុកបន្ទុកក្នុងទ្រង់ទ្រាយធំពិតប្រាកដ។
- SAP npm (មេសា ២០២៦)។ ត្រូវបានពិពណ៌នានៅពេលនោះថាជា Shai-Hulud ខ្នាតតូច៖ លំនាំដង្កូវដូចគ្នា ត្រូវបានធ្វើម្តងទៀតក្នុងទ្រង់ទ្រាយធំ តិចជាងមួយឆ្នាំបន្ទាប់ពីឧប្បត្តិហេតុដើម។ យន្តការមិនបានផ្លាស់ប្តូរទេ។ ការការពារភាគច្រើនក៏មិនបានផ្លាស់ប្តូរដែរ។
ឧប្បត្តិហេតុដង្កូវ npm បី, លំនាំដដែលៗមួយ៖ ធ្វើឱ្យប៉ះពាល់ដល់អ្នកបោះពុម្ពផ្សាយដែលទុកចិត្ត ប្រើប្រាស់ព័ត៌មានសម្គាល់របស់ពួកគេដើម្បីផ្សព្វផ្សាយដោយស្វ័យប្រវត្តិ និងពឹងផ្អែកលើគម្លាតរវាងការបោះពុម្ពផ្សាយ និងការរកឃើញរបស់សហគមន៍ដើម្បីធ្វើអ្វីៗដែលនៅសល់។
លំនាំដែលធ្វើម្តងទៀត
ដកចេញនូវព័ត៌មានលម្អិត ហើយឧប្បត្តិហេតុដង្កូវ npm នីមួយៗធ្វើតាមចង្វាក់បួនដូចគ្នា៖
- ការសម្របសម្រួលគណនី។ ថូខឹនបោះពុម្ពផ្សាយរបស់អ្នកថែទាំ, npm loginឬលិខិតសម្គាល់ CI ត្រូវបានគេលួច ជាធម្មតាតាមរយៈការបន្លំតាមអ៊ីនធឺណិត អាថ៌កំបាំងដែលលេចធ្លាយ ឬការពឹងផ្អែកដែលសម្របសម្រួលបន្ថែមទៀតនៅក្នុងខ្សែសង្វាក់របស់ពួកគេ។
- ការចាក់វ៉ាក់សាំងស្ងាត់។ អ្នកវាយប្រហាររុញកំណែថ្មីនៃកញ្ចប់ស្របច្បាប់ និងគួរឱ្យទុកចិត្តជាមួយនឹងកូដព្យាបាទដែលបានបន្ថែម ជារឿយៗនៅខាងក្នុងស្គ្រីបក្រោយការដំឡើង ឬស្គ្រីបវដ្តជីវិតផ្សេងទៀត ដែលដំណើរការដោយស្វ័យប្រវត្តិនៅពេលដែលមាននរណាម្នាក់ដំឡើងវា។
- ការរីករាលដាលដោយស្វ័យប្រវត្តិ។ ប្រសិនបើអ្នកថែទាំដែលរងការសម្របសម្រួលគ្រប់គ្រងកញ្ចប់ផ្សេងទៀត ឬប្រសិនបើស្គ្រីបព្យាបាទខ្លួនឯងប្រមូលព័ត៌មានសម្ងាត់បន្ថែម ដង្កូវនឹងរីករាលដាលទៅកញ្ចប់បន្ទាប់ និងអ្នកថែទាំបន្ទាប់ដោយគ្មានសកម្មភាពបន្ថែមពីអ្នកវាយប្រហារ។
- ការពន្យារពេលនៃការរកឃើញ។ កញ្ចប់នេះស្ថិតនៅលើបញ្ជីឈ្មោះ ដែលអាចដំឡើងបានដោយនរណាម្នាក់ រហូតដល់មាននរណាម្នាក់កត់សម្គាល់ រាយការណ៍វា ហើយវាត្រូវបានដកចេញ។ ភាពយឺតយ៉ាវនោះ ម៉ោងសម្រាប់ឧប្បត្តិហេតុមួយចំនួន ថ្ងៃសម្រាប់ឧប្បត្តិហេតុផ្សេងទៀត គឺជាបង្អួចទាំងមូលដែលដង្កូវត្រូវការ។
ការទទួលស្គាល់ចង្វាក់ទីបួននោះគឺជាអ្វីដែលពិតជាសំខាន់សម្រាប់ការការពារ។ យុទ្ធសាស្ត្រកាត់បន្ថយនីមួយៗសម្រាប់ឧប្បត្តិហេតុដង្កូវ npm គឺជាការប៉ុនប៉ងដើម្បីបង្រួម ឬរំលងភាពយឺតយ៉ាវនៃការរកឃើញនោះ។
ក្របខ័ណ្ឌមួយដែលគួរដកស្រង់៖ ចម្លើយរបស់ SIP ចំពោះបញ្ហា Cooldown
មិនមែនគ្រប់ការឆ្លើយតបទៅនឹងគំរូនេះសុទ្ធតែមកពីអ្នកលក់នោះទេ។ មួយក្នុងចំណោមការឆ្លើយតបច្បាស់លាស់បំផុតគឺ SIP, ផែនការសន្តិសុខបន្ទាន់របស់លោក Mohammad-Ali A'râbiដែលជាក្របខ័ណ្ឌសង្គ្រោះបន្ទាន់ដែលមានការគ្រប់គ្រងប្រាំសម្រាប់ហានិភ័យខ្សែសង្វាក់ផ្គត់ផ្គង់កម្មវិធី ដែលបានកើតចេញពីសំណួរជាក់ស្តែងមួយដែលត្រូវបានសួរនៅចុងបញ្ចប់នៃវគ្គ SafeDev ថា “ប្រសិនបើយើងអាចធ្វើរឿងមួយចំនួនតូចប៉ុណ្ណោះ តើយើងគួរធ្វើអ្វីមុនគេ?”
ការគ្រប់គ្រងទីពីររបស់ SIP មានគោលបំណងផ្តោតទៅលើបញ្ហាដង្កូវ npm៖ បង្កកការពឹងផ្អែកដែលមិនទាន់បានត្រួតពិនិត្យជាមួយនឹងរយៈពេល cooldown ប្រាំថ្ងៃ និងបិទស្គ្រីបវដ្តជីវិត ដូច្នេះការដំឡើងក្រោយដែលមានគំនិតអាក្រក់មិនអាចប្រតិបត្តិដោយស្វ័យប្រវត្តិក្នុងអំឡុងពេលដំឡើងបានទេ។ នៅក្នុងការអនុវត្ត នោះគឺ... min-release-age=5 និង ignore-scripts=true នៅក្នុងគម្រោងមួយ .npmrcត្រូវបានអនុវត្តនៅក្នុង CI ដូច្នេះឯកសារចាក់សោមិនអាចដោះស្រាយកញ្ចប់ដែលបានបោះពុម្ពផ្សាយកាលពីម្សិលមិញដោយស្ងាត់ៗបានទេ។ វាជាការគ្រប់គ្រងដ៏រឹងមាំ និងចំណាយតិច ហើយវាផ្តោតដោយផ្ទាល់ទៅលើភាពយឺតយ៉ាវនៃការរកឃើញដូចគ្នាដែលឧប្បត្តិហេតុដង្កូវ npm នីមួយៗអាស្រ័យលើ។ ស្វែងយល់បន្ថែម៖
កន្លែងដែលបង្អួច Cooldown នៅតែទុកចន្លោះ
រយៈពេល cooldown គឺជាការភ្នាល់មួយ៖ សហគមន៍នឹងកត់សម្គាល់ និងរាយការណ៍ពីកញ្ចប់ព្យាបាទមុនពេលរយៈពេលរង់ចាំបញ្ចប់។ ភាគច្រើននៃការភ្នាល់នោះទទួលបានផលចំណេញ។ ចំណែកដ៏មានអត្ថន័យនៃកញ្ចប់ដែលរងការសម្របសម្រួលត្រូវបានសម្គាល់ក្នុងរយៈពេលពីរបីថ្ងៃដំបូងនៃការបោះពុម្ពផ្សាយ ដែលជាមូលហេតុដែលរយៈពេលប្រាំថ្ងៃគឺជាលំនាំដើមសមហេតុផល។
ប៉ុន្តែដង្កូវ npm មិនមានឥរិយាបថដូចកញ្ចប់ព្យាបាទធម្មតាទេ ហើយវាផ្លាស់ប្តូរអ្វីដែល cooldown ថេរអាចធ្វើបាន និងមិនអាចធ្វើបានសម្រាប់អ្នក។
ដើម្បីឲ្យបានមុនcisអំពីល្បឿន៖ ដង្កូវដែលរីករាលដាលលឿនពិតជាមិនអាចកម្ចាត់ cooldown ដោយខ្លួនឯងបានទេ។ ប្រសិនបើអ្នកអនុវត្តអាយុចេញផ្សាយអប្បបរមាយ៉ាងតឹងរ៉ឹង កញ្ចប់ដែលបានបោះពុម្ពផ្សាយក្នុងអំឡុងពេលរលកដំបូងនោះនៅតែថ្មីពេកមិនអាចចូលទៅក្នុង build បានទេ មិនថាដង្កូវនោះធ្វើឱ្យខូចកញ្ចប់ប៉ុន្មានក្នុងពេលនេះទេ។ ល្បឿនមានសារៈសំខាន់ ប៉ុន្តែវាមានសារៈសំខាន់សម្រាប់អ្នករាល់គ្នាដែលមិនទាន់ដំណើរការ cooldown មិនមែនសម្រាប់ការយកឈ្នះលើមួយដែលត្រូវបានអនុវត្តរួចហើយនោះទេ។
ដែនកំណត់ពិតប្រាកដគឺការអត់ធ្មត់។ បន្ទុកដែលមានការប្រុងប្រយ័ត្នជាងនេះអាចនៅស្ងៀមហួសពីរយៈពេលត្រជាក់ ដោយធ្វើឱ្យសកម្មលុះត្រាតែថ្ងៃទាំងនោះបានកន្លងផុតទៅ ហើយកញ្ចប់បានចាស់ទៅក្នុងតំបន់ "ដែលទុកចិត្ត" មុនcisely ពីព្រោះវាដឹងថា cooldown កំពុងមើល។ នោះជាសេណារីយ៉ូដែល cooldown ថេរតែមួយមិនគ្រប់គ្រាន់ទេ ហើយជាកន្លែងដែលអ្វីមួយដូចជាការរកឃើញដែលមានមូលដ្ឋានលើភស្តុតាងរបស់ MEW ត្រូវអង្គុយក្បែរវា មិនមែនជំនួសវាទេ។
ទាំងរបៀបបរាជ័យទាំងពីរមិនមែនជាចំណុចខ្វះខាតក្នុងការគិតរបស់ SIP ទេ។ ការ cooldown គឺជាការភ្នាល់លើការរកឃើញសហគមន៍ ហើយការរកឃើញសហគមន៍មានកម្រិតទាប៖ វាមិនអាចចាប់អ្វីដែលគ្មាននរណាម្នាក់បានរាយការណ៍នៅឡើយទេ។ នោះមិនមែនជាគម្លាតដែលមានតែចំពោះ SIP ទេ វាជាដែនកំណត់រចនាសម្ព័ន្ធនៃការការពារណាមួយដែលរង់ចាំហត្ថលេខា ការណែនាំ ឬរបាយការណ៍សាធារណៈមុនពេលធ្វើសកម្មភាព។
របៀបដែល MEW បិទគម្លាត Cooldown-Window
នេះជាមុនcisអេលី គម្លាត ការព្រមានជាមុនអំពីមេរោគ Xygeni (MEW) ត្រូវបានបង្កើតឡើងដើម្បីបិទ។ ជំនួសឱ្យការរង់ចាំរបាយការណ៍សហគមន៍ ឬហត្ថលេខាដែលបានបោះពុម្ពផ្សាយ MEW ស្កេន NPM, PyPI និង Maven ជាបន្តបន្ទាប់ នៅពេលដែលកញ្ចប់ និងកំណែថ្មីត្រូវបានបោះពុម្ពផ្សាយ ដោយវិភាគឥរិយាបថជាជាងការផ្គូផ្គងប្រឆាំងនឹងការគំរាមកំហែងដែលគេស្គាល់។ នៅពេលដែលអ្វីមួយមើលទៅមានគំនិតអាក្រក់ វាត្រូវបានដាក់ឱ្យនៅដាច់ដោយឡែក ហើយការរកឃើញនេះត្រូវបានបញ្ជាក់ដោយអ្នកស្រាវជ្រាវសន្តិសុខមុនពេលបង្ហាញជាសាធារណៈ មិនមែនបន្ទាប់ពីនោះទេ។
ភាពខុសគ្នានោះមានសារៈសំខាន់សម្រាប់របៀបបរាជ័យនៃមេរោគ Worm npm ទាំងពីរខាងលើ។ ប្រឆាំងនឹងមេរោគ Worm ដែលរីករាលដាលលឿន ការរកឃើញហត្ថលេខាមុនមិនត្រូវការរយៈពេលប្រាំថ្ងៃដូចដែលវាត្រូវការនោះទេ។ ប្រឆាំងនឹងបន្ទុកដែលកំពុងសម្រាក ការវិភាគអាកប្បកិរិយារបស់ MEW មិនកំពុងស្វែងរកអាយុ ឬកេរ្តិ៍ឈ្មោះទេ វាកំពុងស្វែងរកអ្វីដែលកូដពិតជាធ្វើ ដូច្នេះការរង់ចាំបង្អួច cooldown មិនទិញអ្វីពីអ្នកវាយប្រហារទេ។
ជញ្ជាំងភ្លើង Dependency Firewall របស់ MEW ពង្រីកមុខងារនេះដល់ចំណុចដំឡើង ដោយរារាំងកញ្ចប់ព្យាបាទក្នុងពេលវេលាជាក់ស្តែង ទោះបីជាវារអិលចេញពីការត្រួតពិនិត្យមុនៗក៏ដោយ ហើយស្រទាប់រកឃើញដូចគ្នាគ្របដណ្តប់... CI/CD ផ្នែកម្ខាងនៃឧប្បត្តិហេតុដង្កូវ npm៖ គំរូ unlock-branch, inject, re-lock ដែលអនុញ្ញាតឱ្យអ្នកវាយប្រហាររុញមេរោគព្យាបាទ commit ហើយបិទបាំងដានរបស់ពួកគេដោយស្ងាត់ៗ ជាមួយនឹងឯកសារសវនកម្មពេញលេញ ប្រសិនបើវាកើតឡើងយ៉ាងណាក៏ដោយ។
SIP និង MEW កំពុងឆ្លើយសំណួរដូចគ្នា នៅកម្រិតផ្សេងៗគ្នា
គ្មានចំណុចណាមួយធ្វើឲ្យការគ្រប់គ្រងការ cooldown របស់ SIP ខុសនោះទេ ហើយវាគួរឲ្យនិយាយឲ្យច្បាស់លាស់ថា៖ ការ cooldown រយៈពេលប្រាំថ្ងៃដែលបិទស្គ្រីបវដ្តជីវិតនៅតែជាការការពារលឿនបំផុត និងថោកបំផុតមួយដែលក្រុមអាចដាក់ឲ្យប្រើប្រឆាំងនឹងឧប្បត្តិហេតុដង្កូវ npm ធម្មតា ហើយវាជាកម្មសិទ្ធិរបស់ផែនការពង្រឹងខ្សែសង្វាក់ផ្គត់ផ្គង់ធ្ងន់ធ្ងរណាមួយ។ តាមការរចនា វាមិនអាចធ្វើបានទេ គឺចាប់យកអ្វីដែលសហគមន៍មិនទាន់បានរកឃើញនៅឡើយ។ នោះជាការងារសម្រាប់ការរកឃើញដែលផ្អែកលើឥរិយាបថជាបន្តបន្ទាប់ដែលដំណើរការនៅក្រោម cooldown មិនមែនជំនួសឲ្យវាទេ។
វិធីសាស្រ្តទាំងពីរនេះត្រូវបានដាក់ជាស្រទាប់ៗជាមួយគ្នា គ្របដណ្តប់លើបញ្ហាទាំងពីរនៃបញ្ហាដូចគ្នា៖ SIP ធ្វើឱ្យការសាងសង់រឹងមាំ។ pipelineការបង្កកភាពអាស្រ័យ និងរូបភាពកុងតឺន័រជុំវិញទេសភាពគំរាមកំហែងដែលគេស្គាល់ និងបង្ហាញឱ្យឃើញ ខណៈពេលដែលការរកឃើញហត្ថលេខាមុនរបស់ MEW គ្របដណ្តប់លើឧប្បត្តិហេតុដង្កូវ npm ដែលមិនទាន់ត្រូវបានបង្ហាញនៅឡើយទេ ដែលជាបង្អួច cooldown តាមតក្កវិជ្ជារបស់វាផ្ទាល់ មិនអាចមើលឃើញថានឹងមកដល់។
សំណួរដែលត្រូវបានសួរជាញឹកញាប់
តើដង្កូវ npm ជាអ្វី ក្នុងប្រយោគមួយ?
កូដព្យាបាទត្រូវបានបោះពុម្ពផ្សាយទៅកាន់ npm ដែលរីករាលដាលដោយស្វ័យប្រវត្តិទៅកាន់កញ្ចប់ផ្សេងទៀត ជាធម្មតាដោយការលួចព័ត៌មានសម្ងាត់របស់អ្នកថែទាំ ហើយប្រើប្រាស់វាដើម្បីចាក់ payload ដូចគ្នានៅកន្លែងផ្សេង ដោយគ្មានសកម្មភាពបន្ថែមពីអ្នកវាយប្រហារ។
តើកញ្ចប់ npm ព្យាបាទនីមួយៗជាដង្កូវ npm ដែរឬទេ?
ទេ។ កញ្ចប់ព្យាបាទដែលមិនរីករាលដាលដោយខ្លួនឯងគឺជាការវាយប្រហារខ្សែសង្វាក់ផ្គត់ផ្គង់ ប៉ុន្តែមិនមែនជាដង្កូវទេ។ អ្វីដែលកំណត់ឧប្បត្តិហេតុដង្កូវ npm ជាពិសេសគឺជំហានរីករាលដាលដោយខ្លួនឯង៖ ការសម្របសម្រួលមួយនាំទៅដល់ការសម្របសម្រួលបន្ទាប់ដោយស្វ័យប្រវត្តិ។
តើរយៈពេល cooldown dependency បញ្ឈប់ដង្កូវ npm ដែរឬទេ?
វាកាត់បន្ថយហានិភ័យយ៉ាងច្រើន ដោយសារកញ្ចប់ព្យាបាទភាគច្រើនត្រូវបានរាយការណ៍ក្នុងរយៈពេលពីរបីថ្ងៃដំបូងនៃការបោះពុម្ពផ្សាយ។ ប៉ុន្តែ cooldown គឺជាការភ្នាល់លើល្បឿនរកឃើញសហគមន៍ ហើយដង្កូវ npm ដែលរីករាលដាលលឿន ឬដោយចេតនាអសកម្មអាចត្រូវបានបង្កើតឡើងជាពិសេសដើម្បីយកឈ្នះលើបង្អួចនោះ។
តើអ្វីទៅដែលអាចចាប់ដង្កូវ npm មុនពេលរយៈពេល cooldown?
ការស្កេនជាបន្តបន្ទាប់ដោយផ្អែកលើឥរិយាបថ ដែលមិនអាស្រ័យលើហត្ថលេខា ឬរបាយការណ៍សាធារណៈដែលមានស្រាប់។ នោះគឺជាចន្លោះប្រហោងជាក់លាក់ដែលឧបករណ៍រកឃើញមុនហត្ថលេខាដូចជា MEW របស់ Xygeni ត្រូវបានបង្កើតឡើងដើម្បីបិទ។
