កញ្ចប់ព្យាបាទប្រភពបើកចំហ៖ បញ្ហា

កញ្ចប់ព្យាបាទប្រភពបើកចំហ៖ បញ្ហា

នេះ​ជា​វគ្គ​ដំបូង​នៅ​ក្នុង​ស៊េរី​អត្ថបទ​អំពី​ការ​វាយ​ប្រហារ​ខ្សែ​សង្វាក់​ផ្គត់ផ្គង់​កម្មវិធី​ដែល​មាន​ច្រើន​បំផុត៖ អ្នក​ដែល (មិន) ប្រើប្រាស់​បញ្ជី​ឈ្មោះ​សាធារណៈ​នៃ​សមាសធាតុ​កម្មវិធី ដែល​មាន​បំណង​សម្រាប់ គម្រោងប្រភពបើកចំហ ដើម្បីផ្ទុកឡើងនូវវត្ថុបុរាណដែលអាចចែករំលែកជាមួយអ្នកប្រើប្រាស់ផ្សេងទៀត។ នៅពេលដែលជនអាក្រក់បោះពុម្ពផ្សាយកម្មវិធីព្យាបាទនៅទីនោះ ដោយប្រើបញ្ជីឈ្មោះជាយានជំនិះសម្រាប់ការចែកចាយមេរោគ យើងមានការវាយប្រហារខ្សែសង្វាក់ផ្គត់ផ្គង់នៅពេលដែលអង្គការជនរងគ្រោះដំឡើង ឬដំណើរការសមាសធាតុកម្មវិធីដែលឆ្លងមេរោគ។ 

ដើម្បីសម្រួលដល់ការពិភាក្សា យើងនឹងនិយាយអំពី កញ្ចប់សូហ្វវែរ:, សមាសភាគក្នុងទម្រង់វេចខ្ចប់ដែលផលិតដោយភាគីទីបី។ នេះមិនត្រឹមតែរួមបញ្ចូលសមាសភាគដែលប្រើដោយអ្នកគ្រប់គ្រងកញ្ចប់ដូចជា NPM ឬ Poetry ប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំង សមាសធាតុប្រព័ន្ធប្រតិបត្តិការ រួមទាំងបណ្ណាល័យ និងឯកសារគោលពីរដែលអាចប្រតិបត្តិបាន រូបភាពកុងតឺន័រ, និងម៉ាស៊ីននិម្មិត ឬ ផ្នែកបន្ថែមឧបករណ៍ សម្រាប់ឧបករណ៍អភិវឌ្ឍន៍ សាងសង់ និងដាក់ពង្រាយ។ យើងបានឃើញកញ្ចប់ព្យាបាទគ្រប់ទីកន្លែង។ ឧក្រិដ្ឋជនតាមអ៊ីនធឺណិតមិនប្រកាន់ទេ៖ ពួកគេពេញចិត្តនឹងជម្រើសដែលផ្តល់ដោយហេដ្ឋារចនាសម្ព័ន្ធកម្មវិធីទំនើបៗ ហើយប្រើប្រាស់បញ្ជីឈ្មោះ និងឧបករណ៍ដែលសមស្របបំផុតនឹងចេតនារបស់ពួកគេ។ ដូច្នេះសូមចងចាំថាកញ្ចប់កម្មវិធីគឺជាអក្សរកាត់សម្រាប់រូបភាពកុងតឺន័រ កញ្ចប់ប្រព័ន្ធគោលពីរ ឃ្លាំងប្រភពបើកចំហ និងផ្នែកបន្ថែម ឬកម្មវិធីជំនួយគ្រប់ប្រភេទ (IDEs, CI/CD ប្រព័ន្ធ ឧបករណ៍បង្កើត)។ ទាំងអស់សុទ្ធតែស្ថិតនៅក្រោមការវាយប្រហារជាប្រចាំ។

