GitHub-ის secret scanner 86%-ით აჩქარდა — ნაკლები ცრუ განგაში

GitHub-მა 2026 წლის 13 ოქტომბრის ტექნიკურ პუბლიკაციაში აღწერა Secret Scanning-ის ახალი კონტექსტური კლასიფიკატორი: წინა LLM-ზე დაფუძნებულ სისტემასთან შედარებით, კოდის გაგზავნის შემდეგ სკანირების მედიანური შესრულების დრო 86%-ით შემცირდა, რეპოზიტორიის მფლობელით შეწონილი შეტყობინებების მიღება 11.5%-ით გაიზარდა, ხოლო კლასიფიკატორის მომსახურების ხარჯი 98%-ზე მეტით შემცირდა. ეს დეველოპერისთვის უფრო სწრაფ უკუკავშირსა და ნაკლებ უსარგებლო გაფრთხილებას ნიშნავს, თუმცა დროის მაჩვენებელი კონკრეტულად post-push სკანირების მედიანას ეხება.

Blockchain.News-ის 13 ოქტომბრის გაშუქებაში აღწერილია იგივე regex–ModernBERT სისტემა და GitHub-ის ოფლაინ შეფასება: წინა LLM კონვეიერთან შედარებით სიზუსტე (precision) 13%-ით, ხოლო რეალური საიდუმლოების აღმოჩენის სისრულე (recall) 19%-ით გაიზარდა. ახალი კლასიფიკატორი უკვე დანერგილ სისტემად არის აღწერილი, მაგრამ გამოქვეყნებული შედეგები GitHub-ის საკუთარ შეფასებებს ეყრდნობა და კონკრეტული რეპოზიტორიისთვის უცვლელ შედეგს არ ჰპირდება.

საეჭვო სტრიქონიდან გაფრთხილებამდე

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

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

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

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

სამი პროცენტი, სამი განსხვავებული საზომი

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

• შეტყობინებების მიღება: 11.5%-ით მეტი. ეს არის რეპოზიტორიის მფლობელის მიხედვით შეწონილი მაჩვენებელი მომხმარებლებთან ჩატარებული A/B შედარებიდან. წონა ამცირებს იმ მომხმარებელთა გავლენას, რომლებიც ერთდროულად უამრავ შეტყობინებას მასობრივად ხურავენ.
• მედიანური შესრულების დრო: 86%-ით ნაკლები. ეს ცვლილება ეხება კოდის გაგზავნის შემდეგ წარმოებულ სკანირებას. მედიანა აღწერს გაზომვების შუა მნიშვნელობას და არ ნიშნავს, რომ ყოველი გაგზავნა ზუსტად ამდენით სწრაფად მოწმდება.
• მომსახურების ხარჯი: 98%-ზე მეტით ნაკლები. საუბარია GitHub-ის ინფრასტრუქტურაზე კომპაქტური კლასიფიკატორის მუშაობის ხარჯის შედარებაზე დისტანციურ LLM გამოძახებებთან; ეს მომხმარებლის გამოწერის ფასის ცვლილება არ არის.

ხარისხის ცალკე, ოფლაინ შეფასებაში იმავე საჯარო ტრაფიკზე ახალ კონვეიერს წინა ვერსიაზე 13%-ით მაღალი precision და 19%-ით მაღალი recall ჰქონდა. პირველი საზომი მიუთითებს, აღმოჩენილ შემთხვევებს შორის რამდენი იყო სწორი, მეორე კი — რეალური საიდუმლოებებიდან რამდენი იპოვა სისტემამ. ეს ერთმანეთისგან განსხვავებული მიმართულებებია: მხოლოდ ცრუ განგაშის შემცირებამ შეიძლება რეალური აღმოჩენებიც შეამციროს, ამიტომ recall-ის ზრდა შედეგის გასაგებად არსებითია.

მფლობელით შეწონილი მიღება უშუალოდ ვერ გადაიქცევა საბოლოო სიზუსტის პროცენტად. მომხმარებელი შეტყობინებას შეიძლება სხვადასხვა სამუშაო მიზეზით იღებდეს ან ხურავდეს; ამას ემატება მფლობელთა მიხედვით შეწონა, რომელიც უბრალო გაფრთხილებების საშუალოსგან განსხვავდება. ამიტომ A/B გარემოში მიღების ზრდა ცრუ განგაშის შემცირების სასარგებლო სიგნალია, ხოლო ცრუ დადებითი შემთხვევებისა და გამოტოვებების შესახებ ცალკე ინფორმაციას ოფლაინ precision და recall იძლევა.

რატომ გადავიდა შემოწმება გაგზავნამდეც

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

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

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

რომელ შემთხვევებში მოქმედებს დაცვის ზღვარი

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

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

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

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

• Anthropic-ის OSS Scanner უფასოა — ანგარიშს ადამიანი წინასწარ არ ამოწმებს
• GitHub-ის passkey საკმარისი არაა — აღდგენის კოდიც წინასწარ შეინახეთ
• GitHub Copilot თუ Amazon Q: AWS-კოდზე სპეციალისტი ზოგად ასისტენტს უსწრებს