requirements.txt: ძირითადი ინსტრუმენტი თუ ფარული საფრთხე?
ყველა Python პროექტს აქვს ეს. ეს უმანკო შესახედაობის requirements.txt თქვენი რეპოს ძირში მოთავსებული ფაილი pip install requirements.txt consumes, რა თქმა უნდა, დამოკიდებულებების სიაა, მაგრამ თუ ფრთხილად არ იქნებით, ეს ასევე შეიძლება გახდეს არასტაბილური ბილდების, დაუცველი პაკეტების და სერიოზული უსაფრთხოების პრობლემების ფართოდ გაღების კარი.
თავის ძირითად, მოთხოვნები. txt აკონტროლებს, თუ რა მესამე მხარის პაკეტებს იღებს თქვენი აპლიკაცია. გაშვებისას pip install -r requirements.txt, Python-ის პაკეტების მენეჯერი ყველა ჩამოთვლილ დამოკიდებულებას აყენებს. მაგრამ აი, რა არის მთავარი: თუ ზუსტ ვერსიებს არ დააკონფიგურირებთ, თქვენ PyPI-ს ნდობა რომ ყოველთვის უზრუნველყოფილი იყოს უსაფრთხო, თავსებადი და შეუცვლელი ვერსია. თანამედროვე AppSec ასე არ მუშაობს.
მიმაგრების გარეშე, ბილდებმა შეიძლება დაზიანდეს. უარესი ის არის, რომ თქვენმა აპლიკაციამ შესაძლოა უნებლიეთ მიიღოს მავნე პაკეტები. ღია ვერსიირება (კოლბა >=1.0, მაგალითად) ან თავისუფალი ვერსიის შეზღუდვები (ჯანგო~=3.2) ნოყიერი ნიადაგია დაუცველი კოდის ინექციისთვის. სწორედ ამიტომ, სათანადო მართვა მოთხოვნები. txt უსაფრთხოების ძირითადი ამოცანაა.
სად იყინება პიპი და სად იყენება პიპს requirements.txt-ის დაშლა
პიპების გაყინვა მოსახერხებელია, მაგრამ ასევე საშიშია, როდესაც გამოიყენება იმის გაგების გარეშე, თუ რას იჭერს. დეველოპერები ხშირად ქმნიან მოთხოვნები. txt გამოყენების პიპ-გაყინვის მოთხოვნები.txt, მოლოდინით, რომ ის მათ გარემოს დაბლოკავს. თუმცა, გაყინვა არ ადასტურებს დამოკიდებულებების უსაფრთხოებას ან წარმოშობას; ის უბრალოდ შლის ყველაფერს, რაც ამჟამად დაინსტალირებულია, მათ შორის გარდამავალ და პოტენციურად მოძველებულ პაკეტებს.
ახლა წარმოიდგინეთ, რომ თანაგუნდელი, ან თქვენი CI, ბრმად დარბის pip install -r requirements.txtთუ ეს ფაილი შეიცავს მოძველებულ, დაუცველ ან თუნდაც ორთოგრაფიული შეცდომებით ჩაკეტილი პაკეტები, თქვენ ახლახან ავტომატიზირეთ უსაფრთხოების ინციდენტი.
სწრაფი მაგალითი:
# Developer's freeze output
pip freeze > requirements.txt
boto3==1.24.20
requests==2.27.1
⚠️ დაუცველი მაგალითი, არ გამოიყენოთ წარმოებაში
ახლა დაამატეთ ეს თქვენს CI-ს pipeline:
- name: Install dependencies
run: pip install -r requirements.txt
თქვენ ენდობით, რომ გარემო რეპროდუცირებადია, რომ PyPI-ში არაფერი შეცვლილა და რომ ყველა დამოკიდებულება კვლავ უსაფრთხოა. ეს უზარმაზარი ვარაუდია, როდესაც ვეყრდნობით პიპ-გაყინვის მოთხოვნები.txt workflows.
რეალური AppSec საფრთხეები: Typosquatting და დამოკიდებულების დაბნეულობა requirements.txt-ში
თავდამსხმელებს უყვართ ღია კოდის ეკოსისტემები. რატომ? იმიტომ, რომ დეველოპერები ხშირად ეყრდნობიან ნაგულისხმევ პარამეტრებს და იმპლიციტურ ნდობას. აი, როგორ ახორციელებენ ისინი შეტევას მოთხოვნები. txt:
- ტიპოქტაცია: მავნე პაკეტის ატვირთვა, რომელსაც აქვს სახელი, როგორიცაა მოთხოვნები ნაცვლად მოითხოვსერთი პერსონაჟის გამოკლებით, თქვენი ბილდი საკუთრებაში გადავა.
მოთხოვნები # ⚠️ საილუსტრაციო მაგალითი, არა რეალური ინსტალაციის პაკეტი
- დამოკიდებულების დაბნეულობათუ თქვენი შიდა პაკეტი არ არის მიმაგრებული ან კონფიდენციალურად დამუშავებული, თავდამსხმელებს შეუძლიათ გამოაქვეყნონ მავნე ვერსია PyPI-ზე იმავე სახელით. თუ თქვენი CI არ ადასტურებს წყაროებს, თქვენ დააინსტალირებთ მათ პაკეტს თქვენი პაკეტის ნაცვლად.
ორივე შეტევა იყენებს მკაცრი პინინგისა და წყაროს კონტროლის ნაკლებობას. მოთხოვნები. txtთუ შენი უბრალოდ ამბობს რაღაც-შინაგანი-ბიბლიოთეკა, და შენ გარბიხარ pip ინსტალაციის მოთხოვნები.txt CI-ში, შესაძლოა, არასწორი პაკეტი არასწორი ადგილიდან მოიტანოს.
Securing requirements.txt ფაილი CI/CD Pipelineჰეშებითა და პინინგებით
აი, როგორ უნდა გამკვრივდეთ მოთხოვნები. txt რეალური სამყაროს საფრთხეების წინააღმდეგ:
- ზუსტი ვერსიების დამაგრება: ყოველთვის გამოიყენეთ == თქვენს ყველა პაკეტზე მოთხოვნები. txtარანაირი ჩანაცვლებითი ნიშნები, არანაირი დიაპაზონი.
- გამოყენება –require-ჰეშები: ეს ქმნის pip install -r requirements.txt შეამოწმეთ თითოეული გადმოწერილი პაკეტის მთლიანობა.
მაგალითი:
flask==2.2.5 \
--hash=sha256:<actual_hash_here>
⚠️ საჩვენებელი მაგალითი, რეალურ პროექტებში რეალური ჰეშით ჩანაცვლება
- იზოლირება გაუკეთეთ თქვენს კონსტრუქციებსყოველთვის სუფთა, მინიმალისტურ კონტეინერებში ააგეთ. არასდროს ენდოთ ბრმად ძირითად სურათს.
- გამოიყენეთ კერძო PyPI ინდექსი: ჰოსტინგი გაუკეთეთ თქვენს საკუთარ პროქსი/ქეშს და ასახეთ მხოლოდ სანდო პაკეტები.
დამოკიდებულების სკანირების გაშვება: ინტეგრირება გაუკეთეთ ისეთ ინსტრუმენტებს, როგორიცაა პიპ-აუდიტი ან გამოყენება SBOMთქვენს მიერ შემუშავებული ანალიზის საფუძველზე pipelines.
GitHub-ის მოქმედებების ფრაგმენტის მაგალითი:
- name: Secure install
run: pip install --require-hashes -r requirements.txt
⚠️ საგანმანათლებლო pipeline მაგალითად, მოერგეთ თქვენს გარემოს
მკაცრი დამუშავება pip install -r requirements.txt in CI/CD ღია კოდის რისკის შემცირების ერთ-ერთი უმარტივესი გზაა.
რეპროდუცირებადი აწყობები: მათი სტაბილურობის შენარჩუნება სხვადასხვა გარემოში
თუ თქვენი აპლიკაცია ლოკალურად მუშაობს, მაგრამ ვერ ახერხებს ეტაპობრივ ან პროდაქშენ მონტაჟს, არათანმიმდევრული დამოკიდებულებები მოთხოვნები. txt ჩვეულებრივი ეჭვმიტანილები არიან. ვერსიის მცირე გადახვევაც კი დიდ პრობლემებს იწვევს.
გამოიყენეთ ეს სტრატეგიები:
- პიპ-ინსტრუმენტებიგამოყენება პიპ-კომპილირება გამომუშავება მოთხოვნები. txt საწყისი მოთხოვნები.inის წყვეტს დამოკიდებულებებს სათანადო პინინგით.
- გარემოს მარკერებიოპერაციული სისტემის სპეციფიკური პაკეტების ან Python-ის ვერსიის სპეციფიკური დამოკიდებულებებისთვის გამოიყენეთ მარკერები, როგორიცაა პლატფორმა_სისტემა == 'Linux'.
- დოკერის ქეშირებაCI-ში, შეინახეთ თქვენი Docker-ის ფენები დამოკიდებულებების ინსტალაციის შემდეგ მოთხოვნები. txt მშენებლობის ცვალებადობის შესამცირებლად.
მაგალითი pip-ინსტრუმენტებით:
# requirements.in
flask
# Compile
pip-compile requirements.in
⚠️ საჩვენებელი მაგალითი, ფაქტობრივი გამომავალი დამოკიდებულია თქვენს გარემოზე
გამომავალი სრულად დამაგრებულია მოთხოვნები. txt.
ინსტრუმენტები, როგორიცაა პიპების გაყინვა, როდესაც შერწყმულია pip install -r requirements.txt მშენებლობის დროს, საჭიროებს დისციპლინას და დამატებით დაცვის ზომებს.
დასკვნა: თქვენი მოთხოვნების თავდაჯერებულად დაფიქსირება
არასწორი მართვა მოთხოვნები. txt ეს მხოლოდ ცუდი პრაქტიკა არ არის; ეს აქტიური უსაფრთხოების რისკია. თავდამსხმელები თქვენს მონაცემებს იყენებენ არასრული დამაგრებით, დაუდასტურებელი ინსტალაციებით და ღია რეესტრებისადმი ბრმა ნდობით. CI/CD pipelineეს თეორიული ხარვეზები არ არის; მათ ყოველდღიურად იყენებენ.
დამოკიდებულების პინინგი საუკეთესო პრაქტიკაზე მეტია. ეს თქვენი პირველი დაცვის ხაზია Python-ში მიწოდების ჯაჭვის შეტევებისგან. შეუხამეთ ეს –require-ჰეშები, შექმენით იზოლაცია და რეპროდუცირებადი ხელსაწყოები, როგორიცაა პიპ-ინსტრუმენტები, და თქვენ მიიღებთ pipeline რომ კომპრომისზე წასვლა უფრო რთულია.
იყენებ თუ არა pip ინსტალაციის მოთხოვნები.txt ადგილობრივად ან CI-ში, ყოველთვის გადაამოწმეთ და აკონტროლეთ თქვენს ბილდებში შემავალი ინფორმაცია. ისეთი ინსტრუმენტები, როგორიცაა ქსიგენი უზრუნველყოს ხილვადობა, პოლიტიკის აღსრულება და ავტომატური შემოწმებები, რომლებიც ბლოკავს თქვენი Python-ის მიწოდების ჯაჭვს პიპ-გაყინვის მოთხოვნები.txt მთელი წარმოების მანძილზე.