ស៊េរីនេះនឹងមាន ៥ ភាគ៖

  • តើ​បញ្ហា​អ្វី​ជាមួយ​កញ្ចប់​ប្រភព​បើកចំហ? នេះជាប្រធានបទនៃការបង្ហោះនេះ។ ហេតុអ្វីបានជាឧក្រិដ្ឋជនគ្រប់ប្រភេទបោះពុម្ពផ្សាយកញ្ចប់ព្យាបាទ? ហេតុអ្វីបានជាខ្ញុំគួរព្រួយបារម្ភ?
  • កាយវិភាគសាស្ត្រនៃកញ្ចប់ព្យាបាទ៖ តើនិន្នាការអ្វីខ្លះ? នៅក្នុងវគ្គនេះ យើងផ្តោតលើការគំរាមកំហែងដែលយើងកំពុងតាមដានជាមួយប្រព័ន្ធ MEW របស់យើងជារៀងរាល់ថ្ងៃ។ ដោយមានសំឡេងរំខានផ្ទៃខាងក្រោយយ៉ាងច្រើនដោយសារតែចំនួនកញ្ចប់ព្យាបាទមួយចំនួនធំដោយប្រើការវាយអក្សរខុស ឬការភាន់ច្រឡំនៃការពឹងផ្អែក ភាគរយនៃការវាយប្រហារតិចជាងមុនគឺមានលក្ខណៈអាក្រក់ជាង និងបង្កហានិភ័យធំជាង។ តើឥរិយាបថរបស់ជនខិលខូចទាក់ទងនឹងប្រព័ន្ធប្រតិបត្តិការបានផ្លាស់ប្តូរយ៉ាងដូចម្តេចក្នុងរយៈពេលកន្លងមកថ្មីៗនេះ? តើតួលេខមានអ្វីខ្លះ? តើយុទ្ធសាស្ត្រ បច្ចេកទេស និងនីតិវិធីដែលបានប្រើមានអ្វីខ្លះ និងសកម្មភាពបង្កគ្រោះថ្នាក់ដែលបានឃើញ?
  • ការការពារប្រឆាំងនឹងកញ្ចប់ព្យាបាទប្រភពបើកចំហ៖ អ្វីដែល (មិន) ដំណើរការអ្នកជំនាញភាគច្រើនដែលយល់ដឹងអំពីសុវត្ថិភាពមានគំនិតអំពីរបៀបដោះស្រាយការគំរាមកំហែងនេះ។ យើងបានឮអ្នកគ្រប់គ្រងសន្តិសុខនិយាយដោយមិនស្ទាក់ស្ទើរថា SCA ឧបករណ៍​ប្រាប់​អ្នក​រួចហើយ​ថា​តើ​កំណែ​កញ្ចប់​មួយ​ជា​មេរោគ​ឬ​អត់។ ឬ​ថា​ពួកគេ​ពឹងផ្អែក​លើ​សមាសធាតុ​កម្មវិធី​ដែល​ល្បី​និង​ត្រូវ​បាន​ពិនិត្យ​យ៉ាង​ខ្លាំង ដែល​មេរោគ​ណាមួយ​នឹង​ត្រូវ​បាន​រក​ឃើញ​និង​លុប​ចេញ​ភ្លាមៗ។ ពួកគេ​ថា​ពួកគេ​ប្រើ​កំណែ​តូចតាច/បំណះ​បើកចំហ​សម្រាប់​ការ​ជួសជុល​ភាព​ងាយ​រងគ្រោះ​ដោយ​ស្វ័យប្រវត្តិ ហើយ​នោះ​គឺជា​វិធី​ត្រឹមត្រូវ​ដែល​បាន​ណែនាំ​ដើម្បី​កាត់បន្ថយ​ហានិភ័យ​លើ​ការពឹងផ្អែក​លើ​ប្រភព​បើកចំហ ដោយ​អនុវត្តតាម​គោលការណ៍ "បំណះ​មុន បំណះ​ញឹកញាប់"។ នៅក្នុង​វគ្គ​នេះ យើង​នឹង​ពិនិត្យ​ឡើងវិញ​ថា​ហេតុអ្វី​បានជា​គំនិត​ទាំងនេះ​ខុស និង​របៀប​ដែល​ការយល់ច្រឡំ​បែបនេះ​រួមចំណែក​ដល់​ប្រជាប្រិយភាព​នៃ​យន្តការ​វាយប្រហារ​នេះ និង​ហានិភ័យ​ដ៏​លើសលប់​ដែល​អង្គការ​កំពុង​ជួបប្រទះ។ យើង​នឹង​បញ្ចប់​ដោយ​អ្វី​ដែល​ដំណើរការ ហើយ​អ្វី​ទៅ​ជា​ការខិតខំ​ប្រឹងប្រែង និង​ធនធាន​ដែល​ពាក់ព័ន្ធ។
  • កញ្ចប់ព្យាបាទប្រភពបើកចំហ៖ វិធីសាស្រ្ត Xygeniនៅក្នុងវគ្គនេះ យើងធ្វើបទបង្ហាញអំពីយុទ្ធសាស្ត្រដែលយើងអនុវត្តតាមនៅ Xygeni សម្រាប់ប្រព័ន្ធព្រមានមេរោគ (MEW) របស់យើង។ តើប្រព័ន្ធពហុដំណាក់កាលនេះដំណើរការយ៉ាងដូចម្តេចក្នុងពេលវេលាជាក់ស្តែង នៅពេលដែលកំណែកញ្ចប់ថ្មីត្រូវបានបោះពុម្ពផ្សាយ របៀបដែលភស្តុតាងត្រូវបានចាប់យកពីប្រភពផ្សេងៗគ្នា របៀបដែលការចាត់ថ្នាក់ត្រូវបានធ្វើ តើលក្ខណៈវិនិច្ឆ័យចំណាត់ថ្នាក់អ្វីដែលយើងកំពុងអនុវត្តតាម និងហេតុអ្វីបានជាការវិភាគដោយដៃមួយចំនួននៅតែត្រូវការដើម្បីបញ្ជាក់ពីលក្ខណៈនៃបេក្ខជនកញ្ចប់ព្យាបាទ? របៀបដែលមតិកែលម្អពីក្រុមផ្ទៃក្នុង និងក្រុមចុះឈ្មោះរបស់យើងជួយប្រព័ន្ធឱ្យរៀនពីភស្តុតាងកន្លងមកដែលប្រមូលបាន ដើម្បីកាត់បន្ថយភាពវិជ្ជមានមិនពិតឱ្យនៅអប្បបរមា។ ហើយយើងនឹងពន្យល់ពីរបៀបដែលយើងកំពុងជួយ NPM, GitHub, PyPI និងហេដ្ឋារចនាសម្ព័ន្ធសំខាន់ៗផ្សេងទៀតនៅក្នុងប្រព័ន្ធអេកូឡូស៊ីប្រភពបើកចំហ ដើម្បីកាត់បន្ថយពេលវេលាស្នាក់នៅ។
  • ការកេងប្រវ័ញ្ចប្រភពបើកចំហ៖ អ្វីដែលត្រូវរំពឹងពីមនុស្សអាក្រក់ស៊េរីនេះបញ្ចប់ដោយផ្តោតលើសកម្មភាពថ្មីៗបំផុតដែលសត្រូវកំពុងឱបក្រសោប ដើម្បីធ្វើឱ្យការវាយប្រហារកាន់តែលួចលាក់ ពិបាករកឃើញ កាន់តែផ្តោតលើឧស្សាហកម្មជាក់លាក់ និងទាញយកអត្ថប្រយោជន៍កាន់តែច្រើនពីការវាយប្រហារប្រភេទនេះ។ តើការវាយប្រហារ ransomware នឹងត្រូវបានផ្តល់ជូនដោយប្រើយានជំនិះនេះដែរឬទេ? តើមនុស្សអាក្រក់កំពុងប្រើប្រាស់ឧបករណ៍ AI ដើម្បីផ្តល់កញ្ចប់ព្យាបាទដ៏ទំនើបជាងមុនយ៉ាងដូចម្តេច? តើគម្រោងពេញនិយមកំពូលៗស្ថិតក្នុងគ្រោះថ្នាក់ដែរឬទេ? នេះគឺដើម្បីផ្តល់ឱ្យអ្នកអាននូវអារម្មណ៍អំពីការប្រណាំងប្រជែងសព្វាវុធនេះ និងអ្វីដែលត្រូវរំពឹងទុកក្នុងរយៈពេលខ្លី (ពាក់កណ្តាលទីពីរនៃឆ្នាំ 2024) និងរយៈពេលមធ្យម (ឆ្នាំ 2025)។ យើងនឹងរៀនពីរបៀបដែលការវាយប្រហារដូចជាថ្មីៗនេះ... ទ្វារក្រោយ XZ-Utilsឬការវាយប្រហារលើមនុស្សរស់នៅលើដីគោក អ្នកបង្កើតអេឡិចត្រុង នៅក្នុងខែមីនា ដល់ ខែមីនា ឆ្នាំ២០២៤ កំពុងបង្ហាញថា យើងគួរតែបន្តប្រុងប្រយ័ត្នអំពីរបៀបដែលសត្រូវវិវឌ្ឍ។ 

