സൈജെനി ലോഗോ വെള്ള
സൗജന്യമായി ആരംഭിക്കുക
ഒരു ഡെമോ ബുക്ക് ചെയ്യുക

എന്ത് കുഴപ്പം സംഭവിക്കാം? CI/CD pipelines?

ഉള്ളടക്ക പട്ടിക

നിർബന്ധമായും വായിക്കേണ്ട പോസ്റ്റുകൾ

താൽപ്പര്യമുള്ള ഏറ്റവും പുതിയ പോസ്റ്റുകൾ

തുടർച്ചയായ സംയോജനവും തുടർച്ചയായ വിതരണവും (CI/CD) pipeline"ആധുനിക" രീതിയിൽ സോഫ്റ്റ്‌വെയർ നിർമ്മിക്കുന്ന ഏതൊരു സോഫ്റ്റ്‌വെയർ സ്ഥാപനത്തിന്റെയും അടിത്തറയാണ് എസ്. ഓട്ടോമേഷൻ മികച്ച ശക്തി നൽകുന്നു, എന്നാൽ മിക്ക ഡെവലപ്പർമാരും അത് ഉൾക്കൊള്ളുന്ന ഉത്തരവാദിത്തം നഷ്ടപ്പെടുത്തുന്നു.

ഡവലപ്പർ: അതെ, ഞങ്ങൾ എടുക്കുന്നു CI/CD സുരക്ഷ ഗൗരവമായി എടുക്കുകയും കോഡ് പരിപാലകരിൽ ശക്തമായ നിയന്ത്രണം ഉണ്ടായിരിക്കുകയും ചെയ്യുക, അവലോകനം ചെയ്യുക commitലയനങ്ങൾക്ക് മുമ്പ്; ജോലികളും pipelineമുതിർന്ന ജീവനക്കാരാണ് ഇവ പരിപാലിക്കുന്നത്, രഹസ്യങ്ങൾ ചോരാതിരിക്കാൻ അവർ ശ്രദ്ധിക്കുന്നു. pipelines. കാര്യം അറിയാവുന്ന ഉദ്യോഗസ്ഥരാണ് ഉപകരണം ഇൻസ്റ്റാൾ ചെയ്തത്. എന്ത് തെറ്റ് സംഭവിക്കാം?

പ്രിയ ഡെവലപ്പർ, CI/CD സിസ്റ്റങ്ങൾ സങ്കീർണ്ണമാണ്. അതിന്റെ വിശാലമായ ആക്രമണ ഉപരിതലം ദുഷ്ടന്മാരെ ആകർഷിക്കുന്നു. ജാഗ്രത പാലിക്കുന്നതും അമിത ആത്മവിശ്വാസം ഒരിക്കലും പുലർത്താത്തതും നല്ലതാണ്.

ചിലപ്പോൾ ഡിഫോൾട്ട് കോൺഫിഗറേഷൻ നിലനിർത്തുകയും ഹാക്കർമാരുടെ ഏറ്റവും നല്ല സുഹൃത്തായി മാറുകയും ചെയ്യും. ഗുരുതരമായ പിഴവുകൾ ഇതിൽ ഉണ്ടാകാം. CI/CD pipeline സിസ്റ്റത്തിന്റെ കോൺഫിഗറേഷനിലോ അല്ലെങ്കിൽ പ്രക്രിയയെയും സന്ദർഭത്തെയും ചുറ്റിപ്പറ്റിയുള്ള ഉറവിടങ്ങൾ, pipeline അത് എങ്ങനെ പ്രവർത്തനക്ഷമമാകുന്നു എന്നും.

ഈ പോസ്റ്റിൽ നമ്മൾ മോശം അഭിനേതാക്കളുടെ സ്ഥാനത്ത് നമ്മളെത്തന്നെയാണ് പ്രതിഷ്ഠിക്കുന്നത്. നമ്മൾ ചിന്തകൾ വായിക്കുകയായിരുന്നുവെന്ന് സങ്കൽപ്പിക്കുക എം3എം3എൻ70 (മെമെന്റോ മോറി?) കൂടാതെ ചതുപ്പ് കോപം ഡാർക്ക് വെബിൽ എവിടെയോ, ഒരുപക്ഷേ പാശ്ചാത്യമല്ലാത്ത ഒരു ഭാഷയിൽ, പക്ഷേ ലോകമെമ്പാടും തിന്മ പടരുന്നത് ഒരിക്കലും കാണാതെ പോകരുത്.

 

പഴയ കാലത്ത് അത് വളരെ എളുപ്പമായിരുന്നു...

എം3എം3എൻ70: പഴയ നല്ല കാലത്തേക്ക് തിരികെ പോകുമ്പോൾ ഞങ്ങളുടെ ബിസിനസ്സ് വളരെ എളുപ്പമായിരുന്നു... സീറോ-ഡേകൾ കുറഞ്ഞ വിലയ്ക്ക് ലഭ്യമായിരുന്നു, എളുപ്പത്തിൽ ചൂഷണം ചെയ്യാവുന്ന വൾണുകളോടെ ആപ്പുകൾ വ്യാപകമായി തുറന്നിരുന്നു, ഞങ്ങൾക്ക് പെട്ടെന്ന് വശങ്ങളിലേക്ക് നീങ്ങാൻ കഴിയും.

ചതുപ്പ് കോപം: ഫൂ#@ഹെൽ! ചിലർക്ക് ഇപ്പോഴും വിഡ്ഢിത്തമുണ്ട്, പക്ഷേ കാര്യങ്ങൾ മാറി. ആ ആപ്പ്സെക് ചീറ്റിന് വലിയ ആളുകൾ ധാരാളം വില കൊടുത്തു.

