ការរួមបញ្ចូលជាបន្តបន្ទាប់ និងការដាក់ពង្រាយជាបន្តបន្ទាប់ (CI/CD) pipelineដើរតួនាទីយ៉ាងសំខាន់ក្នុងការសម្រួលដល់ការអភិវឌ្ឍកម្មវិធីដែលសម្រួល។ យ៉ាងណាក៏ដោយ ដោយសារទាំងនេះ pipelineកាន់តែមានសារៈសំខាន់ខ្លាំងឡើងៗ ភាពចាំបាច់ក្នុងការការពារពួកវាពីភាពងាយរងគ្រោះកាន់តែលេចធ្លោឡើង។ ការស៊ើបអង្កេតស៊ីជម្រៅនេះផ្តោតលើការដោះស្រាយហានិភ័យលេចធ្លោមួយដែលត្រូវបានកំណត់នៅក្នុង OWASP Top-10 CI/CD ហានិភ័យសន្តិសុខ៖ ពុល Pipeline ការប្រតិបត្តិ (PPE)។
អ្វីដែលត្រូវបានបំពុល Pipeline ការប្រតិបត្តិ (PPE)
យោងតាម OWASP Top-10 CI/CD ហានិភ័យសន្តិសុខ, "ពុល Pipeline ការប្រតិបត្តិ (PPE) ហានិភ័យសំដៅទៅលើសមត្ថភាពរបស់អ្នកវាយប្រហារដែលមានសិទ្ធិចូលប្រើប្រព័ន្ធគ្រប់គ្រងប្រភព - និងដោយគ្មានការចូលប្រើបរិស្ថានសាងសង់ - ដើម្បីរៀបចំដំណើរការសាងសង់ដោយចាក់បញ្ចូលកូដ/ពាក្យបញ្ជាព្យាបាទទៅក្នុងការសាងសង់ pipeline ការកំណត់រចនាសម្ព័ន្ធ, សំខាន់ ការបំពុល pipeline និងដំណើរការកូដព្យាបាទជាផ្នែកមួយនៃដំណើរការបង្កើត”
និយាយឲ្យខ្លីទៅ ពុលហើយ Pipeline ការប្រតិបត្តិ (PPE) ត្រូវបានផលិតនៅពេល អ្នកវាយប្រហារអាចកែប្រែ pipeline តក្ក.
មានពីរ វ៉ារ្យ៉ង់:
- សម្ភារៈការពារផ្ទាល់ខ្លួនដោយផ្ទាល់ (សម្ភារៈការពារផ្ទាល់ខ្លួន (D-PPE)នៅក្នុងសេណារីយ៉ូ D-PPE អ្នកវាយប្រហារកែប្រែឯកសារកំណត់រចនាសម្ព័ន្ធ CI នៅក្នុងឃ្លាំងទិន្នន័យ ដែលពួកគេមានសិទ្ធិចូលប្រើ ទាំងដោយការរុញការផ្លាស់ប្តូរដោយផ្ទាល់ទៅកាន់សាខាពីចម្ងាយដែលមិនបានការពារនៅលើ repo ឬដោយការបញ្ជូន PR ជាមួយនឹងការផ្លាស់ប្តូរពីសាខា ឬពី fork។ ចាប់តាំងពី CI pipeline ការប្រតិបត្តិត្រូវបានកំណត់ដោយពាក្យបញ្ជានៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធ CI ដែលបានកែប្រែ ពាក្យបញ្ជាព្យាបាទរបស់អ្នកវាយប្រហារនឹងដំណើរការនៅក្នុងណូតសាងសង់នៅពេលដែលការសាងសង់ pipeline ត្រូវបានកេះ។
- សម្ភារៈការពារផ្ទាល់ខ្លួនដោយប្រយោល (ឧបករណ៍ការពារផ្ទាល់ខ្លួន (I-PPE)ក្នុងករណីខ្លះ លទ្ធភាពនៃ D-PPE មិនមានសម្រាប់សត្រូវដែលអាចចូលប្រើបាន SCM ឃ្លាំងសម្ងាត់ (ឧទាហរណ៍ ប្រសិនបើ pipeline ត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីទាញយកឯកសារកំណត់រចនាសម្ព័ន្ធ CI ពីសាខាដាច់ដោយឡែក និងការពារនៅក្នុងឃ្លាំងដូចគ្នា)។ ក្នុងស្ថានភាពបែបនេះ ជាជាងការបំពុល pipeline ខ្លួនវាផ្ទាល់ អ្នកវាយប្រហារចាក់កូដព្យាបាទចូលទៅក្នុងឯកសារដែលបានយោងដោយ pipeline (ឧទាហរណ៍៖ ស្គ្រីបដែលបានយោងពីក្នុង pipeline ឯកសារកំណត់រចនាសម្ព័ន្ធ)
ក្នុងករណីទាំងពីរនេះ GitHub នឹងប្រតិបត្តិឯកសារដែលបានកែប្រែ pipeline ដោយមិនចាំបាច់មានការពិនិត្យឡើងវិញ ឬការអនុម័តពីមុនមកទេ.
ការរកឃើញដំបូងនៃ PPE
តើយើងអាចរកឃើញភាពងាយរងគ្រោះប្រភេទនេះដោយរបៀបណា?
តោះមើលឧទាហរណ៍នេះ pipeline :
និងខ្លឹមសារនៃស្គ្រីបសែលក្លែងក្លាយ (runtests.sh):
ចំពោះ pipeline គឺសាមញ្ញណាស់៖ គោលបំណងរបស់វាគឺដើម្បីផ្តល់ឱ្យអ្នកពិនិត្យឡើងវិញនូវការណែនាំបឋមមួយចំនួនសម្រាប់ Pull Request ដំណើរការទទួលយក (PR)៖
- វានឹងត្រូវបានបង្កឡើងនៅលើ សំណើ_ទាញ (ឧ. នៅពេលណាដែល PR ត្រូវបានបង្កើតឡើង)
- វាពិនិត្យលេខកូដ PR (ឧ. លេខកូដដែលបានរួមចំណែក)
- វានឹងធ្វើឱ្យការសាងសង់
- វានឹងដំណើរការការធ្វើតេស្តលើកូដដែលបានរួមចំណែក (ឧទាហរណ៍ ដោយការប្រតិបត្តិស្គ្រីបសែល)
ជំហានទី 3 (បង្កើត build) និងជំហានទី 4 (ដំណើរការ test) នឹងបរាជ័យ ប្រសិនបើកូដមិនចងក្រង ឬវាមិនឆ្លងកាត់ការធ្វើតេស្ត។ ដូច្នេះ ជំហានទាំងនេះដើរតួជាលក្ខខណ្ឌចាំបាច់ ប៉ុន្តែមិនគ្រប់គ្រាន់ ដើម្បីទទួលយក PR នោះទេ។ ប្រសិនបើទទួលបានជោគជ័យ អ្នកគ្រប់គ្រង repo នឹងបន្តពិនិត្យមើលកូដដែលបានរួមចំណែក ហើយដោយផ្អែកលើចំណុចនោះ គាត់/នាងនឹងទទួលយក/បដិសេធ/ផ្ដល់យោបល់ PR។
ម៉ាស៊ីនស្កេន Xygeni
ស៊ីហ្គេនី ផ្តល់នូវ CLI ("ម៉ាស៊ីនស្កេន Xygeni) ដែលអាចត្រូវបានបង្កប់ទៅក្នុង pipeline ឬដំណើរការក្នុងបន្ទាត់ពាក្យបញ្ជា។ ម៉ាស៊ីនស្កេន Xygeni នឹងដំណើរការ pipelineដើម្បីពិនិត្យមើលភាពងាយរងគ្រោះ ហើយប្រសិនបើ GitHub PAT ត្រូវបានផ្តល់ជូន វានឹងភ្ជាប់ទៅ GitHub ដើម្បីស្វែងរកភាពងាយរងគ្រោះនៅកម្រិត org/repo។
សារពើភ័ណ្ឌ Xygeni
នៅពេលដែលយើងប្រតិបត្តិ Xygeni Scanner នៅលើ repo នេះ វារកឃើញសំណុំនៃទ្រព្យសកម្មដែលមានប្រយោជន៍ (the សារពើភ័ណ្ឌ Xygeni)។ សារពើភ័ណ្ឌនឹងត្រូវបានបំពេញដោយប្រភេទផ្សេងៗគ្នាជាច្រើន CI/CD ទ្រព្យសកម្ម, ដូចជា:
- ចំពោះ SCM System កន្លែងដែល repo ត្រូវបានរក្សាទុក
- ចំពោះ SCM កម្មវិធីជំនួយ បានដំឡើង/ប្រើប្រាស់
- ចំពោះ ឃ្លាំងកូដ ខ្លួនវា
- ចំពោះ SCM អង្គការ (Organization) កន្លែងដែល repo ជាកម្មសិទ្ធិ
- ចំពោះ CI/CD Pipelines និងការងារ
- ចំពោះ CI/CD System កំពុងរត់ pipelines
- IaC ឯកសារជំនួយ បានកំណត់នៅក្នុង repo
- ខាងក្រៅ ភាពអាស្រ័យ
- ល។
នៅក្នុងឧទាហរណ៍របស់យើង យើងអាចត្រងសារពើភ័ណ្ឌតាមប្រភេទទ្រព្យសកម្មជាក់លាក់មួយចំនួន (SCM- និងទ្រព្យសកម្មទាក់ទងនឹង CICD) ដូច្នេះយើងអាចមើលឃើញថា៖
- SCM ប្រព័ន្ធនេះគឺជា GitHub Cloud
- Repo ត្រូវបានរក្សាទុកនៅក្នុង GitHub Cloud ហើយជាកម្មសិទ្ធិរបស់អង្គការ GitHub ជាក់លាក់មួយ។
- មានពីរ pipelineដំណើរការដោយ GitHub (CI/CD ប្រព័ន្ធ)
- ជារៀងរាល់ pipeline មានជំហានជាក់លាក់មួយ
ដោយជ្រើសរើសខាងលើ pipeline យើងអាចមើលឃើញចំណុចខ្សោយមួយចំនួន៖
- At pipeline កម្រិតវាងាយរងគ្រោះទាំងសងខាង ផ្ទាល់ និង សម្ភារៈការពារផ្ទាល់ខ្លួន (PPE) ដោយប្រយោល។
យើងអាចមើលឃើញព័ត៌មានលម្អិតរបស់អ្នកដែលត្រូវបានបំពុល Pipeline ចំណុចខ្សោយនៃការអនុវត្ត
Xygeni រកឃើញថាវាជា ងាយរងគ្រោះដោយសារ D-PPE ពីព្រោះវាត្រូវបានបង្កឡើងនៅលើ Pull Request ព្រឹត្តិការណ៍ ហើយមិនមានការគ្រប់គ្រងសុវត្ថិភាពបន្ថែមទេ ដូច្នេះអ្នកប្រើប្រាស់ repo ណាមួយអាចកែប្រែ pipeline ហើយការកែប្រែទាំងនោះនឹងត្រូវអនុវត្តដោយមិនចាំបាច់ពិនិត្យ ឬការយល់ព្រមណាមួយឡើយ។
ក្នុងន័យដូចគ្នា Xygeni ក៏រកឃើញថាវា ងាយរងគ្រោះដោយសារ I-PPE ដោយសារតែការហៅទៅកាន់ស្គ្រីបសែលពី pipelineអ្នកប្រើប្រាស់ repo ណាមួយអាចកែប្រែស្គ្រីបសែល ហើយការកែប្រែទាំងនោះនឹងត្រូវបានប្រតិបត្តិដោយមិនចាំបាច់ពិនិត្យ ឬការយល់ព្រមណាមួយឡើយ។
តើអ្នកចង់ដឹងបន្ថែមទេ?
ការកេងប្រវ័ញ្ច PPE
ដើម្បីទាញយកប្រយោជន៍ពីឧបករណ៍ការពារផ្ទាល់ខ្លួន (PPE) ចូរយើងពិចារណាសេណារីយ៉ូមួយដែលមាន អ្នកប្រើប្រាស់ repo ពីរប្រភេទ:
- An អ្នកប្រើប្រាស់ផ្ទៃក្នុង (អ្នកអភិវឌ្ឍន៍ផ្ទៃក្នុងកំពុងធ្វើការលើ repo នោះ) ដោយមានសិទ្ធិសរសេរលើ repo
- An អ្នកប្រើប្រាស់ខាងក្រៅ (អ្នកអភិវឌ្ឍន៍ដែលត្រូវបានផ្តល់ការងារពីខាងក្រៅធ្វើការលើ repo នោះ ប៉ុន្តែមានសិទ្ធិអាននៅលើ repo) ពោលគឺមិនត្រូវបានអនុញ្ញាតឱ្យបំបែក repo និងត្រូវបានបង្ខំឱ្យធ្វើការលើ fork។
ចូរស្រមៃថាទាំងពីរគឺជាអ្នកវាយប្រហារដែលមានគំនិតអាក្រក់ (ឬត្រូវបានក្លែងបន្លំដោយជនល្មើសដែលមានគំនិតអាក្រក់)។ ឃ្លាំងផ្ទុកទិន្នន័យមានអាថ៌កំបាំងមួយចំនួន ហើយទាំងពីរចង់បាន ដើម្បីលួចយកអាថ៌កំបាំងនៃ repo ហើយផ្ញើវាទៅកាន់ម៉ាស៊ីនមេដែលគ្រប់គ្រងដោយពួក Hacker។ ដើម្បីធ្វើវាបាន ពួកគេនឹងទាញយកអត្ថប្រយោជន៍ពី Poisoned Pipeline ចំណុចខ្សោយនៃការអនុវត្ត pipeline.
ក្នុងករណីទាំងពីរ (អ្នកប្រើប្រាស់ខាងក្រៅ និងខាងក្នុង) ពួកគេបើក Pull Request ជាមួយនឹងការកែប្រែដូចគ្នា៖
- ចំពោះ pipeline និងស្គ្រីបសែលត្រូវបានកែប្រែ ទៅ អានអាថ៌កំបាំង ពីបរិស្ថាន និង ផ្ញើវាទៅម៉ាស៊ីនមេដែលគ្រប់គ្រងដោយពួក Hacker
ការកែប្រែអាចមានដូចខាងក្រោម៖
អ្នកប្រើប្រាស់ទាំងពីរនឹងបង្កើត Pull Request ជាមួយនឹងការកែប្រែពេលបង្កើត PR GitHub នឹងអនុវត្តការកែប្រែទាំងពីរ (ដោយមិនចាំបាច់មានការពិនិត្យ ឬការអនុម័តពីមុន)ដែលបណ្តាលឱ្យមានដូចខាងក្រោម៖
ដូចគ្នាសម្រាប់អ្នកប្រើប្រាស់សរសេរ និងអាន ក្នុងករណីទាំងពីរ D-PPE និង I-PPE ត្រូវបានប្រតិបត្តិជាមួយនឹងភាពខុសគ្នានោះ អ្នកប្រើប្រាស់ដែលបានអានមិនអាចចូលប្រើអាថ៌កំបាំងបានទេ។ (!!!!)
ហេតុផលនេះគឺដោយសារតែ, ក្នុងករណី PR មកពី fork នោះ GitHub មិនអនុញ្ញាតឱ្យចូលប្រើអាថ៌កំបាំង repo ទេ។ ទោះបីជាអ្នកប្រើប្រាស់ដែលអានមិនអាចអានអាថ៌កំបាំងបានក៏ដោយ គាត់/នាងនៅតែអាចដំណើរការកម្មវិធីផ្សេងទៀតបាន។ ឧទាហរណ៍នៃការវាយប្រហារធម្មតាគឺការបង្កើត PR ដែលទាញយកកម្មវិធីជីកយករ៉ែគ្រីបតូ ដូច្នេះកម្មវិធី GitHub នឹងប្រតិបត្តិកម្មវិធីជីកយករ៉ែគ្រីបតូនៅពេលប្រតិបត្តិកម្មវិធីដែលត្រូវបានបំពុល។ pipeline.
ជាការពិតណាស់ នេះមិនមែនជាបរិស្ថានដែលមានសុវត្ថិភាពទេ!! តើអ្នកគ្រប់គ្រងឃ្លាំងអាចធ្វើអ្វីខ្លះដើម្បីជៀសវាងវា?
បន្ទាប់ពីស្វែងរកតាម Google មួយចំនួន អ្នកគ្រប់គ្រង repo សម្រេចចិត្តកែប្រែ pipeline ដែលត្រូវបង្កឡើងនៅលើ ទាញ_សំណើ_គោលដៅ ព្រឹត្តិការណ៍។ ហេតុអ្វី? ពីព្រោះ pipelines ត្រូវបានបង្កឡើងនៅលើ pull_request_target មិនអនុញ្ញាតឱ្យប្រតិបត្តិទេ pipeline ការកែប្រែពោលគឺ ទោះបីជាមានការកែប្រែពីអ្នកប្រើប្រាស់ក៏ដោយ “ដើម” pipeline នឹងត្រូវបានប្រតិបត្តិ។
ដោយធ្វើតាមឧទាហរណ៍របស់យើង ការវាយប្រហារនឹងដូចគ្នានឹងមុន។ តើនឹងមានអ្វីកើតឡើងបន្ទាប់ពីនេះ? pipeline ការកែប្រែ?
ដូចរំពឹងទុក, D-PPE មិនត្រូវបានប្រតិបត្តិទេ ប៉ុន្តែ ដោយសារតែ I-PPE នៅតែមាននៅទីនោះ អ្នកប្រើប្រាស់ដែលបានអានឥឡូវនេះអាចចូលប្រើឃ្លាំងសម្ងាត់បានហើយ!!!
តើមូលហេតុអ្វីដែលអ្នកប្រើប្រាស់ដែលបានអានឥឡូវអាចចូលមើលអាថ៌កំបាំងបាន? ទោះបីជា pipeline មិនអាចកែប្រែបានទេ វានៅតែអាចកែប្រែស្គ្រីបសែលបាន។ ពេលណា pipeline ត្រូវបានបង្កឡើងនៅលើ pull_request_target វានឹងត្រូវបានប្រតិបត្តិក្នុងរបៀបពិសេស so វាក៏នឹងជាស្គ្រីបសែលផងដែរដែលធ្វើឱ្យស្គ្រីបសែលមានសិទ្ធិចូលប្រើសម្ងាត់នៃ repo!!
វិធានការបង្ការ
GitHub ផ្តល់នូវវិធានការមួយចំនួនដើម្បីការពារប្រឆាំងនឹង PR ដែលមានគំនិតអាក្រក់។
ច្បាប់ការពារសាខា
ជាមួយ GitHub អ្នកអាចកំណត់ច្បាប់ការពារសាខាលើសាខាដែលបានជ្រើសរើស។
សម្រាប់សាខាដែលអ្នកបានការពារ អ្នកអាចបញ្ជាក់គោលការណ៍មួយដែល តម្រូវឱ្យមានមួយ pull request មុនពេលបញ្ចូលគ្នា (ក៏ដូចជាលក្ខខណ្ឌបន្ថែមដូចជាចំនួននៃការយល់ព្រមដែលត្រូវការ ការពិនិត្យឡើងវិញពីម្ចាស់កូដ។ល។)
លក្ខខណ្ឌមួយចំនួនដែលសមនឹងទទួលបានការពិចារណាជាពិសេសគឺ៖
- "អនុញ្ញាតឱ្យតួអង្គជាក់លាក់រំលងការទាមទារ pull requests"។
- "កុំអនុញ្ញាតឱ្យរំលងការកំណត់ខាងលើ"
ខណៈពេលដែលលក្ខខណ្ឌភាគច្រើនបន្ថែមភាពតឹងរ៉ឹងទៅក្នុងគោលនយោបាយ លក្ខខណ្ឌទាំងនេះបន្ធូរបន្ថយគោលនយោបាយ ហើយនោះអាចនាំឱ្យមានសកម្មភាពព្យាបាទ ឧទាហរណ៍ ក្នុងករណីដែលព័ត៌មានសម្ងាត់ត្រូវបានលួចដោយតួអង្គ "មានឯកសិទ្ធិ"។
ដាក់កម្រិតសិទ្ធិ GITHUB_TOKEN (សិទ្ធិតិចតួចបំផុត)
កំណត់ការអនុញ្ញាតសញ្ញាសម្ងាត់ GitHub ចំពោះការអនុញ្ញាតដែលត្រូវការតែប៉ុណ្ណោះ។ វិធីនេះ សូម្បីតែក្នុងករណីដែលអ្នកវាយប្រហារទទួលបានជោគជ័យក្នុងការធ្វើឱ្យខូចទិន្នន័យរបស់អ្នកក៏ដោយ។ pipelineពួកគេនឹងមិនអាចធ្វើអ្វីបានច្រើនទេ។
ជៀសវាងការបញ្ចូលខ្សែអក្សរដោយប្រើ pipeline អថេរ env
នៅពេលណាដែលអ្នកប្រើអថេរបញ្ចូលមួយចំនួននៅក្នុងរបស់អ្នក pipelineសូមជ្រាបថា ពួកវាគួរតែត្រូវបានចាត់ទុកថាជាទិន្នន័យ "មិនគួរឱ្យទុកចិត្ត" តាមលំនាំដើម (ខ្លឹមសាររបស់ពួកវាត្រូវបានគ្រប់គ្រងដោយអ្នកប្រើប្រាស់ចុងក្រោយ)។ សូមមើល សកម្មភាព និងលំហូរការងារដែលមិនគួរឱ្យទុកចិត្តមានសុវត្ថិភាព និង ស្វែងយល់ពីសកម្មភាព Github។
អ្នកគួរតែប្រើអថេរបរិស្ថានជានិច្ច ដើម្បីបញ្ចូលអថេរបញ្ចូលនៅខាងក្នុងស្គ្រីប ជំនួសឱ្យការប្រើការបញ្ចូលខ្សែអក្សរ។
តម្រូវការអនុម័ត និងដំណើរការការងារ
សម្រាប់ សាធារណៈ repos, GitHub អនុញ្ញាតឱ្យបញ្ជាក់ របៀបធ្វើការជាមួយ PR "ខាងក្រៅ".
ការកំណត់អង្គការ GitHub (“អង្គការ >> ការកំណត់ >> សកម្មភាព >> ទូទៅ”) អនុញ្ញាតឱ្យបញ្ជាក់ពីរបៀបគ្រប់គ្រង PR ខាងក្រៅ៖
តាមលំនាំដើម GitHub នឹងតម្រូវឱ្យមានការយល់ព្រមពី PR សម្រាប់អ្នកចូលរួមលើកដំបូង ដែលធ្វើឱ្យការវាយប្រហារសំណើព្យាបាទកាន់តែស្មុគស្មាញ។ ទោះជាយ៉ាងណាក៏ដោយ អ្នកវាយប្រហារអាចទទួលបានការជឿទុកចិត្តពីអ្នកថែទាំគម្រោង ឧទាហរណ៍ ដោយការរួមចំណែកមួយចំនួនដែលគ្មានកំហុស។ pull request មុនពេលការវាយប្រហារពិតប្រាកដ។
ក្នុងន័យនេះ ជម្រើសទី 3 (តម្រូវឱ្យមានការយល់ព្រមពីអ្នកសហការខាងក្រៅទាំងអស់) បន្ថែមកម្រិតនៃការគ្រប់គ្រងខ្ពស់ជាង។
សម្រាប់ ឯកជន repos, GitHub ក៏ផ្តល់នូវការគ្រប់គ្រងដ៏មានប្រយោជន៍ទាំងនៅកម្រិតអង្គការ និងកម្រិត Repo។
"ដំណើរការលំហូរការងារពី Pull Requests"(មិនត្រូវបានធីកតាមលំនាំដើម) អនុញ្ញាតឱ្យអ្នកប្រើប្រាស់ដំណើរការលំហូរការងារពី fork PRs (ដោយប្រើ GITHUB_TOKEN ដោយមានសិទ្ធិអានតែប៉ុណ្ណោះ និងគ្មានសិទ្ធិចូលប្រើអាថ៌កំបាំង)។ ដោយជ្រើសរើសជម្រើសនេះរួមគ្នាជាមួយជម្រើសចុងក្រោយ ("តម្រូវឱ្យមានការអនុម័តសម្រាប់លំហូរការងារ PR នៃ fork”) អ្នកអាចសម្រេចបាននូវគោលការណ៍ស្រដៀងគ្នាទៅនឹងឃ្លាំងឯកជន (ដូចបានបង្ហាញខាងលើ)។
ដូចដែលយើងបានឃើញនៅក្នុងការកេងប្រវ័ញ្ច PPE ពីអ្នកប្រើប្រាស់ដែលបានអាន អនុញ្ញាតឱ្យដំណើរការលំហូរការងារពី fork pull requests គឺមិនមានសុវត្ថិភាព!!
ជម្រើសដែលនៅសល់ ("ផ្ញើថូខឹនសរសេរទៅកាន់លំហូរការងារពីសមស្រប pull requests"និង"ផ្ញើអាថ៌កំបាំង និងអថេរទៅកាន់លំហូរការងារពី for pull requests") បន្ថយកម្រិតសុវត្ថិភាព បានអនុវត្តចំពោះ PRs fork។
អ្នកអាចកំណត់គោលការណ៍ fork នេះទាំងនៅកម្រិតអង្គការ ឬនៅកម្រិត Repo។ ប្រសិនបើគោលការណ៍នេះត្រូវបានបិទនៅកម្រិតអង្គការ វាមិនអាចបើកដំណើរការនៅកម្រិត repo បានទេ។ ប៉ុន្តែ ប្រសិនបើគោលការណ៍នេះត្រូវបានបើកនៅកម្រិតអង្គការ វាអាចត្រូវបានបិទនៅកម្រិត repo។
Recap ។
យើងសង្ឃឹមថាអ្នកបានឃើញពីផលវិបាកនៃការមានខ្លះ pipeline ងាយរងគ្រោះដោយសារការពុល Pipeline ការប្រតិបត្តិ។ វាងាយស្រួលពេកក្នុងការ commit ងាយរងគ្រោះ pipelineហើយវាពិបាកក្នុងការសរសេរមួយដែលមានសុវត្ថិភាព។
ដូច្នេះវាមានតម្លៃខ្លាំងណាស់ក្នុងការប្រើប្រាស់ Xygeni Scanner ដើម្បីដឹងអំពីភាពងាយរងគ្រោះបែបនេះ។
អ្នកមិនអាចដោះស្រាយកំហុសបានទេ លុះត្រាតែអ្នកដឹងពីអត្ថិភាពរបស់វា!!
ប៉ុន្តែ… នៅតែមានសំណួរមួយដែលមិនទាន់ដោះស្រាយ… តើធ្វើដូចម្តេចដើម្បីជៀសវាង I-PPE?
នេះនឹងជាប្រធានបទនៃការបង្ហោះបន្ទាប់របស់យើង 🙂 … ពុលដោយប្រយោល Pipeline ការប្រតិបត្តិ (I-PPE) !!