ចូរយើងបើកឆាកជាមួយនឹងវគ្គដំបូង៖ តើមានអ្វីកើតឡើងជាមួយកញ្ចប់ប្រភពបើកចំហដែលមានគំនិតអាក្រក់?

តើ​បញ្ហា​អ្វី​ជាមួយ​កញ្ចប់​ប្រភព​បើកចំហ?

ក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ ជនល្មើសគ្រប់ប្រភេទបានប្រើប្រាស់ការចុះបញ្ជីកម្មវិធីប្រភពបើកចំហរដើម្បីផ្តល់ឥរិយាបថព្យាបាទ។ សកម្មភាពទាំងនេះមានអាយុកាលយូរដូចកម្មវិធីប្រភពបើកចំហរដែរ ប៉ុន្តែភាពញឹកញាប់របស់វាបានកើនឡើងយ៉ាងខ្លាំងក្នុងរយៈពេលបីឆ្នាំចុងក្រោយនេះ។ 

ការបោះពុម្ពផ្សាយសមាសធាតុព្យាបាទទៅក្នុងបញ្ជីឈ្មោះសាធារណៈ (ការវាយប្រហារផ្អែកលើការពឹងផ្អែក) គឺជាសង្គ្រាមទ័ពព្រៃអសមមាត្រដែលជនគំរាមកំហែងប្រើដើម្បីចែកចាយមេរោគ ដោយទាញយកផលប្រយោជន៍ពីការជឿទុកចិត្តដែលអង្គការនានាដាក់លើសមាសធាតុប្រភពបើកចំហដែលមកពីអ្នកអភិវឌ្ឍន៍ដែលមិនស្គាល់ (សូមចងចាំ រឿងកំប្លែង xkcd ដែលពឹងផ្អែក?). ដោយសារតែអ្នកទុកចិត្តលើកញ្ចប់ ហើយមិនប្រកាន់ក្នុងការពិនិត្យឡើងវិញដោយដៃនូវខ្លឹមសារកញ្ចប់ និងការពឹងផ្អែករបស់វា ការវាយប្រហារទាំងនេះមានប្រសិទ្ធភាពមិនធម្មតា។ ហើយភាពមិនស៊ីមេទ្រីកើតឡើងដោយសារតែពួកវាអាចត្រូវបានធ្វើដោយស្វ័យប្រវត្តិជាចម្បង ហើយមនុស្សអាក្រក់មិនចាំបាច់ធ្វើអន្តរកម្មជាមួយជនរងគ្រោះដោយផ្ទាល់នោះទេ។ ពួកគេគ្រាន់តែផ្ទុកឡើងកញ្ចប់ទៅក្នុងបញ្ជីឈ្មោះសាធារណៈ ហើយទុកវាចោល។

កញ្ចប់ព្យាបាទ បានកើនឡើង ៦ ដងនៅឆ្នាំ ២០២២ហើយបានបន្តកើនឡើង 2.5 ដងនៅឆ្នាំ 2023។ កាលពីឆ្នាំមុន កញ្ចប់មេរោគចំនួន 245,000 ត្រូវបានគេមើលឃើញ ដែលជាតួលេខដែលច្រើនជាងទ្វេដងនៃចំនួនសរុបពីឆ្នាំមុនៗរួមបញ្ចូលគ្នា។ នេះគឺជាកំណើនអិចស្ប៉ូណង់ស្យែល! ពីការដកកញ្ចប់ចេញជាមេរោគដែលបានបញ្ជាក់រាប់រយក្នុងអំឡុងឆ្នាំ 2021 និងរាប់ពាន់ក្នុងអំឡុងឆ្នាំ 2022 យើងបានឃើញ "សំឡេងរំខាន" ផ្ទៃខាងក្រោយច្រើនជាងមុនក្នុងអំឡុងឆ្នាំ 2023 ជាមួយនឹងល្បឿនស្រដៀងគ្នាសម្រាប់ឆ្នាំនេះ។ ហើយលាក់ខ្លួននៅក្នុងផ្ទៃខាងក្រោយនោះដែលបណ្តាលមកពីឧក្រិដ្ឋជនតាមអ៊ីនធឺណិតដែលមិនមានភាពស្មុគស្មាញដែលដើរតាម "ផ្លូវនៃការតស៊ូតិចបំផុត" ការវាយប្រហារលេចធ្លោមួយចំនួនតូចបានឈានដល់ចំណងជើងសូម្បីតែនៅក្នុងប្រព័ន្ធផ្សព្វផ្សាយទូទៅក៏ដោយ។

ហេតុអ្វីបានជាបញ្ហានេះមានទំហំធំម្ល៉េះ? មាន ការជឿទុកចិត្តហួសហេតុ នៅទូទាំងខ្សែសង្វាក់។ កម្មវិធីប្រភពបើកចំហត្រូវបានចែកចាយជាមួយកូដប្រភពរបស់វា ហើយចេញផ្សាយក្រោមអាជ្ញាប័ណ្ណដែលបានផ្តល់ឱ្យ។ មែនហើយ អ្នកណាក៏អាចត្រួតពិនិត្យកូដប្រភពបានដែរ។ ប៉ុន្តែ តើអ្នកណាធ្វើជាទូទៅ? តើអ្នកណាបន្ទាប់ពីត្រួតពិនិត្យថាកម្មវិធីនេះមិនមានមេរោគ បង្កើតកម្មវិធីពីប្រភព? តើអ្នកណាមុនពេលបញ្ជូនសមាសធាតុដែលបានវេចខ្ចប់ (ត្រូវបានគេស្គាល់ផងដែរថាជា នីមួយៗ) ចុះ​ទៅ​កម្មវិធី​គ្រប់គ្រង​កញ្ចប់ ឬ​ឧបករណ៍​បង្កើត ធ្វើឱ្យប្រាកដថាកញ្ចប់មិនពោរពេញទៅដោយមេរោគ ហើយត្រូវគ្នានឹងកូដប្រភពដែលវាគួរតែមកពី?

