GitLab-ის Dependency Firewall პაკეტს build-მდე აჩერებს

GitLab-მა 2026 წლის 6 ოქტომბერს Transcend-ზე Dependency Firewall-ის ადრეული წვდომა წარადგინა. კონტროლი პაკეტს ორგანიზაციის წესებთან build-მდე ამოწმებს: warn რეჟიმში დარღვევას აფიქსირებს და pipeline-ს ატარებს, block რეჟიმში კი შეუსაბამო დამოკიდებულებას აჩერებს. საქართველოს DevSecOps გუნდებისთვის დანერგვის საწყისი გზა გაფრთხილებებზე დაკვირვებაა, სანამ დაბლოკვა პროგრამის მიწოდებას შეეხება.

ActuIA-ს მიმოხილვა 6 ოქტომბრის განცხადებაში Dependency Firewall-ს ადრეულ წვდომად აღწერს, ხოლო იმავე ღონისძიებაზე წარმოდგენილ Artifact Central-ს — ბეტა ვერსიად. გუნდმა უსაფრთხოების ახალი კონტროლის გამოცდა პაკეტების ახალი საცავის დანერგვისგან უნდა განასხვაოს. ორივე პროდუქტის ერთად გამოყენება შესაძლებელია, მაგრამ მათი გამოშვების ეტაპი და თავდაპირველი დაფარვა განსხვავდება.

რას ამოწმებს კონტროლი პაკეტის მიღებამდე

წესები პაკეტის მავნე სტატუსს, ცნობილი მოწყვლადობების სიმძიმეს, ლიცენზიასა და ვერსიის ასაკს ეხება. მავნე სტატუსისთვის გამოიყენება GitLab-ის advisory მონაცემები. მოწყვლადობის პირობებში გუნდი ირჩევს სიმძიმის ზღვარს და იმ დონეზე დასაშვები აღმოჩენების რაოდენობას; ლიცენზიის შემთხვევაში განსაზღვრავს ნებადართულ ან აკრძალულ ვარიანტებს და იმასაც, რა მოხდეს უცნობი ლიცენზიისას.

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

ჩვეულებრივ dependency scanning-თან სხვაობა შემოწმების მომენტშია. სკანირება უკვე მოტანილ კომპონენტს პოულობს, წინასწარი პოლიტიკა კი ცდილობს გადაწყვეტილება მის ინსტალაციამდე მიიღოს. ეს მნიშვნელოვანია, რადგან მავნე პაკეტის კოდი ინსტალაციისას შეიძლება შესრულდეს და CI გარემოს იმ უფლებებს შეეხოს, რომლებიც build-ის პროცესს აქვს. დაბლოკვა ამ გზას მხოლოდ მაშინ კეტავს, როცა შესაბამისი წესი და შემოწმება კონკრეტულ ნაკადში ჩართულია.

სად გადის ადრეული წვდომის დაფარვის ზღვარი

პაკეტის წინასწარ შესამოწმებლად GitLab CLI გამოიყენება ტერმინალიდან ან სკრიპტიდან. აღწერილ ეკოსისტემებს შორისაა npm, pip, Poetry, Maven, Gradle და Bundler; CLI გუნდს აჩვენებს, გაივლის თუ არა არჩეული პაკეტი მის პოლიტიკას, სანამ დამოკიდებულებას პროექტს დაამატებს. ეს შესაძლებლობა დეველოპერისა და კოდის აგენტის მიერ შერჩეული პაკეტისთვისაც სასარგებლოა: უარყოფილი ვარიანტის შეცვლა შეიძლება build-ის მოლოდინის გარეშე.

CI-ში რეალური დაფარვა თავდაპირველად პროექტების მიხედვით უნდა დაითვალოს. Artifact Central-ის აღწერა განმარტავს, რომ შემოწმება glab CLI-ით თითოეულ pipeline-ში ემატება, ხოლო რეესტრთან უფრო მჭიდრო ინტეგრაცია ჯერ დაგეგმილია. ამიტომ საერთო ჯგუფური პოლიტიკის არსებობა თავისთავად არ ნიშნავს, რომ ყველა არსებული build უკვე კონტროლდება. გუნდისთვის მნიშვნელოვანი ინფორმაციაა, რომელ pipeline-ებში მუშაობს შემოწმება და რომელი გზებით შეიძლება პაკეტი მათ გვერდის ავლით მოხვდეს პროექტში.

