Xygeni-ს ლოგო თეთრი
დაიწყე უფასო
დაჯავშნეთ დემო

რა შეიძლება არასწორად წავიდეს CI/CD pipelines?

სარჩევი

აუცილებლად წასაკითხი პოსტები

უწყვეტი ინტეგრაცია და უწყვეტი მიწოდება (CI/CD) pipelines წარმოადგენს ნებისმიერი პროგრამული უზრუნველყოფის ორგანიზაციის საფუძველს, რომელიც პროგრამულ უზრუნველყოფას „თანამედროვე“ გზით ქმნის. ავტომატიზაცია დიდ ძალას იძლევა, მაგრამ დეველოპერების უმეტესობა ვერ აცნობიერებს მის მიერ მოტანილ პასუხისმგებლობას.

შემქმნელი: კი, ვიღებთ CI/CD უსაფრთხოების სერიოზულად და ძლიერი კონტროლი კოდის შემნახველებზე, გადახედეთ commitშერწყმამდე; სამუშაოები და pipelineს-ებს უფროსი პერსონალი ინარჩუნებს, ისინი ზრუნავენ იმაზე, რომ საიდუმლოებები არ გაჟონოს. pipelineს. და ხელსაწყო დაამონტაჟა პერსონალმა, რომელიც ამ საკითხში ჩახედულია. რა შეიძლება იყოს არასწორი?

ძვირფასო დეველოპერო, CI/CD სისტემები რთულია. მისი ფართო შეტევის ზედაპირი იზიდავდა ბოროტმოქმედ მოთამაშეებს. უმჯობესია იყოთ ფრთხილად და არასდროს იყოთ ზედმეტად თავდაჯერებული.

ნაგულისხმევი კონფიგურაცია ზოგჯერ შენარჩუნებულია და ჰაკერების საუკეთესო მეგობარი ხდება. კრიტიკული ხარვეზები შეიძლება იყოს. CI/CD pipeline წყაროები, სისტემის კონფიგურაციაში ან პროცესისა და კონტექსტის გარშემო pipeline და როგორ ხდება მისი გააქტიურება.

ამ პოსტში ჩვენ თავს ცუდი მსახიობების ადგილას წარმოვიდგენთ. წარმოიდგინეთ, რომ ვკითხულობთ... M3M3N70 (მემენტო მორი?) და ჭაობის მძვინვარება სადღაც ბნელ ქსელში, სავარაუდოდ არადასავლურ ენაზე, მაგრამ არასოდეს გამოტოვოთ, რომ ბოროტება მთელ მსოფლიოშია გავრცელებული.

 

ძველ, კარგ დროში ეს ძალიან მარტივი იყო...

M3M3N70ძველ, კარგ დროს რომ დავუბრუნდეთ, ჩვენი საქმე ძალიან მარტივი იყო... ნულოვანი დღეები ადვილად გამოსაყენებელი იყო, აპლიკაციები ფართოდ იყო ხელმისაწვდომი, ადვილად გამოსაყენებელი დაუცველობებით და მყისიერად შეგვეძლო გვერდითი ნაბიჯების გადადგმა.

ჭაობის მძვინვარებაჯანდაბა! ზოგი უკვე გიჟია, მაგრამ ყველაფერი შეიცვალა. დიდმა ბიჭებმა დიდი ფული ჩადეს AppSec-ის ამ ნაგავში.

M3M3N70: კი. მაგრამ ახალი სულელები დეველოპერები არიან. ჩვენთვის უფრო ადვილი იყო იმ ხელსაწყოების გამოყენება, რომლებსაც ეს ბიჭები იყენებენ. კერძოდ, 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.

შესაძლოა, ძველი კარგი დრო გიტის ისტორიაში პოვნა იყო .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 კლავიშები მუშაობდა! ჯერ აპლიკაციაში inocuos-ის ცვლილება გამოვცადეთ, შემდეგ კი დავამატეთ sting, რადგან იმ ბიჭებმა, როგორც ჩანს, არაფერი იცოდნენ. ბინგო! რა კამპანია იყო...