ហេតុអ្វីបានជាហេដ្ឋារចនាសម្ព័ន្ធអនុញ្ញាតឱ្យមានការវាយប្រហារយ៉ាងងាយស្រួលបែបនេះ?

ការចុះឈ្មោះកញ្ចប់ បើកចំហ ដែលជារឿយៗតម្រូវឱ្យមានការផ្ទៀងផ្ទាត់អត្តសញ្ញាណរបស់អ្នកបោះពុម្ពផ្សាយតិចតួចបំផុត។ “អ្នកណាម្នាក់ត្រូវបានស្វាគមន៍ក្នុងការបោះពុម្ពផ្សាយកម្មវិធីរបស់ពួកគេនៅទីនេះ!” របារសម្រាប់អ្នកវាយប្រហារត្រូវបានកំណត់ឱ្យទាប៖ ពួកគេប្រើអាសយដ្ឋានអ៊ីមែលដែលអាចចោលបាន និងគណនី GitHubgithub ដែលអាចចោលបាន ដើម្បីបង្កើតកញ្ចប់ព្យាបាទរាប់រយក្នុងយុទ្ធនាការខ្លីៗ ដូចជាការបន្លំ។ សម្រាប់តែកញ្ចប់គោលដៅប៉ុណ្ណោះ ត្រូវការភាពទំនើបខ្ពស់ជាងនេះ៖ យើងបានឃើញសូម្បីតែបង្កើតឃ្លាំងប្រភព GitHub ដែលអាចទុកចិត្តបានជាមួយនឹងផ្កាយជាច្រើន និង commitពីអ្នកចូលរួមក្លែងក្លាយច្រើននាក់ និងរង្វាស់ផ្សេងទៀតនៃប្រជាប្រិយភាព និងការថែទាំ។ កំពុងទទួលបាន អ្នកមើលផ្កាយ និងកេរ្តិ៍ឈ្មោះពីការចូលរួមវិភាគទានក្លែងក្លាយ មិនពិបាកក្នុងការធ្វើស្វ័យប្រវត្តិកម្មទេ។ យើងបានឃើញការរំលោភបំពានលើហេដ្ឋារចនាសម្ព័ន្ធកម្មវិធីបើកចំហគ្រប់ប្រភេទ មិនត្រឹមតែមេរោគប៉ុណ្ណោះទេ ដូចជា ឧប្បត្តិហេតុពិធីសារតែ.

កម្មវិធីគ្រប់គ្រងកញ្ចប់ត្រូវបានរចនាឡើងសម្រាប់ភាពងាយស្រួលនៃការប្រើប្រាស់ មិនមែនសម្រាប់សុវត្ថិភាពទេ។ពួកវាអាចដំណើរការស្គ្រីបមុន និងក្រោយការដំឡើង (ជួនកាលការចងក្រងកូដដើមសម្រាប់បណ្ណាល័យគឺចាំបាច់)។ ម្យ៉ាងទៀត អ្នកគ្រប់គ្រងកញ្ចប់ ដំឡើងកញ្ចប់ពីប្រភពច្រើន ហើយពេលខ្លះលំនាំដើមគឺប្រើការចុះឈ្មោះសាធារណៈ។ ពួកគេមិនបានពិនិត្យមើលភាពមិនស៊ីគ្នារវាងទិន្នន័យមេតានៅក្នុងសំណើបោះពុម្ពផ្សាយ និងទិន្នន័យមេតានៅក្នុងកញ្ចប់ខ្លួនឯងទេ។

ភាពអាស្រ័យត្រូវបានដាក់បញ្ចូលគ្នា ហើយបង្កើតជាក្រាហ្វ។ នៅក្នុងប្រព័ន្ធអេកូឡូស៊ីមួយចំនួនដូចជា Node (JavaScript) ភាពអាស្រ័យតូចៗកកកុញរាប់រយ ឬរាប់ពាន់។ រឿងមួយគឺត្រូវមានការគ្រប់គ្រងយ៉ាងតឹងរ៉ឹងលើការពឹងផ្អែកដោយផ្ទាល់ដែលប្រកាសដោយគម្រោងកម្មវិធីរបស់ខ្ញុំ ប៉ុន្តែ ការពឹងផ្អែកអន្តរកាល ពិបាកគ្រប់គ្រងណាស់។ ប្រភពបើកចំហបានអនុវត្តតាម "មិត្តភក្តិរបស់មិត្តភក្តិរបស់ខ្ញុំគឺជាមិត្តភក្តិរបស់ខ្ញុំ"។ ភាតរភាពគឺជាបទដ្ឋាននៅក្នុងតំបន់ព្រៃឆ្ងាយបូព៌ា! អ្នកគំរាមកំហែងដឹងរឿងនេះ ហើយលាក់បាំងឥរិយាបថព្យាបាទយ៉ាងជ្រៅនៅក្នុងភាពអាស្រ័យមិនច្បាស់លាស់ ដែលជារឿយៗមិនស្គាល់។ នេះជាករណីជាមួយ ស្ទ្រីមព្រឹត្តិការណ៍ ឧប្បត្តិហេតុដែលកំណត់គោលដៅ កាបូប​សម្រាប់​បង់ប្រាក់​តាម​ការ​អនុញ្ញាត

