ምን ሊበላሽ ይችላል CI/CD pipelines?

ቀጣይነት ያለው ውህደት እና ቀጣይነት ያለው አቅርቦት (CI/CD) pipelineኤስ ሶፍትዌርን በ"ዘመናዊ" መንገድ የሚገነባ የማንኛውም የሶፍትዌር ድርጅት መሠረት ናቸው። አውቶሜሽን ከፍተኛ ኃይል ይሰጣል፣ ነገር ግን አብዛኛዎቹ ገንቢዎች የሚያስፈልገውን ኃላፊነት ያጣሉት።

ገንቢ: አዎ፣ እንወስዳለን CI/CD መያዣ በቁም ነገር እና በኮድ ጠባቂዎች ላይ ጠንካራ ቁጥጥር አለዎት፣ ይገምግሙ commitከመዋሃድ በፊት፤ ስራዎች እና pipelineበከፍተኛ ሰራተኞች የሚጠበቁ ናቸው፣ በክፍል ውስጥ ሚስጥሮችን እንዳያወጡ ይጠብቃሉ pipelineዎች. እና መሳሪያው የተገጠመው ነገሩን በሚያውቁ ሰራተኞች ነው። ምን ችግር ሊፈጠር ይችላል?

ውድ ገንቢ፣ CI/CD ስርዓቶቹ ውስብስብ ናቸው። ሰፊው የጥቃት ገጽታው ጎጂ ተዋናዮችን ይስባል። መጠንቀቅ እና ከልክ በላይ በራስ መተማመንን ፈጽሞ አለመጠቀም የተሻለ ነው።

ነባሪ ውቅር አንዳንድ ጊዜ ይቀመጣል እና ለጠላፊዎች ምርጥ ጓደኛ ይሆናል። ወሳኝ ጉድለቶች በ ውስጥ ሊኖሩ ይችላሉ CI/CD pipeline ምንጮች፣ በስርዓቱ ውቅር ውስጥ፣ ወይም በሂደቱ እና አውድ ዙሪያ pipeline እና እንዴት እንደሚነቃ።

በዚህ ጽሑፍ ውስጥ እራሳችንን በመጥፎ ተዋናዮች ቦታ እናስቀምጣለን። የ""ን ሀሳቦች እያነበብን እንደሆነ አስቡት። M3M3N70 (ሜሜንቶ ሞሪ?) እና የስዋምፕ ቁጣ በጨለማ ድር ውስጥ፣ ምናልባትም በምዕራባውያን ቋንቋ ያልሆነ፣ ነገር ግን ክፋት በዓለም ዙሪያ መስፋፋቱን ፈጽሞ አታመልጥ።

በድሮ ዘመን በጣም ቀላል ነበር…

M3M3N70፦ ወደ ጥሩው የድሮ ዘመን ስንመለስ ንግዳችን በጣም ቀላል ነበር… ዜሮ-ቀናት ዝቅተኛ ፍሬ ነበሩ፣ መተግበሪያዎች በቀላሉ ጥቅም ላይ ሊውሉ የሚችሉ ብልግናዎች ባሉባቸው ክፍት ነበሩ፣ እና በፍጥነት ወደ ጎን መንቀሳቀስ እንችል ነበር።

የስዋምፕ ቁጣ: ፉ#@ሲኦል! አንዳንድ ጥንቸሎች ገና እዚያ ነበሩ፣ ነገር ግን ነገሮች ተለውጠዋል። ትልልቅ ሰዎች በዚያ የAppSec ስራ ላይ ብዙ ጥርጣሬ ጣሉ።