എം3എം3എൻ70: അതെ. പക്ഷേ പുതിയ വിഡ്ഢികൾ ഡെവലപ്പർമാരാണ്. ഞങ്ങൾക്ക്, ഈ ആളുകൾ ഉപയോഗിക്കുന്ന ഉപകരണങ്ങൾ തിരഞ്ഞെടുക്കുന്നത് എളുപ്പമായി. പ്രത്യേകിച്ച് CI ഒരു സ്വർണ്ണ ഖനിയാണ്! ക്ലൗഡ് ആക്‌സസ് ടോക്കണുകൾ, SCM ക്രെഡൻഷ്യലുകൾ, പ്രൊഡക്ഷൻ ഡാറ്റാബേസ് പാസ്‌വേഡുകൾ, SSH പ്രൈവറ്റ് കീകൾ, മറ്റ് CI ഉപയോക്താക്കളുടെ ക്രെഡൻഷ്യലുകൾ... വിരസമായ ഡെവലപ്‌മെന്റ് കാര്യങ്ങളിൽ നിന്ന് യഥാർത്ഥ കാര്യങ്ങളിലേക്കുള്ള ചാട്ടം വളരെ നിസ്സാരമായിരുന്നു.

സോഫ്റ്റ്‌വെയർ നിർമ്മിക്കുന്നതിനും പരിശോധിക്കുന്നതിനും വിന്യസിക്കുന്നതിനുമുള്ള ഓട്ടോമേഷൻ a ഉപയോഗിച്ച് CI/CD പലപ്പോഴും ഘട്ടങ്ങളിലൂടെ കമാൻഡുകളിലേക്ക് രഹസ്യങ്ങൾ കൈമാറേണ്ടതുണ്ട്. പലപ്പോഴും അവ ചോർന്നൊലിക്കപ്പെടുന്നു, കുപ്രസിദ്ധമായ പ്രത്യാഘാതങ്ങളോടെ.

Pipelineചിലപ്പോൾ ചോർന്നൊലിക്കുന്ന രഹസ്യങ്ങൾ നമുക്ക് ആവശ്യമാണ്.

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

ഒരുപക്ഷേ പഴയ നല്ല കാലം Git ചരിത്രത്തിൽ കണ്ടെത്താനായിരിക്കാം. .env ഫയൽ (ഡെവലപ്പർ അത് ചേർക്കാൻ മറന്നു .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

ഇത് ഒരു GitHub വർക്ക്ഫ്ലോയിൽ ഉപയോഗിച്ചു. .github/deploy.yaml അതിൽ ഇതുപോലുള്ള ഒന്ന് ഉണ്ടായിരുന്നു:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: വൗ! ആ ഓസ് കീകൾ പ്രവർത്തിക്കുന്നുണ്ടായിരുന്നു! ഞങ്ങൾ ആദ്യം ആപ്പിൽ ഒരു ഇനോക്കുവോ മാറ്റം പരീക്ഷിച്ചു, പിന്നീട് ആ ആളുകൾക്ക് അറിയില്ലായിരുന്നതിനാൽ സ്റ്റിംഗ് ചേർത്തു. ബിംഗോ! എന്തൊരു കാമ്പെയ്‌ൻ...

ആ മോശം നടൻ മാൽവെയർ ഉപയോഗിച്ച് പരിഷ്കരിച്ച ഒരു ആപ്ലിക്കേഷൻ അപ്‌ലോഡ് ചെയ്യാൻ AWS കീകൾ ഉപയോഗിച്ചു, തുടർന്ന് അത്തരം ക്രെഡൻഷ്യലുകൾ ഉപയോഗിച്ച് ഡിപ്ലോയ് കമാൻഡ് പ്രവർത്തിപ്പിച്ചു. ചോർന്ന രഹസ്യങ്ങളും അതിൽ അടങ്ങിയിരിക്കുന്ന വിവരങ്ങളും pipeline. "എന്തൊരു പ്രചാരണം!" എന്നതിന്റെ അർത്ഥം മെമന്റോ പാവപ്പെട്ട ഇരയിൽ നാശം വിതച്ചു എന്നാണ്.

മെമെന്റോ ഇവിടെ നമ്മോട് പറയുന്നത്, ഉദാഹരണത്തിലെ AWS ആക്സസ് കീകൾ പോലെ ഒരു രഹസ്യ ചോർച്ച സംഭവിച്ചാൽ, നിങ്ങൾ രഹസ്യം പിൻവലിക്കണം (മുകളിലുള്ള കീകൾ തിരിക്കുക) എന്നാണ്. ഉടനെ. എപ്പോഴും ഒരു എക്സ്പോഷർ വിൻഡോ ചോർച്ചയ്ക്കിടയിൽ commit രഹസ്യ അസാധുവാക്കലും; ജിഐടി ചരിത്രം മാറ്റിയെഴുതുന്നത് ബുദ്ധിമുട്ടാണ്. (ഏറ്റവും കഠിനമായ സ്വേച്ഛാധിപത്യ രാഷ്ട്രം പോലും ഇത്തരത്തിൽ ചരിത്രം മാറ്റിയെഴുതാൻ ശ്രമിച്ചു, പക്ഷേ ഫലമുണ്ടായില്ല) ഒരുപക്ഷേ ഫലപ്രദമല്ലായിരിക്കാം (നമ്മുടെ സുഹൃത്തുക്കൾ രഹസ്യ ചോർച്ചയുമായി സംഭരണിക്ക് മുമ്പായി ക്ലോൺ ചെയ്‌തിരിക്കാം). commit). എക്‌സ്‌പോഷർ വിൻഡോയിൽ ടാർഗെറ്റുചെയ്‌ത അക്കൗണ്ടിനായുള്ള പ്രവർത്തന ലോഗുകൾ വായിക്കുമ്പോൾ കീകൾ ഉടനടി തിരിക്കുക, പ്രാർത്ഥിക്കുക!

