នៅពេលដែលភ្នាក់ងារ AI ដំឡើង Dependencies

សុវត្ថិភាពខ្សែសង្វាក់ផ្គត់ផ្គង់របស់ភ្នាក់ងារ AI៖ អ្វីដែលបញ្ឈប់ការពឹងផ្អែកមិនល្អនៅពេលដែលភ្នាក់ងារ AI ដំឡើងវា

​មាតិកា

ប្រកាសដែលត្រូវតែអាន

ប្រកាសថ្មីៗបំផុតដែលគួរឱ្យចាប់អារម្មណ៍

សុវត្ថិភាពខ្សែសង្វាក់ផ្គត់ផ្គង់របស់ភ្នាក់ងារ 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 ដំឡើងនៅតែអាចចាប់ភ្នាក់ងារដែលសម្របសម្រួលមុនពេលសកម្មភាពរបស់វាឈានដល់ការផលិត ពីព្រោះការគ្រប់គ្រងទាំងនោះមិនអាស្រ័យលើនរណាម្នាក់ដែលអានអ្វីទាំងអស់។

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

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

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