បញ្ហានៅក្នុងប្រយោគមួយ
លើកក្រោយមួយ ជំនួយការ AI ណែនាំកញ្ចប់មួយដើម្បីដំឡើងតើអ្នកពិតជានឹងពិនិត្យមើលថាតើកញ្ចប់នោះមានឬអត់? អ្នកអភិវឌ្ឍន៍ភាគច្រើនមិនទាន់មានទេ។ គម្លាតរវាងការផ្តល់យោបល់ និងការផ្ទៀងផ្ទាត់គឺជាកន្លែងដែលការវាយប្រហារ slopsquatting ចាប់ផ្តើម ហើយវាជាមូលហេតុដែលការយល់ដឹងទាំងការវិវត្តនៃ slopsquatting និងការបង្ការ slopsquatting ជាក់ស្តែងបានក្លាយជាអាទិភាពពិតប្រាកដសម្រាប់ក្រុម AppSec និង DevSecOps។
តើការវាយប្រហារដោយ slopsquatting ជាអ្វី?
ការវាយប្រហារ Slopsquatting គឺជាវ៉ារ្យ៉ង់មួយ ការវាយអក្សរ (ការអនុវត្តការចុះឈ្មោះឈ្មោះដែន ឬកញ្ចប់ដែលធ្វើត្រាប់តាមឈ្មោះស្របច្បាប់តាមរយៈការសរសេរខុសជាទូទៅ ដូចជា តម្រូវការ ជំនួសអោយ សំណើដោយសង្ឃឹមថាកំហុសវាយអក្សរផ្ទាល់ខ្លួនរបស់អ្នកប្រើប្រាស់នឹងបញ្ជូនពួកគេទៅវាដោយផ្ទាល់) ប៉ុន្តែមានភាពខុសគ្នាសំខាន់មួយនៅកន្លែងដែលកំហុសកើតឡើង។ Typosquatting កេងចំណេញពីកំហុសវាយអក្សររបស់មនុស្ស។ ការវាយប្រហារ slopsquatting កេងចំណេញពីកំហុសដែលគំរូភាសាធំៗធ្វើ៖ LLM "បំភាន់" ឈ្មោះកញ្ចប់ដែលស្តាប់ទៅស្របច្បាប់ឥតខ្ចោះ ប៉ុន្តែមិនមាននៅក្នុងបញ្ជីឈ្មោះសាធារណៈណាមួយឡើយ ហើយអ្នកវាយប្រហារទៅដល់ទីនោះមុនគេដោយចុះឈ្មោះឈ្មោះពិតប្រាកដនោះមុនអ្នកដែលមានចេតនាល្អធ្វើ។
យន្តការនៅពីក្រោយការវាយប្រហារ slopsquatting ធម្មតាគឺសាមញ្ញ ហើយភាពសាមញ្ញនោះហើយជាអ្វីដែលធ្វើឱ្យវាមានប្រសិទ្ធភាព៖
- អ្នកអភិវឌ្ឍន៍ម្នាក់សុំឱ្យជំនួយការ AI ជួយដោះស្រាយបញ្ហាសរសេរកូដ។
- គំរូបង្កើតដំណោះស្រាយដែលនាំចូល ឬណែនាំឱ្យដំឡើងកញ្ចប់ដែលមិនធ្លាប់មាន។
- អ្នកវាយប្រហារម្នាក់ដែលបានកត់សម្គាល់ឃើញថាម៉ូដែលជាច្រើនបន្តនិយាយឈ្មោះដដែលៗដដែលៗ បានចុះឈ្មោះកញ្ចប់នោះនៅលើ npm, PyPI ឬបញ្ជីឈ្មោះសាធារណៈផ្សេងទៀត ជាមួយនឹងកូដព្យាបាទនៅខាងក្នុង។ នេះជាពេលដែលការយល់ច្រឡំប្រែទៅជាការវាយប្រហារ slopsquatting ពិតប្រាកដ។
- អ្នកអភិវឌ្ឍន៍បន្ទាប់ដែលទទួលបានការណែនាំដូចគ្នា ហើយមិនបានផ្ទៀងផ្ទាត់វាទេ នឹងដំឡើងកញ្ចប់ដែលឥឡូវនេះជាពិតប្រាកដ ដែលជាទ្វារខាងក្រោយចូលទៅក្នុងបរិស្ថានរបស់ពួកគេ។
ពាក្យថា "slopsquatting" ត្រូវបានបង្កើតឡើងដោយ Seth Larson អ្នកអភិវឌ្ឍន៍សន្តិសុខប្រចាំនៅមូលនិធិ Python Software Foundation និងត្រូវបានផ្សព្វផ្សាយដោយ Andrew Nesbitt ដើម្បីពិពណ៌នាអំពីគំរូនេះយ៉ាងពិតប្រាកដ៖ "ការយល់ច្រឡំកញ្ចប់" បានប្រែក្លាយទៅជាវ៉ិចទ័រវាយប្រហារ។
ការវិវត្តន៍នៃការអង្គុយលើឥដ្ឋ៖ របៀបដែលការចង់ដឹងចង់ឃើញពីការស្រាវជ្រាវបានរីកចម្រើនទៅជាការគំរាមកំហែងពិតប្រាកដ
អ្វីដែលគួរឱ្យកត់សម្គាល់អំពីការវិវត្តន៍នៃ slopsquatting មិនមែនគ្រាន់តែជាគោលគំនិតនោះទេ វាគឺជារបៀបដែលវាបានផ្លាស់ប្តូរយ៉ាងឆាប់រហ័សពីការសង្កេតស្រាវជ្រាវទៅជាថ្នាក់នៃការវាយប្រហារដែលបានកត់ត្រា និងវាស់វែងបាន។
ឆ្នាំ ២០២៣៖ សញ្ញាព្រមានដំបូង។ អ្នកស្រាវជ្រាវសន្តិសុខ Bar Lanyado បានកត់សម្គាល់ឃើញថា LLM ជាច្រើនបានណែនាំម្តងហើយម្តងទៀតនូវកញ្ចប់មួយដែលហៅថា អោបមុខ-cliដែលមិនមាន (កញ្ចប់ពិតប្រាកដត្រូវបានដំឡើងជាមួយ pip ដំឡើង -U “huggingface_hub[cli]”)។ ដើម្បីបង្ហាញពីហានិភ័យ គាត់បានបង្ហោះកំណែទទេនៃកញ្ចប់នោះទៅក្នុងបញ្ជីឈ្មោះសាធារណៈ។ ក្នុងរយៈពេលបីខែ វាទទួលបានការទាញយកជាង 30,000 ដង ដោយគ្មានការផ្សព្វផ្សាយអ្វីទាំងអស់។ ឈ្មោះដែលធ្វើឲ្យមានការយល់ច្រឡំនេះថែមទាំងបានបង្ហាញខ្លួននៅក្នុង README នៃឃ្លាំងទិន្នន័យដែលភ្ជាប់ទៅនឹងការស្រាវជ្រាវពី Alibaba ដែលបង្ហាញពីដំបូងអំពីរបៀបដែលឈ្មោះ "ក្លែងក្លាយ" ទាំងនេះអាចលេចធ្លាយទៅក្នុងឯកសារពិតប្រាកដ និងរៀបចំឆាកសម្រាប់ការវាយប្រហារ slopsquatting ដែលនឹងកើតឡើងបន្ទាប់។
២០២៤: ហានិភ័យបានផ្លាស់ប្តូរពីការបង្ហោះប្លក់របស់អ្នកស្រាវជ្រាវទៅជាការគ្របដណ្តប់លើបច្ចេកវិទ្យាសំខាន់ៗ។ នៅខែមីនា 2024, ចុះឈ្មោះ បានរាយការណ៍អំពីរបៀបដែលគំរូ AI កំពុងបង្កើតឈ្មោះកញ្ចប់កម្មវិធីដោយទំនុកចិត្ត ដែលអ្នកអភិវឌ្ឍន៍កំពុងទាញយក ដែលខ្លះអាចបំពុលដោយមេរោគ។ ការគ្របដណ្តប់នោះមិនសូវសំខាន់ចំពោះអ្វីដែលវាបានបង្ហាញតាមបច្ចេកទេសទេ ប៉ុន្តែសំខាន់ជាងសម្រាប់អ្វីដែលវាបានបង្ហាញ៖ ករណី huggingface-cli លែងជាការចង់ដឹងចង់ឃើញតែម្តងទៀតហើយ។ វាគឺជាសញ្ញាដំបូងនៃគំរូដ៏ធ្ងន់ធ្ងរគ្រប់គ្រាន់សម្រាប់សារព័ត៌មានបច្ចេកវិទ្យាសំខាន់ៗដើម្បីដាក់សញ្ញា មុនពេលការសិក្សាសិក្សាទ្រង់ទ្រាយធំដែលនឹងបញ្ជាក់ពីវិសាលភាពមួយឆ្នាំក្រោយមក។
២០២៥៖ ការវាស់វែងបញ្ហាយ៉ាងម៉ត់ចត់ និងទ្រង់ទ្រាយធំលើកដំបូង។ ឯកសារ “យើងមានកញ្ចប់មួយសម្រាប់អ្នក! ការវិភាគដ៏ទូលំទូលាយនៃការយល់ច្រឡំកញ្ចប់ដោយការបង្កើតលេខកូដ LLMs” (Spracklen et al., ដែលបានបង្ហាញនៅ សន្និសិទសន្តិសុខ USENIX) បានសាកល្បងគំរូបង្កើតកូដចំនួន 16 ទាំងពាណិជ្ជកម្ម (GPT-4, GPT-3.5) និងប្រភពបើកចំហ (CodeLlama, DeepSeek, WizardCoder, Mistral) លើគំរូកូដ Python និង JavaScript ចំនួន 576,000។ ការរកឃើញនេះសម្គាល់ចំណុចច្បាស់លាស់មួយនៅក្នុងការវិវត្តនៃ slopsquatting ដោយផ្លាស់ប្តូរវាពីរឿងខ្លីទៅជាទិន្នន័យ៖
- 19.7% នៃកញ្ចប់ដែលបានណែនាំដោយម៉ូដែលទាំងនោះមិនមានទេ។
- ម៉ូដែលប្រភពបើកចំហមានការយល់ច្រឡំញឹកញាប់ជាង (ជាមធ្យម 21.7%) ជាងម៉ូដែលពាណិជ្ជកម្ម (5.2%)។
- នៅទូទាំងគំរូទាំងអស់ដែលបានសាកល្បង ក្រុមអ្នកស្រាវជ្រាវបានកត់ត្រាឈ្មោះកញ្ចប់ដែលមានលក្ខណៈស្រមើស្រមៃប្លែកៗជាង 205,000 ដែលជាអាងធំល្មមដើម្បីជំរុញការវាយប្រហារដោយចីរភាពនៅទូទាំងប្រព័ន្ធអេកូឡូស៊ីច្រើន។
ព័ត៌មានលម្អិតដ៏សំខាន់មួយពីការសិក្សានេះ និងប្រហែលជាមូលហេតុដែលការវិវត្តនៃ slopsquatting បានបង្កើនល្បឿនជាជាងការរលាយបាត់ទៅ គឺថាឈ្មោះ hallucinated មិនមែនជារឿងចៃដន្យទេ ហើយវាមិនផ្លាស់ប្តូររាល់ការប៉ុនប៉ងនោះទេ។ គំរូដូចគ្នាច្រើនតែនិយាយឈ្មោះដែលបង្កើតឡើងវិញដូចគ្នានៅពេលដែលផ្តល់ការជំរុញស្រដៀងគ្នា ដែលមានន័យថាអ្នកវាយប្រហារមិនចាំបាច់ទាយទេ។ ពួកគេគ្រាន់តែត្រូវសង្កេតមើលឥរិយាបថរបស់គំរូ កំណត់អត្តសញ្ញាណឈ្មោះដែលកើតឡើងដដែលៗ និងចុះឈ្មោះវាមុនពេលអ្នកអភិវឌ្ឍន៍ពិតប្រាកដធ្វើ។ ការវិភាគតាមដាននៃភាពអាចធ្វើម្តងទៀតនេះបានរកឃើញថា នៅពេលដែលអ្នកស្រាវជ្រាវដំណើរការការជំរុញដូចគ្នាឡើងវិញដប់ដងក្នុងមួយៗ 43% នៃឈ្មោះកញ្ចប់ hallucinated បានបង្ហាញខ្លួននៅលើការរត់នីមួយៗ ដែលជាភស្តុតាងដែលថា hallucinations ភាគច្រើនគឺជាវត្ថុបុរាណដែលអាចធ្វើម្តងទៀតបានជាជាងសំឡេងរំខានម្តងម្កាល។ ភាពអាចធ្វើម្តងទៀតនោះគឺជាអ្វីដែលប្រែក្លាយ hallucination ម្តងម្កាលទៅជាការវាយប្រហារ slopsquatting ដែលអាចធ្វើមាត្រដ្ឋានបាន។
២០២៦: ពីកញ្ចប់ដាច់ដោយឡែកទៅជាភ្នាក់ងារស្វយ័ត។ ពីកញ្ចប់ដាច់ដោយឡែករហូតដល់ភ្នាក់ងារស្វយ័ត។ ឆ្នាំនេះបានបង្ហាញភស្តុតាងច្បាស់លាស់បំផុតដែលបង្ហាញថា slopsquatting លែងត្រូវបានកំណត់ចំពោះការចម្លងរបស់អ្នកអភិវឌ្ឍន៍ដែលបិទភ្ជាប់ពាក្យបញ្ជាដំឡើង pip ឬ npm ដែលបានស្នើឡើងទៀតហើយ។ នៅក្នុងខែមករា ឆ្នាំ២០២៦ អ្នកស្រាវជ្រាវសន្តិសុខ Charlie Eriksen បានរកឃើញថាភ្នាក់ងារសរសេរកូដ AI បានផ្សព្វផ្សាយការណែនាំរួចហើយដោយយោងទៅលើកញ្ចប់ npm ដែលមានការយល់ច្រឡំ គឺ react-codeshift (ឈ្មោះដែលរួមបញ្ចូលគ្នានូវឧបករណ៍ពិតពីរគឺ jscodeshift និង react-codemod) នៅទូទាំងឃ្លាំងចំនួន ២៣៧ ដោយភ្នាក់ងារនៅតែព្យាយាមដំឡើងវាជារៀងរាល់ថ្ងៃ។ Eriksen បានចុះឈ្មោះឈ្មោះដោយខ្លួនឯង ដើម្បីការពារ មុនពេលអ្នកវាយប្រហារអាចប្រើប្រាស់វាជាអាវុធ។ ដោយឡែកពីគ្នា កញ្ចប់ព្យាបាទពិតប្រាកដមួយដែលមានឈ្មោះថា unused-imports ដែលមានការយល់ច្រឡំជំនួសឲ្យ eslint-plugin-unused-imports ស្របច្បាប់ នៅតែកត់ត្រាការទាញយកប្រហែល ២៣៣ ដងក្នុងមួយសប្តាហ៍នៅដើមឆ្នាំ២០២៦ ទោះបីជា npm ដាក់វានៅក្រោមការរក្សាទុកសុវត្ថិភាពក៏ដោយ ដែលជាសញ្ញានៃរយៈពេលដែលការវាយប្រហារ slopsquatting អាចទាក់ទាញជនរងគ្រោះបានសូម្បីតែបន្ទាប់ពីវាត្រូវបានសម្គាល់ក៏ដោយ។ ថ្មីៗនេះ នៅក្នុងខែកក្កដា ឆ្នាំ២០២៦ អ្នកស្រាវជ្រាវបានពិពណ៌នាអំពីបច្ចេកទេសពាក់ព័ន្ធមួយ ដែលមានឈ្មោះថា "HalluSquatting" ដែលភ្ជាប់ការយល់ច្រឡំ AI ជាមួយនឹងការចាក់បញ្ចូលរហ័ស ដើម្បីឱ្យភ្នាក់ងារសរសេរកូដ AI ដែលទាញយកធនធានដែលមានការយល់ច្រឡំក្នុងនាមអ្នកប្រើប្រាស់អាចត្រូវបានលួចចូលទៅក្នុងការដំណើរការកូដដែលផ្គត់ផ្គង់ដោយអ្នកវាយប្រហារ ដែលពង្រីកការវិវត្តនៃ slopsquatting ពីហានិភ័យនៃការដំឡើងអកម្មទៅជាវ៉ិចទ័រប្រតិបត្តិកូដពីចម្ងាយសកម្មនៅក្នុងលំហូរការងារអភិវឌ្ឍន៍ភ្នាក់ងារ។
ហេតុអ្វីបានជា "vibe coding" បានពង្រីកផ្ទៃសម្រាប់ការវាយប្រហារ slopsquatting
ការវាយប្រហារ Slopsquatting នឹងមិនមានបញ្ហាច្រើនទេ ប្រសិនបើកូដដែលបង្កើតដោយ AI គឺជាការអនុវត្តពិសេស។ វាមិនមែនទេ។ ការកើនឡើងនៃជំនួយការសរសេរកូដ ភ្នាក់ងារស្វ័យប្រវត្តិ និងលំហូរការងារ "vibe coding" ដែលអ្នកអភិវឌ្ឍន៍ពិនិត្យកូដតិចទៅៗ មុនពេលដំណើរការវា បានផ្លាស់ប្តូរផ្ទៃវាយប្រហារកម្មវិធីតាមវិធីជាក់ស្តែងពីរយ៉ាង ហើយទាំងពីរកំពុងបង្កើនល្បឿនការវិវត្តនៃ slopsquatting៖
- ចំណុចចូលលែងគ្រាន់តែជាអ្នកអភិវឌ្ឍន៍ទៀតហើយ។ ការវាយប្រហារដោយ typosquatting ធ្លាប់ពឹងផ្អែកលើមនុស្សម្នាក់ដែលធ្វើកំហុសវាយអក្សរ។ ឥឡូវនេះ កំហុសអាចកើតចេញពីគំរូខ្លួនឯង ហើយរីករាលដាលដល់អ្នកអភិវឌ្ឍន៍រាប់រយនាក់ផ្សេងៗគ្នា ដែលសួរសំណួរស្រដៀងគ្នា និងទទួលបានអនុសាសន៍ដូចគ្នា ដែលបង្កើនវិសាលភាពនៃការវាយប្រហារ slopsquatting តែមួយ។
- ផ្ទៃវាយប្រហារបានរំកិលទៅមុខទៀតតាមខ្សែសង្វាក់។ វាលែងគ្រប់គ្រាន់ទៀតហើយក្នុងការមើលកូដដែលមនុស្សសរសេរ។ ក្រុមក៏ត្រូវមើលការពឹងផ្អែកដែលជំនួយការ AI ណែនាំ ម៉ាស៊ីនមេ MCP ដែលវាភ្ជាប់ទៅ និងភ្នាក់ងារដែលដំឡើងកញ្ចប់ដោយស្វ័យភាពដោយគ្មានការពិនិត្យដោយផ្ទាល់ពីមនុស្ស។ AppSec បែបប្រពៃណី បង្កើតឡើងដើម្បីពិនិត្យមើលឃ្លាំង និង... commits មិនត្រូវបានរចនាឡើងដើម្បីសង្កេតមើលអន្តរកម្មថ្មីនេះរវាងអ្នកអភិវឌ្ឍន៍ បញ្ញាសិប្បនិម្មិត និងបញ្ជីឈ្មោះកញ្ចប់នោះទេ ដែលជាកន្លែងដែលការវាយប្រហារ slopsquatting ឥឡូវនេះលាក់ខ្លួន។
គ្មានអ្វីទាំងនេះមានន័យថា បញ្ញាសិប្បនិម្មិតដែលបង្កើតឡើងដោយធម្មជាតិមិនមានសុវត្ថិភាពនោះទេ។ វាមានន័យថា វាណែនាំហានិភ័យខ្សែសង្វាក់ផ្គត់ផ្គង់ប្រភេទថ្មី ដែលឧបករណ៍សុវត្ថិភាពបែបប្រពៃណីមិនត្រូវបានបង្កើតឡើងដើម្បីចាប់ ហើយវាទាមទារគោលការណ៍ផ្ទៀងផ្ទាត់ដូចគ្នាដែលយើងអនុវត្តរួចហើយចំពោះការពឹងផ្អែកខាងក្រៅណាមួយ៖ កុំទុកចិត្តតាមលំនាំដើម ផ្ទៀងផ្ទាត់ប្រភព និងធ្វើស្វ័យប្រវត្តិកម្មការផ្ទៀងផ្ទាត់នោះ ជំនួសឱ្យការពឹងផ្អែកលើការចងចាំ ឬការប្រុងប្រយ័ត្នរបស់អ្នកអភិវឌ្ឍន៍គ្រប់រូប។ ស្វ័យប្រវត្តិកម្មនោះគឺជាមូលដ្ឋានគ្រឹះនៃយុទ្ធសាស្ត្របង្ការការរអិលបាក់ដីពិតប្រាកដណាមួយ។
ការបង្ការការអង្គុយលើឥដ្ឋ៖ អ្វីដែលក្រុមអាចធ្វើបាននៅថ្ងៃនេះ
ដំណឹងល្អគឺថា ការបង្ការការរអិលដួលមិនតម្រូវឱ្យមានឧបករណ៍កម្រនិងអសកម្មទេ។ វាតម្រូវឱ្យមានការអនុវត្តអនាម័យអាស្រ័យដែលមានរួចហើយជាប្រព័ន្ធ ប៉ុន្តែក្រុមជាច្រើនត្រូវសម្រាកនៅពេលដែល AI ដែលពួកគេទុកចិត្ត "ណែនាំ" កូដ។ វិធីសាស្រ្តបង្ការការរអិលដួលដែលមានប្រសិទ្ធភាពជាធម្មតារួមបញ្ចូលគ្នានូវចំណុចខាងក្រោម៖
- ផ្ទៀងផ្ទាត់កញ្ចប់ថ្មីណាមួយដោយដៃមុនពេលដំឡើងវាជាពិសេសនៅពេលដែលវាមកពីការណែនាំរបស់ជំនួយការ AI។ សូមបញ្ជាក់ថាវាមាននៅក្នុងបញ្ជីឈ្មោះផ្លូវការ អ្នកណាជាអ្នកថែរក្សាវា ពេលណាដែលវាត្រូវបានបោះពុម្ពផ្សាយ និងថាតើចំនួនទាញយករបស់វាមើលទៅពិតប្រាកដឬអត់។ ទម្លាប់តែមួយនេះគឺជាទម្រង់នៃការបង្ការការរអិលដែលថោកបំផុតដែលមានសម្រាប់ក្រុមណាមួយ។
- កុំសន្មតថាកូដដែលបង្កើតដោយ AI មានសុវត្ថិភាពតាមលំនាំដើម។ កូដខ្លីៗដែល "ដំណើរការ" មិនមានន័យថា dependency របស់វាស្របច្បាប់នោះទេ។ ការពិនិត្យឡើងវិញនូវ Dependency គួរតែជាផ្នែកមួយនៃការពិនិត្យឡើងវិញនូវកូដ មិនមែនជាករណីលើកលែងចំពោះវានោះទេ។
- ប្រើ lockfiles និងការផ្ទៀងផ្ទាត់ hash ដើម្បីដាក់កូដកំណែពិតប្រាកដ និងបញ្ឈប់ការធ្វើបច្ចុប្បន្នភាពស្ងាត់ៗពីការប្តូរទៅជាកញ្ចប់ផ្សេងពីកញ្ចប់ដែលត្រូវបានធ្វើសវនកម្មដំបូង។
- ដាក់ពង្រាយការស្កេនភាពអាស្រ័យដែលសម្គាល់គំរូហានិភ័យលើសពី CVE ដែលគេស្គាល់កញ្ចប់មិនប្រក្រតី ឈ្មោះស្រដៀងគ្នាគួរឱ្យសង្ស័យទៅនឹងកញ្ចប់ដែលមានស្រាប់ អ្នកថែទាំថ្មីដែលគ្មានកំណត់ត្រា ឬដំឡើងស្គ្រីបដែលមានឥរិយាបថមិនធម្មតា។ កញ្ចប់ដែលទើបបោះពុម្ពផ្សាយថ្មីដែលស្ទើរតែគ្មានប្រវត្តិដែលធ្វើត្រាប់តាមឈ្មោះរបស់អ្វីមួយដែល "ស្ទើរតែ" ស៊ាំគឺជាគំរូពិតប្រាកដនៅពីក្រោយការវាយប្រហារ slopsquatting ភាគច្រើនដែលបានកត់ត្រារហូតមកដល់ពេលនេះ។
- ប្រព្រឹត្តចំពោះបញ្ជីឈ្មោះសាធារណៈដោយមានការសង្ស័យដូចគ្នាcism ដូចប្រភពខាងក្រៅដែលមិនទាន់បានផ្ទៀងផ្ទាត់ផ្សេងទៀតដែរ។ ការពិតដែលថា ដំឡើង pip or ល្ងាចដំឡើង ការមិនបង្ហាញកំហុសមិនមែនជាភស្តុតាងនៃភាពស្របច្បាប់ទេ។
- ក្រុមអភិវឌ្ឍន៍រថភ្លើង លើការពិតដែលថាការសរសេរកូដដែលមានជំនួយពី AI មិនលុបបំបាត់ការទទួលខុសត្រូវក្នុងការផ្ទៀងផ្ទាត់អ្វីដែលត្រូវបានដំឡើងនោះទេ; វាគ្រាន់តែបន្ថែមជំហានមួយដែលត្រូវបង្កើតឡើងនៅក្នុងលំហូរការងារជាផ្នែកមួយនៃផែនការបង្ការការរអិល។
វិធានការទាំងនេះមិនមែនជាវិធានការថ្មីដោយខ្លួនឯងទេ។ អ្វីដែលបានផ្លាស់ប្តូរគឺមាត្រដ្ឋាន៖ នៅពេលដែលការណែនាំអំពីការពឹងផ្អែកលែងមកពី Stack Overflow ឬមិត្តរួមការងារ ប៉ុន្តែមកពីគំរូដែលអាចធ្វើកំហុសដដែលៗដដែលៗដល់អ្នកអភិវឌ្ឍន៍រាប់ពាន់នាក់ផ្សេងៗគ្នា ការផ្ទៀងផ្ទាត់ដោយដៃ ខណៈពេលដែលនៅតែចាំបាច់ លែងគ្រប់គ្រាន់ដោយខ្លួនឯងទៀតហើយ។ នោះហើយជាមូលហេតុដែលក្រុមកាន់តែច្រើនកំពុងធ្វើស្វ័យប្រវត្តិកម្មស្រទាប់នៃការបង្ការ slopsquatting នេះនៅក្នុង... ការវិភាគសមាសភាពកម្មវិធី (SCA) ឧបករណ៍ជាជាងទុកវាឱ្យស្ថិតក្រោមវិន័យរបស់អ្នកអភិវឌ្ឍន៍ម្នាក់ៗ។
នេះជាមុនcisអេលី ហេតុអ្វី ASPM វេទិកា ដូច ស៊ីហ្គេនី បង្កើតការរកឃើញការពឹងផ្អែកគួរឱ្យសង្ស័យ ដែលគ្របដណ្តប់លើកំហុសវាយអក្សរ ការភាន់ច្រឡំនៃការពឹងផ្អែក និងកញ្ចប់ព្យាបាទដែលគេស្គាល់ ទៅក្នុងការវិភាគប្រភពបើកចំហ និង AI-dependency ដូចគ្នា។ pipelineដូច្នេះការបង្ការការរអិលមិនអាស្រ័យលើអ្នកអភិវឌ្ឍន៍គ្រប់រូបដែលចងចាំពិនិត្យមើលវារាល់ពេលដែលជំនួយការ AI ណែនាំការពឹងផ្អែកថ្មីនោះទេ។
សំណួរដែលត្រូវបានសួរជាញឹកញាប់
តើការវាយប្រហារដោយ slopsquatting ដូចគ្នានឹងការវាយប្រហារដោយ typosquatting ដែរឬទេ?
មិនមែនទាំងស្រុងទេ។ ទាំងពីរពាក់ព័ន្ធនឹងការចុះឈ្មោះឈ្មោះកញ្ចប់ក្លែងក្លាយដើម្បីបញ្ឆោតអ្នកណាដែលដំឡើងវា ប៉ុន្តែប្រភពនៃកំហុសគឺខុសគ្នា។ Typosquatting កេងប្រវ័ញ្ចកំហុសវាយអក្សររបស់មនុស្ស។ ការវាយប្រហារ slopsquatting កេងប្រវ័ញ្ចឈ្មោះកញ្ចប់ដែលបង្កើតឡើងដោយគំរូ AI (ដែលធ្វើឲ្យមានការយល់ច្រឡំ) ដែលអ្នកវាយប្រហារបន្ទាប់មកចុះឈ្មោះមុនពេលវាមានសុពលភាពស្របច្បាប់។
តើកម្មវិធីគ្រប់គ្រងកញ្ចប់អាចការពារការវាយប្រហារប្រភេទនេះដោយស្វ័យប្រវត្តិបានទេ?
មិនមែនទាំងស្រុងទេ ដែលជាមូលហេតុដែលការបង្ការការលួចចូលប្រព័ន្ធ (slopsquatting) មិនអាចបញ្ឈប់នៅកម្រិតអ្នកគ្រប់គ្រងកញ្ចប់បានទេ។ ប្រសិនបើអ្នកវាយប្រហារចុះឈ្មោះកញ្ចប់ដែលមានការយល់ច្រឡំមុនពេលអ្នកអភិវឌ្ឍន៍ព្យាយាមដំឡើងវា ការដំឡើងនឹងបញ្ចប់ដោយគ្មានកំហុសណាមួយឡើយ ពីព្រោះកញ្ចប់នោះពិតជាមានមែន ទោះបីជាវាមានគ្រោះថ្នាក់ក៏ដោយ។ ការបង្ការប្រកបដោយប្រសិទ្ធភាពត្រូវការការផ្ទៀងផ្ទាត់បន្ថែមអំពីប្រភពដើម និងឥរិយាបថរបស់កញ្ចប់។
តើនេះប៉ះពាល់តែលើម៉ូដែលប្រភពបើកចំហរទេ?
ទេ។ ការសិក្សារបស់ Spracklen និងក្រុមការងារបានរកឃើញការយល់ច្រឡំនៅទូទាំងម៉ូដែលទាំងអស់ដែលបានសាកល្បង រួមទាំងម៉ូដែលពាណិជ្ជកម្មផងដែរ ទោះបីជាក្នុងអត្រាទាបជាងច្រើនក៏ដោយ (5.2% ធៀបនឹង 21.7% សម្រាប់ម៉ូដែលប្រភពបើកចំហដែលបានវាយតម្លៃ)។ គ្មានម៉ូដែលណាមួយរួចផុតពីបញ្ហានេះទាំងស្រុងនោះទេ ដែលជាផ្នែកមួយនៃមូលហេតុដែលការវិវត្តនៃ slopsquatting រក្សាល្បឿនជាមួយនឹងការរីកចម្រើននៃការសរសេរកូដដែលមានជំនួយពី AI ជារួម។
តើនេះជាហានិភ័យទ្រឹស្តីឬវាត្រូវបានគេកេងប្រវ័ញ្ចរួចហើយ?
ចំពោះ អោបមុខ-cli case ដែលជាកញ្ចប់ទទេមួយដែលបានផ្ទុកឡើងដោយអ្នកស្រាវជ្រាវម្នាក់ ដែលត្រូវបានទាញយកច្រើនជាង 30,000 ដងក្នុងរយៈពេលបីខែដោយគ្មានការផ្សព្វផ្សាយ បង្ហាញថាហានិភ័យមិនមែនគ្រាន់តែជាទ្រឹស្តីនោះទេ៖ ឈ្មោះដែលមានការយល់ច្រឡំគ្រាន់តែត្រូវមានភាពស៊ីសង្វាក់គ្នាគ្រប់គ្រាន់នៅទូទាំងការជំរុញផ្សេងៗគ្នាសម្រាប់នរណាម្នាក់ដើម្បីប្រែក្លាយវាទៅជាការវាយប្រហារ slopsquatting ពិតប្រាកដ។