ഒരുപക്ഷേ സംഘടനകൾ ദീർഘകാല രഹസ്യങ്ങൾ ഉപയോഗിക്കുന്നത് നിരോധിക്കുക CI/CD pipelines, കൂടാതെ അവയെ താൽക്കാലിക ക്രെഡൻഷ്യലുകൾ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുക. GitHub പ്രവർത്തനങ്ങളിൽ AWS കീകൾ ഉള്ള മുൻ ഉദാഹരണത്തിൽ, ഒരു ഉപയോഗിക്കുന്നത് സുരക്ഷിതമാണ് ഓപ്പൺഐഡി കണക്ട് (OIDC) ദാതാവ് പ്രവർത്തനങ്ങൾക്ക് ആവശ്യമായ ഹ്രസ്വകാല ക്രെഡൻഷ്യലുകൾ ലഭിക്കുന്നതിന്.

ചതുപ്പ് കോപം: നീ എത്ര ഭാഗ്യവതിയായിരുന്നു! പഴയ കാലത്ത് ഹാർഡ്‌കോഡ് ചെയ്ത കീകൾ ഉപയോഗിച്ച് സ്ക്രിപ്റ്റുകൾ ചോർത്തുന്നത് പതിവായിരുന്നു, പൊതുജനങ്ങൾക്ക് ആക്‌സസ് ചെയ്യാവുന്ന S3 ബക്കറ്റുകളിൽ പോലും. ബക്കറ്റിലെ വസ്തുക്കൾ മുറിച്ചുകടന്ന് രസകരമായ കാര്യങ്ങൾ കണ്ടെത്താൻ കുറച്ച് ശ്രമിച്ചാൽ മതിയായിരുന്നു.

ചിലപ്പോൾ വിന്യാസത്തിനായി ഉപയോഗിച്ച ഏരിയ (ഈ ഉദാഹരണത്തിലെ ഒരു AWS S3 ബക്കറ്റ്) ഒരു കോൺഫിഗറേഷൻ പിഴവ് കാരണം (കണ്ടെത്താതെ പോയി) പുറത്തുനിന്നുള്ളവർക്ക് വായിക്കാൻ തുറന്നിരിക്കും. എന്ത് ചതുപ്പ് കോപം ഉപയോഗിച്ചത് ഇതുപോലെയായിരുന്നു:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

സുരക്ഷാ പിഴവുകൾക്കായി യാന്ത്രികമായി സ്കാൻ ചെയ്യാൻ കഴിയുന്ന ഒരു പ്രൊവിഷനിംഗ് ടെംപ്ലേറ്റിലാണ് ബക്കറ്റ് സൃഷ്ടിച്ചിരിക്കാൻ സാധ്യത.

ടൂൾ ഡിഫോൾട്ട് കോൺഫിഗറേഷൻ ഞങ്ങൾക്ക് ഒരു കളിപ്പാട്ടമായിരുന്നു.

വ്യക്തമായ ഉദാഹരണങ്ങൾ നൽകുന്നതിനായി നമുക്ക് സംസാരിക്കാം ജെങ്കിൻസ്, ഏറ്റവും ജനപ്രിയമായ CI ഉപകരണങ്ങളിലൊന്ന്.

ചതുപ്പ് കോപം: ജെൻകിൻസിലെ “സുരക്ഷ പ്രാപ്തമാക്കുക” എന്ന ചെക്ക്‌ബോക്‌സ് നിങ്ങൾക്ക് ഓർമ്മയുണ്ടോ, സൗകര്യാർത്ഥം എത്ര ഓർഗനൈസേഷനുകൾ അത് സജീവമാക്കരുതെന്ന് തിരഞ്ഞെടുത്തു? കൂടാതെ “ആർക്കും എന്തും ചെയ്യാം” ഡിഫോൾട്ടായി പെർമിഷൻ കോമ്പോകളാണോ? ആ അസ്വസ്ഥമായ ജെങ്കിൻസ് പ്ലഗിനുകൾ, ഉദാഹരണത്തിന് GitHub OAuth പ്ലഗിൻ? ഇത് കോൺഫിഗർ ചെയ്ത ആൾ “എല്ലാ ഓതന്റിക്കേറ്റഡ് ഉപയോക്താക്കൾക്കും READ അനുമതികൾ നൽകുക” എന്നും “GitHub റിപ്പോസിറ്ററി അനുമതികൾ ഉപയോഗിക്കുക” എന്നും തിരഞ്ഞെടുത്തു, അതുവഴി അവരുടെ എല്ലാ പ്രോജക്റ്റുകളിലേക്കും ഞങ്ങൾക്ക് ആക്‌സസ് ലഭിച്ചു.

(ക്ഷമിക്കണം, ജെങ്കിൻസ്, നിങ്ങളെ ഒരു ഉദാഹരണമായി കാണിച്ചതിന് 😉)