ბოროტმოქმედმა უბრალოდ გამოიყენა AWS გასაღებები მავნე პროგრამით მოდიფიცირებული აპლიკაციის ასატვირთად და შემდეგ ასეთი ავტორიზაციის გამოყენებით შეასრულა deploy ბრძანება. გაჟონილი საიდუმლოებები, მასში შემავალ ინფორმაციასთან ერთად, pipeline„რა კამპანია!“ ალბათ იმას ნიშნავდა, რომ მემენტომ საწყალი მსხვერპლი ქაოსში ჩააგდო.

Memento აქ გვეუბნება, რომ საიდუმლო გაჟონვის შემდეგ, მაგალითად, AWS წვდომის გასაღებების მსგავსად, თქვენ უნდა გააუქმოთ საიდუმლო (შეცვალოთ ზემოთ მოცემული გასაღებები). სასწრაფოდყოველთვის არსებობს ექსპოზიციის ფანჯარა გაჟონვას შორის commit და საიდუმლო ბათილად ცნობა; Git-ის ისტორიის გადაწერა რთულია (ისტორიის ასეთი გადაწერა ყველაზე მკაცრი ავტორიტარული სახელმწიფოც კი ცდილობდა, თუმცა უშედეგოდ) და, სავარაუდოდ, არაეფექტური (შესაძლოა, ჩვენმა მეგობრებმა საიდუმლო გაჟონვის საცავამდე კლონირება მოახდინეს) 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>'"

ბაკეტი, სავარაუდოდ, შეიქმნა უზრუნველყოფის შაბლონში, რომლის უსაფრთხოების ხარვეზების ავტომატურად სკანირებაც შეიძლებოდა.

ხელსაწყოს ნაგულისხმევი კონფიგურაცია ჩვენთვის სათამაშო იყო

კონკრეტული მაგალითების მოსაყვანად, მოდით ვისაუბროთ Jenkins, ერთ-ერთი ყველაზე პოპულარული CI ინსტრუმენტი.

ჭაობის მძვინვარებაგახსოვთ ჯენკინსში „უსაფრთხოების ჩართვის“ ველი და რამდენმა ორგანიზაციამ აირჩია მისი არ გააქტიურება მოხერხებულობის მიზნით? და ეს „ნებისმიერს შეუძლია ნებისმიერი რამის გაკეთება„ნებართვების კომბინაციები ნაგულისხმევად?“ და ის შემაწუხებელი Jenkins-ის დანამატები, როგორიცაა GitHub OAuth დანამატიკონფიგურაციის ავტორმა აირჩია როგორც „ყველა ავტორიზებული მომხმარებლისთვის წაკითხვის ნებართვის მინიჭება“, ასევე „GitHub საცავის ნებართვების გამოყენება“, რამაც მოგვცა წვდომა მათ ყველა პროექტზე.

(ბოდიშს გიხდი, ჯენკინს, რომ შენ მაგალითად მოგიყვანე 😉)

უსაფრთხოების პრინციპების დაცვა (თუნდაც დამოკიდებულების შენარჩუნება) აუცილებელია. ერთ-ერთი მათგანია ნაგულისხმევად დაცულია პრინციპი: კონტროლი ნაგულისხმევად უნდა იყოს დაყენებული ყველაზე უსაფრთხო პარამეტრებზე. უსაფრთხოება უნდა იყოს ჩაშენებული CI/CD ინსტრუმენტები და pipelineნულიდან დაწყებული და არა მეორეხარისხოვანი. თუმცა, მომხმარებლისთვის მოსახერხებელი და მოსახერხებელი დიზაინი ხშირად უსაფრთხოებას ეწინააღმდეგება.