នេះជារបៀបដែលកម្មវិធីប្រភពបើកចំហដំណើរការតាំងពីការចាប់ផ្តើមរបស់វា។ វានឹងមិនមានការផ្លាស់ប្តូរច្រើនទេ។ ការចុះឈ្មោះកញ្ចប់មួយចំនួនទាមទារការផ្ទៀងផ្ទាត់ពីរកត្តាល្អបំផុត ហើយជារឿយៗសម្រាប់តែកញ្ចប់ដែលពេញនិយមបំផុតប៉ុណ្ណោះ។ ការចុះឈ្មោះមួយចំនួនផ្តល់វិសាលភាព ដែលជាលំហឈ្មោះដែលគ្រប់គ្រងដោយអង្គការដែលបានត្រួតពិនិត្យ ប៉ុន្តែ... សោកនាដកម្ម អ្នកផ្សេងទៀតមិនគាំទ្រវាទេ (PyPI) ឬធ្វើឱ្យវាជាជម្រើស (NPM)។  វាគួរឱ្យចាប់អារម្មណ៍ក្នុងការកត់សម្គាល់ថាសូម្បីតែមួយ គ្រោងការណ៍ត្រួតពិនិត្យសាមញ្ញ (ផ្អែកលើការគ្រប់គ្រង DNS ឬឃ្លាំង/អង្គការ GitHub ដែលត្រូវគ្នានឹងលេខសម្គាល់ក្រុម) និងធ្វើឱ្យ ហត្ថលេខា PGP ចាំបាច់ សម្រាប់​វត្ថុបុរាណ​ទាំងអស់​លើកលែងតែ checksums លុប​ចេញ​ភាគច្រើន​នៃ "សំឡេង​រំខាន" ដែល​ជា​កញ្ចប់​ព្យាបាទ​ដែល​ស្រដៀង​នឹង​ការ​វាយអក្សរ ហើយ​កំណត់​ភាគច្រើន​នៃ ភាពច្របូកច្របល់នៃការពឹងផ្អែកការវាយប្រហារដ៏ស្មុគស្មាញអាចធ្វើទៅបាន ប៉ុន្តែពិបាកជាងនេះទៅទៀត ដោយមានតែពីរបីប៉ុណ្ណោះដូចជា com.github.codingandcoding:maven-compiler-plugin ត្រូវបានគេស្គាល់ដោយសារ Maven Central។ ហើយមិនមែនការចុះឈ្មោះ maven ទាំងអស់សុទ្ធតែអនុវត្តតាមការអនុវត្តដូចគ្នានោះទេ!

ការគ្រប់គ្រងសុវត្ថិភាពលើកម្មវិធីគ្រប់គ្រងកញ្ចប់អាចជាបន្ទុក ប៉ុន្តែមិនរារាំងការវាយប្រហារអាស្រ័យនោះទេ។ បញ្ហាជាមួយនឹងការផ្ទៀងផ្ទាត់ពហុកត្តាគឺថា សម្រាប់ស្វ័យប្រវត្តិកម្ម ព័ត៌មានសម្ងាត់ដែលទទួលបានដូចជា ថូខឹនចូលប្រើ ឬកូនសោ APIapi ត្រូវបានបង្កើតសម្រាប់គណនីដែលត្រូវប្រើក្នុងការហៅ APIapi ដែលធ្វើឡើងពីស្គ្រីបស្វ័យប្រវត្តិកម្ម ដោយគ្មានអ្នកប្រើប្រាស់អន្តរកម្មគាំទ្រផ្តល់កត្តាទីពីរ។ MFA គឺល្អសម្រាប់ការពារគណនីអ្នកប្រើប្រាស់ពីការលេចធ្លាយពាក្យសម្ងាត់ ប៉ុន្តែថូខឹនចូលប្រើ ឬកូនសោ APIapi ដែលបានបង្កើតត្រូវការពារនៅពេលសកម្ម ឬម្ចាស់របស់ពួកគេនឹងត្រូវបានក្លែងបន្លំដោយគូប្រជែង។ យុទ្ធនាការខ្សែសង្វាក់ផ្គត់ផ្គង់ដែលមានមូលដ្ឋានលើកញ្ចប់មួយចំនួនធំចាប់ផ្តើមជាមួយនឹងកូនសោ/ថូខឹនដែលលេចធ្លាយ។ គ្រាន់តែចាំថាឧប្បត្តិហេតុដូចជា សៀវភៅធំ, 3CXនិងច្រើនទៀត ដែលព័ត៌មានសម្ងាត់មិនមែនអន្តរកម្មត្រូវបានច្រោះចេញជាលើកដំបូងនៅក្នុងការឈ្លានពានបឋម ដើម្បីចាប់ផ្តើមការវាយប្រហារខ្សែសង្វាក់ផ្គត់ផ្គង់។

ការឆ្លើយតបចំពោះការគំរាមកំហែងនេះមិនរឹងមាំគ្រប់គ្រាន់ទេ។ នៅក្នុងវគ្គទីបី យើងនឹងផ្តោតលើអ្វីដែលដំណើរការ និងអ្វីដែលបរាជ័យយ៉ាងវេទនា។ ឧស្សាហកម្មនេះត្រូវធ្វើការរួមគ្នាលើ standardដំណើរការ ការអប់រំ និងឧបករណ៍ ដើម្បីកាត់បន្ថយហានិភ័យដល់ខ្សែសង្វាក់ផ្គត់ផ្គង់សកល។ នេះមិនមែនជាបញ្ហាដែលអង្គការតែមួយអាចដោះស្រាយដោយខ្លួនឯងបានទេ។

ដើម្បីបញ្ចប់ផ្នែកនេះ ការយល់ច្រឡំដ៏សំខាន់៖ យើងកំពុងនិយាយអំពី ព្យាបាទ កញ្ចប់, មិនមែន ងាយរងគ្រោះ មួយ​ចំនួន។ ភាពងាយរងគ្រោះកើតចេញពីកំហុសក្នុងការរចនា ឬការសរសេរកូដ ដែលត្រូវបានណែនាំដោយចៃដន្យ ដោយគ្មានចេតនាអាក្រក់។ ភាពងាយរងគ្រោះទាំងនោះអាចត្រូវបានកេងប្រវ័ញ្ច ប៉ុន្តែភាគច្រើនមិនមែនទេ។ កញ្ចប់ព្យាបាទតែងតែមានចេតនា ហើយមានភាពងាយរងគ្រោះ 100% ប្រសិនបើវាត្រូវបានប្រតិបត្តិ។ គ្មានហានិភ័យដែលអាចប្រៀបធៀបបានទេ! ដូច្នេះ វា​ជា​រឿង​ផ្ទុយ​ស្រឡះ​ដែល​ឃើញ​ថា​មាន​ការ​ខិតខំ​ប្រឹងប្រែង​ប៉ុន្មាន​ដែល​ត្រូវ​បាន​ដាក់​ចេញ​ដើម្បី​រក​ឃើញ និង​កាត់​បន្ថយ​ភាព​ងាយ​រងគ្រោះ និង​កង្វះ​វិធានការ​សមមូល​សម្រាប់​សមាសធាតុ​ដែល​មាន​គំនិត​អាក្រក់។