സുരക്ഷാ തത്വങ്ങളിൽ (ആസക്തനാണെങ്കിൽ പോലും) പ്രാവീണ്യം നേടുക. ഒന്ന് സ്ഥിരസ്ഥിതിയായി സുരക്ഷിതമാക്കുക തത്വം: നിയന്ത്രണങ്ങൾ സാധ്യമായ ഏറ്റവും സുരക്ഷിതമായ ക്രമീകരണങ്ങളിലേക്ക് സ്ഥിരസ്ഥിതിയാക്കണം. സുരക്ഷ ഇതിൽ ഉൾച്ചേർക്കണം CI/CD ഉപകരണങ്ങളും pipelineഒരു പിന്‍ചിന്തയായിരിക്കുന്നതിനുപകരം, അടിസ്ഥാനപരമായി മുതല്‍ ഉയര്‍ന്ന നിലവാരത്തില്‍ നിന്നുള്ളതാണ്. എന്നാല്‍ ഉപയോക്തൃ സൗഹൃദവും സൗകര്യവും പലപ്പോഴും സുരക്ഷയുമായി ഏറ്റുമുട്ടുന്നു.

ജെങ്കിൻസ് കേസിൽ, ബിൽറ്റ്-ഇൻ പ്രാമാണീകരണം വളരെ ദുർബലമാണ്: ജെൻകിൻസിലെ ബിൽറ്റ്-ഇൻ പ്രാമാണീകരണ സംവിധാനങ്ങൾ ഒരിക്കലും ഉപയോഗിക്കരുത്.. റോൾ-ബേസ്ഡ് ഓതറൈസേഷൻ സ്ട്രാറ്റജി (“RBAC”) പ്ലഗിൻ ഉള്ള ഒരു മൂന്നാം കക്ഷി സംവിധാനം (SAML, LDAP, Google ...) തിരഞ്ഞെടുക്കുന്നതാണ് നല്ലത്. കൂടാതെ അതീവ ജാഗ്രത പാലിക്കുക. admin അക്കൗണ്ട്.

ജോലി എങ്ങനെയെന്നും ശ്രദ്ധിക്കുക pipeline Jenkins-ലെ ഫയലുകൾ കൈകാര്യം ചെയ്യുന്നു. അതുപോലെ തന്നെ കോഡ്-ആസ്-കോഡ് പ്ലഗിൻ ജെങ്കിൻസ് കോൺഫിഗറേഷനു ബാധകമായ അതിന്റെ കോൺഫിഗറേഷൻ ഫയലുകളും.

സ്വയം ഹോസ്റ്റ് ചെയ്തതിൽ നിന്ന് മാറുന്നു CI/CD ക്ലൗഡ് അധിഷ്ഠിത SaaS സിസ്റ്റങ്ങളിലേക്കുള്ള സിസ്റ്റം, ഓർഗനൈസേഷൻ നെറ്റ്‌വർക്കിനുള്ളിൽ ലാറ്ററൽ മൂവ്‌മെന്റ് അനുവദിക്കുന്ന ചില സാധ്യതയുള്ള അപകടസാധ്യതകൾ ഇല്ലാതാക്കുന്നു, എന്നാൽ നിലവിലുള്ള ആന്തരിക സിസ്റ്റങ്ങൾക്കും ബാഹ്യവൽക്കരിക്കപ്പെട്ട സിസ്റ്റങ്ങൾക്കും ഇടയിൽ ബാഹ്യ കണക്ഷനുകൾ തുറക്കേണ്ടിവരുന്നത് പോലുള്ള മറ്റുള്ളവയും ചേർത്തു. CI/CD ഉപകരണം.

സംഘടനകൾ പരിശ്രമിക്കണം.cisകഠിനമാക്കുന്നതിൽ വേണ്ടത്ര ശ്രദ്ധ ചെലുത്തുക CI/CD സിസ്റ്റം, ഏറ്റവും നിയന്ത്രിതമായ ക്രമീകരണങ്ങളിൽ നിന്ന് ആരംഭിച്ച് ക്രമേണ ആവശ്യമായ ഏറ്റവും കുറഞ്ഞ അനുമതികളോടെ തുറക്കുന്നു pipeline ഘട്ടങ്ങൾ.

സുരക്ഷ കോൺഫിഗർ ചെയ്യുന്നു CI/CD ഉപകരണങ്ങൾ സങ്കീർണ്ണമായ ഒരു നേട്ടമായിരിക്കാം. പലതിലും പ്ലഗിനുകളോ എക്സ്റ്റെൻഷനുകളോ ഉണ്ട്, അവയിൽ മിക്കതും ദുർബലതകൾ ഉള്ളവയാണ്, അവ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടതുണ്ട്.

അത്തരം സങ്കീർണ്ണമായ ഉപകരണങ്ങൾക്കായുള്ള സുരക്ഷാ തെറ്റായ കോൺഫിഗറേഷൻ സ്കാനറുകൾ അല്ലെങ്കിൽ ബെഞ്ച്മാർക്കുകൾ സഹായിച്ചേക്കാം.

കോഡ് കുത്തിവയ്ക്കുന്നു pipeline രസത്തിനും ലാഭത്തിനും വേണ്ടിയുള്ള കമാൻഡുകൾ

എം3എം3എൻ70: കമാൻഡ്-ഇൻജക്ഷന് സാധ്യതയുള്ള പ്രവർത്തനങ്ങളും സ്ക്രിപ്റ്റുകളും ദുർബലമാകുന്ന അൺട്രസ്റ്റഡ് കോഡ് ചെക്ക്ഔട്ടുകൾ നിങ്ങൾ എപ്പോഴെങ്കിലും ഉപയോഗിച്ചിട്ടുണ്ടോ?