M3M3N70አዎ። ግን አዲሶቹ ሞኞች ገንቢዎቹ ናቸው። ለእኛ፣ እነዚህ ሰዎች የሚጠቀሙባቸውን መሳሪያዎች መጠቀም ቀላል ሆኖልናል። በተለይም 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 ቁልፎች፣ መጠቀም የበለጠ አስተማማኝ ነው የOpenID Connect (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 መሳሪያዎች አንዱ።

የስዋምፕ ቁጣበጄንኪንስ ውስጥ ያለውን “ደህንነትን አንቃ” የሚል ሳጥን ታስታውሳለህ፣ እና ስንት ድርጅቶች ለምቾት ሲባል እንዳይነቃቁ እንደመረጡ ታስታውሳለህ? እና እነዚያ “ማንኛውም ሰው ማንኛውንም ነገር ማድረግ ይችላል"የፈቃድ ጥምረቶች እንደ ነባሪ?" እና እነዚያ አስቸጋሪ የጄንኪንስ ተሰኪዎች፣ እንደ የጂትሆብ OAuth ተሰኪያዋቀረው ሰው ሁለቱንም "ለሁሉም የተረጋገጡ ተጠቃሚዎች የንባብ ፈቃዶችን ይስጡ" እና "የጂቲሃብ ማከማቻ ፈቃዶችን ይጠቀሙ" መርጦ ሁሉንም ፕሮጀክቶቻቸውን እንድንደርስ ያስችለናል።

(ይቅርታ ጄንኪንስ፣ እንደ ምሳሌ ስለገለጽክልንህ 😉

የደህንነት መርሆዎችን ጠንቅቀው (ሱስ እንኳን) ያዳብሩ። አንደኛው በነባሪነት ደህንነቱ የተጠበቀ መርህ፡ መቆጣጠሪያዎች በተቻለ መጠን በጣም ደህንነታቸው በተጠበቀ ሁኔታ ወደተቀመጡት ቅንብሮች በነባሪነት መመረጥ አለባቸው። ደህንነት የተገነባ መሆን አለበት CI/CD መሳሪያዎች እና pipelineከመሠረቱ ጀምሮ፣ ከኋላ ማሰብ ሳይሆን። ነገር ግን ለተጠቃሚ ምቹነት እና ምቾት ብዙውን ጊዜ ከደህንነት ጋር ይጋጫሉ።

ለጄንኪንስ ጉዳይ፣ አብሮ የተሰራ ማረጋገጫ በጣም ደካማ ነው፡ በጄንኪንስ ውስጥ አብሮ የተሰሩ የማረጋገጫ ዘዴዎችን በጭራሽ አይጠቀሙ. የሶስተኛ ወገን ዘዴ (SAML፣ LDAP፣ Google …)፣ በሚና ላይ የተመሠረተ የፈቃድ ስትራቴጂ (“RBAC”) ተሰኪ በመጠቀም መምረጥ የተሻለ ነው። እና በ admin መለያ.

እንዴት እንደሚሰራ እና እንዴት እንደሚሰራ ጥንቃቄ ያድርጉ pipeline በጄንኪንስ ውስጥ ያሉ ፋይሎች ይስተናገዳሉ። ከ ጋርም ተመሳሳይ ነው የውቅር-እንደ-ኮድ ተሰኪ እና የጄንኪንስ ውቅርን የሚመለከቱ የውቅር ፋይሎቹ።

ከራስ-አስተናጋጅነት ወደ ሌላ ቦታ በመዛወር ላይ CI/CD በደመና ላይ የተመሰረቱ SaaS ስርዓቶች በድርጅቱ አውታረ መረብ ውስጥ የጎን እንቅስቃሴን የሚፈቅዱ አንዳንድ ሊሆኑ የሚችሉ አደጋዎችን ያስወግዳል፣ ነገር ግን እንደ ነባር ውስጣዊ ስርዓቶች እና ውጫዊ ስርዓቶች መካከል ውጫዊ ግንኙነቶችን መክፈት ያሉ ሌሎችንም አክሏል። CI/CD መሣሪያ.

ድርጅቶች ሊያደርጉት የሚገባ ተግባርcisበማጠናከር ረገድ ተገቢው ጥንቃቄ CI/CD ስርዓቱ፣ በጣም ገዳቢ በሆኑ ቅንብሮች በመጀመር እና ቀስ በቀስ አስፈላጊዎቹን ፈቃዶች በመጠቀም ለስርዓቱ ክፍት ይሆናል pipeline እርምጃዎች.

ደህንነትን በ ውስጥ ማዋቀር CI/CD መሳሪያዎች ውስብስብ ተግባር ሊሆኑ ይችላሉ። ብዙዎቹ አብዛኛዎቹ ተጋላጭነቶች ያሏቸው እና መዘመን የሚያስፈልጋቸው ተሰኪዎች ወይም ቅጥያዎች አሏቸው።

ለእንደዚህ አይነት ውስብስብ መሳሪያዎች ወይም መለኪያዎች የደህንነት የተሳሳተ ውቅር ስካነሮች ሊረዱ ይችላሉ።

ኮድ በማስገባት ላይ pipeline ለደስታ እና ለትርፍ ትዕዛዞች

M3M3N70፦ ለትእዛዝ-መርፌ ተጋላጭ የሆኑ ተጋላጭ ድርጊቶችን እና ስክሪፕቶችን የሚጠቀሙበትን የማይታመን የኮድ ቼኮችን ተጠቅመህ ታውቃለህ?

ይህ ክፍል የሚያሳየው ይህንን ነው pipeline እሱ ራሱ መጥፎ ተዋናዮች የዘፈቀደ የኮድ አፈፃፀምን በኮድ ውስጥ እንዲገቡ የሚያስችሏቸው የኮድ ስህተቶች ሊኖሩት ይችላል pipeline ሳይቀይሩት pipeline ምንጭ ራሱለምሳሌ የህዝብ ግንኙነት ግንኙነትን በመጠቀም

የአንድ ሰው የመጀመሪያ ምሳሌ አሳዛኝ የጂቲሃብ የስራ ፍሰት:

# 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 ኮዱን ይመልከቱ፣ የማይታመን ማከማቻ፣
• በPR ቁጥጥር በሚደረግባቸው ይዘቶች ላይ ሊሰራ የሚችል ማንኛውንም ስክሪፕት ያስነሱ፣ ለምሳሌ npm install, እና
• ለቀስቀሳው ሁኔታ አለመጠቀም pull_request_target ክስተቱ የሚካሄደው 'ይህ የህዝብ ግንኙነት विषां ተረጋግጧል' የሚል መለያ ለህዝብ ግንኙነት ከተሰጠ ብቻ ነው (የውጭ ተጠቃሚዎች መለያዎችን ለህዝብ ግንኙነት መስጠት አይችሉም)።

ሁለተኛው ምሳሌ የማይታመን ግብዓትን ይወስዳል (ከአንድ ጉዳይ፣ አስተያየት ወይም pull request) ለተላለፈው ክርክር ምንጭ ሆኖ pipeline በቃላት አገላለጾች በኩል ትዕዛዝ። ይህ pipeline የስርዓተ ክወና ትዕዛዝ መርፌ ተጋላጭነት ስሪት።

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

የሩጫ ክዋኔው በአብነት ላይ የተመሠረተ ጊዜያዊ የሼል ስክሪፕት ያመነጫል፣ ከ $ ተክቷል፣ ይህም ለሼል ትዕዛዝ መርፌ ተጋላጭ ያደርገዋል። የውሸት የጂቲቢ መለያ ያለው አጥቂ በርዕስ ላይ ችግር ሊፈጥር ይችላል a"; bad_code_goes_here;#እና ቡም! 

የስዋምፕ ቁጣኦህ፣ እነዚያ ሰዎች አንድ ችግር በመክፈት ብቻ የኮማንድ መርፌን በሩን እየከፈቱ ነበር…

በጂትሆብ እርምጃዎች ውስጥ የኮድ አፈፃፀም ተጋላጭነቶች ነበሩ፣ ለምሳሌ gajira-commentአሁን ተስተካክሏል። እባክዎ ያንብቡ «በጂትሆብ የስራ ፍሰቶች ውስጥ የማይታመን ግብዓት» ለተሟላ ዝርዝሮች.

የታሪኩ የሞራል ሁኔታ፡- መጀመሪያ የህዝብ ግንኙነትን ሳይገመግሙ ከማይታመኑ ምንጮች የ PR ግዢ ፈጽመው በጭራሽ አይፈጽሙ። እዚህ ላይ 'ያልታመነ'፣ በአስቸጋሪ ሁኔታ የመነሻ ማረጋገጫ ስር ካልሆነ በስተቀር፣ ማንኛውም የተጠለፈ የገንቢ መለያ ማለት ሊሆን ይችላል።

ያልታሰበ የማልዌር ማሰማራት እዚህ አለ!

ቀጣይነት ያለው ማሰማራት የአውቶሜሽን መደምደሚያ ነው፣ ነገር ግን ያ መደምደሚያ በጉዳዩ ላይ ተገቢ የማረጋገጫ ቁጥጥር ባለመኖሩ ሊበሳጭ ይችላል pipeline ፍሰት.

ከምንጩ ሙሉ በሙሉ በራስ-ሰር የማሰማራት አደጋዎች commit የምርት ስርዓቶች ተንኮል አዘል ኮድ ሳይታወቅ ወደ ምርት አካባቢዎች የመሰማራት አቅምን እንዲሁም በማሰማራት ሂደት ውስጥ ያሉ ስህተቶች መስተጓጎል ወይም መቋረጥ ሊያስከትሉ የሚችሉበትን አቅም ያካትታሉ።

እነዚህን አደጋዎች ለመቀነስ ድርጅቶች ብዙውን ጊዜ በማሰማራት ሂደታቸው ውስጥ "ጠንካራ እረፍት" እንዲተገብሩ ይመከራል፣ ይህም የሚጠይቀውን የሰው ይሁንታ ወደ መጨረሻ አካባቢዎች ከመሰማራቱ በፊት።

በሮችን እየዘጉ ነው

የስዋምፕ ቁጣ: እነዚያ አስደሳች ነባሪ የይለፍ ቃሎች በ ውስጥ CI/CD መሳሪያዎች እየተሰረዙ ነው። መድረስ /var/lib/jenkins/secrets/initialAdminPassword አሁን የማይረባ መንገድ ነው። ብዙ መሳሪያዎች አሁን 2FA እያቀረቡ ነው፣ ይህም ኮቪድ ተወዳጅ ያደረጋቸው፣ እና እዚያ ያለው በጣም ሰነፍ የኮድ ጦጣ እንኳን እየተጠቀመበት ነው!

M3M3N70፦ 2FA እየተዋጋን ነው፣ ግን ያን ያህል ቀላል አይደለም። እነዚያን ሰዎች በፊሽካ ማጥመድ ከባድ ነው፣ ምክንያቱም "ስኳተር ስዋይን" በትዊሊዮ ያደረገውበWebAuthn ቁልፎች በጣም ከባድ ነው። ቢያንስ፣ መሞከር እንችላለን ኤምኤፍኤውን ለማለፍ ኩኪዎችን መስረቅግን ወደ ገንቢው ሳጥን ውስጥ መግባት ያስፈልጋል።

ባለብዙ-ደረጃ ማረጋገጫ የማረጋገጫ ሚስጥሮች የሚፈሱበትን አደጋ ለመገደብ በትክክለኛው አቅጣጫ ጥሩ እርምጃ ነው። አብዛኛዎቹ ዘመናዊ የDevOps መሳሪያዎች MFAን ይደግፋሉ። እና በWebAuthn / U2F ስር የማረጋገጫ ቁልፎችን ይመልከቱ (ይመልከቱ) የFIDO2 ፕሮጀክት) በአግባቡ ከተቀናበረ በDevOps ውስጥ ለMFA በጣም ጥሩው አማራጭ ሊሆኑ ይችላሉ።

የስዋምፕ ቁጣየዴቭኦፕስ ሰዎች እየተነቁ ነው። በደማቸው ውስጥ “ዝቅተኛ መብት” የሚባል ነገር አላቸው። እና ከእንግዲህ የኮድ ጦጣዎች አይደሉም። አሁን በገምጋሚዎች እጅ ወድቀን እንገኛለን።

በእውነቱ, pipelineዎች አሁን ከጥቂት ዓመታት በፊት ከነበሩት ይልቅ ትንሽ ጠንካራ ናቸው፣ ደካማ እርምጃዎች እና ስክሪፕቶች ተወግደዋል፣ እና ተጨማሪ የደህንነት ሙከራ ደረጃዎችን በመጠቀም ጠብታዎቻችንን በድብቅ ተደብቀው ለይተው አውቀዋል። commitዎች እና ፓኬጆችን ጠልፈናል።

ለአንባቢው ጥያቄ፡- ሶፍትዌሩን ከምንጮች የመገንባት እና ወደ ምርት የማሰማራት ሂደት አደገኛ ንግድ ነው? የእርስዎን DevOps ደረጃ ላይ ማየት ይችላሉ? መልካም ጊዜያት ለክፉዎች?

የመጨረሻ ምክሮች

ከየት መጀመር ይቻላል? CI/CD pipelines?

የመጀመሪያው ምክር እዚህ ቀላል ነው፡ በጥንቃቄ ግምገማ pipelines (እነሱ ናቸው ወሳኝ ለደህንነት ጉዳዮች) ግብዓቶች። ግምገማዎች ውድ ናቸው ግን አስፈላጊ ናቸው፣ እና በአግባቡ መከናወን አለባቸው። ገምጋሚዎች ምን መመልከት እንዳለባቸው ማወቅ አለባቸው። እያንዳንዱ እርምጃ ጉድለቶች መኖራቸውን ማረጋገጥ አለበት።

ምናልባት በራስ-ሰር ተንኮል አዘል የኮድ ስካነሮችን የታጠቁ የባለሙያ ገምጋሚዎች ጥምረት ሊረዳ ይችላል።

ሁለተኛው ምክረ ሀሳብ ደግሞ የሚጽፉ ገንቢዎችን ያሠለጥኑ pipelineእና በደህንነት ላይ እንዲቆዩ ማድረግሊታሰቡባቸው የሚገቡ ነገሮች፡

• የረጅም ጊዜ የምስክር ወረቀቶችን ከመያዝ ጋር ተያይዞ የሚመጣውን ችግር በማስወገድ ውስጣዊ እና የደመና አገልግሎቶችን በመጠቀም ማረጋገጫን እንዴት በአግባቡ መያዝ እንደሚቻል።
• እንዴት መገደብ እንደሚቻል pipelineመድረስ ወደሚያስፈልጋቸው ትክክለኛ የሀብት ስብስብ። የዝቅተኛ መብት መርህ እንደገና ያበራል።
• የዝግጅት ደረጃዎችን እንዴት እንደሚጽፉ pipelineእንደ ስሪት ፒንኒንግ እና የትዕዛዝ መርፌ ተጋላጭነቶችን ማስወገድ ያሉ ሊባዛ የሚችል።
• ከደህንነት አንፃር ማሰማራትን እንዴት ማፅደቅ እንደሚቻል (ሌሎች ናቸው!): የትኛው ደህንነት standardዎች መዛመድ አለባቸው እና ተጓዳኝ ቼኮችን/በሮችን እንዴት ማከል እንደሚቻል በ pipelines.

ሦስተኛው ምክረ ሀሳብ ደግሞ ማዋቀር CI/CD ስርዓት በጥንቃቄጠንካራ ማረጋገጫ፣ ነባሪ የይለፍ ቃሎች ወይም ደህንነታቸው ያልተጠበቁ ቅንብሮች፣ አነስተኛ መብቶች… በተጫኑ ተሰኪዎች እና ቅጥያዎች ውስጥ ያሉ ተጋላጭነቶችን ይጠንቀቁ። ይህ የሚከተሉት ልጥፎች ትኩረት ሊሆን ይችላል፣ እባክዎን ይከታተሉ።

አራተኛው ምክረ ሀሳብ ደግሞ መጠቀም CI/CD pipelineለደህንነት አውቶሜሽን sየምንጭ ኮድ ትንተና (SAST)፣ የምንጭ ቅንብር ትንተና (SCA)፣ የሚስጥር ፍንጮች ቅኝት፣ ፀረ-ማልዌር መሳሪያዎች፣ የኮንቴይነር ደህንነት ስካነሮች ወይም አውቶማቲክ የሩጫ ጊዜ መመርመሪያዎች (DAST እና ማልዌር) በ... ላይ በመደበኛነት ሊሰሩ ይችላሉ። pipelineእና ድርጅትዎ ሊያስፈጽም ይችላል standardበደህንነት ቅኝት ላይ ስላለው ሽፋን ዎች CI/CD.

ያስታውሱ፣ እነዚህ መሳሪያዎች የባለሙያዎችን ግምገማ ከእኩልታው አያስወግዱም፣ አለበለዚያ የተሳሳተ የደህንነት ስሜት ሊኖርዎት ይችላል።

የ OWASP ከፍተኛ-አስርዎችን ልምድ ካሎት፣ በቅርብ ጊዜ የተገኘ ጥሩ ፕሮጀክት ነው OWASP ከፍተኛ 10 CI/CD የደህንነት ስጋት.

የኃላፊነት ማስተባበያ ማስታወሻ

(1) በዚህ ጽሑፍ ውስጥ ያሉት ምሳሌዎች GitHub ን እንደ SCM, AWS እንደ የደመና አቅራቢ፣ እና GitHub Actions ወይም Jenkins እንደ CI/CD መሳሪያ። ከአማራጫዎቻቸው ደካማ/ደህንነታቸው የተጠበቀ አይደለም። መጥፎ የፕሬስ አላማ የለም! እነዚህ መሳሪያዎች ኃይለኛ ናቸው እና በአግባቡ ጥቅም ላይ መዋል አለባቸው።

(2) M3M3N70 ና የስዋምፕ ቁጣ ልብ ወለድ ገፀ-ባህሪያት ናቸው። ከሰዎች ወይም ከቡድኖች ጋር የሚመሳሰል ማንኛውም ነገር፣ መኖርም ሆነ ሞት፣ እንዲሁ በአጋጣሚ ነው… ወይስ ነው?

የበለጠ ለማንበብ

• ሃይሞር፣ ኤ. እና ሌሎችም። "እኛ እንዴት እንደተደራደርን የሚያሳዩ 10 እውነተኛ ታሪኮች" CI/CD pipelineዎች ”. የኤንሲሲ ግሩፕ፣ ጥር 2022።
• configure-aws-credentials የጂትሃብ እርምጃ ና በአማዞን የድር አገልግሎቶች ውስጥ የOpenID አገናኝን ማዋቀር በ GitHub የስራ ፍሰቶች ውስጥ ለማሰማራት የAWS ትዕዛዞችን እንዴት ማስኬድ እንደሚቻል ዝርዝሮችን ለማግኘት።
• ሎባሴቭስኪ ጄ. "የጂቲኤችቲ እርምጃዎችዎን እና የስራ ፍሰቶችዎን ደህንነቱ የተጠበቀ ማድረግ ክፍል 1፡ የፕውን ጥያቄዎችን መከላከል". የጊትላብ ደህንነት ላብራቶሪ፣ ታህሳስ 2020።
• ሎባሴቭስኪ ጄ. «የGitHub እርምጃዎችዎን እና የስራ ፍሰቶችዎን ደህንነቱ የተጠበቀ ማድረግ ክፍል 2፡ የማይታመን ግብዓት». የጊትላብ ደህንነት ላብራቶሪ፣ ጥር 2021።
• ኦዋስፕ። «የOWASP 10 ምርጥ CI/CD የደህንነት አደጋዎች "". ጁላይ 2022።
• ሳልትዘር ጄ. እና ሽሮደር ኤም. "በኮምፒውተር ስርዓቶች ውስጥ የመረጃ ጥበቃ"ኤፕሪል 1975። የደህንነት መርሆዎች በቴክኖሎጂ ተሻሽለዋል፣ ነገር ግን ከ47 ዓመታት በኋላ አብዛኛዎቹ የS&S ሀሳቦች አሁንም ተግባራዊ ሆነዋል።
• የዩኬ ኤንሲኤስሲ። "ግንባታውን እና ማሰማራቱን ይጠብቁ pipeline"የዩኬ ብሔራዊ የሳይበር ደህንነት ማዕከል፣ የካቲት 2019።