DevSecOps-ის შიში და ზიზღი

ჩვენ გვქონდა 2 კოდის ანალიზატორი, 4 დინამიური ტესტირების ინსტრუმენტი, საკუთარი ხელნაკეთობები და 250 სკრიპტი. ეს არ არის ის, რომ ეს ყველაფერი საჭიროა მიმდინარე პროცესში, მაგრამ როგორც კი დაიწყებთ DevSecOps-ის დანერგვას, ბოლომდე უნდა წახვიდეთ.

წყარო. პერსონაჟის შემქმნელები: ჯასტინ როილანდი და დენ ჰარმონი.

რა არის SecDevOps? რაც შეეხება DevSecOps-ს? რა განსხვავებებია? აპლიკაციის უსაფრთხოება - რაზეა საუბარი? რატომ აღარ მუშაობს კლასიკური მიდგომა? იცის ყველა ამ კითხვაზე პასუხი იური შაბალინი საქართველოს Swordfish უსაფრთხოება. იური ყველაფერს დეტალურად უპასუხებს და გააანალიზებს აპლიკაციის უსაფრთხოების კლასიკური მოდელიდან DevSecOps პროცესზე გადასვლის პრობლემებს: როგორ სწორად მივუდგეთ უსაფრთხო განვითარების პროცესის ინტეგრაციას DevOps-ის პროცესში და არაფერი დაარღვიოთ, როგორ გავიაროთ ძირითადი ეტაპები. უსაფრთხოების ტესტირების შესახებ, რა ინსტრუმენტების გამოყენება შეიძლება, და რით განსხვავდებიან ისინი და როგორ უნდა მოხდეს მათი სწორად კონფიგურაცია, რათა თავიდან ავიცილოთ ხარვეზები.

სპიკერის შესახებ: იური შაბალინი - უსაფრთხოების მთავარი არქიტექტორი კომპანიაში Swordfish უსაფრთხოება. პასუხისმგებელია SSDL-ის დანერგვაზე, აპლიკაციის ანალიზის ხელსაწყოების საერთო ინტეგრაციაზე განვითარებისა და ტესტირების ერთიან ეკოსისტემაში. ინფორმაციული უსაფრთხოების სფეროში 7 წლიანი გამოცდილება. მუშაობდა Alfa-Bank-ში, Sberbank-ში და Positive Technologies-ში, რომლებიც ამუშავებენ პროგრამულ უზრუნველყოფას და ახორციელებენ სერვისებს. მომხსენებელი საერთაშორისო კონფერენციებზე ZerONights, PHDays, RISSPA, OWASP.

აპლიკაციის უსაფრთხოება: რაზეა საუბარი?

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

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

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

კანონიკური SDLC ძალიან დეტალურია სხვადასხვა მეთოდოლოგიაში - OpenSAMM, BSIMM, OWASP. მეთოდოლოგია განსხვავებულია, მაგრამ ზოგადად მსგავსია.

უსაფრთხოების შენობის სიმწიფის მოდელი

ყველაზე მეტად მომწონს BSIMM - უსაფრთხოების შენობის სიმწიფის მოდელი. მეთოდოლოგიის საფუძველია Application Security პროცესის დაყოფა 4 დომენად: მმართველობა, დაზვერვა, SSDL Touchpoints და Deployment. თითოეულ დომენს აქვს 12 პრაქტიკა, რომლებიც წარმოდგენილია 112 აქტივობის სახით.

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

რატომ DevSecOps

DevOps არის ზოგადი, დიდი პროცესი, რომელშიც უსაფრთხოება უნდა იყოს გათვალისწინებული.

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

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

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

DevSecOps-ზე გადასვლა

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

DevOps-ის პროცესში ინსტრუმენტების უბრალოდ ჩართვა საკმარისი არ არის - პროცესის მონაწილეებს შორის კომუნიკაცია და გაგება მნიშვნელოვანია.

ხალხი უფრო მნიშვნელოვანია და არა იარაღები.

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

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

პირველ რიგში, აღწერეთ რა შედეგი გსურთ და როგორი იქნება პროცესი. ეს ხელს შეუწყობს ხელსაწყოს და უსაფრთხოების როლის გაგებას პროცესში.

დაიწყეთ იმით, რაც უკვე გამოიყენება

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

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

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

შედეგად, დოკუმენტი ერთი კვირის შემდეგ მივიღეთ.