ჯენკინსის შემთხვევაში, ჩაშენებული ავთენტიფიკაცია ძალიან მყიფეა: არასოდეს გამოიყენოთ ჯენკინსში ჩაშენებული ავტორიზაციის მექანიზმებიუმჯობესია აირჩიოთ მესამე მხარის მექანიზმი (SAML, LDAP, Google...), როლებზე დაფუძნებული ავტორიზაციის სტრატეგიის („RBAC“) მოდულით. და განსაკუთრებული სიფრთხილე გამოიჩინეთ. admin ანგარიშზე.

იზრუნეთ სამუშაოზე და pipeline ფაილები დამუშავდება Jenkins-ში. იგივე ეხება კონფიგურაციის-როგორც-კოდის-მოდული და მისი კონფიგურაციის ფაილები, რომლებიც გამოიყენება Jenkins-ის კონფიგურაციისთვის.

თვითორგანიზებული ჰოსტინგიდან გადასვლა CI/CD ღრუბელზე დაფუძნებულ SaaS სისტემებზე გადასვლა გამორიცხავს ზოგიერთ პოტენციურ რისკს, რომელიც ორგანიზაციის ქსელში გვერდითი მოძრაობის საშუალებას იძლევა, მაგრამ დამატებულია სხვა რისკებიც, როგორიცაა გარე კავშირების გახსნა არსებულ შიდა სისტემებსა და გარეგანიზებულ სისტემებს შორის. CI/CD ინსტრუმენტი.

ორგანიზაციებმა უნდა განახორციელონcisგამკვრივებისას სათანადო სიფრთხილე გამოიჩინეთ CI/CD სისტემა, დაწყებული ყველაზე შემზღუდავი პარამეტრებით და თანდათანობით გახსნილი მინიმალური საჭირო ნებართვებით pipeline ნაბიჯები.

უსაფრთხოების კონფიგურაცია CI/CD ინსტრუმენტები შეიძლება რთული იყოს. ბევრ მათგანს აქვს დანამატები ან გაფართოებები, რომლებსაც აქვთ დაუცველობის უმეტესობა და საჭიროებენ განახლებას.

ასეთი რთული ინსტრუმენტებისთვის უსაფრთხოების არასწორი კონფიგურაციის სკანერები ან საორიენტაციო ტესტები შეიძლება დაგეხმაროთ.

კოდის შეყვანა pipeline ბრძანებები გართობისა და მოგებისთვის

M3M3N70ოდესმე გამოგიყენებიათ არასანდო კოდის შემოწმება, რომელიც დაუცველია ბრძანების ინექციის მიმართ?

ეს განყოფილება აჩვენებს, რომ 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 კოდი წყაროდან, არასანდო საცავი,
  • ნებისმიერი სკრიპტის გააქტიურება, რომელიც შეიძლება მუშაობდეს PR-ის მიერ კონტროლირებად შინაარსზე, მაგალითად, npm installდა
  • ტრიგერისთვის პირობის არ გამოყენება pull_request_target ღონისძიება შესრულდება მხოლოდ იმ შემთხვევაში, თუ PR-ს მინიჭებული აქვს რაიმე სახის „ეს PR შემოწმებულია“ იარლიყი (გარე მომხმარებლებს არ შეუძლიათ PR-სთვის იარლიყების მინიჭება).

მეორე მაგალითი იღებს არასანდო შეყვანას (პრობლემიდან, კომენტარიდან ან pull request) როგორც წყარო არგუმენტებისთვის, რომლებიც გადაეცემა a-ს pipeline ბრძანება გამოთქმების მეშვეობით. ეს არის pipeline ოპერაციული სისტემის ბრძანების ინექციის დაუცველობის ვერსია.

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

გაშვების ოპერაცია შაბლონის საფუძველზე წარმოქმნის დროებით shell სკრიპტს, $ ჩანაცვლებულია, რაც მას დაუცველს ხდის shell ბრძანების ინექციის მიმართ. ყალბი GitHub ანგარიშის მქონე თავდამსხმელს შეუძლია შექმნას პრობლემა სათაურთან დაკავშირებით. a"; bad_code_goes_here;#და ბუმ! 