«យើងយកចិត្តទុកដាក់យ៉ាងខ្លាំងចំពោះសន្តិសុខ»

កញ្ចប់ព្យាបាទប្រភពបើកចំហ៖ បញ្ហាទី 2

ចូរយើងស្រមៃមើលទម្លាប់ សាជីវកម្មអាគ្រីAcme ដែលជាអ្នកផ្តល់សេវាដ៏សំខាន់សម្រាប់ WileCoyote.com មានកម្មវិធីភាគច្រើនរបស់ខ្លួនមកពីភាគីទីបី ដែលជាង 80% មកពីគម្រោងប្រភពបើកចំហ។ ពួកគេផលិតកម្មវិធីសម្រាប់ការប្រើប្រាស់ផ្ទៃក្នុង ប៉ុន្តែពួកគេក៏ផ្តល់កម្មវិធីសម្រាប់ដៃគូ អ្នកផ្តល់សេវា និងអតិថិជន/អ្នកប្រើប្រាស់ចុងក្រោយរបស់ពួកគេផងដែរ។ Acme មានកម្មវិធីដែលសរសេរជាភាសា Go, JavaScript, Java, C# និង Python ហើយដំណើរការកម្មវិធីភាគច្រើនរបស់ខ្លួននៅលើ cloud ក្រោមចង្កោម Kuberneteskubernetes។ Acme បង្កើតរូបភាពផ្ទាល់ខ្លួនរបស់ខ្លួនពីរូបភាពមូលដ្ឋានដែលយកចេញពី Docker Hub និងបញ្ជីឈ្មោះផ្សេងទៀត។ ហើយពួកគេចែករំលែកបណ្ណាល័យ កញ្ចប់ និងរូបភាពកុងតឺន័រមួយចំនួននៅក្នុងបញ្ជីឈ្មោះសាធារណៈផងដែរ។

ក្រុមហ៊ុន Acme យកចិត្តទុកដាក់យ៉ាងខ្លាំងចំពោះសន្តិសុខ។ ពួកគេដឹងច្បាស់អំពីបញ្ហានៃ open source securityនិងហានិភ័យដែលវាបង្ហាញ។ អ្នកអភិវឌ្ឍន៍ អ្នកគ្រប់គ្រងប្រព័ន្ធ និងវិស្វករ DevOps ទាំងអស់ប្រើកូនសោរគ្រីបតូតូចៗគួរឱ្យស្រលាញ់ទាំងនោះជាការផ្ទៀងផ្ទាត់កត្តាទីពីរ។ ទាំងអស់ commits ទៅកាន់ឃ្លាំងកូដត្រូវបានចុះហត្ថលេខា ការការពារសាខាត្រូវបានបើកជាមួយនឹងការពិនិត្យកូដជាកាតព្វកិច្ច CI/CD ចាក់សោ អាថ៌កំបាំងត្រូវបានរក្សាទុកក្នុងទូសម្ងាត់ និងមានបញ្ជីឈ្មោះខាងក្នុងដែលឆ្លុះបញ្ចាំងដោយផ្នែកនូវបញ្ជីឈ្មោះខាងក្រៅ ដែលមានតែសមាសធាតុដែលត្រូវបានអនុញ្ញាត និងបានចុះបញ្ជីសប៉ុណ្ណោះដែលត្រូវបានរក្សាទុក។ វាតម្រូវឱ្យកម្មវិធីដែលបង្កើតឡើងដោយ Acme ត្រូវតែទទួលយកការពឹងផ្អែករបស់ភាគីទីបីពីបញ្ជីឈ្មោះនេះ។ 

ប្រហែលជាអង្គការភាគច្រើនសមនឹងទម្រង់នេះ។ អ្នកអានជាទីគោរព របស់អ្នកពិតជាសមនឹងអ្នក ប្រសិនបើអ្នកនៅទីនេះ មែនទេ?

បន្ទាប់មកថ្ងៃមួយដ៏អកុសល អ្នកអភិវឌ្ឍន៍ផ្នែកខាងមុខដ៏សំខាន់ម្នាក់ នៅ Acme បានរត់ npm ដំឡើង acme-cute-libដោយភ្លេចថា @acme/cute-lib គឺជាការពឹងផ្អែកដែលមានវិសាលភាពត្រឹមត្រូវ។ កំហុសពិតប្រាកដមិនសំខាន់ទេ មានរឿងជាច្រើនអាចខុស ទោះបីជាមនុស្សម្នាក់សន្មត់ថាគ្រប់គ្រងវដ្តជីវិតកម្មវិធីបានយ៉ាងល្អឥតខ្ចោះក៏ដោយ។ អ្នកអភិវឌ្ឍន៍របស់យើងមិនបានដឹងថាក្រុម APT មួយកំពុងកំណត់គោលដៅ Acme ហើយបានបោះពុម្ពផ្សាយសមាសធាតុព្យាបាទក្រោមឈ្មោះនោះ តាមរបៀបដ៏ប៉ិនប្រសប់ ដូច្នេះឥរិយាបថព្យាបាទធ្វើឱ្យសកម្មតែនៅពេលដែលកម្មវិធីត្រូវបានដំឡើងនៅលើកុំព្យូទ័រ Acme ប៉ុណ្ណោះ។ កញ្ចប់នេះមិនត្រូវបានរកឃើញអស់រយៈពេលជាច្រើនសប្តាហ៍បន្ទាប់ពីការបោះពុម្ពផ្សាយរបស់វា។ 

