തുടർച്ചയായ സംയോജനവും തുടർച്ചയായ വിന്യാസവും (CI/CD) pipelineകാര്യക്ഷമമായ സോഫ്റ്റ്വെയർ വികസനം സാധ്യമാക്കുന്നതിൽ s ഒരു നിർണായക പങ്ക് വഹിക്കുന്നു. എന്നിരുന്നാലും, ഇവ പോലെ pipelineകൂടുതൽ നിർണായകമാകുന്നതോടെ, അവയെ ദുർബലതകളിൽ നിന്ന് സംരക്ഷിക്കേണ്ടതിന്റെ ആവശ്യകത കൂടുതൽ വ്യക്തമാകുന്നു. OWASP ടോപ്പ്-10 ൽ തിരിച്ചറിഞ്ഞിട്ടുള്ള ഒരു പ്രധാന അപകടസാധ്യതയെ അഭിസംബോധന ചെയ്യുന്നതിൽ ഈ ആഴത്തിലുള്ള അന്വേഷണം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു. CI/CD സുരക്ഷാ അപകടസാധ്യതകൾ: വിഷബാധയേറ്റത് Pipeline വധശിക്ഷ (പിപിഇ).
എന്താണ് വിഷം കലർന്നത്? Pipeline വധശിക്ഷ (PPE)
OWASP ടോപ്പ്-10 പ്രകാരം CI/CD സുരക്ഷാ അപകടസാധ്യതകൾ, "വിഷം കൊടുത്തു Pipeline വധശിക്ഷ (PPE) റിസ്ക് എന്നത് ഉറവിട നിയന്ത്രണ സംവിധാനങ്ങളിലേക്ക് ആക്സസ് ഉള്ളതും ബിൽഡ് പരിതസ്ഥിതിയിലേക്ക് ആക്സസ് ഇല്ലാത്തതുമായ ഒരു ആക്രമണകാരിയുടെ കഴിവിനെ സൂചിപ്പിക്കുന്നു - ബിൽഡിലേക്ക് ക്ഷുദ്ര കോഡ്/കമാൻഡുകൾ കുത്തിവച്ച് ബിൽഡ് പ്രക്രിയയിൽ കൃത്രിമം കാണിക്കാൻ pipeline കോൺഫിഗറേഷൻ, അടിസ്ഥാനപരമായി 'വിഷം' കലർത്തൽ pipeline "ബിൽഡ് പ്രക്രിയയുടെ ഭാഗമായി ക്ഷുദ്ര കോഡ് പ്രവർത്തിപ്പിക്കുന്നതും"
ചുരുക്കം വാക്കുകളിൽ പറഞ്ഞാൽ, വിഷം കലർത്തി Pipeline എക്സിക്യൂഷൻ (PPE) നിർമ്മിക്കുന്നത് ആക്രമണകാരിക്ക് പരിഷ്കരിക്കാൻ കഴിയും pipeline തര്ക്കശാസ്തം.
രണ്ട് ഉണ്ട് വേരിയന്റുകൾ:
- നേരിട്ടുള്ള പിപിഇ (ഡി-പിപിഇ): ഒരു D-PPE സാഹചര്യത്തിൽ, ആക്രമണകാരി CI കോൺഫിഗറേഷൻ ഫയൽ പരിഷ്കരിക്കുന്നു. റിപ്പോയിലെ ഒരു സുരക്ഷിതമല്ലാത്ത റിമോട്ട് ബ്രാഞ്ചിലേക്ക് നേരിട്ട് മാറ്റം വരുത്തിക്കൊണ്ടോ അല്ലെങ്കിൽ ഒരു ബ്രാഞ്ചിൽ നിന്നോ ഫോർക്കിൽ നിന്നോ ഉള്ള മാറ്റം ഉപയോഗിച്ച് ഒരു PR സമർപ്പിച്ചുകൊണ്ടോ അവർക്ക് ആക്സസ് ഉള്ള ഒരു റിപ്പോസിറ്ററിയിൽ. സി.ഐ മുതൽ pipeline പരിഷ്കരിച്ച CI കോൺഫിഗറേഷൻ ഫയലിലെ കമാൻഡുകൾ അനുസരിച്ചാണ് എക്സിക്യൂഷൻ നിർവചിക്കുന്നത്, ബിൽഡ് കഴിഞ്ഞാൽ ആക്രമണകാരിയുടെ ക്ഷുദ്ര കമാൻഡുകൾ ഒടുവിൽ ബിൽഡ് നോഡിൽ പ്രവർത്തിക്കുന്നു. pipeline ട്രിഗർ ചെയ്തിരിക്കുന്നു.
- പരോക്ഷ PPE (ഐ-പിപിഇ): ചില സന്ദർഭങ്ങളിൽ, ഒരു എതിരാളിക്ക് D-PPE യുടെ സാധ്യത ലഭ്യമല്ല, അതിൽ SCM സംഭരണി (ഉദാ. എങ്കിൽ pipeline ഒരേ റിപ്പോസിറ്ററിയിലെ ഒരു പ്രത്യേക സംരക്ഷിത ശാഖയിൽ നിന്ന് CI കോൺഫിഗറേഷൻ ഫയൽ പിൻവലിക്കാൻ ക്രമീകരിച്ചിരിക്കുന്നു). അത്തരമൊരു സാഹചര്യത്തിൽ, വിഷം കലർത്തുന്നതിനുപകരം pipeline തന്നെ, ഒരു ആക്രമണകാരി പരാമർശിച്ച ഫയലുകളിലേക്ക് ക്ഷുദ്ര കോഡ് കുത്തിവയ്ക്കുന്നു pipeline (ഉദാഹരണത്തിന്: ഉള്ളിൽ നിന്ന് പരാമർശിച്ച സ്ക്രിപ്റ്റുകൾ pipeline കോൺഫിഗറേഷൻ ഫയൽ)
രണ്ട് സാഹചര്യങ്ങളിലും, പരിഷ്കരിച്ചത് GitHub നടപ്പിലാക്കും pipeline മുൻ അവലോകനത്തിന്റെയോ അംഗീകാരത്തിന്റെയോ ആവശ്യമില്ലാതെ.
പിപിഇ നേരത്തേ കണ്ടെത്തൽ
ഈ തരത്തിലുള്ള ദുർബലത നമുക്ക് എങ്ങനെ കണ്ടെത്താനാകും?
ഈ ഉദാഹരണം നോക്കാം pipeline :
ഒരു ഡമ്മി ഷെൽ സ്ക്രിപ്റ്റിന്റെ (runtests.sh) ഉള്ളടക്കവും:
ദി pipeline വളരെ ലളിതമാണ്: അതിന്റെ ലക്ഷ്യം അവലോകകന് ചില പ്രാഥമിക സൂചനകൾ നൽകുക എന്നതാണ്. Pull Request (പിആർ) സ്വീകാര്യത പ്രക്രിയ:
- ഇത് പ്രവർത്തനക്ഷമമാക്കപ്പെടും പുൾ_റിക്വസ്റ്റ് (അതായത് ഒരു PR സൃഷ്ടിക്കപ്പെടുമ്പോഴെല്ലാം)
- ഇത് പിആർ കോഡ് പരിശോധിക്കുന്നു (അതായത് സംഭാവന ചെയ്ത കോഡ്)
- ഇത് നിർമ്മാണം നടത്തും
- ഇത് സംഭാവന ചെയ്ത കോഡിൽ പരിശോധനകൾ നടത്തും (ഉദാ: ഒരു ഷെൽ സ്ക്രിപ്റ്റ് എക്സിക്യൂട്ട് ചെയ്തുകൊണ്ട്)
കോഡ് കംപൈൽ ചെയ്തില്ലെങ്കിലോ ടെസ്റ്റുകളിൽ വിജയിക്കാൻ കഴിഞ്ഞില്ലെങ്കിലോ ഘട്ടങ്ങൾ #3 (ബിൽഡ് നിർമ്മിക്കുക) ഉം #4 (റൺ ടെസ്റ്റ്) ഉം പരാജയപ്പെടും. അതിനാൽ, ഈ ഘട്ടങ്ങൾ PR സ്വീകരിക്കുന്നതിന് ആവശ്യമായ, എന്നാൽ പര്യാപ്തമല്ലാത്ത ഒരു വ്യവസ്ഥയായി പ്രവർത്തിക്കുന്നു. വിജയകരമാണെങ്കിൽ, repo അഡ്മിൻ സംഭാവന ചെയ്ത കോഡ് അവലോകനം ചെയ്യുന്നതിലേക്ക് പോകും, അതിന്റെ അടിസ്ഥാനത്തിൽ, അവൻ/അവൾ PR സ്വീകരിക്കും/നിരസിക്കും/അഭിപ്രായം പറയും.
സൈജെനി സ്കാനർ
സൈജെനി ഒരു CLI നൽകുന്നു (“സൈജെനി സ്കാനർ”) അത് a-യിൽ ഉൾച്ചേർക്കാൻ കഴിയും pipeline അല്ലെങ്കിൽ ഒരു കമാൻഡ്-ലൈനിൽ പ്രവർത്തിപ്പിക്കുക. Xygeni സ്കാനർ പ്രോസസ്സ് ചെയ്യും pipelineദുർബലതകൾ പരിശോധിക്കുന്നതിനായി s ഉപയോഗിക്കുക, ഒരു GitHub PAT നൽകിയിട്ടുണ്ടെങ്കിൽ, org/repo തലത്തിൽ ദുർബലതകൾ കണ്ടെത്തുന്നതിന് അത് GitHub-ലേക്ക് കണക്റ്റുചെയ്യും.
സൈജെനി ഇൻവെന്ററി
ഈ റിപ്പോയിൽ നമ്മൾ Xygeni സ്കാനർ എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ, അത് ഉപയോഗപ്രദമായ ഒരു കൂട്ടം അസറ്റുകൾ കണ്ടെത്തുന്നു (the സൈജെനി ഇൻവെന്ററി). ഇൻവെന്ററിയിൽ പലതരം ഇനങ്ങൾ ഉണ്ടാകും. CI/CD അസറ്റുകൾ, അതുപോലെ:
- ദി SCM സിസ്റ്റം റിപ്പോ എവിടെയാണ് സൂക്ഷിച്ചിരിക്കുന്നത്
- ദി SCM പ്ലഗിനുകൾ ഇൻസ്റ്റാൾ ചെയ്തു/ഉപയോഗിച്ചു
- ദി കോഡ് ശേഖരം സ്വയം
- ദി SCM സംഘടന റിപ്പോ എവിടെയാണ് ഉൾപ്പെടുന്നത്
- ദി CI/CD Pipelineകളും ജോലികളും
- ദി CI/CD സിസ്റ്റം പ്രവർത്തിപ്പിക്കുന്നത് pipelines
- IaC ഉറവിടങ്ങൾ റിപ്പോയിൽ നിർവചിച്ചിരിക്കുന്നു
- ബാഹ്യ ആശ്രയിച്ചിരിക്കുന്നു
- മുതലായവ
നമ്മുടെ ഉദാഹരണത്തിൽ, നമുക്ക് ചില പ്രത്യേക അസറ്റ് തരം അനുസരിച്ച് ഇൻവെന്ററി ഫിൽട്ടർ ചെയ്യാൻ കഴിയും (SCM- CICD-യുമായി ബന്ധപ്പെട്ട ആസ്തികൾ), അങ്ങനെ നമുക്ക് കാണാൻ കഴിയും:
- SCM സിസ്റ്റം GitHub ക്ലൗഡ് ആണ്
- റെപ്പോ GitHub ക്ലൗഡിൽ സംഭരിച്ചിരിക്കുന്നു കൂടാതെ ഒരു പ്രത്യേക GitHub ഓർഗനൈസേഷന്റെതാണ്.
- രണ്ട് ഉണ്ട് pipelineGitHub നൽകുന്ന s (CI/CD സിസ്റ്റം)
- ഓരോ pipeline ഒരു പ്രത്യേക ഘട്ടം ഉൾക്കൊള്ളുന്നു
മുകളിൽ പറഞ്ഞവ തിരഞ്ഞെടുക്കുന്നതിലൂടെ pipeline നമുക്ക് ചില ദുർബലതകൾ കാണാൻ കഴിയും:
- At pipeline ലെവൽ, ഇത് രണ്ടിനും ദുർബലമാണ് നേരിട്ട് ഒപ്പം പരോക്ഷ PPE.
വിഷം കഴിച്ചവരുടെ വിശദാംശങ്ങൾ നമുക്ക് കാണാൻ കഴിയും Pipeline നിർവ്വഹണ ദുർബലതകൾ
സൈജെനി അത് കണ്ടെത്തുന്നു ഡി-പിപിഇക്ക് വിധേയമാകാൻ സാധ്യതയുള്ളത് കാരണം അത് ഒരു Pull Request ഇവന്റ് കൂടാതെ അധിക സുരക്ഷാ നിയന്ത്രണങ്ങളൊന്നുമില്ല, അതിനാൽ ഏതൊരു റിപ്പോ ഉപയോക്താവിനും ഇത് പരിഷ്കരിക്കാനാകും pipeline ആ പരിഷ്കാരങ്ങൾ യാതൊരു അവലോകനമോ അംഗീകാരമോ ഇല്ലാതെ നടപ്പിലാക്കും.
അതേ അർത്ഥത്തിൽ, സൈജെനിയും അത് കണ്ടെത്തുന്നു I-PPE യ്ക്ക് വിധേയമാകാൻ സാധ്യതയുള്ളത് ഷെൽ സ്ക്രിപ്റ്റിലേക്കുള്ള കോൾ കാരണം pipeline: ഏതൊരു റിപ്പോ ഉപയോക്താവിനും ഷെൽ സ്ക്രിപ്റ്റ് പരിഷ്കരിക്കാൻ കഴിയും, കൂടാതെ ആ പരിഷ്കാരങ്ങൾ യാതൊരു അവലോകനമോ അംഗീകാരമോ ഇല്ലാതെ നടപ്പിലാക്കും.
നിങ്ങൾക്ക് കൂടുതൽ അറിയണോ?
പിപിഇ ദുരുപയോഗം ചെയ്യുന്നു
PPE ഉപയോഗപ്പെടുത്തുന്നതിന്, രണ്ട് തരം റിപ്പോ ഉപയോക്താക്കൾ:
- An ആന്തരിക ഉപയോക്താവ് (ആ റിപ്പോയിൽ പ്രവർത്തിക്കുന്ന ഒരു ആന്തരിക ഡെവലപ്പർ), റിപ്പോയിൽ എഴുതാനുള്ള അനുമതികളോടെ
- An ബാഹ്യ ഉപയോക്താവ് (ആ റിപ്പോയിൽ റീഡ് പെർമിഷനുകൾ ഉള്ള ഒരു ഔട്ട്സോഴ്സ്ഡ് ഡെവലപ്പർ), അതായത് റിപ്പോ ബ്രാഞ്ച് ചെയ്യാൻ അനുവാദമില്ല, ഒരു ഫോർക്കിൽ പ്രവർത്തിക്കാൻ നിർബന്ധിതനാകുന്നു.
രണ്ടുപേരും ദുരുദ്ദേശ്യപരമായ ആക്രമണകാരികളാണെന്ന് (അല്ലെങ്കിൽ ഒരു ദുരുദ്ദേശ്യപരമായ നടനാൽ ആൾമാറാട്ടം ചെയ്യപ്പെട്ടവരാണെന്ന്) നമുക്ക് സങ്കൽപ്പിക്കാം. റെപ്പോയിൽ ചില രഹസ്യങ്ങൾ അടങ്ങിയിരിക്കുന്നു, രണ്ടുപേർക്കും റിപ്പോ രഹസ്യം മോഷ്ടിക്കാൻ ഒരു ഹാക്കർ നിയന്ത്രിത സെർവറിലേക്ക് അയയ്ക്കുക. അത് ചെയ്യുന്നതിന്, അവർ വിഷബാധയെ പ്രയോജനപ്പെടുത്തും. Pipeline ന്റെ നിർവ്വഹണ ദുർബലതകൾ pipeline.
രണ്ട് സാഹചര്യങ്ങളിലും (ബാഹ്യ ഉപയോക്താവും ആന്തരിക ഉപയോക്താവും), അവർ ഒരു Pull Request സമാന പരിഷ്കാരങ്ങളോടെ:
- ദി pipeline ഷെൽ സ്ക്രിപ്റ്റ് പരിഷ്ക്കരിച്ചു. ലേക്ക് രഹസ്യം വായിക്കുക പരിസ്ഥിതിയിൽ നിന്നും ഒരു ഹാക്കർ നിയന്ത്രിത സെർവറിലേക്ക് അത് അയയ്ക്കുക
പരിഷ്കാരങ്ങൾ ഇനിപ്പറയുന്നതായിരിക്കാം:
രണ്ട് ഉപയോക്താക്കളും ഒരു സൃഷ്ടിക്കും Pull Request പരിഷ്കാരങ്ങളോടെപിആർ രൂപീകരിച്ചതിനുശേഷം, രണ്ട് പരിഷ്കാരങ്ങളും GitHub നടപ്പിലാക്കും (മുൻ അവലോകനമോ അംഗീകാരമോ ആവശ്യമില്ലാതെ), ഇനിപ്പറയുന്നവയിൽ കലാശിക്കുന്നു:
എഴുതാനും വായിക്കാനും ഉപയോഗിക്കുന്നവർക്കും ഒരുപോലെ, രണ്ട് സാഹചര്യങ്ങളിലും D-PPE, I-PPE എന്നിവ നടപ്പിലാക്കുന്നു., ആ വ്യത്യാസത്തോടെ വായിക്കുന്ന ഉപയോക്താവിന് രഹസ്യങ്ങൾ ആക്സസ് ചെയ്യാൻ കഴിയില്ല. (!!!!)
ഈ കാരണം കാരണം, ഒരു ഫോർക്കിൽ നിന്ന് വരുന്ന ഒരു PR യുടെ കാര്യത്തിൽ, repo രഹസ്യങ്ങളിലേക്ക് പ്രവേശനം GitHub അനുവദിക്കുന്നില്ല. റീഡ് ഉപയോക്താവിന് രഹസ്യങ്ങൾ വായിക്കാൻ കഴിയില്ലെങ്കിലും, അയാൾക്ക്/അവൾക്ക് മറ്റേതെങ്കിലും പ്രോഗ്രാം പ്രവർത്തിപ്പിക്കാൻ കഴിയും. ഒരു സാധാരണ ആക്രമണ ഉദാഹരണം ഒരു ക്രിപ്റ്റോ മൈനർ ഡൗൺലോഡ് ചെയ്യുന്ന PR-കൾ സൃഷ്ടിക്കുന്നതാണ്, അതിനാൽ വിഷം കലർന്ന ഒരു pipeline.
ഇത് സുരക്ഷിതമായ ഒരു അന്തരീക്ഷമല്ല, തീർച്ചയായും!! അത് ഒഴിവാക്കാൻ റിപ്പോ അഡ്മിന് എന്തുചെയ്യാൻ കഴിയും?
കുറച്ച് ഗൂഗിളിൽ അന്വേഷിച്ചതിന് ശേഷം, റിപ്പോ അഡ്മിൻ ഇതിൽ മാറ്റം വരുത്താൻ തീരുമാനിക്കുന്നു pipeline ഒരു സമയത്ത് പ്രവർത്തനക്ഷമമാക്കാൻ പുൾ_റിക്വസ്റ്റ്_ടാർഗെറ്റ് സംഭവം. എന്തുകൊണ്ട്? കാരണം pipelinepull_request_target-ൽ ട്രിഗർ ചെയ്ത s, എക്സിക്യൂട്ട് ചെയ്യാൻ അനുവദിക്കുന്നില്ല. pipeline പരിഷ്ക്കരണങ്ങൾ, അതായത്, ഉപയോക്താവ് ഏതെങ്കിലും പരിഷ്ക്കരണങ്ങൾ വരുത്തിയാലും “ഒറിജിനൽ” pipeline നടപ്പിലാക്കും.
നമ്മുടെ ഉദാഹരണം പിന്തുടർന്നാൽ, ആക്രമണം മുമ്പത്തെപ്പോലെ തന്നെയായിരിക്കും. ഇതിനുശേഷം എന്ത് സംഭവിക്കും? pipeline പരിഷ്കരണം?
പ്രതീക്ഷിച്ച പോലെ, ഡി-പിപിഇ നടപ്പിലാക്കിയിട്ടില്ല. പക്ഷേ, I-PPE ഇപ്പോഴും ഉള്ളതിനാൽ, വായിച്ച ഉപയോക്താവിന് ഇപ്പോൾ റെപ്പോ രഹസ്യം ആക്സസ് ചെയ്യാൻ കഴിയും!!!
വായിക്കുന്ന ഉപയോക്താവിന് ഇപ്പോൾ രഹസ്യങ്ങളിലേക്ക് പ്രവേശനം ലഭിക്കാനുള്ള കാരണം എന്താണ്? pipeline പരിഷ്കരിക്കാൻ കഴിയില്ല, പക്ഷേ ഷെൽ സ്ക്രിപ്റ്റ് പരിഷ്കരിക്കാൻ ഇപ്പോഴും സാധ്യമാണ്. എപ്പോഴാണ് ഒരു pipeline pull_request_target-ൽ ട്രിഗർ ചെയ്താൽ, അത് പ്രിവിലേജ്ഡ് മോഡിൽ എക്സിക്യൂട്ട് ചെയ്യപ്പെടും. so അത് ഷെൽ സ്ക്രിപ്റ്റും ആയിരിക്കും., ഷെൽ സ്ക്രിപ്റ്റിന് റെപ്പോ രഹസ്യങ്ങളിലേക്ക് ആക്സസ് ലഭിക്കുന്നതിന് കാരണമാകുന്നു!!
പ്രതിരോധ നടപടികൾ
ക്ഷുദ്രകരമായ പിആർ-കളിൽ നിന്ന് പരിരക്ഷിക്കുന്നതിന് GitHub ചില നടപടികൾ നൽകുന്നു.
ശാഖ സംരക്ഷണ നിയമങ്ങൾ
തിരഞ്ഞെടുത്ത ബ്രാഞ്ചുകളിൽ ബ്രാഞ്ച് പ്രൊട്ടക്ഷൻ നിയമങ്ങൾ GitHub ഉപയോഗിച്ച് നിങ്ങൾക്ക് നിർവചിക്കാൻ കഴിയും.
നിങ്ങളുടെ സംരക്ഷിത ശാഖകൾക്കായി, നിങ്ങൾക്ക് ഒരു നയം വ്യക്തമാക്കാൻ കഴിയും ഒരു ആവശ്യമാണ് pull request ലയിപ്പിക്കുന്നതിന് മുമ്പ് (അതുപോലെ തന്നെ ആവശ്യമായ അംഗീകാരങ്ങളുടെ എണ്ണം, കോഡ് ഉടമകളിൽ നിന്നുള്ള അവലോകനങ്ങൾ മുതലായവ പോലുള്ള അധിക വ്യവസ്ഥകളും.)
പ്രത്യേക പരിഗണന അർഹിക്കുന്ന രണ്ട് വ്യവസ്ഥകൾ ഇവയാണ്:
- "നിർദ്ദിഷ്ട അഭിനേതാക്കളെ ആവശ്യമായവ മറികടക്കാൻ അനുവദിക്കുക pull requests".
- "മുകളിലുള്ള ക്രമീകരണങ്ങൾ മറികടക്കാൻ അനുവദിക്കരുത്."
മിക്ക വ്യവസ്ഥകളും നയത്തിൽ കർശനത ചേർക്കുമ്പോൾ, ഇവ നയത്തിൽ അയവ് വരുത്തുന്നു, അത് ക്ഷുദ്ര പ്രവർത്തനങ്ങൾക്ക് തുറന്നിടാൻ ഇടയാക്കും, ഉദാഹരണത്തിന്, "പ്രിവിലേജ്ഡ്" അഭിനേതാക്കൾ ക്രെഡൻഷ്യലുകൾ മോഷ്ടിച്ചാൽ.
GITHUB_TOKEN അനുമതികൾ നിയന്ത്രിക്കുക (കുറഞ്ഞ-പ്രിവിലേജ്)
ആവശ്യമുള്ളവയിലേക്ക് മാത്രം GitHub ടോക്കൺ അനുമതികൾ പരിമിതപ്പെടുത്തുക; ഈ രീതിയിൽ, ആക്രമണകാരികൾ നിങ്ങളുടെ pipeline, അവർക്ക് അധികമൊന്നും ചെയ്യാൻ കഴിയില്ല.
ഉപയോഗിച്ച് സ്ട്രിംഗ് ഇന്റർപോളേഷൻ ഒഴിവാക്കുക pipeline env വേരിയബിളുകൾ
നിങ്ങളുടെ ചില ഇൻപുട്ട് വേരിയബിളുകൾ ഉപയോഗിക്കുമ്പോഴെല്ലാം pipeline, അവ സ്ഥിരസ്ഥിതിയായി "വിശ്വസനീയമല്ലാത്ത" ഡാറ്റയായി കണക്കാക്കണമെന്ന് അറിഞ്ഞിരിക്കുക (അവയുടെ ഉള്ളടക്കം അന്തിമ ഉപയോക്താവാണ് നിയന്ത്രിക്കുന്നത്). കാണുക വിശ്വസനീയമല്ലാത്ത പ്രവർത്തനങ്ങളും വർക്ക്ഫ്ലോകളും സുരക്ഷിതം ഒപ്പം ഗിത്തബ് പ്രവർത്തനങ്ങൾ പഠിക്കുക.
സ്ക്രിപ്റ്റുകൾക്കുള്ളിൽ ഇൻപുട്ട് വേരിയബിളുകൾ ചേർക്കാൻ സ്ട്രിംഗ് ഇന്റർപോളേഷൻ ഉപയോഗിക്കുന്നതിന് പകരം നിങ്ങൾ എല്ലായ്പ്പോഴും എൻവയോൺമെന്റ് വേരിയബിളുകൾ ഉപയോഗിക്കണം.
വർക്ക്ഫ്ലോ റൺസും അംഗീകാര ആവശ്യകതകളും
വേണ്ടി പൊതു repos, വ്യക്തമാക്കാൻ GitHub അനുവദിക്കുന്നു "ബാഹ്യ" പിആറുകളിൽ എങ്ങനെ പ്രവർത്തിക്കാം.
GitHub ഓർഗനൈസേഷൻ ക്രമീകരണങ്ങൾ (“Org >> ക്രമീകരണങ്ങൾ >> പ്രവർത്തനങ്ങൾ >> പൊതുവായത്”) ബാഹ്യ പിആറുകൾ എങ്ങനെ കൈകാര്യം ചെയ്യണമെന്ന് വ്യക്തമാക്കട്ടെ:
ഡിഫോൾട്ടായി, ആദ്യമായി സംഭാവന നൽകുന്നവർക്ക് GitHub-ൽ പിആർ അംഗീകാരം ആവശ്യമായി വരും, ഇത് ക്ഷുദ്രകരമായ അഭ്യർത്ഥന ആക്രമണങ്ങളെ കൂടുതൽ സങ്കീർണ്ണമാക്കുന്നു. അങ്ങനെയാണെങ്കിലും, ആക്രമണകാരിക്ക് പ്രോജക്റ്റ് പരിപാലകരുടെ വിശ്വാസം നേടിയെടുക്കാൻ കഴിയും, ഉദാഹരണത്തിന് ചില നിരപരാധികളായ pull request യഥാർത്ഥ ആക്രമണത്തിന് മുമ്പ്.
ഈ അർത്ഥത്തിൽ, ദി മൂന്നാമത്തെ ഓപ്ഷൻ (പുറത്തുള്ള എല്ലാ സഹകാരികൾക്കും അംഗീകാരം ആവശ്യമാണ്) ഉയർന്ന തലത്തിലുള്ള നിയന്ത്രണം ചേർക്കുന്നു.
വേണ്ടി സ്വകാര്യ റിപ്പോകളിൽ, ഓർഗനൈസേഷൻ തലത്തിലും റിപ്പോ തലത്തിലും GitHub സഹായകരമായ നിയന്ത്രണവും നൽകുന്നു.
"ഇതിൽ നിന്ന് വർക്ക്ഫ്ലോകൾ പ്രവർത്തിപ്പിക്കുക Pull Requests” (സ്ഥിരസ്ഥിതിയായി പരിശോധിച്ചിട്ടില്ല) ഉപയോക്താക്കളെ ഫോർക്ക് പിആറുകളിൽ നിന്ന് വർക്ക്ഫ്ലോകൾ പ്രവർത്തിപ്പിക്കാൻ അനുവദിക്കുന്നു (വായിക്കാൻ മാത്രമുള്ള അനുമതികളുള്ളതും രഹസ്യങ്ങളിലേക്ക് ആക്സസ് ഇല്ലാത്തതുമായ ഒരു GITHUB_TOKEN ഉപയോഗിച്ച്). അവസാനത്തേതിനൊപ്പം ഈ ഓപ്ഷൻ തിരഞ്ഞെടുക്കുന്നതിലൂടെ (“ഫോർക്ക് പിആർ വർക്ക്ഫ്ലോകൾക്ക് അംഗീകാരം ആവശ്യമാണ്”), നിങ്ങൾക്ക് സ്വകാര്യ റിപ്പോകൾക്ക് സമാനമായ ഒരു നയത്തിൽ എത്തിച്ചേരാനാകും (മുകളിൽ കാണിച്ചിരിക്കുന്നത് പോലെ).
ഒരു റീഡ് ഉപയോക്താവിൽ നിന്നുള്ള PPE ചൂഷണത്തിൽ നമ്മൾ കണ്ടതുപോലെ, ഫോർക്കിൽ നിന്ന് പ്രവർത്തിപ്പിക്കുന്ന വർക്ക്ഫ്ലോകൾ അനുവദിക്കുന്നു pull requests സുരക്ഷിതമല്ല!!
ശേഷിക്കുന്ന ഓപ്ഷനുകൾ ("ഫോർക്കിൽ നിന്ന് വർക്ക്ഫ്ലോകളിലേക്ക് റൈറ്റ് ടോക്കണുകൾ അയയ്ക്കുക pull requests" ഒപ്പം "രഹസ്യങ്ങളും വേരിയബിളുകളും വർക്ക്ഫ്ലോകളിലേക്ക് അയയ്ക്കുക എന്നതിൽ നിന്ന് pull requests") സുരക്ഷാ നിലവാരം കുറയ്ക്കുക ഫോർക്ക് പിആറുകളിൽ പ്രയോഗിച്ചു.
ഈ ഫോർക്ക് നയം നിങ്ങൾക്ക് ഓർഗനൈസേഷൻ തലത്തിലോ റെപ്പോ-ലെവലിലോ നിർവചിക്കാം. org-ലെവലിൽ നയം പ്രവർത്തനരഹിതമാക്കിയിട്ടുണ്ടെങ്കിൽ, അത് റെപ്പോ തലത്തിൽ പ്രവർത്തനക്ഷമമാക്കാൻ കഴിയില്ല. എന്നാൽ, നയം org-ലെവലിൽ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടെങ്കിൽ, അത് റെപ്പോ-ലെവലിൽ പ്രവർത്തനരഹിതമാക്കാം.
കളിവീണ്ടും
ചിലത് ഉണ്ടായിരിക്കുന്നതിന്റെ പ്രത്യാഘാതങ്ങൾ നിങ്ങൾ കണ്ടിട്ടുണ്ടെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു pipeline വിഷബാധയ്ക്ക് സാധ്യതയുള്ളത് Pipeline വധശിക്ഷ. ഇത് വളരെ എളുപ്പമാണ് commit ദുർബലമായ pipeline, സുരക്ഷിതമായ ഒന്ന് എഴുതാൻ പ്രയാസമാണ്.
അതുകൊണ്ട് അത്തരം ദുർബലതകളെക്കുറിച്ച് ബോധവാന്മാരാകാൻ Xygeni സ്കാനർ ഉപയോഗിക്കുന്നത് വളരെ വിലപ്പെട്ടതാണ്.
ഒരു വൾണിന്റെ നിലനിൽപ്പിനെക്കുറിച്ച് നിങ്ങൾക്ക് ബോധമില്ലെങ്കിൽ അത് പരിഹരിക്കാൻ കഴിയില്ല!!
പക്ഷേ... ഇപ്പോഴും ഒരു ചോദ്യം ബാക്കിയാണ്... I-PPE എങ്ങനെ ഒഴിവാക്കാം?
ഇതായിരിക്കും നമ്മുടെ അടുത്ത പോസ്റ്റിന്റെ വിഷയം 🙂 … പരോക്ഷ വിഷബാധ Pipeline നിർവ്വഹണം (I-PPE) !!