ഈ വിഭാഗം കാണിക്കുന്നത് pipeline മോശം അഭിനേതാക്കളെ അനിയന്ത്രിതമായ കോഡ് എക്സിക്യൂഷൻ കുത്തിവയ്ക്കാൻ പ്രാപ്തമാക്കുന്ന കോഡിംഗ് പിശകുകൾ അതിൽ തന്നെ ഉണ്ടാകാം. pipeline മാറ്റാതെ തന്നെ pipeline ഉറവിടം തന്നെ. ഉദാഹരണത്തിന് ഒരു PR ഉപയോഗിക്കുന്നത്

ഒരു ആദ്യ ഉദാഹരണം നിർഭാഗ്യകരമായ GitHub വർക്ക്ഫ്ലോ:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

സംയോജിപ്പിക്കുന്നു pull_request_target വിശ്വസനീയമല്ലാത്ത ഒരു PR ന്റെ വ്യക്തമായ ചെക്ക്ഔട്ടുള്ള വർക്ക്ഫ്ലോ ട്രിഗർ എന്നത് റിപ്പോസിറ്ററി വിട്ടുവീഴ്ചയിലേക്ക് നയിച്ചേക്കാവുന്ന അപകടകരമായ ഒരു രീതിയാണ്. ഉദാഹരണത്തിൽ, ഇവയുടെ നിർഭാഗ്യകരമായ സംയോജനം:

  • pull_request_target ബാഹ്യ ഫോർക്കുകളിൽ നിന്ന് പോലും, ടാർഗെറ്റ് റിപ്പോസിറ്ററിയിലേക്കും ടാർഗെറ്റ് റിപ്പോസിറ്ററി രഹസ്യങ്ങളിലേക്കും ഡിഫോൾട്ടായി റൈറ്റ് അനുമതിയുള്ള ഇവന്റ്, കൂടാതെ PR-ന്റെ ടാർഗെറ്റ് റിപ്പോസിറ്ററിയുടെ സന്ദർഭത്തിൽ പ്രവർത്തിക്കുന്നു,
  • ഉറവിടത്തിൽ നിന്ന് പിആർ കോഡ് പരിശോധിക്കുക, വിശ്വസനീയമല്ലാത്ത റിപ്പോ,
  • പിആർ നിയന്ത്രിത ഉള്ളടക്കങ്ങളിൽ പ്രവർത്തിക്കുന്ന ഏതൊരു സ്ക്രിപ്റ്റും ട്രിഗർ ചെയ്യുക, ഉദാഹരണത്തിന് npm install, ഒപ്പം
  • ട്രിഗറിംഗിനായി ഒരു കണ്ടീഷൻ ഉപയോഗിക്കാത്തത് pull_request_target 'ഈ പിആർ പരിശോധിച്ചു' എന്ന ലേബൽ പിആറിന് നൽകിയിട്ടുണ്ടെങ്കിൽ മാത്രമേ ഇവന്റ് പ്രവർത്തിപ്പിക്കൂ (ബാഹ്യ ഉപയോക്താക്കൾക്ക് പിആറിന് ലേബലുകൾ നൽകാൻ കഴിയില്ല).

രണ്ടാമത്തെ ഉദാഹരണം വിശ്വസനീയമല്ലാത്ത ഇൻപുട്ട് എടുക്കുന്നു (ഒരു പ്രശ്നത്തിൽ നിന്നോ, കമന്റിൽ നിന്നോ അല്ലെങ്കിൽ pull request) ആർഗ്യുമെന്റുകൾക്കുള്ള ഉറവിടമായി a ലേക്ക് കൈമാറി pipeline എക്സ്പ്രഷനുകൾ വഴിയുള്ള കമാൻഡ്. ഇതാണ് pipeline OS കമാൻഡ് ഇഞ്ചക്ഷൻ ദുർബലതയുടെ പതിപ്പ്.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

റൺ പ്രവർത്തനം ടെംപ്ലേറ്റിനെ അടിസ്ഥാനമാക്കി ഒരു താൽക്കാലിക ഷെൽ സ്ക്രിപ്റ്റ് സൃഷ്ടിക്കുന്നു, $ പകരം വച്ചിരിക്കുന്നു, ഇത് ഷെൽ കമാൻഡ് കുത്തിവയ്പ്പിന് ഇരയാകുന്നു. വ്യാജ GitHub അക്കൗണ്ട് ഉള്ള ഒരു ആക്രമണകാരിക്ക് ഒരു ശീർഷകത്തിൽ ഒരു പ്രശ്നം സൃഷ്ടിക്കാൻ കഴിയും. a"; bad_code_goes_here;#, ബൂം! 

ചതുപ്പ് കോപം: ഓ, ആ ആളുകൾ ഒരു പ്രശ്നം തുറന്നുകൊണ്ട് കമാൻഡ് ഇഞ്ചക്ഷനുള്ള വാതിൽ തുറക്കുകയായിരുന്നു...

GitHub പ്രവർത്തനങ്ങളിൽ കോഡ് എക്സിക്യൂഷൻ ദുർബലതകൾ ഉണ്ടായിരുന്നു, ഉദാഹരണത്തിന് ഗജിറ-അഭിപ്രായം, ഇപ്പോൾ പരിഹരിച്ചു. ദയവായി വായിക്കുക. “GitHub വർക്ക്ഫ്ലോകളിലെ വിശ്വസനീയമല്ലാത്ത ഇൻപുട്ട്” പൂർണ്ണ വിശദാംശങ്ങൾക്ക്.

