CRA-ს მზადყოფნა კოდბაზიდან იწყება: 7 კითხვა ხარვეზების გამოსავლენად

კიბერგამძლეობის აქტი (CRA) ხშირად პოლიტიკურ ან საანგარიშო გამოწვევად განიხილება, თუმცა ციფრული ელემენტების მწარმოებლებისთვის მისი გავლენა ბევრად ადრე იჩენს თავს: pull request-ებში, build პაიპლაინებში, გამოშვების დამტკიცებასა და ტესტების კრებულებში. კომპანია ვერ შეძლებს გამოყენებულ დაუცველობაზე სარწმუნო ანგარიშის წარდგენას, თუ წინასწარ ვერ უპასუხებს მარტივ საინჟინრო კითხვებს: რომელი ვერსიებია დაზარალებული, რომელმა კომპონენტმა შექმნა რისკი და იმუშავა თუ არა შესწორებამ რეალურ პროდუქტში.

ვადები, რომლებიც უკვე ამოქმედდა

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

პოლიტიკიდან დაკვირვებად კონტროლამდე

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

შვიდი კითხვა, რომელიც ხარვეზებს ამჟღავნებს

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

რისკით პრიორიტეტიზაცია და AI-ის გავლენა

შეფასების შედეგი რისკის მიხედვით დალაგებული გეგმა უნდა იყოს: ინტერნეტისთვის ღია პროდუქტში დაკარგული უსაფრთხო ნაგულისხმევი პარამეტრი უფრო სასწრაფოა, ვიდრე დაბალი რისკის შიდა კომპონენტის ავტომატიზაციის ხარვეზი. მხედველობაში მიიღება პროდუქტის ღიაობა, ფუნქციის კრიტიკულობა, ექსპლუატაციის შესაძლებლობა და დაზარალებული ვერსიების რაოდენობა. ამას ემატება აგენტური განვითარების ზრდა: Sonar-ის კვლევაში დეველოპერების 96% აცხადებს, რომ AI-ის მიერ დაწერილ კოდს სრულად არ ენდობა, თუმცა მხოლოდ 48% ამოწმებს მას ყოველთვის კომიტამდე. ეს სხვაობა ავტომატურ კონტროლს შეუცვლელს ხდის, მიუხედავად იმისა, კოდი ადამიანს ეკუთვნის თუ აგენტს.

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