ჭაობის მძვინვარებაოჰ, ეს ბიჭები ბრძანების ინექციისთვის კარს აღებდნენ უბრალოდ პრობლემის გახსნით…

GitHub-ის მოქმედებებში კოდის შესრულების ხარვეზები იყო, მაგალითად გაჯირას კომენტარი, ახლა გამოსწორებულია. გთხოვთ, წაიკითხოთ „არასანდო შეყვანა GitHub-ის სამუშაო პროცესებში“ სრული დეტალები.

ამბის მორალი: არასდროს არ შეამოწმოთ და არ შექმნათ PR-ები არასანდო წყაროებიდან PR-ის წინასწარი გადახედვის გარეშე. „არასანდო“ აქ, თუ წარმომავლობის მკაცრი ავთენტიფიკაციის ქვეშ არ არის, შეიძლება ნიშნავდეს ნებისმიერ პოტენციურად გატაცებულ დეველოპერის ანგარიშს.

 

გაუთვალისწინებელი მავნე პროგრამის განლაგება აქ!

უწყვეტი განლაგება ავტომატიზაციის კულმინაციაა, მაგრამ ეს კულმინაცია შეიძლება ჩაიშალოს შესაბამისი დამტკიცების კონტროლის არარსებობის გამო. pipeline ნაკადი.

წყაროდან სრულად ავტომატიზირებული განლაგების რისკები commit წარმოების სისტემებში არსებული რისკები მოიცავს მავნე კოდის წარმოების გარემოში გამოვლენის გარეშე განლაგების პოტენციალს, ასევე განლაგების პროცესში დაშვებული შეცდომების პოტენციალს, რამაც შეიძლება გამოიწვიოს შეფერხებები ან გათიშვები.

ამ რისკების შესამცირებლად, ორგანიზაციებს ხშირად ურჩევენ, რომ განახორციელონ „მკაცრი შესვენება“ განლაგების პროცესში, რაც მოითხოვს ადამიანის მოწონება სანამ რელიზები საბოლოო გარემოში განთავსდება.

ისინი კარებს კეტავენ

ჭაობის მძვინვარება: ეს მხიარული ნაგულისხმევი პაროლები CI/CD ხელსაწყოები იწმინდება. წვდომა /var/lib/jenkins/secrets/initialAdminPassword ახლა უკვე მკვდარი გზაა. ბევრი ინსტრუმენტი ამჟამად უზრუნველყოფს 2FA-ს, რომელიც კოვიდმა პოპულარული გახადა და მას ყველაზე ზარმაცი კოდის მაიმუნიც კი იყენებს!

M3M3N70ჩვენ 2FA-ს ვებრძვით, მაგრამ ეს ასე ადვილი არ არის. ამ ბიჭების დაშინება რთულია, რადგან „Scatter Swine“-მა Twilio-სთან ერთად გააკეთაWebAuthn გასაღებებით ეს გაცილებით რთულია. ყოველ შემთხვევაში, შეგვიძლია ვცადოთ ქუქი-ფაილების მოპარვა MFA-ს გვერდის ავლით, მაგრამ დეველოპერის ყუთში შეღწევა მჭირდება.

მრავალფაქტორიანი ავთენტიფიკაცია კარგი ნაბიჯია სწორი მიმართულებით ავთენტიფიკაციის საიდუმლოებების გაჟონვის რისკის შესამცირებლად. თანამედროვე DevOps ინსტრუმენტების უმეტესობა მხარს უჭერს MFA-ს. ხოლო ავთენტიფიკაციის გასაღებები WebAuthn / U2F-ის ფარგლებში (იხ. FIDO2 პროექტი) შესაძლოა, DevOps-ში MFA-სთვის საუკეთესო ვარიანტი იყოს, თუ სწორად იმართება.

ჭაობის მძვინვარებაDevOps-ის ბიჭები იღვიძებენ. მათ სისხლში „უმცირესი პრივილეგიის“ პრინციპი აქვთ. და ისინი აღარ არიან კოდის მაიმუნები. ახლა რეცენზენტებმა დანაშაულის ჩადენისას დაგვიჭირეს.