მოთხოვნებისთვის, ჩეკებისთვის და სხვა რამეებისთვის შექმენით გვერდი მაგ. შესართავთან - ყველასთვის მოსახერხებელია.

უფრო ადვილია გადაფორმატოთ ის, რაც უკვე გაქვთ და გამოიყენოთ დასაწყებად.

გამოიყენეთ უსაფრთხოების ჩემპიონები

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

უსაფრთხოების ჩემპიონები არიან ადამიანები განვითარების გუნდში, რომლებიც დაინტერესებულნი არიან თქვენი პროდუქტის უსაფრთხოებით.

უსაფრთხოების ჩემპიონი არის შესვლის წერტილი განვითარების გუნდში და უსაფრთხოების მახარებელი შემოვიდა ერთში.

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

-და შენ ვინ ხარ? პირველად გნახავ. ჩემთან ყველაფერი კარგადაა - ჩემმა უფროსმა მეგობარმა მომცა "მიმართვა" კოდის განხილვაზე, ჩვენ გადავდივართ!

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

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

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

ტესტირების ეტაპები

პარადიგმა 20-დან 80-მდე ამბობს, რომ ძალისხმევის 20% იძლევა 80% შედეგს. ეს 20% არის განაცხადის ანალიზის პრაქტიკა, რომელიც შეიძლება და უნდა იყოს ავტომატიზირებული. ასეთი აქტივობების მაგალითებია სტატიკური ანალიზი - SASTდინამიური ანალიზი - DAST и ღია კოდის კონტროლი. მე უფრო დეტალურად გეტყვით აქტივობებზე, ასევე ინსტრუმენტებზე, რა მახასიათებლებს ვაწყდებით ჩვეულებრივ პროცესში მათი დანერგვისას და როგორ გავაკეთოთ ეს სწორად.

ხელსაწყოების ძირითადი პრობლემები

მე გამოვყოფ პრობლემებს, რომლებიც აქტუალურია ყველა ინსტრუმენტისთვის და მოითხოვს ყურადღებას. მათ უფრო დეტალურად გავაანალიზებ, რათა აღარ განმეორდეს.

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

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

არ არის ინტეგრაცია არსებულ ინსტრუმენტებთან. შეხედეთ ინსტრუმენტებს ინტეგრაციის თვალსაზრისით იმასთან, რასაც უკვე იყენებთ. მაგალითად, თუ გაქვთ Jenkins ან TeamCity, შეამოწმეთ ინსტრუმენტების ინტეგრაცია ამ პროგრამულ უზრუნველყოფასთან და არა GitLab CI-სთან, რომელსაც თქვენ არ იყენებთ.

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

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

პროცესის მახასიათებლები

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

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

"აქ ხარ დაუცველები, არსად წახვალ!"

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

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

- ბიჭებო, თქვენ გაქვთ პრობლემები, გთხოვთ, მიაქციოთ მათ ყურადღება.

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

- ბიჭებო, რამდენჯერმე გაგაფრთხილეთ, არაფერი გაგიკეთებიათ - ამით არ გაგიშვებთ.

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

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

პროგრამული უზრუნველყოფის ხარისხის ყველა პრობლემა არ არის უსაფრთხოების პრობლემა. მაგრამ უსაფრთხოების ყველა პრობლემა დაკავშირებულია პროგრამული უზრუნველყოფის ხარისხთან. შერიფ მანსური, ექსპედია.

ვინაიდან ყველა დაუცველობა არის იგივე დეფექტი, ისინი უნდა განთავსდეს იმავე ადგილას, როგორც ყველა განვითარების დეფექტი. ასე რომ დაივიწყეთ ანგარიშები და საშინელი PDF-ები, რომლებსაც არავინ კითხულობს.

როდესაც ვმუშაობდი დეველოპერულ კომპანიაში, მივიღე ანგარიში სტატიკური ანალიზის ხელსაწყოებიდან. გავხსენი, შემეშინდა, ყავა მოვამზადე, 350 გვერდი გადავავლე, დავხურე და გავაგრძელე მუშაობა. დიდი ცნობები მკვდარი ცნობებია. როგორც წესი, ისინი არსად მიდიან, ასოები იშლება, ავიწყდება, იკარგება, ან ბიზნესი ამბობს, რომ იღებს რისკებს.

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

სტატიკური ანალიზი - SAST