Dependency Firewall თავსებადად არის აღწერილი GitLab Artifact Central-თან და Sonatype Nexus Repository-სა და JFrog Artifactory-ის გარე რეესტრებთან. ეს თავსებადობა არ ცვლის საჭიროებას, რომ ადრეულ წვდომაში საკუთარი რეესტრის, პაკეტის ფორმატისა და CI კონფიგურაციის კომბინაცია გაირკვეს. npm-ის ან Maven-ის ხსენება CLI-ის ჩამონათვალში ავტომატურად არ ამტკიცებს, რომ არსებული რეესტრის ყოველი მოთხოვნა უკვე იმავე წესით იბლოკება.

Warn რეჟიმიდან block რეჟიმამდე

Warn რეჟიმში წესთან დამთხვევა აუდიტის მოვლენად ინახება, dashboard-ზე ჩნდება და CI-ის შეჯამებაშიც ჩანს, მაგრამ build გრძელდება. ეს გუნდს საშუალებას აძლევს, მოქმედი დამოკიდებულებების მიმართ წესის შედეგი შეაფასოს მიწოდების შეჩერების გარეშე. ჩანაწერი კონკრეტულ პაკეტს, პოლიტიკასა და პროექტს უნდა დაუკავშირდეს: მხოლოდ გაფრთხილებების რაოდენობა ვერ აჩვენებს, პრობლემა პაკეტშია თუ ზედმეტად მკაცრ ზღვარში.

საწყისი განხილვისას გაფრთხილებას შეიძლება მოჰყვეს დამოკიდებულების შეცვლა, პოლიტიკის დაზუსტება ან დასაბუთებული გამონაკლისი. მაგალითად, უცნობი ლიცენზია ავტომატურ დაბლოკვამდე შეიძლება ხელით გადამოწმებას მოითხოვდეს; ახლად გამოქვეყნებული ვერსია კი შეიძლება უბრალოდ ასაკის პირობას ვერ აკმაყოფილებდეს. ეს რისკზე დაფუძნებული დანერგვის თანმიმდევრობაა: warn რეჟიმი დაკვირვების საშუალებას იძლევა, მაგრამ ყველა გუნდისთვის ერთნაირ მისაღებ ზღვარს არ ადგენს.

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

როგორ ინარჩუნებს გუნდი წესების მართვას

Dependency Firewall-ის წესები security policy პროექტში კოდად ინახება და მათი ცვლილება merge request-ით განიხილება. ზედა დონის ჯგუფში დაწესებული პოლიტიკა მის ქვეშ მყოფ პროექტებს გადაეცემა, ხოლო ჯგუფსა თუ პროექტს შეუძლია უფრო მკაცრი პირობის დამატება. თუ წესები ერთმანეთს ფარავს, მკაცრი ვარიანტი მოქმედებს; ეს საერთო მინიმუმის შენარჩუნებისა და უფრო მგრძნობიარე სერვისისთვის დამატებითი მოთხოვნის დაწესების საშუალებას იძლევა.

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

ადრეული წვდომის მოთხოვნა GitLab.com-ისა და GitLab Self-Managed-ის Premium ან Ultimate მომხმარებლებს შეუძლიათ. რეესტრთან დაგეგმილ უფრო მჭიდრო ინტეგრაციამდე ორგანიზაციის პოლიტიკის არსებობასა და თითოეულ pipeline-ში მოქმედ შემოწმებას შორის სხვაობა დაფარვის რეალური საზომია.

ასევე წაიკითხეთ:

• Stripe Atlas თუ Clerky: დაბალი საწყისი ფასი სრულ პაკეტს არ ნიშნავს
• GitHub Actions თუ GitLab CI: იაფ წუთს გუნდის აბონემენტი შეიძლება აჯობოს