ઝીગેની લોગો સફેદ
મફતમાં શરૂઆત કરો
એક ડેમો બુક કરો

શું ખોટું થઈ શકે છે CI/CD pipelines?

સામગ્રીનું કોષ્ટક

અવશ્ય વાંચવા જેવી પોસ્ટ્સ

રસપ્રદ નવીનતમ પોસ્ટ્સ

સતત એકીકરણ અને સતત ડિલિવરી (CI/CD) pipelineકોઈપણ સોફ્ટવેર સંસ્થાનો પાયો એ છે જે "આધુનિક" રીતે સોફ્ટવેર બનાવે છે. ઓટોમેશન મહાન શક્તિ પ્રદાન કરે છે, પરંતુ મોટાભાગના વિકાસકર્તાઓ તેમાં રહેલી જવાબદારી ચૂકી જાય છે.

ડેવલોપર: હા, અમે લઈએ છીએ CI/CD સુરક્ષા ગંભીરતાથી અને કોડ જાળવણી કરનારાઓ પર મજબૂત નિયંત્રણ રાખો, સમીક્ષા કરો commitમર્જ પહેલાંના કાર્યો; નોકરીઓ અને pipelines ની જાળવણી વરિષ્ઠ સ્ટાફ દ્વારા કરવામાં આવે છે, તેઓ રહસ્યો લીક ન થાય તેનું ધ્યાન રાખે છે pipelines. અને આ સાધન એવા કર્મચારીઓ દ્વારા ઇન્સ્ટોલ કરવામાં આવ્યું હતું જેઓ વસ્તુ જાણે છે. શું ખોટું થઈ શકે છે?

પ્રિય ડેવલપર, CI/CD સિસ્ટમો જટિલ છે. તેની વિશાળ હુમલો સપાટીએ ઘાતક તત્વોને આકર્ષ્યા છે. સાવચેત રહેવું અને ક્યારેય વધુ પડતો આત્મવિશ્વાસ ન રાખવો વધુ સારું છે.

ડિફોલ્ટ રૂપરેખાંકન ક્યારેક રાખવામાં આવે છે અને હેકર્સ માટે શ્રેષ્ઠ મિત્ર બની જાય છે. તેમાં ગંભીર ખામીઓ હોઈ શકે છે CI/CD pipeline સ્ત્રોતો, સિસ્ટમના રૂપરેખાંકનમાં, અથવા પ્રક્રિયા અને સંદર્ભની આસપાસ pipeline અને તે કેવી રીતે ટ્રિગર થાય છે.

આ પોસ્ટમાં આપણે પોતાને ખરાબ કલાકારોના સ્થાને મૂકીશું. કલ્પના કરો કે આપણે એમ3એમ3એન70 (સ્મૃતિચિહ્ન મોરી?) અને સ્વેમ્પ રેજ ડાર્ક વેબમાં ક્યાંક, કદાચ કોઈ બિન-પશ્ચિમી ભાષામાં, પણ ક્યારેય ભૂલશો નહીં કે દુષ્ટતા વિશ્વભરમાં ફેલાયેલી છે.

 

જૂના સમયમાં તે ખૂબ જ સરળ હતું...

એમ3એમ3એન70: જૂના સમયમાં અમારો વ્યવસાય ખૂબ જ સરળ હતો... શૂન્ય-દિવસ ઓછા ફાયદાકારક હતા, એપ્લિકેશનો ખુલ્લી હતી જેમાં સરળતાથી ઉપયોગ કરી શકાય તેવી નબળાઈઓ હતી, અને અમે પળવારમાં બાજુ તરફ આગળ વધી શકતા હતા.

સ્વેમ્પ રેજ: Fu#@Hell ! કેટલાક લોકો હજુ સુધી ખૂબ જ વિચારી રહ્યા છે, પણ પરિસ્થિતિ બદલાઈ ગઈ છે. મોટા લોકોએ એપસેકની આ વાત પર ઘણી બધી મહેનત કરી.