ស្គ្រីបដំឡើងមួយត្រូវបានដំណើរការដែលស្វែងរកព័ត៌មានសម្ងាត់ (មានថូខឹនចូលប្រើជាច្រើននៅក្នុងកុំព្យូទ័រយួរដៃរបស់អ្នកអភិវឌ្ឍន៍របស់យើង) ដែលអនុញ្ញាតឱ្យចូលប្រើឃ្លាំងកម្មវិធីខាងក្នុង និងឃ្លាំងខាងក្នុងដែលបានរៀបរាប់ខាងលើ ដែលជាការពិតណាស់អាចចូលប្រើបានតែតាមរយៈ VPN ប៉ុណ្ណោះ។ កូដព្យាបាទបានគ្រប់គ្រងដើម្បីប្រើប្រាស់ការតភ្ជាប់ VPN ដែលមានស្រាប់ និងបោះពុម្ពផ្សាយសមាសធាតុព្យាបាទដំណាក់កាលទីពីរទៅក្នុងបញ្ជីឈ្មោះខាងក្នុង ដែលប៉ះពាល់ដល់បណ្ណាល័យឧបករណ៍ប្រើប្រាស់ទូទៅដែលចែករំលែកដោយកម្មវិធីភាគច្រើនដែលផ្តល់ដោយ Acme។

ប៉ុន្មានសប្តាហ៍ក្រោយមក អង្គការផ្សេងទៀតដែលប្រើប្រាស់ឧបករណ៍ដែលបានបោះពុម្ពផ្សាយរបស់ Acme បានចាប់ផ្តើមឃើញចរាចរណ៍ចម្លែកនៅលើបណ្តាញរបស់ពួកគេ ដោយចរាចរណ៍ប្រើប្រាស់ពិធីការរបស់ Acme ប៉ុន្តែត្រូវបានដឹកនាំទៅកាន់ម៉ាស៊ីនដែលស្រដៀងនឹងដែន Acme។ ចរាចរណ៍ត្រូវបានអ៊ិនគ្រីប ប៉ុន្តែឧបករណ៍ត្រួតពិនិត្យប្រព័ន្ធបានរកឃើញការចូលប្រើឯកសារដែលមិននឹកស្មានដល់ និងការប្រតិបត្តិដំណើរការដែលមើលទៅដូចជាពាក្យបញ្ជាប្រព័ន្ធ ប៉ុន្តែបញ្ចប់ដោយដំណើរការឯកសារដែលអាចប្រតិបត្តិបានដែលបានទាញយក។ 

អ្វីដែលនៅសល់គឺជាប្រវត្តិសាស្ត្រ៖ ដំបូងឡើយ Acme បានបដិសេធថា ឥរិយាបថបែបនេះមិនអាចបង្កគ្រោះថ្នាក់ដល់ពួកគេបានទេ ហើយថាវិធានការសន្តិសុខទាំងអស់ត្រូវបានអនុវត្ត។ មានតែបន្ទាប់ពីប្រព័ន្ធផ្សព្វផ្សាយសន្តិសុខតាមអ៊ីនធឺណិតចាប់ផ្តើមសួរថាហេតុអ្វីបានជាប្រភពនៃឥរិយាបថដែលត្រូវបានរកឃើញមានប្រភពមកពីសមាសធាតុរបស់ Acme ហើយការវិភាគសុវត្ថិភាពបានបង្ហោះថាតើសមាសធាតុទាំងនោះពោរពេញទៅដោយមេរោគលួចលាក់យ៉ាងដូចម្តេច Acme ត្រូវទទួលស្គាល់ឧប្បត្តិហេតុនេះ ហើយបានហៅក្រុមហ៊ុនឆ្លើយតបឧប្បត្តិហេតុ។ យុទ្ធនាការទីផ្សារអវិជ្ជមានមួយដែលបានធ្វើឱ្យខូចទំនុកចិត្តដែលរកបានដោយលំបាកក្នុងមួយវិនាទី។Acme គឺគ្រាន់តែដំឡើង npm មួយប៉ុណ្ណោះពី disaster« » គឺជាចំណងជើងទូទៅមួយ។ បន្ទាប់មក បណ្តឹង និងកិច្ចសន្យាដែលត្រូវបានលុបចោលក៏បានកើតឡើងតាមក្រោយ។

តើអ្នកឃើញភាពស្រដៀងគ្នានឹងឧប្បត្តិហេតុដែលគេស្គាល់ពីមុនទេ? Acme បានធ្លាក់ចូលទៅក្នុងឧប្បត្តិហេតុខ្សែសង្វាក់ផ្គត់ផ្គង់ជាពីរដំណាក់កាល ដោយប្រើល្បាយនៃ ការភាន់ច្រឡំនៃការពឹងផ្អែក/ការវាយអក្សរខុស ការវាយប្រហារដែលបានប្រើស្ថានីយការងាររបស់អ្នកអភិវឌ្ឍន៍ជាចំណុចកណ្តាលសម្រាប់ឆ្លងសមាសធាតុដែលបានបញ្ចប់នៅក្នុងកម្មវិធីដែលប្រើដោយភាគីទីបី។ តើបញ្ហានេះអាចត្រូវបានការពារ ឬកាត់បន្ថយដោយរបៀបណា? 

ហេតុអ្វីបានជាកញ្ចប់ពុលមានប្រជាប្រិយភាពខ្លាំងម្ល៉េះ