കഥയുടെ ധാർമ്മികത: ആദ്യം പിആർ അവലോകനം ചെയ്യാതെ ഒരിക്കലും വിശ്വസനീയമല്ലാത്ത ഉറവിടങ്ങളിൽ നിന്ന് ചെക്ക്ഔട്ട് ചെയ്ത് പിആർ നിർമ്മിക്കരുത്. ഇവിടെ 'അൺട്രസ്റ്റഡ്' എന്നത്, ഉത്ഭവത്തിന്റെ ക്രൂരമായ പ്രാമാണീകരണത്തിന് കീഴിലല്ലെങ്കിൽ, ഹൈജാക്ക് ചെയ്യപ്പെടാൻ സാധ്യതയുള്ള ഏതെങ്കിലും ഡെവലപ്പർ അക്കൗണ്ടിനെ അർത്ഥമാക്കാം.

 

ഇവിടെ അപ്രതീക്ഷിത മാൽവെയർ വിന്യാസം!

തുടർച്ചയായ വിന്യാസം ഓട്ടോമേഷൻ ക്ലൈമാക്സാണ്, പക്ഷേ ആ ക്ലൈമാക്സ് ഉചിതമായ അംഗീകാര നിയന്ത്രണങ്ങളുടെ അഭാവം മൂലം നിരാശാജനകമായേക്കാം. pipeline ഒഴുകുന്നു.

ഉറവിടത്തിൽ നിന്ന് പൂർണ്ണമായും യാന്ത്രികമായി വിന്യാസം നടത്തുന്നതിന്റെ അപകടസാധ്യതകൾ commit പ്രൊഡക്ഷൻ സിസ്റ്റങ്ങളിലേക്ക് വരുന്ന സുരക്ഷാ നടപടികളിൽ, ക്ഷുദ്ര കോഡ് കണ്ടെത്തപ്പെടാതെ പ്രൊഡക്ഷൻ പരിതസ്ഥിതികളിലേക്ക് വിന്യസിക്കാനുള്ള സാധ്യതയും, വിന്യാസ പ്രക്രിയയിലെ പിശകുകൾ തടസ്സങ്ങൾക്കോ ​​തടസ്സങ്ങൾക്കോ ​​കാരണമാകാനുള്ള സാധ്യതയും ഉൾപ്പെടുന്നു.

ഈ അപകടസാധ്യതകൾ ലഘൂകരിക്കുന്നതിന്, സ്ഥാപനങ്ങൾ അവരുടെ വിന്യാസ പ്രക്രിയയിൽ ഒരു "ഹാർഡ് ബ്രേക്ക്" നടപ്പിലാക്കാൻ പലപ്പോഴും ശുപാർശ ചെയ്യപ്പെടുന്നു, അതിന് മനുഷ്യ അംഗീകാരം എൻഡ് എൻവയോൺമെന്റുകളിലേക്ക് റിലീസുകൾ വിന്യസിക്കുന്നതിന് മുമ്പ്.

അവർ വാതിലുകൾ അടയ്ക്കുകയാണ്

ചതുപ്പ് കോപം: ആ സന്തോഷകരമായ സ്ഥിരസ്ഥിതി പാസ്‌വേഡുകൾ CI/CD ഉപകരണങ്ങൾ തുടച്ചുമാറ്റപ്പെടുന്നു. ആക്‌സസ് ചെയ്യുന്നു /var/lib/jenkins/secrets/initialAdminPassword ഇപ്പോൾ ഒരു നിർജ്ജീവമായ ട്രാക്കാണ്. കോവിഡ് ജനപ്രിയമാക്കിയ 2FA നിരവധി ഉപകരണങ്ങൾ ഇപ്പോൾ നൽകുന്നു, ലോകത്തിലെ ഏറ്റവും മടിയനായ കോഡ് കുരങ്ങൻ പോലും ഇത് ഉപയോഗിക്കുന്നു!

എം3എം3എൻ70: നമ്മൾ 2FA യുമായി പോരാടുകയാണ്, പക്ഷേ അത് അത്ര എളുപ്പമല്ല. അവരെ കുന്തമുനയിൽ നിർത്തുക പ്രയാസമാണ്, കാരണം “സ്കാറ്റർ സ്വൈൻ” ട്വിലിയോയുമായി ചെയ്തു. WebAuthn കീകളിൽ ഇത് വളരെ ബുദ്ധിമുട്ടാണ്. കുറഞ്ഞത്, നമുക്ക് ശ്രമിക്കാം MFA മറികടക്കാൻ കുക്കികൾ മോഷ്ടിക്കുക, പക്ഷേ ഡെവലപ്പറുടെ പെട്ടിയിൽ കയറേണ്ടതുണ്ട്.

ആധികാരികത രഹസ്യങ്ങൾ ചോർന്നൊലിക്കുന്നതിനുള്ള സാധ്യത പരിമിതപ്പെടുത്തുന്നതിനുള്ള ശരിയായ ദിശയിലുള്ള ഒരു നല്ല ചുവടുവയ്പ്പാണ് മൾട്ടി-ഫാക്ടർ ഓതന്റിക്കേഷൻ. മിക്ക ആധുനിക DevOps ടൂളുകളും MFA-യെ പിന്തുണയ്ക്കുന്നു. WebAuthn / U2F-ന് കീഴിലുള്ള ആധികാരികത കീകളും (കാണുക FIDO2 പ്രോജക്റ്റ്) എന്നിവ ഒരുപക്ഷേ, ശരിയായി കൈകാര്യം ചെയ്യുകയാണെങ്കിൽ, DevOps-ൽ MFA-യ്ക്കുള്ള ഏറ്റവും മികച്ച ഓപ്ഷനാണ്.