એમ3એમ3એન70: હા. પણ નવા મૂર્ખ લોકો વિકાસકર્તાઓ છે. અમારા માટે, આ લોકો જે સાધનોનો ઉપયોગ કરે છે તે પસંદ કરવાનું સરળ બન્યું છે. ખાસ કરીને, CI સોનાની ખાણ છે! ક્લાઉડ એક્સેસ ટોકન્સ, SCM ઓળખપત્રો, પ્રોડક્શન ડેટાબેઝ પાસવર્ડ્સ, SSH પ્રાઇવેટ કી, અન્ય CI વપરાશકર્તાઓના ઓળખપત્રો... કંટાળાજનક વિકાસકર્તાઓથી વાસ્તવિક વસ્તુઓ પર કૂદકો મારવો એ ખૂબ જ નજીવી વાત હતી.

સોફ્ટવેર બનાવવા, પરીક્ષણ કરવા અને જમાવટ કરવા માટે ઓટોમેશન 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.

કદાચ સારા જૂના સમયનો અર્થ ગિટ ઇતિહાસમાં શોધવાનો હતો એક .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 કી કામ કરી રહી હતી! અમે પહેલા એપમાં એક ઇનોક્યુઓસ ફેરફારનું પરીક્ષણ કર્યું, પછી તે લોકો અજાણ હોવાથી સ્ટિંગ ઉમેર્યું. બિંગો! શું ઝુંબેશ છે...

ખરાબ વ્યક્તિએ ફક્ત 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 પ્લગઇન? જે વ્યક્તિએ તેને ગોઠવ્યું તેણે "Grant READ permissions to all Authenticated Users" અને "Use GitHub repository permissions" બંને પસંદ કર્યા, જેનાથી અમને તેમના બધા પ્રોજેક્ટ્સની ઍક્સેસ મળી.

(જેનકિન્સ, તમને ઉદાહરણ તરીકે રજૂ કરવા બદલ માફ કરશો 😉)

સુરક્ષા સિદ્ધાંતોમાં પારંગત (વ્યસની પણ) રહો. એક છે ડિફૉલ્ટ રૂપે સુરક્ષિત સિદ્ધાંત: નિયંત્રણો શક્ય તેટલી સુરક્ષિત સેટિંગ્સ પર ડિફોલ્ટ હોવા જોઈએ. સુરક્ષા તેમાં બનેલી હોવી જોઈએ CI/CD સાધનો અને pipelineશરૂઆતથી જ, પછીથી વિચારવાને બદલે. પરંતુ વપરાશકર્તા-મિત્રતા અને સુવિધા ઘણીવાર સુરક્ષા સાથે અથડામણ કરે છે.

જેનકિન્સ કેસ માટે, બિલ્ટ-ઇન પ્રમાણીકરણ ખૂબ નાજુક છે: જેનકિન્સમાં ક્યારેય બિલ્ટ-ઇન ઓથેન્ટિકેશન મિકેનિઝમનો ઉપયોગ કરશો નહીં. રોલ-આધારિત ઓથોરાઇઝેશન સ્ટ્રેટેજી ("RBAC") પ્લગઇન સાથે તૃતીય-પક્ષ મિકેનિઝમ (SAML, LDAP, Google …) પસંદ કરવું વધુ સારું છે. અને admin એકાઉન્ટ

કેવી રીતે કામ કરવું તેનું ધ્યાન રાખો અને pipeline જેનકિન્સમાં ફાઇલો હેન્ડલ કરવામાં આવે છે. સાથે પણ એવું જ કોડ તરીકે રૂપરેખાંકન પ્લગઇન અને તેની રૂપરેખા ફાઇલો, જે જેનકિન્સ રૂપરેખાંકનને લાગુ પડે છે.

સ્વ-હોસ્ટેડથી સ્થળાંતર 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 ના ટાર્ગેટ રિપોઝીટરીના સંદર્ભમાં ચાલે છે,
  • સ્રોતમાંથી પીઆર કોડ તપાસો, અવિશ્વસનીય રેપો,
  • કોઈપણ સ્ક્રિપ્ટને ટ્રિગર કરો જે PR નિયંત્રિત સામગ્રી પર કાર્ય કરી શકે છે, જેમ કે કિસ્સામાં npm install, અને
  • ટ્રિગરિંગ માટે શરતનો ઉપયોગ ન કરવો pull_request_target ઇવેન્ટ ફક્ત ત્યારે જ ચલાવવામાં આવશે જો કોઈ પ્રકારનું 'આ PR ચકાસાયેલ હતું' લેબલ PR ને સોંપવામાં આવ્યું હોય (બાહ્ય વપરાશકર્તાઓ PR ને લેબલ સોંપી શકતા નથી).

