სადღაც თქვენს დასტაში არის დეველოპერის უსაფრთხოების ინსტრუმენტი ლიცენზიით, რომელსაც არავინ იყენებს. მან გაიარა შესყიდვის პროცესი. მან გაიარა პილოტური ტესტირება. CISO-მ ხელი მოაწერა. ექვსი თვის შემდეგ კი დეველოპერები გვერდს უვლიან მას, აჩუმებენ მის შეტყობინებებს ან ჩუმად აგრძელებენ მუშაობას ისე, როგორც ყოველთვის აკეთებდნენ. ეს არ არის ტრენინგის პრობლემა ან შესაბამისობის კულტურის პრობლემა. ეს არის დეველოპერების უსაფრთხოების დანერგვის პრობლემა და ის გაცილებით გავრცელებული და გაცილებით პროგნოზირებადია, ვიდრე უსაფრთხოების ლიდერების უმეტესობას სურს აღიაროს.
რას ნიშნავს სინამდვილეში დეველოპერების უსაფრთხოების დანერგვა
დეველოპერის უსაფრთხოების დანერგვა არის უფსკრული ხელსაწყოს დანერგვასა და იმ ხელსაწყოს გამოყენებას შორის, რომელიც შექმნილია ისე, რომ გამოყენებული იქნას ყოველდღიურად, ვინმეს მიერ მისი აღსრულების გარეშე. სკანერი მუშაობს CI-ში ის, რასაც დეველოპერები არასდროს ხსნიან, დანერგილია და არა მიღებული. დასკვნა, რომელიც ერთი შეხედვით იგნორირებულია, რადგან ბოლო ათი ცრუ დადებითი შედეგი იყო, დანერგილია და არა მიღებული. დეველოპერების მიერ უსაფრთხოების რეალური დანერგვა მოსაწყენად გამოიყურება: დეველოპერები ნებაყოფლობით ხსნიან ინსტრუმენტს, მოქმედებენ იმის მიხედვით, რასაც ის აძლევს და არ ეძებენ გვერდის ავლით გზებს.
ეს განსხვავება მნიშვნელოვანია, რადგან შესყიდვებისა და დანერგვის მეტრიკები სრულიად განსხვავებულ რამეებს ზომავს. უსაფრთხოების გუნდს შეუძლია 100%-იანი დანერგვის დაფარვის შესახებ განაცხადოს, მაშინ როცა დეველოპერების მიერ უსაფრთხოების დანერგვა ნულთან ახლოსაა და ორივე რიცხვი შეიძლება ერთდროულად სიმართლე იყოს.
რატომ ვერ ხერხდება ტრადიციული დეველოპერული უსაფრთხოების პროგრამული უზრუნველყოფის გამოყენება
დეველოპერების უსაფრთხოების ინსტრუმენტების უმეტესობა ვერ ახერხებს დანერგვას ერთი და იგივე მიზეზების გამო, რაც მეორდება თითქმის ყველა ორგანიზაციაში, რომელმაც სცადა მათი დანერგვა:
- ძალიან ბევრი ხმაური, ძალიან ცოტა ნდობა. დეველოპერების უსაფრთხოების დანერგვის ჩაშლის ყველაზე სწრაფი გზა ცრუ დადებითი შედეგების მაღალი მაჩვენებელია. მას შემდეგ, რაც დეველოპერი სამ დასკვნას მიჰყვება, რომლებიც არაფრის მომტანი აღმოჩნდა, ის წყვეტს მეოთხეს ენდობა და მეხუთეს ყურადღებას წყვეტს.
- ის ისეთ ადგილას მდებარეობს, სადაც დეველოპერები არ ცხოვრობენ. A dashboard დეველოპერებს უნდა ახსოვდეთ, რომ გახსნა არის dashboard ისინი დაივიწყებენ. უსაფრთხოების პროგრამული უზრუნველყოფა, რომელიც მოითხოვს IDE-ს დატოვებას, კონტექსტის შეცვლას და მოგვიანებით დაბრუნებას, კარგავს იმ მომენტს, როდესაც გამოსწორება ყველაზე იაფი და მარტივი შესასრულებელია.
- ის პრობლემებზე მიუთითებს მათი გამოსწორების შეთავაზების გარეშე. დასკვნა, რომელიც ამბობს „SQL ინექცია, 42-ე ხაზი“, ექსპლოიტის გზის ახსნის ან გამოსწორების შეთავაზების გარეშე, დეველოპერს საშინაო დავალებას აძლევს და არა დახმარებას. ეს მნიშვნელოვანი გადასახადია დეველოპერის უსაფრთხოების დანერგვაზე, რადგან ის ყველა დასკვნას კვლევით პროექტად აქცევს დეველოპერის ნაცვლად.cisიონი
- ის ბლოკავს ბილდებს მიზეზის ახსნის გარეშე. წითელი pipeline კონტექსტის გარეშე, ის დაბრკოლებად აღიქმება და არა სიგნალად. დეველოპერები სწავლობენ, რომ უსაფრთხოების კარიბჭე ისეთ რამედ აღიქვან, რასაც გვერდის ავლით უნდა გაიარონ და არა ისეთად, რასაც უნდა მოუსმინონ.
- ის აუდიტორისთვისაა შექმნილი და არა დეველოპერისთვის. ამას ხშირად ადასტურებს ის ინსტრუმენტები, რომლებიც ძირითადად შესაბამისობის მტკიცებულებების წარმოსადგენად არის შექმნილი: ვრცელი ანგარიშები, ჟარგონზე დაფუძნებული დასკვნები, იმ პირის ენაზე საუბრის არანაირი მცდელობა, ვისგანაც მათზე რეაგირება რეალურად არის მოსალოდნელი.
უსაფრთხოების პროგრამული უზრუნველყოფის შემქმნელის ტესტი: გახსნიდნენ თუ არა ისინი მას მეორედ?
აქ მოცემულია სასარგებლო ფილტრი ნებისმიერი დეველოპერის უსაფრთხოების პროგრამული უზრუნველყოფის შესაფასებლად მის შეძენამდე: გახსნის თუ არა დეველოპერი მას ხვალ, ყოველგვარი მოთხოვნის გარეშე? არა იმიტომ, რომ ამას პოლიტიკა მოითხოვს, არამედ იმიტომ, რომ გუშინ მას სასარგებლო რამ მისცა. დეველოპერის უსაფრთხოების დანერგვაში ჩავარდნილი ინსტრუმენტების უმეტესობა ამ ტესტს პირველივე დღესვე ჩააბარებდა და ყველა ამას კონტრაქტის ხელმოწერამდეც კი ეჭვობდა.
გამავალ ინსტრუმენტებს რამდენიმე საერთო მახასიათებელი აქვთ. ისინი რედაქტორის შიგნით არიან და არა მის უკან. loginისინი დასკვნას ისე ხსნიან, როგორც უფროსი ინჟინერი გააკეთებდა კოდის მიმოხილვისას და არა ისე, როგორც შესაბამისობის ანგარიში. ისინი გვთავაზობენ კონკრეტულ გამოსწორებას და არა მხოლოდ დიაგნოზს. და რაც მთავარია, ისინი ხშირად საკმარისად მართლები არიან, რომ დეველოპერს არ მოუწევს თითოეული შეტყობინების ორჯერ შემოწმება, სანამ მას ენდობა.
რა იწვევს სინამდვილეში შვილად აყვანას
დეველოპერების უსაფრთხოების სწორად დანერგვა არ არის უკეთესი ტრენინგი ან უფრო მკაცრი მანდატი. ეს დამოკიდებულია დიზაინის მცირე რაოდენობაზე.cisიონები:
- შეხვდით დეველოპერებს იქ, სადაც ისინი უკვე მუშაობენ. IDE-ში ჩაშენებული უსაფრთხოებასაქართველოს pull requestდა CLI გამოიყენება. უსაფრთხოება, რომელიც ცალკე დანიშნულების ადგილს მოითხოვს, არა.
- ახსენი, უბრალოდ დროშით ნუ მონიშნავ. აღმოჩენა და ექსპლოიტის გზის მარტივ ენაზე ახსნა-განმარტებას კრიპტოვალუტულ შეტყობინებას ისეთ რამედ აქცევს, რაზეც დეველოპერს შეუძლია დაუყოვნებლივ იმსჯელოს და მასზედ იმოქმედოს.
- შესთავაზეთ გამოსავალი და არა მხოლოდ პრობლემა. ავტომატური გამოსწორება, რომლის განხილვა და დამტკიცებაც დეველოპერს წამებში შეუძლია, პატივს სცემს მათ დროს ისე, როგორც შეცდომის ანგარიში არასდროს აკეთებს ამას.
- შეინარჩუნეთ სიგნალ-ხმაურის თანაფარდობა მაღალი. აგრესიული ცრუ-დადებითი ფილტრაცია არ არის სასიამოვნო, ის ყველაზე დიდი ბერკეტია იმის დასადგენად, გადარჩება თუ არა დეველოპერების მიერ უსაფრთხოების დანერგვა პირველი თვის შემდეგ.
- მყარი ბლოკები შეინახეთ იმისთვის, რაც რეალურად მნიშვნელოვანია. Guardrails რომ დაარღვიოს მშენებლობა ყველა დაბალი სიმძიმის აღმოჩენის მატარებლის დეველოპერები კარიბჭის უკმაყოფილებას გამოხატავენ. Guardrails რომ ბლოკირება მხოლოდ ნამდვილად კრიტიკულ, გამოსწორებად პრობლემებს ასწავლის დეველოპერებს მის ნდობას.
როგორ უდგება Xygeni დეველოპერის უსაფრთხოების პროგრამული უზრუნველყოფის დიზაინს
Xygeni IDE მოდული მუშაობს იქ, სადაც დეველოპერები უკვე იმყოფებიან, IDE-ს შიგნით, სადაც ადამიანისა და ხელოვნური ინტელექტის მიერ გენერირებულ კოდს უწყვეტად სკანირებენ მისი დაწერის პროცესში, ყოველგვარი მოთხოვნების გარეშე. როდესაც ის რამეს პოულობს, ის გასაგებ ენაზე განმარტავს ექსპლოიტის სრულ გზას და გვთავაზობს გამოსწორებას, რომლის განხილვა და გამოყენებაც დეველოპერს შეუძლია, იმის ნაცვლად, რომ მას მხოლოდ CVE იდენტიფიკატორიდან ამოხსნა დაავალოს.
ხელოვნური ინტელექტის ტრიაჟი იყენებს იგივე ცრუ-დადებით ფილტრაციას SAST, საიდუმლოებები, IaCდა მავნე პროგრამების აღმოჩენები მთელი პლატფორმის მასშტაბით, რათა ხმაურის პრობლემა, რომელიც დეველოპერების უსაფრთხოების სხვაგან დანერგვას აფერხებს, მოგვარდეს მანამ, სანამ აღმოჩენა დეველოპერების რიგში მოხვდება. guardrails პოლიტიკის აღსრულება pipeline დონეზე, მაგრამ შერჩევით, ბლოკავს ნამდვილად კრიტიკულ, გამოსწორებად საკითხებს, იმის ნაცვლად, რომ ყველა აღმოჩენა თანაბრად ნგრევად მიიჩნიოს. სწორედ ეს განსხვავება უშლის ხელს დეველოპერებს ისწავლონ კარიბჭის გვერდის ავლა.
ეს ყველაფერი ვერ ცვლის იმ რეალობას, რომ დეველოპერები, როგორც წესი, ბერკეტს წარმოადგენენ და არა ეკონომიკურ მყიდველებს. enterprise AppSec decisიონი. ა CISკონტრაქტს ხელს აწერს O; ინჟინერიის ვიცე-პრეზიდენტს აინტერესებს, შეუქმნის თუ არა ინსტრუმენტი უსიამოვნებებს მათ გუნდს. თუმცა, დეველოპერების უსაფრთხოების დანერგვა სწორედ ისაა, რაც ამ ბერკეტს ბერკეტად აქცევს: ინსტრუმენტი, რომელსაც დეველოპერები რეალურად იყენებენ, ხსნის რეალურ დაუცველობებს, ხოლო ინსტრუმენტი, რომელსაც ისინი გვერდის ავლით იყენებენ, არცერთს არ ხსნის, მიუხედავად იმისა, თუ ვინ დაამტკიცა შესყიდვის შეკვეთა.
ადაპტაციის გაზომვა, და არა მხოლოდ დანერგვის
თუ გსურთ, რომ თქვენს ორგანიზაციაში დეველოპერების უსაფრთხოების დანერგვის შესახებ გულწრფელი ინფორმაცია მიიღოთ, დანერგვის დაფარვა არასწორი მაჩვენებელია. უკეთესი სიგნალები მოიცავს:
- რამდენად ხშირად ხსნიან დეველოპერები ინსტრუმენტს მითითების გარეშე.
- შემოთავაზებული შესწორებების რა წილი მიიღება და რა წილი უარყოფილია.
- რეალურად მცირდება თუ არა გამოსწორების დრო და არა მხოლოდ ხდება თუ არა დასკვნების რეგისტრაცია.
- ითხოვენ თუ არა დეველოპერები ინსტრუმენტს ახალ პროექტზე, თუ ელოდებიან მის ინსტალაციას.
ლიცენზიების რაოდენობა გიჩვენებთ, რა შეიძინეთ. ეს რიცხვები გიჩვენებთ, რეალურად მოხდა თუ არა დეველოპერების მიერ უსაფრთხოების დანერგვა.
კითხვა-პასუხი
რას ნიშნავს „დეველოპერის უსაფრთხოების ადაპტაცია“?
ეს არის უფსკრული უსაფრთხოების ინსტრუმენტის დანერგვასა და მის რეალურად გამოყენებას შორის ისე, როგორც ის იყო შექმნილი, ნებაყოფლობით, ყოველდღიურად, ყოველგვარი იძულების გარეშე. მაღალი დანერგვის დაფარვა და დეველოპერების მიერ დაბალი უსაფრთხოების დანერგვა შეიძლება თანაარსებობდეს და ხშირად თანაარსებობს კიდეც.
რატომ უგულებელყოფენ დეველოპერები უსაფრთხოების ინსტრუმენტებს ტრენინგის შემდეგაც კი?
ტრენინგი არ ასწორებს ინსტრუმენტს, რომელიც ძალიან ბევრ ცრუ დადებით შედეგს გამოიმუშავებს, დეველოპერის სამუშაო პროცესის მიღმაა ან პრობლემას აღნიშნავს გამოსწორების შეთავაზების გარეშე. ეს არის დიზაინის პრობლემები და არა ცოდნის ხარვეზები და ტრენინგის არც ერთი რაოდენობა არ ცვლის არსებულ უთანხმოებას.
რა არის დეველოპერების მიერ უსაფრთხოების დანერგვის ყველაზე მნიშვნელოვანი ფაქტორი?
ენდეთ სიგნალს. როგორც კი დეველოპერები შეწყვეტენ დასკვნის რეალური ნამდვილობის ნდობას, ისინი წყვეტენ ყველა მათგანზე რეაგირებას, მათ შორის მნიშვნელოვანებზეც. აგრესიული ცრუ დადებითი შედეგების ფილტრაცია, როგორც წესი, ყველაზე ეფექტური გამოსავალია.
რით განსხვავდება დეველოპერის უსაფრთხოების პროგრამული უზრუნველყოფა ტრადიციული AppSec ინსტრუმენტებისგან?
საუკეთესო დეველოპერის უსაფრთხოების პროგრამული უზრუნველყოფა დეველოპერს ძირითად მომხმარებლად მიიჩნევს და არა მხოლოდ შესაბამისობის სამიზნედ: ის მუშაობს IDE-ში, მარტივად განმარტავს დასკვნებს და გვთავაზობს გამოსწორებებს, იმის ნაცვლად, რომ შექმნას ანგარიში სხვისთვის მოგვიანებით ინტერპრეტაციისთვის.
უნდა CISგაინტერესებთ დეველოპერების უსაფრთხოების დანერგვა, თუ ისინი ყიდულობენ ინსტრუმენტს?
დიახ, პირდაპირ. ინსტრუმენტი, რომელსაც აქვს ძლიერი შესაბამისობის დაფარვა, მაგრამ სუსტი დეველოპერის უსაფრთხოების დანერგვა, რეალურად არ ამცირებს რისკს, ის უბრალოდ აწარმოებს ანგარიშებს. რისკის შემცირება CISO ყიდვა მხოლოდ იმ შემთხვევაში მოხდება, თუ დეველოპერები გამოიყენებენ ინსტრუმენტს.