ചതുപ്പ് കോപം: DevOps ആളുകൾ ഉണർന്നെഴുന്നേൽക്കുകയാണ്. അവരുടെ രക്തത്തിൽ "ഏറ്റവും കുറഞ്ഞ പ്രിവിലേജ്" എന്ന ശാപം ഉണ്ട്. അവർ ഇപ്പോൾ കോഡ് കുരങ്ങന്മാരല്ല. ഇപ്പോൾ നമ്മൾ അവലോകകരുടെ കൈകളിൽ കുടുങ്ങിയിരിക്കുന്നു.

സത്യത്തിൽ, pipelineദുർബലമായ പ്രവർത്തനങ്ങളും സ്ക്രിപ്റ്റുകളും നീക്കം ചെയ്തതോടെ, സ്റ്റെൽത്തിൽ ഒളിഞ്ഞിരിക്കുന്ന ഞങ്ങളുടെ ഡ്രോപ്പറുകൾ പോലും കണ്ടെത്തുന്ന അധിക സുരക്ഷാ പരിശോധന ഘട്ടങ്ങളിലൂടെ, s ഇപ്പോൾ കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പുള്ളതിനേക്കാൾ കുറച്ചുകൂടി ശക്തമാണ്. commitകളും പാക്കേജുകളും ഞങ്ങൾ ഹൈജാക്ക് ചെയ്തു.

വായനക്കാരോടുള്ള ചോദ്യം: ഉറവിടങ്ങളിൽ നിന്ന് സോഫ്റ്റ്‌വെയർ നിർമ്മിച്ച് ഉൽ‌പാദനത്തിലേക്ക് വിന്യസിക്കുന്ന പ്രക്രിയ അപകടകരമായ ഒരു ബിസിനസ്സാണോ? നിങ്ങളുടെ DevOps ഈ ഘട്ടത്തിൽ കാണാൻ കഴിയുമോ? നല്ല സമയങ്ങൾ! മോശം ആളുകൾക്ക് വേണ്ടി?

അന്തിമ ശുപാർശകൾ

എവിടെ തുടങ്ങണം CI/CD pipelineഎസ്?

ആദ്യത്തെ ശുപാർശ ഇവിടെ ലളിതമാണ്: ശ്രദ്ധാപൂർവ്വം അവലോകനം pipelines (അവർ ഗുരുതരമായ സുരക്ഷാ പ്രശ്നങ്ങൾക്ക്) വിഭവങ്ങൾ. അവലോകനങ്ങൾ ചെലവേറിയതാണ്, പക്ഷേ അത്യാവശ്യമാണ്, അവ ശരിയായി ചെയ്യണം. എന്ത് നോക്കണമെന്ന് അവലോകകർ അറിഞ്ഞിരിക്കണം. ഓരോ ഘട്ടത്തിലും പോരായ്മകൾ പരിശോധിക്കണം.

ഓട്ടോമേറ്റഡ് മാലിഷ്യസ് കോഡ് സ്കാനറുകൾ ഘടിപ്പിച്ച വിദഗ്ദ്ധ അവലോകകരുടെ സംയോജനം സഹായിച്ചേക്കാം.

രണ്ടാമത്തെ ശുപാർശ ഇതാണ് എഴുതുന്ന ഡെവലപ്പർമാരെ പരിശീലിപ്പിക്കുക pipelineഅവ സുരക്ഷിതമായി പരിപാലിക്കുക. പരിഗണിക്കേണ്ട കാര്യങ്ങൾ:

  • ദീർഘകാല ക്രെഡൻഷ്യലുകൾ കൈകാര്യം ചെയ്യുന്നതിന്റെ ശല്യം ഒഴിവാക്കിക്കൊണ്ട്, ആന്തരിക, ക്ലൗഡ് സേവനങ്ങളിൽ പ്രാമാണീകരണം എങ്ങനെ ശരിയായി കൈകാര്യം ചെയ്യാം.
  • എങ്ങനെ പരിമിതപ്പെടുത്താം pipelineഅതിന് ആക്‌സസ് ആവശ്യമുള്ള കൃത്യമായ വിഭവങ്ങളുടെ കൂട്ടത്തിലേക്ക്. ഏറ്റവും കുറഞ്ഞ പ്രിവിലേജ് എന്ന തത്വം വീണ്ടും പ്രകാശിക്കുന്നു.
  • നിർമ്മിക്കാനുള്ള ഘട്ടങ്ങൾ എങ്ങനെ എഴുതാം pipelineപതിപ്പ് പിന്നിംഗ് പോലെ പുനർനിർമ്മിക്കാവുന്നതും കമാൻഡ് ഇഞ്ചക്ഷൻ ദുർബലതകൾ ഒഴിവാക്കുന്നതും.
  • സുരക്ഷാ വീക്ഷണകോണിൽ നിന്ന് വിന്യാസങ്ങൾ എങ്ങനെ അംഗീകരിക്കാം (അവ മറ്റുള്ളവരാണ്!): ഏത് സുരക്ഷയാണ് standardകൾ പൊരുത്തപ്പെടുത്തണം, അനുബന്ധ ചെക്കുകൾ/ഗേറ്റുകൾ എങ്ങനെ ചേർക്കാം pipelines.