બીજું ઉદાહરણ અવિશ્વસનીય ઇનપુટ લે છે (કોઈ મુદ્દા, ટિપ્પણી અથવા pull request) ને પસાર કરાયેલ દલીલોના સ્ત્રોત તરીકે 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 વર્કફ્લોમાં અવિશ્વસનીય ઇનપુટ" સંપૂર્ણ વિગતો માટે.

વાર્તાનો નૈતિક સિદ્ધાંત: પહેલા PR ની સમીક્ષા કર્યા વિના ક્યારેય પણ અવિશ્વસનીય સ્ત્રોતોમાંથી PR ચેકઆઉટ કરશો નહીં અને બનાવો નહીં. અહીં 'અવિશ્વસનીય' નો અર્થ, જ્યાં સુધી મૂળના કઠોર પ્રમાણીકરણ હેઠળ ન હોય, તેનો અર્થ કોઈપણ સંભવિત રીતે હાઇજેક થયેલ ડેવલપર એકાઉન્ટ હોઈ શકે છે.

 

અહીં અનિચ્છનીય માલવેર જમાવટ!

સતત જમાવટ ઓટોમેશન ક્લાઇમેક્સ છે, પરંતુ તે ક્લાઇમેક્સ યોગ્ય મંજૂરી નિયંત્રણોના અભાવે નિરાશ થઈ શકે છે 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નબળા એક્શન અને સ્ક્રિપ્ટ્સ દૂર કરીને, અને વધારાના સુરક્ષા પરીક્ષણ પગલાંઓ સાથે, જે અમારા ડ્રોપર્સને પણ ચોરીછૂપીથી છુપાયેલા શોધી કાઢે છે, તે હવે થોડા વર્ષો પહેલા કરતાં થોડા વધુ મજબૂત છે. commits અને પેકેજો જે અમે હાઇજેક કર્યા હતા.

વાચક માટે પ્રશ્ન: શું સ્ત્રોતોમાંથી સોફ્ટવેર બનાવવાની અને ઉત્પાદનમાં જમાવટ કરવાની પ્રક્રિયા જોખમી વ્યવસાય છે? શું તમે તમારા DevOps ને આ તબક્કામાં જોઈ શકો છો? ખુબ સારા સમય ખરાબ લોકો માટે?

અંતિમ ભલામણો

ક્યાંથી શરૂઆત કરવી CI/CD pipelineઓ?

અહીં પહેલી ભલામણ સરળ છે: કાળજીપૂર્વક સમીક્ષા pipelines (તેઓ છે જટિલ સુરક્ષા મુદ્દાઓ માટે સંસાધનો). સમીક્ષાઓ ખર્ચાળ છે પરંતુ જરૂરી છે, અને તે યોગ્ય રીતે થવી જોઈએ. સમીક્ષકોએ શું જોવું તે અંગે જાગૃત હોવું જોઈએ. દરેક પગલામાં ખામીઓ માટે તપાસ કરવી જોઈએ.

કદાચ ઓટોમેટેડ દૂષિત કોડ સ્કેનર્સથી સજ્જ નિષ્ણાત સમીક્ષકોનું સંયોજન મદદ કરી શકે છે.

બીજી ભલામણ એ છે કે લખતા વિકાસકર્તાઓને તાલીમ આપો pipelineઅને તેમને સુરક્ષા પર જાળવી રાખોધ્યાનમાં રાખવા જેવી બાબતો:

  • લાંબા ગાળાના ઓળખપત્રોને હેન્ડલ કરવાના ઉપદ્રવને ટાળીને, આંતરિક અને ક્લાઉડ સેવાઓ સાથે પ્રમાણીકરણને યોગ્ય રીતે કેવી રીતે હેન્ડલ કરવું.
  • કેવી રીતે મર્યાદિત કરવું pipelineતેને જરૂરી સંસાધનોના ચોક્કસ સમૂહ સુધી પહોંચે છે. ઓછામાં ઓછા વિશેષાધિકારનો સિદ્ધાંત ફરીથી ચમકે છે.
  • બનાવવા માટેના પગલાં કેવી રીતે લખવા pipelineવર્ઝન પિનિંગની જેમ પુનઃઉત્પાદનક્ષમ, અને કમાન્ડ ઇન્જેક્શન નબળાઈઓને ટાળી શકાય છે.
  • સુરક્ષાના દૃષ્ટિકોણથી જમાવટને કેવી રીતે મંજૂરી આપવી (તેઓ અન્ય છે!): કઈ સુરક્ષા standards મેળ ખાતા હોવા જોઈએ અને તેમાં અનુરૂપ ચેક/ગેટ્સ કેવી રીતે ઉમેરવા pipelines.