ეს არის კოდის ანალიზი დაუცველობისთვის., მაგრამ ეს არ არის იგივე, რაც SonarQube. ჩვენ არ ვამოწმებთ მხოლოდ შაბლონებს ან სტილს. ანალიზში გამოყენებულია მთელი რიგი მიდგომები: დაუცველობის ხის მიხედვით, მიხედვით Მონაცემთა ნაკადი, კონფიგურაციის ფაილების ანალიზით. ეს არის ყველაფერი, რაც ეხება თავად კოდს.

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

Cons - ეს არის საჭირო ენების მხარდაჭერის ნაკლებობა.

აუცილებელი ინტეგრაციები, რომელიც უნდა იყოს ინსტრუმენტებში, ჩემი სუბიექტური აზრით:

• ინტეგრაციის ინსტრუმენტი: Jenkins, TeamCity და Gitlab CI.
• განვითარების გარემო: Intellij IDEA, Visual Studio. დეველოპერისთვის უფრო მოსახერხებელია არა გაუგებარი ინტერფეისის ნავიგაცია, რომელიც ჯერ კიდევ დასამახსოვრებელია, არამედ დაინახოს ყველა საჭირო ინტეგრაცია და დაუცველობა, რომელიც მან აღმოაჩინა სამუშაო ადგილზე, საკუთარი განვითარების გარემოში.
• კოდის მიმოხილვა: SonarQube და სახელმძღვანელო მიმოხილვა.
• დეფექტების ტრეკერები: ჯირა და ბუგზილა.

სურათზე ნაჩვენებია სტატიკური ანალიზის რამდენიმე საუკეთესო წარმომადგენელი.

მნიშვნელოვანია არა ინსტრუმენტები, არამედ პროცესი, ამიტომ არის ღია კოდის გადაწყვეტილებები, რომლებიც ასევე კარგია პროცესის შესამოწმებლად.

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

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

CVS დონის ინტეგრაცია

თუ თქვენ გაქვთ Bitbucket ან GitLab, შეგიძლიათ ინტეგრირება დონეზე კონკურენტული ვერსიების სისტემა.

მოვლენის მიხედვით - მოითხოვე, ჩაიდინე. თქვენ სკანირებთ კოდს და build-ის სტატუსი აჩვენებს, უსაფრთხოების შემოწმება გაიარა თუ ვერ მოხერხდა.

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

კოდის განხილვის სისტემასთან ინტეგრაცია

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

ინტეგრაცია SonarQube-თან

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

ინტეგრაცია CI დონეზე

აქ ყველაფერი ასევე საკმაოდ მარტივია:

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

ეს ყველაფერი სრულყოფილ ვარდისფერ სამყაროშია. რეალურ ცხოვრებაში ასეთი რამ არ არსებობს, მაგრამ ჩვენ ვიბრძვით. უსაფრთხოების შემოწმების გაშვების შედეგი უნდა იყოს ერთეულის ტესტების შედეგების მსგავსი.

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

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

უსაფრთხოების კარიბჭის მაგალითია ხარისხიანი კარიბჭის ანალოგი, კოდში დაუცველობის არსებობისა და რაოდენობის თვალსაზრისით.

ჩვენ ვაერთიანებთ SonarQube-ს - დაინსტალირებულია დანამატი, ყველაფერი ძალიან მოსახერხებელი და მაგარია.

ინტეგრაცია განვითარების გარემოსთან

ინტეგრაციის ვარიანტები:

• სკანირების გაშვება განვითარების გარემოდან ჩადენამდე.
• შედეგების ნახვა.
• შედეგების ანალიზი.
• სერვერთან სინქრონიზაცია.

ასე გამოიყურება სერვერისგან შედეგების მიღება.

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

ღია

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

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

ღია კოდის ანალიზი - OSA

ინსტრუმენტი მოიცავს სამ დიდ ეტაპს.

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

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

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

თვისებები:

• განსხვავებული პოლიტიკა განვითარების სხვადასხვა ეტაპებზე.
• კომპონენტების მონიტორინგი სამრეწველო გარემოში.
• ორგანიზაციის ფარგლებში ბიბლიოთეკების კონტროლი.
• მხარდაჭერა სხვადასხვა build სისტემებისა და ენებისთვის.
• დოკერის სურათების ანალიზი.

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

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

პროცესის ინტეგრაცია

