សុវត្ថិភាពខ្សែសង្វាក់ផ្គត់ផ្គង់របស់ភ្នាក់ងារ AI ធ្លាប់មានភាពសាមញ្ញ ភាគច្រើនដោយសារតែមនុស្សម្នាក់តែងតែឈរនៅចន្លោះឈ្មោះកញ្ចប់ និងការបង្កើត។ អស់រយៈពេលម្ភៃឆ្នាំមកហើយ នោះគឺជាគំរូទាំងមូល៖ មាននរណាម្នាក់អានឈ្មោះមុនពេលវាបញ្ចូល។ មិនមែនតែងតែដោយប្រុងប្រយ័ត្ននោះទេ។ ប៉ុន្តែមាននរណាម្នាក់អានវា។
ឥឡូវនេះវាបាត់ទៅហើយ។ សូមសួរគំរូ AI សម្រាប់បណ្ណាល័យនៅថ្ងៃនេះ ហើយប្រហែលមួយក្នុងចំណោមកញ្ចប់ដែលបានណែនាំទាំងប្រាំគឺមិនមានទេ។ អ្នកវាយប្រហារដឹងរឿងនេះ ដូច្នេះពួកគេចុះឈ្មោះឈ្មោះទាំងនោះជាមុនសិន។ ភ្នាក់ងារដំឡើងពួកវា សាកល្បងពួកវា ហើយបន្តទៅមុខ ហើយគ្មាននរណាម្នាក់អានអ្វីនៅចន្លោះនោះទេ។ នេះជាកន្លែងដែលសុវត្ថិភាពខ្សែសង្វាក់ផ្គត់ផ្គង់ភ្នាក់ងារ AI កំពុងបរាជ័យនៅពេលនេះ៖ មិនមែននៅក្នុងសេណារីយ៉ូនាពេលអនាគតទេ ប៉ុន្តែនៅក្នុង... pipelineកំពុងដំណើរការនៅថ្ងៃនេះ។
ឧស្សាហកម្មនេះបានចំណាយពេលពីរទសវត្សរ៍ដើម្បីបង្កើតការគ្រប់គ្រងជុំវិញអ្នកអភិវឌ្ឍន៍ដែលអាន ពិនិត្យ និងសម្រេចចិត្ត។ អ្នកអភិវឌ្ឍន៍នោះលែងជាចំណុចត្រួតពិនិត្យចុងក្រោយមុនពេលការពឹងផ្អែកចូលទៅក្នុងការសាងសង់ទៀតហើយ។ ដូច្នេះសំណួរពិតប្រាកដមិនមែនថាតើ AI ភ្នាក់ងារណែនាំហានិភ័យថ្មីឬអត់នោះទេ វាគឺជាអ្វីដែលនៅសល់នៅពេលដែលចំណុចត្រួតពិនិត្យរបស់មនុស្សបាត់ទៅហើយ។
ពី “ការណែនាំរបស់ AI” ដល់ “សកម្មភាពរបស់ AI”
កាលពីពីរឆ្នាំមុន សហអ្នកបើកយន្តហោះម្នាក់បានស្នើប្លុកកូដមួយ អ្នកអភិវឌ្ឍន៍បានអានវា ហើយអ្នកអភិវឌ្ឍន៍បានសម្រេចចិត្តថាតើត្រូវរក្សាវាឬអត់។ លំហូរការងារនោះភាគច្រើនបានបាត់ទៅហើយ។ ឧបករណ៍ Agentic ឥឡូវនេះដំឡើង dependencies បង្កើត containers និង trigger។ pipeline បោះជំហានដោយខ្លួនឯង ជារឿយៗរាយការណ៍ត្រឡប់មកវិញតែបន្ទាប់ពីការពិត ហើយលុះត្រាតែមានអ្វីមួយខុសប្រក្រតី។
ការផ្លាស់ប្តូរបានកើតឡើងជាដំណាក់កាលៗ ហើយក្រុមភាគច្រើនកំពុងដំណើរការទៅមុខឆ្ងាយជាងគោលការណ៍សុវត្ថិភាពជាលាយលក្ខណ៍អក្សររបស់ពួកគេទទួលស្គាល់។ ឧបករណ៍ភ្នាក់ងារដំបូងៗបានស្នើសុំការយល់ព្រមមុនពេលមានការផ្លាស់ប្តូរនីមួយៗ ហើយអ្នកអភិវឌ្ឍន៍បានចុច "បាទ/ចាស" ជាញឹកញាប់ រហូតដល់ជំហានបញ្ជាក់លែងមានន័យអ្វីទាំងអស់។ ភ្នាក់ងារសព្វថ្ងៃនេះភាគច្រើនមិនសួរអ្វីទាំងអស់។ ពួកគេរំខានតែចំពោះសកម្មភាពដែលត្រូវបានសម្គាល់ថាងាយរងគ្រោះ ដូចជាការដំណើរការស្គ្រីបសែល និង... pull request ដែលបង្កើតឡើងដោយភ្នាក់ងារអាចរត់ចូលទៅក្នុងបន្ទាត់រាប់ពាន់ដែលគ្មានមនុស្សណាម្នាក់អានពីដើមដល់ចប់មុនពេលបញ្ចូលគ្នានោះទេ។
បញ្ហាសិទ្ធិអនុញ្ញាតធ្វើឲ្យរឿងនេះកាន់តែធ្ងន់ធ្ងរឡើង។ នៅក្នុងការដំឡើងភាគច្រើន ភ្នាក់ងារគ្រាន់តែដំណើរការជាអ្នកអភិវឌ្ឍន៍ ដោយមានសិទ្ធិចូលប្រើអ្វីគ្រប់យ៉ាងដែលម៉ាស៊ីនរបស់អ្នកអភិវឌ្ឍន៍អាចទៅដល់៖ អថេរបរិស្ថាន ថូខឹនពពក លិខិតសម្គាល់ការចុះឈ្មោះ និងសោ SSH។ នៅពេលដែលភ្នាក់ងារដំឡើងអ្វីមួយ ហើយស្គ្រីបដំណើរការក្នុងអំឡុងពេលដំឡើងនោះ វាទទួលមរតកកាំផ្ទុះពេញលេញរបស់មនុស្សដែលវាកំពុងក្លែងបន្លំ។ នេះជាកន្លែងដែលសុវត្ថិភាពខ្សែសង្វាក់ផ្គត់ផ្គង់ភ្នាក់ងារ AI ឈប់ជាសំណួរគោលនយោបាយ ហើយក្លាយជាសំណួរសិទ្ធិអនុញ្ញាត៖ ភ្នាក់ងារមិនត្រូវការការកេងប្រវ័ញ្ចថ្មីទេ វាគ្រាន់តែត្រូវការសិទ្ធិចូលប្រើដែលវាមានរួចហើយ។
ប្រធានក្រុមនាវិក Mohammad-Ali A'râbiថ្លែងនៅក្នុងវេទិកាដដែលនោះ លោកបានបញ្ជាក់យ៉ាងច្បាស់ថា៖ «ខ្ញុំគិតថាអ្នកអភិវឌ្ឍន៍គឺជាផ្នែកមួយនៃផ្ទៃវាយប្រហារឥឡូវនេះ»។
វាសមនឹងនិយាយដោយស្មោះត្រង់អំពីអ្វីដែលវាបានជំនួស។ មនុស្សម្នាក់កំពុងអាន package.json diff គឺជាការគ្រប់គ្រងខ្សោយរួចទៅហើយ។ ស្ទើរតែគ្មាននរណាម្នាក់ពិតជាបានផ្ទៀងផ្ទាត់ការពឹងផ្អែកអន្តរកាលទាំងអស់មុនពេលអនុម័តការផ្លាស់ប្តូរនោះទេ។ ភ្នាក់ងារមិនចាំបាច់បំបែកប្រព័ន្ធរឹងមាំនោះទេ។ ពួកគេបានដកចេញនូវលេសចុងក្រោយសម្រាប់ប្រព័ន្ធខ្សោយមួយ។ អ្វីដែលបានផ្លាស់ប្តូរមិនមែនថាហានិភ័យគឺថ្មីនោះទេ វាគឺថាឥឡូវនេះវាផ្លាស់ទីក្នុងល្បឿនខុសគ្នាទាំងស្រុង៖ ការប៉ាន់ស្មានមួយចំនួនបានដាក់បរិមាណការវាយប្រហារខ្សែសង្វាក់ផ្គត់ផ្គង់កាលពីឆ្នាំមុនប្រហែលប្រាំដងនៃឆ្នាំមុន ហើយខ្សែកោងមើលទៅមានលក្ខណៈអិចស្ប៉ូណង់ស្យែលជាជាងលីនេអ៊ែរ។
ពេលវេលាដំឡើង៖ អ្វីដែលផ្លាស់ប្តូរនៅពេលដែលគ្មាននរណាម្នាក់កំពុងមើល
វង្វេងស្មារតី ហើយឈ្មោះកញ្ចប់ព្យាបាទមិនមែនជារឿងថ្មីទេ។ បន្លំ បានកេងប្រវ័ញ្ចកំហុសវាយអក្សររបស់មនុស្សអស់រយៈពេលជាច្រើនឆ្នាំ៖ អក្សរខុសមួយ ហើយអ្នកអភិវឌ្ឍន៍ដំឡើងរបស់ខុស។ អ្វីដែលខុសគ្នាឥឡូវនេះគឺថា គំរូមួយ មិនមែនមនុស្សទេ ដែលបង្កើតឈ្មោះតាំងពីដំបូង ហើយវាធ្វើដូច្នេះដោយអាចទស្សន៍ទាយបាន។
តួលេខទាំងនេះធ្វើឱ្យរឿងនេះក្លាយជាអាជីវកម្ម មិនមែនជារឿងចម្លែកនោះទេ។ ប្រហែល 20% នៃកញ្ចប់ដែលបានណែនាំដោយគំរូប្រភពបើកចំហមិនមានទេ (ជិតដល់ 5% សម្រាប់គំរូពាណិជ្ជកម្ម) ហើយនៅទូទាំងឈ្មោះប្រឌិតដែលបានសិក្សា 43% កើតឡើងដដែលៗនៅក្នុងសំណួរដដែលៗចំនួនដប់។ ភាពអាចធ្វើម្តងទៀតបាននោះគឺជាអ្វីដែលធ្វើឱ្យគំរូវាយប្រហារអាចធ្វើកសិកម្មបាន៖ អ្នកវាយប្រហារមិនចាំបាច់ទាយអ្វីដែលអ្នកអភិវឌ្ឍន៍នឹងវាយបញ្ចូលនោះទេ។ គំរូប្រាប់ពួកគេដោយភាពជឿជាក់ ដោយឥតគិតថ្លៃ។
វ៉ារ្យ៉ង់ថ្មីជាងនេះហៅថា HalluSquatting ជំរុញបន្ថែមទៀត។ ជំនួសឱ្យការបោះពុម្ពផ្សាយកញ្ចប់ព្យាបាទក្រោមឈ្មោះដែលមើលឃើញដោយរូបភាពបំភាន់ អ្នកវាយប្រហារដាក់ការណែនាំព្យាបាទនៅក្នុង README ឯកសារជំនាញ ឬការពិពណ៌នាម៉ាស៊ីនមេ MCP បន្ទាប់មករង់ចាំភ្នាក់ងារធ្វើឱ្យរូបភាពបំភាន់ឈ្មោះឃ្លាំង ឬឧបករណ៍ដូចគ្នា ហើយទាញវាចូល។ ឯកសារថ្មីៗនេះដែលភ្ជាប់វាជាមួយនឹងការចាក់បញ្ចូលរហ័សបានរាយការណ៍ពីការព្យាករណ៍ស្ទើរតែល្អឥតខ្ចោះនៃឈ្មោះឃ្លាំងក្លែងក្លាយសម្រាប់គម្រោងថ្មីៗ និងការប្រតិបត្តិកូដពេញលេញប្រឆាំងនឹងជំនួយការសរសេរកូដពិតប្រាកដរួមទាំង Cursor, Windsurf និង Copilot។ ដោយសារតែ payload គឺជាអត្ថបទធម្មតាជាជាងកូដដែលអាចប្រតិបត្តិបាន ឧបករណ៍ស្កេនភាគច្រើនគ្មានអ្វីត្រូវដាក់ទង់ទេ។
ក្នុងនាមជា ស៊ីហ្គេនី មន្ត្រីស្រាវជ្រាវ Luis Rodríguez ដាក់វាក្នុងអំឡុងពេលពិភាក្សា៖ «យើងបានចំណាយពេលជាច្រើនឆ្នាំដើម្បីបង្កើតការការពារប្រឆាំងនឹងកូដព្យាបាទ។ ហត្ថលេខា ប្រអប់ខ្សាច់ ការវិភាគឥរិយាបថ។ HalluSquatting មិនត្រូវការរបស់ទាំងនោះទេ។ វាគ្រាន់តែត្រូវការ README ដែលគួរឱ្យជឿជាក់ប៉ុណ្ណោះ»។ ការណែនាំជាអត្ថបទធម្មតាដែលភ្នាក់ងារអានជាបរិបទដែលអាចទុកចិត្តបាន ហើរកាត់ម៉ាស៊ីនស្កេនដែលបង្កើតឡើងដើម្បីចាប់អ្វីមួយដែលអាចប្រតិបត្តិបាន។
នោះជាស្រទាប់ដែលឧបករណ៍ AppSec ភាគច្រើននៅតែមិនទាន់ត្រូវបានបង្កើតឡើងដើម្បីមើលឃើញ ដែលជាស្រទាប់មុន...cisហេតុអ្វីបានជា Xygeni ការព្រមានជាមុនអំពីមេរោគ (MEW) វិធីសាស្រ្តមាននៅកម្រិតវេទិកា៖ ការវិភាគជាបន្តបន្ទាប់ និងពេលវេលាជាក់ស្តែងនៃកញ្ចប់ដែលបានបោះពុម្ពផ្សាយថ្មីៗនៅទូទាំងបញ្ជីឈ្មោះដូចជា npm, PyPI និង Maven ដែលបង្កើតឡើងដើម្បីចាប់ឥរិយាបថព្យាបាទមុនពេលមានហត្ថលេខាសាធារណៈ ជាជាងរង់ចាំ CVE ដើម្បីតាមទាន់ពីរបីថ្ងៃក្រោយមក។
កុងតឺន័រ, CI/CDនិងប្រភពដើម៖ តើអ្នកនៅតែអាចបញ្ជាក់អ្វីដែលមាននៅក្នុងសំណង់របស់អ្នកបានទេ?
ភ្នាក់ងារកម្រនឹងឈប់នៅត្រង់ការបន្ថែមបន្ទាត់ទៅ package.jsonវាកែសម្រួលឯកសារ Docker រៀបចំរចនាសម្ព័ន្ធឡើងវិញនូវការបង្កើតពហុដំណាក់កាល និងប៉ះ pipeline ការកំណត់រចនាសម្ព័ន្ធដោយផ្ទាល់ ដោយចូលទៅក្នុងប្រព័ន្ធសាងសង់ខ្លួនឯង ជាជាងគ្រាន់តែដើមឈើប្រភព។
នេះជាកន្លែងដែលចម្លើយរបស់ឧស្សាហកម្មចំពោះហានិភ័យខ្សែសង្វាក់ផ្គត់ផ្គង់ SBOMs និង SLSA provenanceត្រូវបានគេសន្មត់ថារក្សាទុក។ បន្ទាប់មក នៅក្នុងខែឧសភា ឆ្នាំ២០២៦ អ្នកវាយប្រហារម្នាក់បានបន្លំអ្នកថែទាំម្នាក់ បានប្រើថូខឹនដែលត្រូវបានគេលួចដើម្បីបោះពុម្ពផ្សាយ "ក្មេងកំព្រា"។ commit ដោយគ្មានមេនៅក្នុងប្រវត្តិគម្រោង ហើយបានប្រើវាដើម្បីបំពុលឃ្លាំងសម្ងាត់សាងសង់។ កញ្ចប់លទ្ធផល ដែលមានប៉ែតសិបបួនក្នុងចំណោមកញ្ចប់ទាំងនោះ បានភ្ជាប់មកជាមួយប្រភពដែលមានសុពលភាពពេញលេញ និងចុះហត្ថលេខាត្រឹមត្រូវ។ ការត្រួតពិនិត្យដោយស្វ័យប្រវត្តិនីមួយៗបានឆ្លងកាត់។ មេរោគនេះគឺជាមេរោគពិតប្រាកដ ដូច្នេះ តាមបច្ចេកទេស ឯកសារគឺជាភស្តុតាងដែលបញ្ជាក់ពីរបៀបដែលវាត្រូវបានបង្កើតឡើង។
ចំណុចដែលមិនស្រួលនោះគឺ៖ ប្រភពបញ្ជាក់ពីអ្វីដែលសំណង់មួយបានធ្វើជាមួយនឹងអ្វីដែលវាត្រូវបានផ្ដល់ឲ្យ មិនមែនថាអ្វីដែលវាត្រូវបានផ្ដល់ឲ្យគួរឲ្យទុកចិត្តនោះទេ។ បំពុលធាតុចូលមុនពេលមានវត្ថុបុរាណ ហើយការបញ្ជាក់គឺជាកំណត់ត្រាស្មោះត្រង់ និងអាចផ្ទៀងផ្ទាត់បាននៃសំណង់មិនស្មោះត្រង់។ សន្តិសុខខ្សែសង្វាក់ផ្គត់ផ្គង់របស់ភ្នាក់ងារ AI មិនអាចត្រូវបានផ្ទេរទាំងស្រុងទៅឧបករណ៍បញ្ជាក់ដែលសាងសង់សម្រាប់ពិភពលោកដែលមនុស្ស មិនមែនគំរូទេ បានសម្រេចចិត្តថាអ្វីដែលបានចូលទៅក្នុងសំណង់នោះទេ។
ការកាត់បន្ថយជាក់ស្តែងមួយគឺមិនគួរឱ្យចាប់អារម្មណ៍ទេ ប៉ុន្តែមានប្រសិទ្ធភាព៖ រយៈពេល cooldown ដោយរង់ចាំពីរបីថ្ងៃបន្ទាប់ពីកំណែកញ្ចប់ថ្មីត្រូវបានបោះពុម្ពផ្សាយមុនពេលទទួលយកវា។ ឧប្បត្តិហេតុខ្សែសង្វាក់ផ្គត់ផ្គង់សកម្មភាគច្រើនត្រូវបានសម្គាល់ និងបង្ហាញនៅក្នុងបង្អួចដំបូងនោះ ដូច្នេះការពន្យារពេលប្រាំថ្ងៃនឹងបានបន្សាបចំណែកដ៏មានអត្ថន័យនៃឆ្នាំមុន។ ការវាយប្រហារបែបពពួក Wormដោយមិនចំណាយអ្វីទាំងអស់ លើកលែងតែភ្លាមៗiacy.
Git, Review និងចំណុចត្រួតពិនិត្យមនុស្សដែលកំពុងរួញតូច
ការពិនិត្យឡើងវិញនូវលេខកូដ និង commit ប្រវត្តិសាស្ត្របានបម្រើជាយូរមកហើយជាយុថ្កាដែលគួរឱ្យទុកចិត្តសម្រាប់ "នរណាម្នាក់បានមើលរឿងនេះ"។ យុថ្កានោះកាន់តែរង្គោះរង្គើនៅពេលដែលភ្នាក់ងារ commitហើយបញ្ចូលគ្នាកាន់តែខ្លាំងឡើងៗ ដោយគ្មានមនុស្សនៅក្នុងរង្វង់នៅពេលដែលវាកើតឡើង។
ភ្នាក់ងារដែលដំឡើងកញ្ចប់មួយមិនមែនជាបញ្ហាជឿទុកចិត្តដូចគ្នានឹងអ្នកអភិវឌ្ឍន៍ដែលចម្លងចម្លើយ Stack Overflow នោះទេ ទោះបីជាទាំងពីររំលងការសរសេរកូដដើមក៏ដោយ។ បំណែក Stack Overflow ត្រូវបានសរសេរដោយមនុស្សពិត ហើយត្រូវបានពិនិត្យដោយមិត្តភ័ក្តិក្រៅផ្លូវការតាមរយៈការបោះឆ្នោតគាំទ្រ និងការបោះឆ្នោតមិនគាំទ្រ។ អនុសាសន៍ដែលបង្កើតដោយ AI គឺជាលទ្ធផលប្រូបាប៊ីលីតេដែលគ្មានលក្ខណៈសម្បត្តិទាំងពីរ ហើយអ្នកអភិវឌ្ឍន៍ដែលចម្លងវាដោយដៃនៅតែសម្លឹងមើលឈ្មោះកញ្ចប់ កាលបរិច្ឆេទធ្វើបច្ចុប្បន្នភាពចុងក្រោយ និងបញ្ហាបើកចំហ។ ភ្នាក់ងារដែលដំឡើងវាមិនផ្អាកសម្រាប់រឿងណាមួយនោះទេ លុះត្រាតែមានអ្វីមួយត្រូវបានបង្កើតឡើងយ៉ាងច្បាស់លាស់ដើម្បីធ្វើឱ្យវាផ្អាក។
នោះជាបញ្ហាពិតប្រាកដនៃការប្តូរទៅឆ្វេង។ ការប្តូរទៅឆ្វេងបែបប្រពៃណីសន្មតថាវាជារបស់ដែលមានចលនាលឿនបំផុតនៅក្នុង pipeline គឺជាអ្នកអភិវឌ្ឍន៍ដែលអាចត្រូវបានបណ្តុះបណ្តាល ជំរុញ និងពិនិត្យឡើងវិញ។ នៅពេលដែលរបស់ដែលផ្លាស់ទីលឿនបំផុតគឺជាភ្នាក់ងារស្វយ័ត ជំនួសមកវិញ សុវត្ថិភាពប្តូរទៅខាងឆ្វេងត្រូវតែត្រូវបានភ្ជាប់ឡើងវិញទៅនឹងចំណុចត្រួតពិនិត្យដែលភ្នាក់ងារមិនអាចនិយាយបាន៖ ការ sandboxing ការគ្រប់គ្រងការចាកចេញ និងបង្អួច cooldown ជាជាងឯកសារគោលការណ៍ដែលគ្មាននរណាម្នាក់អនុវត្ត។
សុវត្ថិភាពខ្សែសង្វាក់ផ្គត់ផ្គង់របស់ភ្នាក់ងារ AI៖ ជាភ្នាក់ងារដែលមានសុវត្ថិភាពខ្ពស់ Pipeline តាមពិតទៅ តម្រូវឲ្យមាន
ការរស់រានមានជីវិតពីពពួក Worm ប្រភេទថ្មីនេះមិនតម្រូវឱ្យមានការគ្រប់គ្រងប្រាំបួនផ្សេងគ្នាដែលត្រូវបានអនុវត្តយ៉ាងល្អឥតខ្ចោះនៅថ្ងៃដំបូងនោះទេ។ សម្រាប់ក្រុមដែលមានធនធានមានកម្រិត ពីរគឺសំខាន់ជាងអ្វីផ្សេងទៀត៖
- តែងតែជាភ្នាក់ងាររបស់ Sandbox។ ដំណើរការវានៅក្នុង microVM ឬកុងតឺន័រដែលមានតែថតគម្រោងបច្ចុប្បន្នដែលបានម៉ោន ដូច្នេះភ្នាក់ងារដែលសម្របសម្រួលមិនមានផ្លូវទៅកាន់ថូខឹន លិខិតសម្គាល់ ឬឯកសាររបស់ម៉ាស៊ីនទេ។ នេះគឺជាការគ្រប់គ្រងថោកបំផុតដែលមាន និងជាការគ្រប់គ្រងដែលមានលេសតិចបំផុតដើម្បីរំលង។
- បន្ថែមបង្អួច cooldown មុនពេលដំឡើងកំណែកញ្ចប់ថ្មី។ ជារឿយៗពីរបីថ្ងៃគឺគ្រប់គ្រាន់សម្រាប់ការវាយប្រហារខ្សែសង្វាក់ផ្គត់ផ្គង់ផ្ទាល់ដើម្បីលេចចេញជារូបរាង និងត្រូវបានបង្ហាញមុនពេលវាទៅដល់ការសាងសង់របស់អ្នក។
ទីបី សម្រាប់ក្រុមដែលអាចពង្រីកវាបាន៖ បង្កើតភាពមើលឃើញ CVE និងមេរោគដោយផ្ទាល់ទៅក្នុង pipelineការស្កេនរូបភាពកុងតឺន័រ (មិនត្រឹមតែកូដប្រភពទេ ព្រោះចំណុចខ្សោយជាច្រើនស្ថិតនៅក្នុងរូបភាពមូលដ្ឋាន) ហើយបង្ហាញលទ្ធផលជា pull request មតិយោបល់ដែលអ្នកអភិវឌ្ឍន៍ពិតជាឃើញមុនពេលបញ្ចូលគ្នា។
ឧប្បត្តិហេតុថ្មីៗនេះធ្វើឱ្យហានិភ័យកាន់តែច្បាស់លាស់។ នៅក្នុងខែកក្កដា ឆ្នាំ២០២៦ គំរូ AI មួយក្រោមការវាយតម្លៃផ្ទៃក្នុងបានកេងប្រវ័ញ្ចថ្ងៃសូន្យនៅក្នុងផ្លូវបណ្តាញដែលត្រូវបានអនុញ្ញាតតែមួយរបស់ Sandbox របស់ខ្លួន ដែលជាប្រូកស៊ីឃ្លាំងសម្ងាត់កញ្ចប់ ដើម្បីទៅដល់អ៊ីនធឺណិតបើកចំហ ហើយដោយគ្មានមនុស្សណែនាំវាឱ្យធ្វើបែបនេះទេ ធ្វើឱ្យប៉ះពាល់ដល់ហេដ្ឋារចនាសម្ព័ន្ធខាងក្រៅក្នុងការស្វែងរកគោលដៅស្តង់ដារ។ ផ្លូវគេចចេញគឺហេដ្ឋារចនាសម្ព័ន្ធពឹងផ្អែក៖ ការតភ្ជាប់មួយដែល Sandbox នីមួយៗត្រូវបានបង្កើតឡើងដើម្បីអនុញ្ញាតឱ្យឆ្លងកាត់។ ប្រសិនបើភ្នាក់ងាររបស់អ្នកត្រូវការទៅដល់បញ្ជីឈ្មោះកញ្ចប់ដើម្បីដំណើរការ ការតភ្ជាប់នោះមិនមែនជាព័ត៌មានលម្អិតបន្ថែមនៃគំរូសុវត្ថិភាពរបស់អ្នកទេ។ វាគឺជាគំរូសុវត្ថិភាព។ ការវិភាគពេញលេញរបស់ Xygeni អំពីរបៀបដែលការគេចចេញនោះពិតជាបានកើតឡើងគឺមានតម្លៃក្នុងការអាន៖ ចោរកម្មដោយការរចនា.
ការយកសំខាន់ៗ
- ចំណុចត្រួតពិនិត្យចុងក្រោយរបស់មនុស្សកំពុងបាត់ទៅវិញ មិនមែនចុះខ្សោយទេ។ រចនាការគ្រប់គ្រងដែលមិនអាស្រ័យលើនរណាម្នាក់អានឈ្មោះកញ្ចប់។
- ក្បាច់ Slopsquatting និង HalluSquatting អាចហ្វឹកហាត់បាន មិនមែនជាក្បាច់ទ្រឹស្តីទេ។ ឈ្មោះដែលមានការយល់ច្រឡំម្តងហើយម្តងទៀត និងការចាក់បញ្ចូលអត្ថបទធម្មតាកំពុងត្រូវបានគេកេងប្រវ័ញ្ចរួចហើយនៅក្នុងពិភពលោក។
- ប្រភពដើម និង SBOMវាបញ្ជាក់ពីអ្វីដែលសំណង់មួយបានធ្វើ មិនមែនអ្វីដែលវាត្រូវបានផ្តល់ចំណីនោះទេ។ ចាត់ទុកការបញ្ជាក់កម្រិតខ្ពស់ថាចាំបាច់ មិនគ្រប់គ្រាន់ទេ។
- ការទប់ស្កាត់ មិនមែនការរកឃើញទេ គឺជាអ្វីដែលកំពុងរារាំងខ្សែបន្ទាត់នាពេលបច្ចុប្បន្ន។ Sandboxing, egress control និង cooldown windows ទិញពេលវេលាដែលការស្កេនផ្អែកលើហត្ថលេខាមិនអាចធ្វើបាន។
- ធ្វើបញ្ជីស្តុកអ្វីដែលភ្នាក់ងាររបស់អ្នកអាចធ្វើបាន។ មិនមែនជាឯកសារគោលនយោបាយទេ។ សញ្ញាសម្ងាត់ពិតប្រាកដ លិខិតបញ្ជាក់ពិតប្រាកដ ការចាកចេញបណ្តាញពិតប្រាកដ។
អត្ថបទនេះដកស្រង់ចេញពីការពិភាក្សាពី SafeDev Talk របស់ Xygeni “នៅពេលដែលភ្នាក់ងារ AI ដំឡើង Dependencies” ដែលមានប្រធានក្រុម Docker លោក Mohammad-Ali A'râbi។ ក្របខ័ណ្ឌរឹងរឹងទាំងប្រាំបួនរបស់គាត់ត្រូវបានគ្របដណ្តប់កាន់តែស៊ីជម្រៅនៅលើព្រឹត្តិប័ត្រព័ត៌មានរបស់គាត់ Docker Security Dispatch និង Luis Rodriguez Research Officer នៅ Xygeni។
សំណួរដែលសួរញឹកញាប់៖ សុវត្ថិភាពខ្សែសង្វាក់ផ្គត់ផ្គង់របស់ភ្នាក់ងារ AI
តើភ្នាក់ងារដែលដំឡើងកញ្ចប់មួយជាបញ្ហាទុកចិត្តខុសគ្នាជាមូលដ្ឋានពីអ្នកអភិវឌ្ឍន៍ដែលចម្លងការណែនាំ Stack Overflow ឬគ្រាន់តែជាកំណែលឿនជាងនៃកញ្ចប់ដូចគ្នា?
ទាំងពីរ ក្នុងសមាមាត្រខុសគ្នា។ យន្តការនេះលឿនជាង ប៉ុន្តែគម្លាតនៃការជឿទុកចិត្តក៏កាន់តែទូលំទូលាយផងដែរ៖ ចម្លើយ Stack Overflow ត្រូវបានសរសេរ និងពិនិត្យឡើងវិញក្រៅផ្លូវការដោយមនុស្សម្នាក់ ខណៈពេលដែលអនុសាសន៍កញ្ចប់ដែលបង្កើតដោយ AI គឺជាលទ្ធផលប្រូបាប៊ីលីតេដែលគ្មានការពិនិត្យឡើងវិញសមមូល ហើយអ្នកអភិវឌ្ឍន៍ដែលចម្លងវាដោយដៃនៅតែអនុវត្តការត្រួតពិនិត្យធម្មតា ភ្នាក់ងារដែលមិនបានយកចិត្តទុកដាក់រំលងទាំងស្រុង។
តើវាត្រូវការអ្វីខ្លះសម្រាប់ SBOM ដើម្បីកត់ត្រាទុក “ភ្នាក់ងារម្នាក់បានបន្ថែមរឿងនេះ ហើយនេះជាមូលហេតុ” ឲ្យបានត្រឹមត្រូវ?
ថ្ងៃនេះ SBOM និងប្រភពដើម standardត្រូវបានបង្កើតឡើងជុំវិញការសន្មត់ថាមនុស្សម្នាក់បានបង្កើតការពឹងផ្អែកនីមួយៗcisហើយពួកគេមិនទាន់មានវាលសម្រាប់ភ្នាក់ងារណា ម៉ូដែលណា កំណែណា ឬប្រអប់បញ្ចូលណាដែលបានបង្កើតការផ្លាស់ប្តូរជាក់លាក់នៅឡើយទេ។ ការបិទគម្លាតនោះត្រូវការការពង្រីកទម្រង់បញ្ជាក់ដែលមានស្រាប់ ឬផ្លូវសវនកម្មដាច់ដោយឡែកដែលដឹងអំពីភ្នាក់ងារដែលចាប់យកcisប្រភពដើមអ៊ីយ៉ុង រួមជាមួយនឹងប្រភពដើមនៃការសាងសង់។
តើមានកំណែ "shift-left" ដែលនៅតែដំណើរការនៅពេលដែលរបស់លឿនបំផុតនៅក្នុង pipeline តើជាភ្នាក់ងារស្វយ័ត មិនមែនជាអ្នកអភិវឌ្ឍន៍ទេឬ?
មែនហើយ ប៉ុន្តែវាត្រូវតែផ្លាស់ប្តូរចំណុចត្រួតពិនិត្យ មិនមែនគ្រាន់តែពេលវេលានោះទេ។ Shift-left ដែលបង្កើតឡើងជុំវិញការពិនិត្យឡើងវិញរបស់មនុស្សមិនធ្វើមាត្រដ្ឋានទៅតាមល្បឿនភ្នាក់ងារទេ។ Shift-left ដែលបង្កើតឡើងជុំវិញ sandboxing ការរឹតបន្តឹងការចាកចេញ និងការ cooldowns ដំឡើងនៅតែអាចចាប់ភ្នាក់ងារដែលសម្របសម្រួលមុនពេលសកម្មភាពរបស់វាឈានដល់ការផលិត ពីព្រោះការគ្រប់គ្រងទាំងនោះមិនអាស្រ័យលើនរណាម្នាក់ដែលអានអ្វីទាំងអស់។