ત્રીજી ભલામણ એ છે કે ગોઠવો CI/CD યોગ્ય કાળજી સાથે સિસ્ટમ. મજબૂત પ્રમાણીકરણ, કોઈ ડિફોલ્ટ પાસવર્ડ કે અસુરક્ષિત સેટિંગ્સ નહીં, ન્યૂનતમ વિશેષાધિકારો... ઇન્સ્ટોલ કરેલા પ્લગઇન્સ અને એક્સટેન્શનમાં નબળાઈઓનું ધ્યાન રાખો. આ આગામી પોસ્ટ્સનું કેન્દ્રબિંદુ હોઈ શકે છે, કૃપા કરીને ટ્યુન કરતા રહો.

ચોથી ભલામણ એ છે કે લાભ મેળવો CI/CD pipelineસુરક્ષા ઓટોમેશન માટે s. સોર્સ કોડ વિશ્લેષણ (SAST), સ્ત્રોત રચના વિશ્લેષણ (SCA), સિક્રેટ લીક્સ સ્કેનિંગ, એન્ટી-માલવેર ટૂલ્સ, કન્ટેનર સિક્યુરિટી સ્કેનર્સ, અથવા ઓટોમેટેડ રનટાઇમ ડિટેક્ટર (DAST અને માલવેર) નિયમિત રૂપે ચલાવી શકાય છે. pipeline. અને તમારી સંસ્થા standardસુરક્ષા સ્કેનિંગ પર કવરેજ વિશે CI/CD.

યાદ અપાવો, આ સાધનો હજુ સુધી સમીકરણમાંથી નિષ્ણાત સમીક્ષાને દૂર કરતા નથી, નહીં તો તમને સુરક્ષાની ખોટી ભાવના થઈ શકે છે.

જો તમે OWASP ટોપ-ટેન્સમાં પારંગત છો, તો તાજેતરનો એક સરસ પ્રોજેક્ટ છે OWASP ટોપ 10 CI/CD સુરક્ષા જોખમ.

અસ્વીકરણ નોંધ

(૧) આ પોસ્ટમાં આપેલા ઉદાહરણો GitHub નો ઉપયોગ આ રીતે કરી રહ્યા છે SCM, ક્લાઉડ પ્રદાતા તરીકે AWS, અને GitHub Actions અથવા Jenkins તરીકે CI/CD સાધન. તેઓ તેમના વિકલ્પો કરતાં નબળા / સલામત નથી. કોઈ ખરાબ પ્રેસ ઇરાદો નથી! આ સાધનો શક્તિશાળી છે અને તેનો યોગ્ય રીતે ઉપયોગ કરવાની જરૂર છે.

(2) એમ3એમ3એન70 અને સ્વેમ્પ રેજ કાલ્પનિક પાત્રો છે. વ્યક્તિઓ કે જૂથો સાથે કોઈ સામ્યતા, જીવિત કે મૃત્યુ, ફક્ત સંયોગ છે... કે શું તે છે?

વધુ વાંચવા માટે

સ્કા-ટૂલ્સ-સોફ્ટવેર-રચના-વિશ્લેષણ-ટૂલ્સ
તમારા સોફ્ટવેર જોખમોને પ્રાથમિકતા આપો, સુધારણા કરો અને સુરક્ષિત કરો
તમારું મફત ખાતું મેળવો.
કોઈ ક્રેડિટ કાર્ડ જરૂરી નથી.
મફતમાં શરૂઆત કરો

તમારા સોફ્ટવેર ડેવલપમેન્ટ અને ડિલિવરી સુરક્ષિત કરો

ઝાયજેની પ્રોડક્ટ સ્યુટ સાથે

મફતમાં શરૂઆત કરો
પ્રોડક્ટ ટૂર લો
ઝીગેની લોગો સફેદ

© ૨૦૨૬ ઝીજેની. બધા હકો અમારી પાસે રાખેલા છે.

લિંક્ડિન-ઇન એક્સ-ટ્વિટર યૂટ્યૂબ

પ્રોડક્ટ્સ

સંપત્તિ

કંપની

કાનૂની