മൂന്നാമത്തെ ശുപാർശ ഇതാണ് കോൺഫിഗർ ചെയ്യുക CI/CD ശ്രദ്ധയോടെയുള്ള സംവിധാനം. ശക്തമായ ആധികാരികത, സ്ഥിരസ്ഥിതി പാസ്‌വേഡുകളോ സുരക്ഷിതമല്ലാത്ത ക്രമീകരണങ്ങളോ ഇല്ല, കുറഞ്ഞ പ്രത്യേകാവകാശങ്ങൾ... ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള പ്ലഗിനുകളിലെയും എക്സ്റ്റെൻഷനുകളിലെയും അപകടസാധ്യതകൾ ശ്രദ്ധിക്കുക. ഇനിപ്പറയുന്ന പോസ്റ്റുകളുടെ ശ്രദ്ധാകേന്ദ്രം ഇതായിരിക്കാം, ദയവായി തുടരുക.

നാലാമത്തെ ശുപാർശ ഇതാണ് പ്രയോജനപ്പെടുത്തുക CI/CD pipelineസുരക്ഷാ ഓട്ടോമേഷനുള്ള എസ്.. സോഴ്‌സ് കോഡ് വിശകലനം (SAST), ഉറവിട ഘടന വിശകലനം (SCA), സീക്രട്ട്സ് ലീക്ക്സ് സ്കാനിംഗ്, ആന്റി-മാൽവെയർ ടൂളുകൾ, കണ്ടെയ്നർ സെക്യൂരിറ്റി സ്കാനറുകൾ, അല്ലെങ്കിൽ ഓട്ടോമേറ്റഡ് റൺടൈം ഡിറ്റക്ടറുകൾ (DAST, മാൽവെയർ) എന്നിവ പതിവായി പ്രവർത്തിപ്പിക്കാൻ കഴിയും. pipeline. നിങ്ങളുടെ സ്ഥാപനം നടപ്പിലാക്കിയേക്കാം standardസുരക്ഷാ സ്കാനിംഗിലെ കവറേജിനെക്കുറിച്ച് CI/CD.

ഓർമ്മിപ്പിക്കുക, ഈ ഉപകരണങ്ങൾ ഇതുവരെ സമവാക്യത്തിൽ നിന്ന് വിദഗ്ദ്ധ അവലോകനത്തെ നീക്കം ചെയ്യുന്നില്ല, അല്ലാത്തപക്ഷം നിങ്ങൾക്ക് തെറ്റായ സുരക്ഷിതത്വബോധം ഉണ്ടാകാം.

നിങ്ങൾ OWASP ടോപ്പ്-ടെൻസിൽ പ്രാവീണ്യമുള്ള ആളാണെങ്കിൽ, അടുത്തിടെ പുറത്തിറങ്ങിയ ഒരു നല്ല പ്രോജക്റ്റ് ഇതാണ് OWASP ടോപ്പ് 10 CI/CD സുരക്ഷാ അപകടം.

നിരാകരണ കുറിപ്പ്

(1) ഈ പോസ്റ്റിലെ ഉദാഹരണങ്ങൾ GitHub ഉപയോഗിക്കുന്നത് ഇങ്ങനെയാണ് SCM, ക്ലൗഡ് ദാതാവായി AWS, കൂടാതെ GitHub Actions അല്ലെങ്കിൽ Jenkins ആയി CI/CD ഉപകരണം. അവ അവയുടെ ബദലുകളേക്കാൾ ദുർബലമോ സുരക്ഷിതമോ അല്ല. ദുരുപയോഗ ഉദ്ദേശ്യമില്ല! ഈ ഉപകരണങ്ങൾ ശക്തമാണ്, ഉചിതമായി ഉപയോഗിക്കേണ്ടതുണ്ട്.

(2) എം3എം3എൻ70 ഒപ്പം ചതുപ്പ് കോപം സാങ്കൽപ്പിക കഥാപാത്രങ്ങളാണ്. വ്യക്തികളുമായോ ഗ്രൂപ്പുകളുമായോ, ജീവിച്ചിരിക്കുന്നവരുമായോ മരണവുമായോ ഉള്ള ഏതെങ്കിലും സാമ്യം വെറും യാദൃശ്ചികമാണോ... അതോ അങ്ങനെയാണോ?

കൂടുതൽ വായിക്കാൻ

സ്കാ-ടൂളുകൾ-സോഫ്റ്റ്‌വെയർ-കോമ്പോസിഷൻ-വിശകലന-ടൂളുകൾ
നിങ്ങളുടെ സോഫ്റ്റ്‌വെയർ അപകടസാധ്യതകൾക്ക് മുൻഗണന നൽകുക, പരിഹരിക്കുക, സുരക്ഷിതമാക്കുക
നിങ്ങളുടെ സൗജന്യ അക്കൗണ്ട് നേടൂ.
ക്രെഡിറ്റ് കാർഡ് ആവശ്യമില്ല.
സൗജന്യമായി ആരംഭിക്കുക

നിങ്ങളുടെ സോഫ്റ്റ്‌വെയർ വികസനവും ഡെലിവറിയും സുരക്ഷിതമാക്കുക

സൈജെനി ഉൽപ്പന്ന സ്യൂട്ടിനൊപ്പം

സൗജന്യമായി ആരംഭിക്കുക
ഉൽപ്പന്ന ടൂർ നടത്തുക
സൈജെനി ലോഗോ വെള്ള

© 2026 സൈജെനി. എല്ലാ അവകാശങ്ങളും നിക്ഷിപ്തം.

ലിങ്ക്ഡിൻ-ഇൻ എക്സ്-ട്വിറ്റർ യൂട്യൂബ്

ഉല്പന്നങ്ങൾ

ഉറവിടങ്ങൾ

സംഘം

നിയമ