ბიბლიოთეკების პერიმეტრის კონტროლი, რომლებიც ჩამოტვირთულია გარე წყაროებიდან. ჩვენ გვაქვს გარე და შიდა საცავი. მაგალითად, Event Central გადის Nexus-ს და ჩვენ გვინდა დავრწმუნდეთ, რომ ჩვენს საცავში არ არის დაუცველობა „კრიტიკული“ ან „მაღალი“ სტატუსით. თქვენ შეგიძლიათ დააკონფიგურიროთ proxying Nexus Firewall Lifecycle ხელსაწყოს გამოყენებით ისე, რომ ასეთი დაუცველობა მოწყდეს და არ დასრულდეს შიდა საცავში.

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

ინტეგრაცია არტეფაქტებთან: Nexus და JFrog.

ინტეგრაცია განვითარების გარემოში. თქვენ მიერ არჩეულ ინსტრუმენტებს უნდა ჰქონდეთ ინტეგრაცია განვითარების გარემოსთან. დეველოპერს უნდა ჰქონდეს წვდომა სკანირების შედეგებზე მისი სამუშაო ადგილიდან, ან თავად კოდის სკანირებისა და დაუცველობის შესამოწმებლად CVS-ზე დადებამდე.

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

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

• აშენებისას ვამოწმებთ, რომ არავის რაიმე ცუდი არ ჩამოუვარდა, ყველა კომპონენტი უსაფრთხოა და არავის რაიმე საშიში არ მოუტანია ფლეშკაზე.
• ჩვენ გვაქვს მხოლოდ სანდო კომპონენტები საცავში.
• განლაგებისას, ჩვენ კიდევ ერთხელ ვამოწმებთ თავად პაკეტს: war, jar, DL ან Docker image, რათა დავრწმუნდეთ, რომ იგი შეესაბამება პოლიტიკას.
• ინდუსტრიაში შესვლისას ჩვენ ვაკვირდებით რა ხდება ინდუსტრიულ გარემოში: ჩნდება ან არ ჩნდება კრიტიკული დაუცველობა.

დინამიური ანალიზი - DAST

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

იგივე სისტემა საშუალებას გაძლევთ შეამოწმოთ შაბლონის დაუცველობა ღია წყაროში. ვინაიდან DAST არ იცის, რომელ ღია წყაროს ვიყენებთ, ის უბრალოდ აგდებს „მავნე“ შაბლონებს და აანალიზებს სერვერის პასუხებს:

- კი, აქ დესერიალიზაციის პრობლემაა, აქ არა.

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

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

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

-ბიჭებო მეხუმრე?! ჩვენ მოგეცით ანგარიშები და თქვენ შექმენით სტენდი!

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

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

რამდენიმე რესურსი, რომელსაც ჩვენ ჩვეულებრივ ვიყენებთ.

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

პროცესის ინტეგრაცია

ინტეგრაცია საკმაოდ კარგად და მარტივად ხდება: დაიწყეთ სკანირება წარმატებული ინსტალაციის შემდეგ განაცხადები სტენდისთვის და სკანირება წარმატებული ინტეგრაციის ტესტირების შემდეგ.

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

• იდეალურ შემთხვევაში, ცალკე სატესტო სტენდი.
• ტესტირებამდე ჩაწერეთ შესვლის თანმიმდევრობა.
• ადმინისტრაციული სისტემის ტესტირება მხოლოდ ხელით ხდება.

პროცესი

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

ყველა პროცესს სჭირდება კონტროლი.

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

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

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

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

ძირითადი Takeaways

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

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

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

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

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

თუ IS გუნდის ზომა მცირეა - გამოიყენეთ უსაფრთხოების ჩემპიონები.

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

მოთხოვნები ხელსაწყოებისთვის.

• დაბალი დონის ცრუ დადებითი.
• ანალიზის ადექვატური დრო.
• მარტივად გამოყენება.
• ინტეგრაციების ხელმისაწვდომობა.
• პროდუქტის განვითარების საგზაო რუკის გაგება.
• ხელსაწყოების მორგების შესაძლებლობა.

იურის ანგარიში ერთ-ერთ საუკეთესოდ იქნა არჩეული DevOpsConf 2018. კიდევ უფრო საინტერესო იდეებისა და პრაქტიკული შემთხვევების გასაცნობად მობრძანდით სკოლკოვოში 27 და 28 მაისს. DevOpsConf ფარგლებში ფესტივალი RIT++. კიდევ უკეთესი, თუ მზად ხართ თქვენი გამოცდილების გაზიარება, მაშინ ვრცელდება ანგარიშისთვის 21 აპრილამდე.

წყარო: www.habr.com