უსაფრთხოების ხარვეზის ჭორიც კი საკმარისია ექსპლოიტის საპოვნელად

ხარვეზი, რომელზეც სკანირება მალევე დაიწყო

OCaml-ის ეკოსისტემის დეველოპერმა და კემბრიჯის უნივერსიტეტის მკვლევარმა ანილ მადჰავაპედიმ 22 აგვისტოს გამოაქვეყნა ჩანაწერი იმაზე, თუ როგორ იცვლება ღია კოდის უსაფრთხოების ჩვეული პროცესი. მან გამოუშვა cohttp 6.3.0-ის უსაფრთხოების განახლება, რომელიც ბილიკის გავლით მანიპულაციის (path traversal) ხარვეზს ასწორებს. პრობლემა კერძოდ Jane Street-ის Slack-არხზე შეტყობინებით მოვიდა და, ავტორის სიტყვებით, Claude Fable-ის დახმარებით იქნა ნაპოვნი.

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

ემბარგოები აღარ იცავს

ჩანაწერის მეორე ნაწილი უსაფრთხოების ემბარგოების ეფექტურობას ეხება. ტრადიციული პროცესი ხარვეზის დეტალების საიდუმლოდ შენახვას ეყრდნობოდა, თუმცა, ავტორის თქმით, თანამედროვე აგენტურ სისტემებს მხოლოდ მიმართულება სჭირდებათ. Fang-ისა და თანაავტორების 2024 წლის კვლევაში GPT-4-ზე აგებულმა აგენტმა 15 ხარვეზის სიმრავლიდან 87% აითვისა CVE-ის აღწერილობის მიცემისას და მხოლოდ 7% — აღწერილობის გარეშე.

ექსპლოიტის შექმნის საშუალო დრო, ავტორის მოყვანილი მონაცემებით, ახლა უარყოფითია — დაახლოებით -7 დღე, ანუ ექსპლუატაცია განახლებაზე ადრე ხდება. 2018-2019 წლებში ეს მაჩვენებელი დაახლოებით 63 დღე იყო, ნული კი 2024 წელს გადაილახა. მაგალითად, marimo-ს CVE-2026-39987-ზე ექსპლუატაციის პირველი მცდელობა გაფრთხილებიდან 9 საათში დაფიქსირდა საჯარო PoC-ის არარსებობის მიუხედავად, Langflow-ის CVE-2026-33017-ზე — 20 საათში.

ჩანაწერში მოხსენიებულია 2026 წლის მაისის ნაშრომიც, რომელმაც ტერმინი bugonomics შემოიღო: მისი არგუმენტით, ბარიერი დამცველების მხრიდან გამოსწორების სიჩქარეზე გადავიდა, ვინაიდან მოვლის, ტრიაჟისა და გამოშვების ტემპი უცვლელია. ავტორი აღნიშნავს, რომ Project Glasswing-ის ფარგლებში ფრონტიერ მოდელებზე წვდომა 15 ქვეყნის 150 ორგანიზაციას აქვს, მცირე პროექტებს კი — არა.

რა შეიძლება გაკეთდეს

ავტორი სამ მიმართულებას განიხილავს. პირველი — გამოსწორებების მომზადება მაქსიმალურად დახურულ გარემოში; GitHub-ის დროებითი კერძო fork-ები ამას მხოლოდ ნაწილობრივ აკეთებს, ვინაიდან CI მათზე წვდომას კარგავს და მხოლოდ ერთი PR შეიძლება გაერთიანდეს. მეორე — ემბარგოების ნაცვლად უწყვეტი გამოშვება, როგორც Chrome აკეთებს კვირეული უსაფრთხოების განახლებებით; Linux-ის ბირთვი გამოსწორებებს მაქსიმუმ 7, გამონაკლისად — 14 დღეში აქვეყნებს. მესამე — დაცვა პროტოკოლის დონეზე: პროცენტული კოდირების ბილიკის გამყოფების ნორმალიზაცია შესაძლებელია მაშინვე, სანამ სრული გამოსწორება შემოწმებასა და პაკეტირებას გაივლის.

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