ឧប្បត្តិហេតុសម្មតិកម្មនេះបង្ហាញថា ទោះបីជាមានវិធីសាស្រ្តសមហេតុផលចំពោះសុវត្ថិភាពប្រភពបើកចំហក៏ដោយ អង្គការនានាត្រូវការវិធានការជាក់លាក់ដើម្បីជៀសវាងការធ្លាក់ជាជនរងគ្រោះនៃមេរោគនៅក្នុងសមាសធាតុប្រភពបើកចំហ។ តាមគ្រោងការណ៍ អ្នកគំរាមកំហែងអាច៖

  • បង្កើតកញ្ចប់ថ្មី (ដោយអនុវត្តតាមវិធីដែលគេស្គាល់យ៉ាងច្បាស់អំពី typosquatting ឬការភាន់ច្រឡំនៃការពឹងផ្អែក នេះគឺជាផ្លូវដែលមនុស្សអាក្រក់ឆ្លងកាត់ច្រើនបំផុត);
  • ព្យាយាមចម្លងមេរោគដែលមានស្រាប់ ទាំងដោយការបញ្ចូលវាទៅក្នុងកូដប្រភព ដោយព្យាយាមក្លែងបន្លំវាជាអ្នករួមចំណែកតាមរយៈ pull requestឬប្រើប្រាស់វិស្វកម្មសង្គមដើម្បីក្លាយជាអ្នកថែទាំ (ដូចដែល “Jao Tan” បានធ្វើនៅក្នុង XZ Backdoor ឬ Ctrl ស្តាំ អ្នកប្រើប្រាស់ GitHub បានធ្វើនៅក្នុង ស្ទ្រីមព្រឹត្តិការណ៍ ឧប្បត្តិហេតុនៅរដូវស្លឹកឈើជ្រុះឆ្នាំ 2018) ឬដោយការទទួលបានលិខិតសម្គាល់ឃ្លាំងទិន្នន័យប្រភពបើកចំហ និងធ្វើពុតជាអ្នកថែទាំ;
  • ចាក់មេរោគកំឡុងពេលបង្កើតកញ្ចប់ ទាំងដោយការដំណើរការស្គ្រីបបង្កើតមេរោគឬជ្រៀតជ្រែកក្នុងការទាញយកកញ្ចប់ជាមួយនឹងការស្ទាក់ចាប់ដោយ man-in-the-middle (ជាសំណាងល្អ TLS ឥឡូវនេះត្រូវបានទាមទារជានិច្ចនៅក្នុងបញ្ជីឈ្មោះភាគច្រើន)។
  • ចាក់សមាសធាតុដែលបានវេចខ្ចប់ដោយផ្ទាល់ទៅក្នុងបញ្ជីឈ្មោះ ជាធម្មតាដោយការចាប់យកព័ត៌មានសម្ងាត់បញ្ជីឈ្មោះ (ជម្រើសដែលពេញចិត្តសម្រាប់ការវាយប្រហារដ៏ស្មុគស្មាញជាច្រើនដូចជា Acme ដែលស្ថានីយការងារដែលរងការសម្របសម្រួលនៅដំណាក់កាលដំបូងមានថូខឹនចូលប្រើបញ្ជីឈ្មោះខាងក្នុង ឧ. នៅក្នុងធម្មតា .NS or ~/.m2/settings.xml: តួអង្គអាក្រក់ពិតជាដឹងពីកន្លែងដែលត្រូវរកមើលអាថ៌កំបាំង)។ ភាពងាយរងគ្រោះនៅក្នុងការចុះឈ្មោះក៏ត្រូវបានគេកេងប្រវ័ញ្ចផងដែរ។ 

ការបំពុលបញ្ជីឈ្មោះជាមួយមេរោគគឺជាមូលដ្ឋានសម្រាប់ការវាយប្រហារដោយពឹងផ្អែក។ គ្មានអ្វីថ្មីនៅក្រោមព្រះអាទិត្យទេ៖ ភាពរីករាលដាលរបស់វាបានផ្ទុះឡើងយ៉ាងខ្លាំង ប៉ុន្តែបច្ចេកទេសដូចគ្នានេះដំណើរការឥឡូវនេះដូចកាលពីប្រាំឆ្នាំមុន។  

កញ្ចប់​ព្យាបាទ​អាច​ដំណើរការ​នៅពេល​ដំឡើង អំឡុងពេល​បង្កើត​កម្មវិធី ឬ​នៅពេល​ដំណើរការ។ ហើយ​ឥរិយាបថ​មាន​ចាប់ពី​ការ​លួច​យក​ព័ត៌មាន ឧទាហរណ៍ ការ​ទាញយក​អាថ៌កំបាំង​សម្រាប់​ការប៉ុនប៉ង​ដំណាក់កាល​ទីពីរ រហូតដល់​ការ​ទាញយក​កូដ​ប្រភព ការ​ទម្លាក់​មេរោគ​បន្ថែម។ នៅក្នុង​វគ្គ​បន្ទាប់ យើង​នឹង​វិភាគ​កញ្ចប់​ព្យាបាទ និង​របៀប​ដែល​ពួកវា​ត្រូវបាន​បោះពុម្ពផ្សាយ។

អានបន្ថែម

វគ្គបន្ទាប់ កាយវិភាគសាស្ត្រនៃកញ្ចប់ព្យាបាទ៖ តើនិន្នាការអ្វីខ្លះ? នឹងផ្តោតលើករណីពិតដែលយើងកំពុងតាមដានជាមួយប្រព័ន្ធព្រមានជាមុនអំពីមេរោគរបស់យើង ជារៀងរាល់ថ្ងៃ។ យើងនឹងពិនិត្យមើលថាតើមេរោគប្រភេទណាដែលត្រូវបានគេឃើញ និងយុទ្ធសាស្ត្រ បច្ចេកទេស និងនីតិវិធីណាដែលពេញនិយម។ យើងនឹងពិនិត្យមើលការបិទបាំង និងរបៀបដែលពួកគេព្យាយាមលាក់ខ្លួនពីអ្នកពិនិត្យដែលមានសក្តានុពល បច្ចេកទេសគេចវេះដើម្បីជៀសវាងការរកឃើញ និងរបៀបដែលពួកគេកំពុងវិវត្តជាមួយនឹងតេឡេម៉ែត្រ និងចលនាចំហៀង។ សូមរង់ចាំតាមដាន! 

ឯកសារយោង

កាយវិភាគសាស្ត្រនៃកញ្ចប់ព្យាបាទ៖ តើនិន្នាការអ្វីខ្លះ?

ការការពារប្រឆាំងនឹងកញ្ចប់ព្យាបាទ OSS៖ អ្វីដែល (មិន) ដំណើរការ

ឧបករណ៍វិភាគសមាសភាពកម្មវិធី sca
ផ្តល់អាទិភាព ដោះស្រាយ និងធានាសុវត្ថិភាពហានិភ័យផ្នែកទន់របស់អ្នក
ទទួលបានគណនីឥតគិតថ្លៃរបស់អ្នក។
មិនតម្រូវឱ្យមានកាតឥណទានទេ។

ធានាសុវត្ថិភាពនៃការអភិវឌ្ឍន៍ និងការដឹកជញ្ជូនកម្មវិធីរបស់អ្នក

ជាមួយឈុតផលិតផល Xygeni