GitHub Secret Scanning თუ Gitleaks: precision და recall სხვადასხვა გამარჯვებულს აჩვენებს

თუ გუნდის კოდი GitHub-ზეა და მას რეპოზიტორიაში მართვადი გაფრთხილებები და push protection სჭირდება, GitHub Secret Scanning უფრო პირდაპირი არჩევანია. თუ შემოწმება commit-მდე, ლოკალურად ან სხვადასხვა CI/CD გარემოში უნდა შესრულდეს, Gitleaks უკეთ ერგება ამ ამოცანას. არჩევანისას მნიშვნელოვანია აღმოჩენის სიზუსტეც და ისიც, რამდენ რეალურ საიდუმლოს პოულობს სკანერი.

2023 წელს გამოქვეყნებულ 818 საჯარო GitHub რეპოზიტორიის კვლევაში GitHub Secret Scanner-ის precision 75% იყო, Gitleaks-ის precision — 46%, ხოლო Gitleaks-ის recall რეპოზიტორიის დონეზე — 88% და F1 — 60%. ეს გამოქვეყნებული ტესტის შედეგებია და დღევანდელ კერძო რეპოზიტორიაში იმავე პროცენტებს არ იძლევა. ისინი აჩვენებს, რატომ შეიძლება ერთ გუნდს უფრო სანდო გაფრთხილება სჭირდებოდეს, მეორეს კი — საიდუმლოების უფრო ფართო აღმოჩენა.

რას ცვლის precision და recall არჩევანში

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

ამ კვლევაში GitHub-ის შედეგი გაფრთხილებების სანდოობით გამოირჩეოდა, Gitleaks-ისა კი ნამდვილი საიდუმლოების მოძებნის სიფართოვით. F1 ორივე მეტრიკას აერთიანებს, მაგრამ გუნდის სამუშაო დატვირთვას ვერ აღწერს: ცრუ განგაშის განხილვას დრო სჭირდება, გამორჩენილი გასაღები კი შეიძლება შეუმჩნეველი დარჩეს. ამიტომ ერთიანი ქულა თავისთავად ვერ გადაწყვეტს, რომელი შეცდომა უფრო ძვირია კონკრეტული პროექტისთვის.

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

GitHub-ში რა მოჰყვება აღმოჩენას

GitHub Secret Scanning-ის მთავარი პრაქტიკული უპირატესობა რეპოზიტორიის სამუშაო პროცესთან კავშირია. GitHub-ის აღწერით, სისტემა ამოწმებს Git-ის ისტორიას ყველა branch-ზე, აღმოჩენილი credential-ისთვის რეპოზიტორიის უსაფრთხოების განყოფილებაში ქმნის გაფრთხილებას და ახალი ტიპის საიდუმლოებების დამატებისას კოდს ხელახლა სკანირებს. ეს გუნდს აღმოჩენისა და რეაგირების ერთ სივრცეში მართვის საშუალებას აძლევს.

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

ხელმისაწვდომობაც არჩევანის ნაწილია: GitHub-ის დაფარვის წესებით, საჯარო რეპოზიტორიები ავტომატურად და უფასოდ სკანირდება, ხოლო ორგანიზაციის კერძო და შიდა რეპოზიტორიებისთვის GitHub Team-ზე ან GitHub Enterprise Cloud-ზე GitHub Secret Protection-ის ჩართვაა საჭირო; push protection ბლოკავს მხოლოდ მხარდაჭერილი შაბლონების ნაწილს და საჯარო რეპოზიტორიაში 50 MB-ზე დიდ push-ს საერთოდ არ სკანირებს. ამიტომ შეუჩერებელი push არ ნიშნავს, რომ ცვლილებაში საიდუმლო არ არის. Push protection და რეპოზიტორიის შემდგომი სკანირება ერთმანეთისგან განსხვავებული კონტროლია.

Gitleaks სად ჯდება სამუშაო პროცესში

Gitleaks-ის უპირატესობა გაშვების ადგილის არჩევანია. პროექტის README აღწერს Git რეპოზიტორიის, ფაილებისა და სტანდარტული შეყვანის სკანირებას, pre-commit hook-ს, GitHub Action-სა და საკუთარი წესების კონფიგურაციას; იქვე ავტორი აღნიშნავს, რომ პროექტი ფუნქციურად დასრულებულია და მომავალი გამოშვებები უსაფრთხოების შესწორებებით შემოიფარგლება. ბრძანების სტრიქონიდან გაშვება გუნდს საშუალებას აძლევს, სკანერი სხვა CI/CD სისტემაშიც ჩართოს.

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

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

არჩევანის მატრიცა ოთხი სცენარისთვის

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

• Pre-commit. Gitleaks შეეფერება გუნდს, რომელსაც კანდიდატის აღმოჩენა დეველოპერის ლოკალურ Git პროცესში სურს. GitHub-ის რეპოზიტორიული გაფრთხილება ამ მომენტში ლოკალურ hook-ს ვერ შეცვლის. თუ ამ ეტაპის შემოწმება სავალდებულო უნდა იყოს, მხოლოდ დეველოპერის მიერ დაყენებულ hook-ზე დაყრდნობა არასაკმარისია.
• GitHub-ის საჯარო რეპოზიტორია. GitHub Secret Scanning მოსახერხებელი საწყისი კონტროლია, რადგან სკანირება ავტომატურია და აღმოჩენების განხილვა პლატფორმაშივე ხდება. Gitleaks-ის დამატება აზრიანია, თუ გუნდს commit-მდე შემოწმება ან სხვა წესებით უფრო ფართო ძიება სჭირდება. Push protection-ის ბლოკირება მკაფიო სიგნალია, მაგრამ მის არმოქმედებას უსაფრთხოების დასტურად ნუ ჩათვლით.
• კერძო კორპორაციული რეპოზიტორია. GitHub-ის მართვადი ვარიანტი შეეფერება ორგანიზაციას, რომელსაც შესაბამისი გეგმა და GitHub Secret Protection აქვს და სურს გაფრთხილებების იმავე პლატფორმაზე დამუშავება. Gitleaks შეიძლება დაემატოს ლოკალურ ან CI ეტაპზე, განსაკუთრებით საკუთარი წესების გამოსაყენებლად. აქ გადაწყვეტილებას განსაზღვრავს ფუნქციის ხელმისაწვდომობა, აღმოჩენების მოცულობა და მათზე პასუხისმგებელი გუნდი.
• მრავალპლატფორმიანი CI. Gitleaks-ის CLI უფრო პირდაპირ ერგება პროექტებს, რომლებიც სხვადასხვა ჰოსტინგსა და CI/CD სისტემაშია განაწილებული. საერთო წესების გაშვება შესაძლებელია იქ, სადაც pipeline სრულდება. GitHub-ის ჩაშენებული გაფრთხილებები გამოსადეგი რჩება GitHub-ზე მოთავსებული რეპოზიტორიებისთვის, მაგრამ სხვა პლატფორმებზე მიმდინარე სკანირებას თავისთავად ვერ ფარავს.

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

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

• Claude თუ Gemini კოდისთვის: ერთი benchmark გამარჯვებულს ვერ არჩევს
• Cursor თუ GitHub Copilot: აგენტის არჩევანს დავალების ტიპი წყვეტს
• GitHub-ის passkey საკმარისი არაა — აღდგენის კოდიც წინასწარ შეინახეთ