სინამდვილეში, pipelineახლა s-ები ცოტა უფრო სტაბილურია, ვიდრე რამდენიმე წლის წინ, სუსტი მოქმედებებითა და სკრიპტებით ამოღებული და დამატებითი უსაფრთხოების ტესტირების ნაბიჯებით, რომლებმაც ფარულად დამალული ჩვენი dropper-ებიც კი აღმოაჩინა. commits და პაკეტები, რომლებიც ჩვენ მოვიპარეთ.

კითხვა მკითხველისთვის: პროგრამული უზრუნველყოფის წყაროებიდან შექმნისა და წარმოებაში განთავსების პროცესი სარისკოა? ხედავთ თუ არა თქვენს DevOps-ს ამ ეტაპზე? ძველი კარგი დრო ბოროტმოქმედებისთვის?

საბოლოო რეკომენდაციები

საიდან დავიწყოთ CI/CD pipelineს?

პირველი რეკომენდაცია აქ მარტივია: ფრთხილად განიხილავს pipelines (ისინი არიან კრიტიკული რესურსები) უსაფრთხოების საკითხებისთვის. მიმოხილვები ძვირია, მაგრამ აუცილებელია და სათანადოდ უნდა ჩატარდეს. მიმომხილველებმა უნდა იცოდნენ, რას უნდა მიაქციონ ყურადღება. თითოეული ნაბიჯი უნდა შემოწმდეს ხარვეზებზე.

შესაძლოა, ავტომატიზირებული მავნე კოდის სკანერებით შეიარაღებული ექსპერტი რეცენზენტების კომბინაცია დაგეხმაროთ.

მეორე რეკომენდაცია არის ის, რომ მოამზადეთ დეველოპერები, რომლებიც წერენ pipelineდა შეინარჩუნეთ ისინი უსაფრთხოების დონეზეგასათვალისწინებელი ფაქტორები:

  • როგორ სწორად გავუმკლავდეთ ავთენტიფიკაციას შიდა და ღრუბლოვან სერვისებთან, რათა თავიდან ავიცილოთ გრძელვადიანი ავტორიზაციის მონაცემების დამუშავების უსიამოვნება.
  • როგორ შევზღუდოთ pipelineრესურსების ზუსტად იმ ერთობლიობამდე, რომელზეც მას წვდომა სჭირდება. უმცირესი პრივილეგიის პრინციპი კვლავ იკვეთება.
  • როგორ დავწეროთ ნაბიჯების გაკეთებისთვის pipelineრეპროდუცირებადია, როგორიცაა ვერსიის პინინგირება და ბრძანების ინექციის დაუცველობების თავიდან აცილება.
  • როგორ დავამტკიცოთ განლაგებები უსაფრთხოების პერსპექტივიდან (ისინი სხვები არიან!): რომელი უსაფრთხოების standards უნდა იყოს შესატყვისი და როგორ დავამატოთ შესაბამისი ჩეკები/კარიბჭეები 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) M3M3N70 მდე ჭაობის მძვინვარება გამოგონილი პერსონაჟები არიან. ნებისმიერი მსგავსება პირებთან ან ჯგუფებთან, ცოცხლებთან თუ გარდაცვლილებთან, უბრალოდ დამთხვევაა… თუ არა?

მეტი წასაკითხად

sca-tools-software-composition-analysis-tools
თქვენი პროგრამული უზრუნველყოფის რისკების პრიორიტეტიზაცია, გამოსწორება და დაცვა
მიიღეთ თქვენი უფასო ანგარიში.
საკრედიტო ბარათი არ არის საჭირო.
დარეგისტრირდით უფასო

უზრუნველყავით თქვენი პროგრამული უზრუნველყოფის შემუშავება და მიწოდება

Xygeni Product Suite-თან ერთად

დაიწყე უფასო
გაიარეთ პროდუქტის ტური