Վախ և զզվանք DevSecOps-ից

Մենք ունեինք 2 կոդի անալիզատոր, 4 դինամիկ փորձարկման գործիք, մեր սեփական արհեստներ և 250 սցենար: Այնպես չէ, որ այս ամենը անհրաժեշտ է ընթացիկ գործընթացում, բայց երբ սկսեք DevSecOps-ի ներդրումը, պետք է գնալ մինչև վերջ:

Աղբյուր. Կերպարների ստեղծողներ՝ Ջասթին Ռոյլենդ և Դեն Հարմոն։

Ի՞նչ է SecDevOps-ը: Ինչ վերաբերում է DevSecOps-ին: Որո՞նք են տարբերությունները: Հավելվածի անվտանգություն. ինչի՞ մասին է խոսքը: Ինչու՞ դասական մոտեցումն այլևս չի աշխատում: Գիտի այս բոլոր հարցերի պատասխանը Յուրի Շաբալին - ից Swordfish Security. Յուրին մանրամասն կպատասխանի ամեն ինչին և կվերլուծի դասական Application Security մոդելից DevSecOps գործընթացին անցնելու խնդիրները. ինչպես ճիշտ մոտենալ անվտանգ զարգացման գործընթացի ինտեգրմանը DevOps գործընթացին և ոչինչ չխախտել, ինչպես անցնել հիմնական փուլերը: անվտանգության թեստավորում, ինչ գործիքներ կարող են օգտագործվել, և ինչով են դրանք տարբերվում և ինչպես ճիշտ կարգավորել դրանք՝ ծուղակներից խուսափելու համար:

Բանախոսի մասին. Յուրի Շաբալին - Անվտանգության գլխավոր ճարտարապետ ընկերությունում Swordfish Security. Պատասխանատու է SSDL-ի ներդրման, կիրառական վերլուծության գործիքների ընդհանուր ինտեգրման համար միասնական զարգացման և փորձարկման էկոհամակարգում: 7 տարվա աշխատանքային փորձ տեղեկատվական անվտանգության ոլորտում։ Աշխատել է Alfa-Bank-ում, Sberbank-ում և Positive Technologies-ում, որը մշակում է ծրագրեր և ծառայություններ է մատուցում: Զեկուցող միջազգային կոնֆերանսների ZerONights, PHDays, RISSPA, OWASP:

Հավելվածի անվտանգություն. ինչի՞ մասին է խոսքը:

Դիմումների անվտանգություն - Սա անվտանգության բաժինն է, որը պատասխանատու է հավելվածի անվտանգության համար: Սա չի վերաբերում ենթակառուցվածքին կամ ցանցային անվտանգությանը, այլ այն, ինչ մենք գրում ենք, և ինչի վրա աշխատում են մշակողները. սրանք հենց հավելվածի թերություններն ու խոցելիությունն են:

Ուղղություն SDL կամ SDLC - Անվտանգության զարգացման կյանքի ցիկլը - մշակվել է Microsoft-ի կողմից: Դիագրամը ցույց է տալիս կանոնական SDLC մոդելը, որի հիմնական խնդիրն անվտանգության մասնակցությունն է զարգացման յուրաքանչյուր փուլում՝ պահանջներից մինչև թողարկում և արտադրություն: Microsoft-ը հասկացավ, որ արդյունաբերության մեջ չափազանց շատ սխալներ կան, դրանք ավելի շատ են, և ինչ-որ բան պետք է անել դրա դեմ, և նրանք առաջարկեցին այս մոտեցումը, որը դարձել է կանոնական:

Application Security-ը և SSDL-ն ուղղված են ոչ թե խոցելիության հայտնաբերմանը, ինչպես ընդունված է համարել, այլ դրանց առաջացումը կանխելուն: Ժամանակի ընթացքում Microsoft-ի կանոնական մոտեցումը բարելավվել, մշակվել և ներդրվել է ավելի խորը, ավելի մանրամասն ուսումնասիրության մեջ:

Կանոնական SDLC-ն շատ մանրամասն է տարբեր մեթոդաբանություններում՝ OpenSAMM, BSIMM, OWASP: Մեթոդաբանությունները տարբեր են, բայց ընդհանուր առմամբ նման են:

Անվտանգության կառուցում հասունության մոդելում

Ինձ ամենաշատը դուր է գալիս BSIMM - Անվտանգության կառուցում հասունության մոդելում. Մեթոդաբանության հիմքը Application Security գործընթացի բաժանումն է 4 տիրույթների՝ Governance, Intelligence, SSDL Touchpoints և Deployment։ Յուրաքանչյուր տիրույթ ունի 12 պրակտիկա, որոնք ներկայացված են որպես 112 գործունեություն:

112 գործողություններից յուրաքանչյուրն ունի Հասունության 3 մակարդակ՝ սկսնակ, միջին և առաջադեմ: Դուք կարող եք ուսումնասիրել բոլոր 12 պրակտիկան բաժին առ բաժին, ընտրել ձեզ համար կարևոր բաներ, պարզել, թե ինչպես դրանք իրականացնել և աստիճանաբար ավելացնել տարրեր, օրինակ՝ ստատիկ և դինամիկ կոդի վերլուծություն կամ կոդի վերանայում: Դուք գրում եք պլան և հանգիստ աշխատում դրա համաձայն՝ որպես ընտրված գործողությունների իրականացման մաս:

Ինչու DevSecOps

DevOps-ը ընդհանուր, մեծ գործընթաց է, որի ընթացքում պետք է հաշվի առնել անվտանգությունը:

Սկզբում DevOps ներգրավված անվտանգության ստուգումներ. Գործնականում անվտանգության թիմերի թիվը շատ ավելի փոքր էր, քան այժմ, և նրանք հանդես էին գալիս ոչ թե որպես գործընթացի մասնակիցներ, այլ որպես վերահսկող և վերահսկիչ մարմին, որը պահանջներ է դնում նրան և ստուգում է արտադրանքի որակը թողարկման ավարտին: Սա դասական մոտեցում է, երբ անվտանգության թիմերը մշակումից հետո պատի հետևում էին և չէին մասնակցում գործընթացին:

Հիմնական խնդիրն այն է, որ տեղեկատվական անվտանգությունը զատված է զարգացումից։ Սովորաբար սա տեղեկատվական անվտանգության մի տեսակ է և պարունակում է 2-3 մեծ և թանկարժեք գործիքներ: Վեց ամիսը մեկ գալիս է սկզբնական կոդը կամ հավելվածը, որը պետք է ստուգվի, և տարին մեկ անգամ դրանք արտադրվում են pentests. Այս ամենը հանգեցնում է նրան, որ արդյունաբերության թողարկման ամսաթիվը հետաձգվում է, և մշակողը ենթարկվում է ավտոմատացված գործիքների հսկայական թվով խոցելիությունների: Այս ամենը ապամոնտաժել և վերանորոգել հնարավոր չէ, քանի որ նախորդ վեց ամիսների արդյունքները չեն դասավորվել, բայց ահա նոր խմբաքանակ։

Մեր ընկերության աշխատանքի ընթացքում մենք տեսնում ենք, որ անվտանգությունը բոլոր ոլորտներում և արդյունաբերություններում հասկանում է, որ ժամանակն է հասնել և զարգացնել նույն անիվի վրա. Արագաշարժ. DevSecOps պարադիգմը կատարելապես համապատասխանում է արագաշարժ զարգացման մեթոդաբանությանը, ներդրմանը, աջակցությանը և մասնակցությանը յուրաքանչյուր թողարկման և կրկնության մեջ:

Անցում DevSecOps-ին

Անվտանգության զարգացման կենսացիկլում ամենակարևոր բառն է «գործընթաց». Դուք պետք է հասկանաք սա, նախքան մտածեք գործիքներ գնելու մասին:

Պարզապես գործիքների ներդրումը DevOps գործընթացում բավարար չէ. գործընթացի մասնակիցների միջև հաղորդակցությունն ու փոխըմբռնումը կարևոր է:

Մարդիկ ավելի կարևոր են, ոչ թե գործիքներ:

Հաճախ անվտանգ զարգացման գործընթացի պլանավորումը սկսվում է գործիք ընտրելով և գնելով, և ավարտվում է գործիքը ընթացիկ գործընթացում ինտեգրելու փորձերով, որոնք մնում են փորձեր: Սա հանգեցնում է դժբախտ հետևանքների, քանի որ բոլոր գործիքներն ունեն իրենց առանձնահատկությունները և սահմանափակումները:

Տարածված դեպքն այն է, երբ անվտանգության վարչությունը ընտրեց լավ, թանկարժեք գործիք՝ լայն հնարավորություններով և եկավ մշակողների մոտ՝ այն ինտեգրելու գործընթացին: Բայց դա չի ստացվում. գործընթացը կառուցված է այնպես, որ արդեն գնված գործիքի սահմանափակումները չեն տեղավորվում ընթացիկ պարադիգմում:

Նախ նկարագրեք, թե ինչ արդյունք եք ուզում և ինչպիսին կլինի գործընթացը: Սա կօգնի հասկանալ գործիքի և անվտանգության դերը գործընթացում:

Սկսեք նրանից, ինչն արդեն օգտագործվում է

Նախքան թանկարժեք գործիքներ գնելը, տեսեք, թե ինչ ունեք արդեն։ Յուրաքանչյուր ընկերություն ունի զարգացման անվտանգության պահանջներ, կան ստուգումներ, պենտեստներ. ինչու՞ այս ամենը չվերափոխել բոլորի համար հասկանալի և հարմար ձևի:

Սովորաբար պահանջները թղթե Թալմուդ են, որոնք ընկած են դարակի վրա: Եղել է դեպք, երբ մենք եկել ենք ընկերություն՝ դիտարկելու գործընթացները և խնդրել ենք տեսնել ծրագրային ապահովման անվտանգության պահանջները: Սրանով զբաղվող մասնագետը երկար ժամանակ փնտրել է.

- Հիմա, ինչ-որ տեղ գրառումների մեջ մի ճանապարհ կար, որտեղ այս փաստաթուղթն է:

Արդյունքում մենք փաստաթուղթը ստացանք մեկ շաբաթ անց։

Պահանջների, ստուգումների և այլ բաների համար ստեղծեք էջ, օրինակ. Հորդություն - դա հարմար է բոլորի համար:

Ավելի հեշտ է վերափոխել այն, ինչ արդեն ունեք և օգտագործել այն սկսելու համար:

Օգտագործեք անվտանգության չեմպիոնները

Որպես կանոն, 100-200 ծրագրավորող ունեցող միջին ընկերությունում կա մեկ անվտանգության մասնագետ, ով կատարում է մի քանի գործառույթ և ֆիզիկապես ժամանակ չունի ամեն ինչ ստուգելու համար: Նույնիսկ եթե նա փորձի առավելագույնը, նա միայնակ չի ստուգի այն բոլոր ծածկագրերը, որոնք ստեղծում են զարգացումը: Նման դեպքերի համար մշակվել է հայեցակարգ. Անվտանգության չեմպիոններ.

Անվտանգության չեմպիոնները մշակողների թիմում գտնվող մարդիկ են, ովքեր հետաքրքրված են ձեր արտադրանքի անվտանգությամբ:

Անվտանգության չեմպիոնը մուտքի կետ է մշակողների թիմում և անվտանգության ավետարանիչը՝ մեկում:

Սովորաբար, երբ անվտանգության մասնագետը գալիս է մշակողների թիմ և նշում կոդի սխալը, նա զարմացած պատասխան է ստանում.

-Իսկ դու ո՞վ ես: Ես քեզ առաջին անգամ եմ տեսնում: Ինձ հետ ամեն ինչ կարգին է. ավագ ընկերս ինձ «դիմել» է կոդի վերանայման վրա, մենք առաջ ենք գնում:

Սա տիպիկ իրավիճակ է, քանի որ շատ ավելի մեծ վստահություն կա ավագների կամ պարզապես թիմակիցների նկատմամբ, որոնց հետ ծրագրավորողը մշտապես շփվում է աշխատանքի և կոդերի վերանայման ժամանակ: Եթե ​​անվտանգության աշխատակցի փոխարեն անվտանգության չեմպիոնը մատնանշի սխալն ու հետեւանքները, ապա նրա խոսքն ավելի մեծ կշիռ կունենա։

Բացի այդ, մշակողները գիտեն իրենց կոդը ավելի լավ, քան անվտանգության ցանկացած մասնագետ: Այն մարդու համար, ով ստատիկ վերլուծության գործիքում ունի առնվազն 5 նախագիծ, սովորաբար դժվար է հիշել բոլոր նրբությունները: Անվտանգության չեմպիոնները գիտեն իրենց արտադրանքը. ինչն է փոխազդում ինչի հետ և ինչին պետք է նայել սկզբում, նրանք ավելի արդյունավետ են:

Այսպիսով, մտածեք Security Champions-ի ներդրման մասին և ընդլայնելու ձեր անվտանգության թիմի ազդեցությունը: Սա օգտակար է նաև հենց չեմպիոնի համար՝ մասնագիտական ​​զարգացում նոր ոլորտում, ընդլայնելով իր տեխնիկական հորիզոնները, կատարելագործելով տեխնիկական, կառավարչական և առաջնորդական հմտությունները, շուկայական արժեքի բարձրացում: Սա սոցիալական ճարտարագիտության որոշ տարր է, ձեր «աչքերը» զարգացման թիմում:

Փորձարկման փուլեր

Պարադիգմ 20-ից 80 ասում է, որ ջանքերի 20%-ը տալիս է արդյունքի 80%-ը: Այս 20%-ը դիմումների վերլուծության պրակտիկա է, որը կարող է և պետք է ավտոմատացված լինի: Նման գործողությունների օրինակներ են ստատիկ վերլուծությունը. SAST, դինամիկ վերլուծություն - DAST и Բաց կոդով հսկողություն. Ես ձեզ ավելին կպատմեմ գործունեության, ինչպես նաև գործիքների մասին, թե ինչ առանձնահատկություններ ենք մենք սովորաբար հանդիպում գործընթացում դրանք ներկայացնելիս և ինչպես դա անել ճիշտ:

Գործիքների հիմնական խնդիրները

Ես կառանձնացնեմ խնդիրները, որոնք տեղին են բոլոր գործիքների համար և պահանջում են ուշադրություն: Ես դրանք ավելի մանրամասն կվերլուծեմ՝ հետագայում չկրկնելու համար։

Երկար վերլուծության ժամանակ: Եթե ​​թողարկման պարտավորությունից 30 րոպե է պահանջվում բոլոր թեստերի և հավաքման համար, ապա տեղեկատվական անվտանգության ստուգումները կտևեն մեկ օր: Այսպիսով, ոչ ոք չի դանդաղեցնի գործընթացը: Հաշվի առեք այս հատկանիշը և հետևություններ արեք:

Բարձր մակարդակի կեղծ բացասական կամ կեղծ դրական: Բոլոր ապրանքները տարբեր են, բոլորն օգտագործում են տարբեր շրջանակներ և իրենց սեփական կոդավորման ոճը: Տարբեր կոդերի բազաների և տեխնոլոգիաների վրա գործիքները կարող են ցույց տալ կեղծ բացասական և կեղծ դրականի տարբեր մակարդակներ: Այսպիսով, տեսեք, թե կոնկրետ ինչում է գտնվում ձեր մասին ընկերությունների և համար ձեր հավելվածները ցույց կտան լավ և հուսալի արդյունքներ:

Ոչ մի ինտեգրում գոյություն ունեցող գործիքների հետ. Նայեք գործիքներին՝ ինտեգրվելու առումով այն, ինչ դուք արդեն օգտագործում եք: Օրինակ, եթե ունեք Jenkins կամ TeamCity, ստուգեք գործիքների ինտեգրումը այս ծրագրաշարի հետ, այլ ոչ թե GitLab CI-ի հետ, որը դուք չեք օգտագործում:

Անհատականացման բացակայություն կամ չափազանց բարդություն: Եթե ​​գործիքը չունի API, ապա ինչու է դա անհրաժեշտ: Այն ամենը, ինչ կարելի է անել ինտերֆեյսում, պետք է հասանելի լինի API-ի միջոցով: Իդեալում, գործիքը պետք է ունենա ստուգումներ հարմարեցնելու հնարավորություն:

Արտադրանքի զարգացման ճանապարհային քարտեզ չկա: Զարգացումը կանգ չի առնում, մենք միշտ օգտագործում ենք նոր շրջանակներ և գործառույթներ՝ հին ծածկագիրը վերագրելով նոր լեզուների: Մենք ցանկանում ենք վստահ լինել, որ մեր գնած գործիքը կաջակցի նոր շրջանակներին և տեխնոլոգիաներին: Հետեւաբար, կարեւոր է իմանալ, որ ապրանքն ունի իրական եւ ճիշտ Ճանապարհային քարտեզը զարգացում.

Գործընթացի առանձնահատկությունները

Բացի գործիքների առանձնահատկություններից, հաշվի առեք զարգացման գործընթացի առանձնահատկությունները: Օրինակ՝ զարգացմանը խոչընդոտելը սովորական սխալ է։ Եկեք նայենք, թե ինչ այլ հատկանիշներ պետք է հաշվի առնել, և ինչի վրա պետք է ուշադրություն դարձնի անվտանգության թիմը:

Մշակման և թողարկման ժամկետները բաց չթողնելու համար ստեղծեք տարբեր կանոններ և տարբեր ցույց տալ խցանները - խոցելիության առկայության դեպքում կառուցման գործընթացը դադարեցնելու չափանիշներ. տարբեր միջավայրերի համար. Օրինակ, մենք հասկանում ենք, որ ներկայիս մասնաճյուղը գնում է զարգացման ստենդ կամ UAT, ինչը նշանակում է, որ մենք կանգ չենք առնում և ասում.

«Այստեղ դուք խոցելի տեղեր ունեք, այլ տեղ չեք գնա»:

Այս պահին կարևոր է ծրագրավորողներին ասել, որ կան անվտանգության խնդիրներ, որոնք ուշադրության կարիք ունեն:

Խոցելիության առկայությունը խոչընդոտ չէ հետագա փորձարկման համար: ձեռնարկ, ինտեգրում կամ ձեռնարկ: Մյուս կողմից, մենք պետք է ինչ-որ կերպ բարձրացնենք արտադրանքի անվտանգությունը, և որպեսզի մշակողները չանտեսեն այն, ինչ նրանք համարում են անվտանգ: Հետևաբար, երբեմն մենք դա անում ենք. ստենդում, երբ այն տարածվում է զարգացման միջավայր, մենք պարզապես տեղեկացնում ենք զարգացմանը.

- Տղերք, դուք խնդիրներ ունեք, խնդրում եմ ուշադրություն դարձրեք դրանց:

UAT փուլում մենք կրկին ցույց ենք տալիս նախազգուշացումներ խոցելիության մասին, իսկ թողարկման փուլում ասում ենք.

- Տղե՛րք, մենք ձեզ մի քանի անգամ զգուշացրել ենք, դուք ոչինչ չեք արել, մենք ձեզ սրանով դուրս չենք թողնի:

Եթե ​​խոսում ենք կոդի և դինամիկայի մասին, ապա անհրաժեշտ է ցույց տալ և զգուշացնել միայն այն հատկանիշների և կոդի խոցելիության մասին, որոնք հենց նոր գրվել են այս ֆունկցիայի մեջ։ Եթե ​​ծրագրավորողը կոճակը տեղափոխում է 3 պիքսել, և մենք նրան ասում ենք, որ նա այնտեղ SQL ներարկում ունի և, հետևաբար, պետք է շտապ շտկել, դա սխալ է: Նայեք միայն այն, ինչ հիմա գրված է և այն փոփոխությունը, որը գալիս է դիմումին:

Ենթադրենք, մենք ունենք որոշակի ֆունկցիոնալ թերություն՝ ինչպես հավելվածը չպետք է աշխատի. գումար չի փոխանցվում, երբ սեղմում ես կոճակի վրա, անցում չի կատարվում հաջորդ էջ, կամ ապրանքը չի բեռնվում։ Անվտանգության թերություններ - սրանք նույն թերություններն են, բայց ոչ թե կիրառական շահագործման, այլ անվտանգության առումով։

Ծրագրային ապահովման որակի ոչ բոլոր խնդիրներն են անվտանգության խնդիրներ: Բայց անվտանգության բոլոր խնդիրները կապված են ծրագրային ապահովման որակի հետ: Շերիֆ Մանսուր, Expedia.

Քանի որ բոլոր խոցելիությունները նույն թերություններն են, դրանք պետք է տեղակայվեն նույն տեղում, ինչ զարգացման բոլոր թերությունները: Այսպիսով, մոռացեք զեկույցների և սարսափելի PDF-ների մասին, որոնք ոչ ոք չի կարդում:

Երբ ես աշխատում էի մշակող ընկերությունում, ստացա հաշվետվություն ստատիկ վերլուծության գործիքներից: Բացեցի, սարսափեցի, սուրճ եփեցի, թերթեցի 350 էջ, փակեցի ու շարունակեցի աշխատել։ Խոշոր հաշվետվությունները մահացած զեկույցներ են. Սովորաբար նրանք ոչ մի տեղ չեն գնում, տառերը ջնջվում են, մոռացվում, կորչում, կամ բիզնեսն ասում է, որ ընդունում է ռիսկերը։

Ինչ անել? Պարզապես հաստատված թերությունները, որոնք գտել ենք, վերածում ենք զարգացման համար հարմար ձևի, օրինակ՝ դրանք դնում ենք Ժիրայում հետնահերթում։ Մենք առաջնահերթ ենք համարում թերությունները և վերացնում դրանք ըստ առաջնահերթության՝ ֆունկցիոնալ թերությունների և փորձարկման թերությունների հետ մեկտեղ:

Ստատիկ վերլուծություն - SAST

Սա խոցելիության կոդի վերլուծություն է:, բայց դա նույնը չէ, ինչ SonarQube-ն: Մենք պարզապես չենք ստուգում նախշերը կամ ոճը: Վերլուծության մեջ կիրառվում են մի շարք մոտեցումներ՝ ըստ խոցելիության ծառի, ըստ DataFlow, վերլուծելով կազմաձևման ֆայլերը։ Սա այն ամենն է, ինչ վերաբերում է հենց կոդը։

Մոտեցման դրական կողմերը: Կոդի խոցելիության բացահայտում զարգացման վաղ փուլումերբ դեռ չկան տակդիրներ կամ պատրաստի գործիքներ, և աստիճանական սկանավորման հնարավորությունկոդի մի հատվածի սկանավորում, որը փոխվել է, և միայն այն գործառույթը, որը մենք ներկայումս անում ենք, ինչը նվազեցնում է սկանավորման ժամանակը:

Դեմ - սա անհրաժեշտ լեզուների աջակցության բացակայությունն է:

Անհրաժեշտ ինտեգրումներ, որոնք պետք է լինեն գործիքների մեջ, իմ սուբյեկտիվ կարծիքով.

• Ինտեգրման գործիք՝ Jenkins, TeamCity և Gitlab CI:
• Մշակման միջավայր՝ Intellij IDEA, Visual Studio: Մշակողի համար ավելի հարմար է ոչ թե նավարկելու անհասկանալի ինտերֆեյս, որը դեռ պետք է անգիր անել, այլ տեսնել բոլոր անհրաժեշտ ինտեգրումներն ու խոցելիությունները, որոնք նա գտել է հենց աշխատավայրում իր զարգացման միջավայրում:
• Կոդի վերանայում. SonarQube և ձեռքով վերանայում:
• Արատների հետքեր՝ Jira և Bugzilla:

Նկարում ներկայացված են ստատիկ վերլուծության լավագույն ներկայացուցիչներից մի քանիսը:

Կարևորը ոչ թե գործիքներն են, այլ գործընթացը, ուստի կան բաց կոդով լուծումներ, որոնք նույնպես լավ են գործընթացը փորձարկելու համար:

SAST Open Source-ը չի գտնի մեծ թվով խոցելիություններ կամ բարդ DataFlows, բայց դրանք կարող են և պետք է օգտագործվեն գործընթաց կառուցելիս: Դրանք օգնում են հասկանալ, թե ինչպես է կառուցվելու գործընթացը, ով կարձագանքի սխալներին, ովքեր կզեկուցեն և ով կզեկուցեն: Եթե ​​ցանկանում եք իրականացնել ձեր կոդի անվտանգության կառուցման սկզբնական փուլը, օգտագործեք բաց կոդով լուծումներ։

Ինչպե՞ս կարող է սա ինտեգրվել, եթե դուք ձեր ճանապարհորդության սկզբում եք և ոչինչ չունեք՝ ոչ CI, ոչ Jenkins, ոչ TeamCity: Դիտարկենք գործընթացին ինտեգրումը։

CVS մակարդակի ինտեգրում

Եթե ​​ունեք Bitbucket կամ GitLab, կարող եք ինտեգրվել մակարդակով Համաժամանակյա տարբերակների համակարգ.

Ըստ իրադարձության - խնդրանք քաշել, պարտավորվել: Դուք սկանավորում եք կոդը, և կառուցման կարգավիճակը ցույց է տալիս, թե արդյոք անվտանգության ստուգումն անցել է, թե ձախողվել:

Հետադարձ կապ. Իհարկե, հետադարձ կապը միշտ անհրաժեշտ է: Եթե ​​դուք պարզապես կողքից անվտանգություն եք արել, դրեք այն տուփի մեջ և ոչ ոքի ոչինչ չեք ասել դրա մասին, այնուհետև ամսվա վերջում մի խումբ սխալներ եք նետել, դա ճիշտ չէ և լավ չէ:

Ինտեգրում կոդի վերանայման համակարգի հետ

Մի անգամ մենք գործել ենք որպես տեխնիկական AppSec օգտատիրոջ լռելյայն վերանայող մի շարք կարևոր նախագծերում: Կախված նրանից, թե արդյոք սխալներ են հայտնաբերվել նոր կոդում, թե սխալներ չկան, վերանայողը «ընդունել» կամ «աշխատանքի կարիք ունի» կարգավիճակը սահմանում է «ընդունել» կամ «աշխատանքի կարիք». բարելավման կարիք ունի: Արտադրության մեջ մտնող տարբերակի հետ ինտեգրվելու համար մենք միաձուլման արգելք ենք տվել, եթե տեղեկատվական անվտանգության թեստը չանցնի: Մենք սա ներառել ենք ձեռքով կոդի վերանայման մեջ, և գործընթացի մյուս մասնակիցները տեսան այս կոնկրետ գործընթացի անվտանգության կարգավիճակները:

Ինտեգրում SonarQube-ի հետ

Շատերն ունեն որակյալ դարպաս կոդի որակի առումով։ Այստեղ նույնն է. դուք կարող եք նույն դարպասները պատրաստել միայն SAST գործիքների համար: Կլինի նույն ինտերֆեյսը, նույն որակի դարպասը, միայն այն կկոչվի անվտանգության դարպաս. Եվ նաև, եթե SonarQube-ի օգտագործող գործընթաց ունեք, կարող եք հեշտությամբ ինտեգրել այնտեղ ամեն ինչ:

Ինտեգրում CI մակարդակում

Այստեղ ամեն ինչ նույնպես բավականին պարզ է.

• Ավտոթեստերի հետ հավասար, միավորի թեստեր.
• Բաժանում ըստ զարգացման փուլերի՝ dev, փորձարկում, արդ. Կարող են ներառվել կանոնների տարբեր հավաքածուներ կամ ձախողման տարբեր պայմաններ՝ դադարեցրեք հավաքումը, մի կանգնեցրեք հավաքը:
• Սինխրոն/ասինխրոն գործարկում. Սպասում ենք անվտանգության թեստերի ավարտին, թե ոչ։ Այսինքն՝ մենք ուղղակի գործարկել ենք դրանք և առաջ ենք շարժվում, իսկ հետո ստանում ենք այն կարգավիճակը, որ ամեն ինչ լավ է կամ վատ։

Այս ամենը կատարյալ վարդագույն աշխարհում է: Իրական կյանքում նման բան չկա, բայց մենք ձգտում ենք։ Անվտանգության ստուգումների կատարման արդյունքը պետք է նման լինի միավորի թեստերի արդյունքներին:

Օրինակ, մենք վերցրեցինք մի մեծ նախագիծ և որոշեցինք, որ այժմ մենք սկանավորելու ենք այն SAST-ով - OK: Մենք մտցրեցինք այս նախագիծը SAST-ի մեջ, այն մեզ տվեց 20 խոցելիություն և վճռական կամքով որոշեցինք, որ ամեն ինչ լավ է: 000 խոցելիությունը մեր տեխնիկական պարտքն է. Մենք պարտքը կդնենք տուփի մեջ, կամաց-կամաց կփակենք այն և վրիպակներ կավելացնենք արատների հետքերում: Եկեք վարձենք ընկերություն, ամեն ինչ ինքներս անենք, կամ ապահովության չեմպիոնները մեզ օգնեն, և տեխնիկական պարտքը կնվազի:

Եվ բոլոր նոր ի հայտ եկած խոցելիությունները նոր օրենսգրքում պետք է վերացվեն այնպես, ինչպես սխալները միավորում կամ ավտոմատ փորձարկումներում: Համեմատաբար ասած, ժողովը սկսվեց, մենք անցկացրինք այն, երկու թեստ և երկու անվտանգության թեստ ձախողվեցին: Լավ. մենք գնացինք, նայեցինք, թե ինչ եղավ, մի բան շտկեցինք, մյուսը շտկեցինք, հաջորդ անգամ գործարկեցինք. ամեն ինչ լավ էր, ոչ մի նոր խոցելիություն չհայտնվեց, ոչ մի թեստ չհաջողվեց: Եթե ​​այս առաջադրանքն ավելի խորն է, և դուք պետք է այն լավ հասկանաք, կամ խոցելիության շտկումը ազդում է գլխարկի տակ ընկածի մեծ շերտերի վրա. թերությունների հետագծում սխալ է ավելացվել, այն առաջնահերթ է և ուղղվում: Ցավոք, աշխարհը կատարյալ չէ, և թեստերը երբեմն ձախողվում են:

Անվտանգության դարպասի օրինակ է որակյալ դարպասի անալոգը՝ կոդի մեջ առկա խոցելիության և քանակի առումով:

Մենք ինտեգրվում ենք SonarQube-ի հետ - plugin-ը տեղադրված է, ամեն ինչ շատ հարմար է և զով:

Ինտեգրում զարգացման միջավայրի հետ

Ինտեգրման ընտրանքներ.

• Զարգացման միջավայրից սկանավորումը կատարելուց առաջ:
• Դիտել արդյունքները.
• Արդյունքների վերլուծություն.
• Համաժամացում սերվերի հետ:

Ահա թե ինչ տեսք ունի սերվերից արդյունքներ ստանալը:

Մեր զարգացման միջավայրում Խելացի Գաղափար Պարզապես հայտնվում է լրացուցիչ նյութ, որը տեղեկացնում է, որ սկանավորման ընթացքում հայտնաբերվել են նման խոցելիություններ: Դուք կարող եք անմիջապես խմբագրել կոդը, դիտել առաջարկությունները և Հոսքի գրաֆիկ. Այս ամենը գտնվում է ծրագրավորողի աշխատավայրում, ինչը շատ հարմար է. կարիք չկա հետևել այլ հղումներին և որևէ լրացուցիչ բան նայել:

Open Source

Սա իմ սիրելի թեման է: Բոլորն օգտագործում են բաց կոդով գրադարաններ. ինչու՞ գրել մի փունջ հենակներ և հեծանիվներ, երբ կարող եք վերցնել պատրաստի գրադարան, որտեղ ամեն ինչ արդեն ներդրված է:

Իհարկե, դա ճիշտ է, բայց գրադարանները նույնպես մարդիկ են գրում, դրանք ներառում են նաև որոշակի ռիսկեր և կան նաև խոցելիություններ, որոնց մասին պարբերաբար կամ անընդհատ հաղորդվում է: Հետևաբար, կա հավելվածի անվտանգության հաջորդ քայլը՝ սա բաց կոդով բաղադրիչների վերլուծությունն է:

Բաց կոդով վերլուծություն - OSA

Գործիքը ներառում է երեք մեծ փուլ.

Գրադարաններում խոցելիության որոնում: Օրինակ, գործիքը գիտի, որ մենք օգտագործում ենք ինչ-որ գրադարան, և որ CVE կամ կան որոշ խոցելիություններ bug trackers-ում, որոնք վերաբերում են գրադարանի այս տարբերակին: Երբ փորձեք օգտագործել այն, գործիքը նախազգուշացում կհրապարակի, որ գրադարանը խոցելի է և խորհուրդ է տալիս օգտագործել այլ տարբերակ, որը չունի խոցելի կետեր:

Լիցենզիայի մաքրության վերլուծություն: Սա դեռ առանձնապես հայտնի չէ այստեղ, բայց եթե դուք աշխատում եք արտասահմանում, ապա ժամանակ առ ժամանակ կարող եք այնտեղ հարկ ստանալ բաց կոդով բաղադրիչ օգտագործելու համար, որը չի կարող օգտագործվել կամ փոփոխվել: Լիցենզավորված գրադարանի քաղաքականության համաձայն՝ մենք չենք կարող դա անել։ Կամ, եթե մենք փոփոխել ենք այն և օգտագործել այն, մենք պետք է տեղադրենք մեր կոդը: Իհարկե, ոչ ոք չի ցանկանում հրապարակել իր արտադրանքի կոդը, բայց դուք կարող եք նաև պաշտպանվել ձեզ դրանից:

Արդյունաբերական միջավայրում օգտագործվող բաղադրիչների վերլուծություն: Եկեք պատկերացնենք հիպոթետիկ իրավիճակ, որ մենք վերջապես ավարտեցինք մշակումը և թողարկեցինք մեր միկրոսերվիսի վերջին թողարկումը: Նա այնտեղ հիանալի է ապրում՝ մեկ շաբաթ, մեկ ամիս, մեկ տարի։ Մենք չենք հավաքում այն, մենք անվտանգության ստուգումներ չենք անցկացնում, ամեն ինչ կարծես թե լավ է։ Բայց հանկարծ, թողարկումից երկու շաբաթ անց, բաց կոդով բաղադրիչում հայտնվում է կրիտիկական խոցելիություն, որը մենք օգտագործում ենք այս կոնկրետ նախագծում՝ արդյունաբերական միջավայրում: Եթե ​​մենք չգրանցենք, թե ինչ և որտեղ ենք օգտագործում, ապա մենք պարզապես չենք տեսնի այս խոցելիությունը: Որոշ գործիքներ հնարավորություն ունեն վերահսկելու գրադարանների խոցելիությունը, որոնք ներկայումս օգտագործվում են արդյունաբերության մեջ: Դա շատ օգտակար է։

Նկարագրություն:

• Տարբեր քաղաքականություն զարգացման տարբեր փուլերի համար:
• Արդյունաբերական միջավայրում բաղադրիչների մոնիտորինգ:
• Կազմակերպության ներսում գրադարանների վերահսկում.
• Աջակցություն կառուցման տարբեր համակարգերի և լեզուների համար:
• Docker պատկերների վերլուծություն:

Արդյունաբերության առաջատարների մի քանի օրինակներ, ովքեր զբաղվում են բաց կոդով վերլուծությամբ:

Միակ անվճարը սա է Կախվածություն-Ստուգ OWASP-ից: Դուք կարող եք այն միացնել առաջին փուլերում, տեսնել, թե ինչպես է այն աշխատում և ինչ է աջակցում: Հիմնականում սրանք բոլորը ամպային ապրանքներ են կամ ներկառուցված, բայց դրանց բազայի հետևում դրանք դեռ ուղարկվում են ինտերնետ: Նրանք ուղարկում են ոչ թե ձեր գրադարանները, այլ հեշերը կամ իրենց սեփական արժեքները, որոնք նրանք հաշվարկում են, և մատնահետքեր են ուղարկում իրենց սերվերին՝ խոցելիության առկայության մասին տեղեկատվություն ստանալու համար:

Գործընթացի ինտեգրում

Գրադարանների պարագծային հսկողություն, որոնք ներբեռնվում են արտաքին աղբյուրներից։ Մենք ունենք արտաքին և ներքին պահոցներ: Օրինակ, Event Central-ն աշխատում է Nexus-ը, և մենք ցանկանում ենք համոզվել, որ մեր պահոցում խոցելիություններ չկան «կրիտիկական» կամ «բարձր» կարգավիճակով: Դուք կարող եք կարգավորել պրոքսինգը՝ օգտագործելով Nexus Firewall Lifecycle գործիքը, որպեսզի այդպիսի խոցելիությունները կտրվեն և չհայտնվեն ներքին պահոցում:

Ինտեգրում CI-ին. Նույն մակարդակի վրա՝ ավտոթեստերի, միավորի թեստերի և զարգացման փուլերի բաժանման հետ՝ մշակում, թեստ, արտադր. Յուրաքանչյուր փուլում կարող եք ներբեռնել ցանկացած գրադարան, օգտագործել որևէ բան, բայց եթե «կրիտիկական» կարգավիճակի հետ կապված ինչ-որ դժվար բան կա, գուցե արժե ծրագրավորողների ուշադրությունը հրավիրել դրա վրա արտադրության թողարկման փուլում:

Ինտեգրում արտեֆակտների հետNexus և JFrog:

Ինտեգրում զարգացման միջավայրում: Ձեր ընտրած գործիքները պետք է ինտեգրված լինեն զարգացման միջավայրերին: Մշակողը պետք է հասանելի լինի սկանավորման արդյունքներին իր աշխատավայրից կամ հնարավորություն ունենա սկանավորել և ստուգել կոդը խոցելիության համար՝ նախքան CVS-ին միանալը:

CD ինտեգրում. Սա հիանալի հատկություն է, որն ինձ իսկապես դուր է գալիս, և որի մասին ես արդեն խոսել եմ՝ արդյունաբերական միջավայրում նոր խոցելիության ի հայտ գալու մոնիտորինգ: Այն աշխատում է նման բան.

Մենք ունենք Հանրային բաղադրիչների պահոցներ — որոշ գործիքներ դրսում և մեր ներքին պահոցը: Մենք ցանկանում ենք, որ այն պարունակի միայն վստահելի բաղադրիչներ: Հարցման պրոքսիինգի ժամանակ մենք ստուգում ենք, որ ներբեռնված գրադարանը խոցելիություններ չունի: Եթե ​​այն պատկանում է որոշակի քաղաքականությանը, որը մենք սահմանել ենք և անպայմանորեն համաձայնեցնում ենք մշակման հետ, ապա մենք չենք վերբեռնում այն ​​և մեզ հուշում են օգտագործել մեկ այլ տարբերակ: Համապատասխանաբար, եթե գրադարանում իսկապես կրիտիկական և վատ բան կա, ապա մշակողը չի ստանա գրադարանը տեղադրման փուլում՝ թող օգտագործի ավելի բարձր կամ ցածր տարբերակ:

• Կառուցելիս մենք ստուգում ենք, որ ոչ ոքի որևէ վատ բան չի սայթաքել, բոլոր բաղադրիչները անվտանգ են և ոչ ոք ֆլեշ կրիչի վրա վտանգավոր բան չի բերել։
• Մենք պահոցում ունենք միայն վստահելի բաղադրիչներ:
• Տեղակայելիս մենք ևս մեկ անգամ ստուգում ենք փաթեթը` war, jar, DL կամ Docker պատկերը` համոզվելու համար, որ այն համապատասխանում է քաղաքականությանը:
• Արդյունաբերություն մտնելիս մենք վերահսկում ենք, թե ինչ է կատարվում արդյունաբերական միջավայրում՝ կրիտիկական խոցելիություններ են հայտնվում կամ չեն ի հայտ գալիս։

Դինամիկ վերլուծություն - DAST

Դինամիկ վերլուծության գործիքները սկզբունքորեն տարբերվում են այն ամենից, ինչ ասվել է նախկինում: Սա հավելվածի հետ օգտագործողի աշխատանքի մի տեսակ իմիտացիա է: Եթե ​​սա վեբ հավելված է, ապա մենք հարցումներ ենք ուղարկում՝ մոդելավորելով հաճախորդի աշխատանքը, սեղմում ենք դիմացի կոճակների վրա, ձևից ուղարկում ենք արհեստական ​​տվյալներ՝ չակերտներ, փակագծեր, տարբեր կոդավորումներով նիշեր, տեսնելու, թե ինչպես է հավելվածն աշխատում և մշակվում։ արտաքին տվյալներ.

Նույն համակարգը թույլ է տալիս ստուգել կաղապարի խոցելիությունը Open Source-ում: Քանի որ DAST-ը չգիտի, թե որ բաց կոդով ենք մենք օգտագործում, այն պարզապես նետում է «վնասակար» նախշեր և վերլուծում սերվերի պատասխանները.

- Այո, այստեղ ապասերիալացման խնդիր կա, այստեղ՝ ոչ։

Սրա մեջ մեծ ռիսկեր կան, քանի որ եթե անվտանգության այս թեստն անցկացնեք նույն նստարանին, որի հետ աշխատում են փորձարկողները, տհաճ բաներ կարող են տեղի ունենալ:

• Բարձր ծանրաբեռնվածություն հավելվածի սերվերի ցանցում:
• Ոչ մի ինտեգրացիա:
• Վերլուծված հավելվածի կարգավորումները փոխելու ունակություն:
• Անհրաժեշտ տեխնոլոգիաների աջակցություն չկա։
• Տեղադրման դժվարություն:

Մենք ունեինք մի իրավիճակ, երբ վերջապես գործարկեցինք AppScan-ը. մենք երկար ժամանակ ծախսեցինք՝ փորձելով մուտք գործել հավելված, ստացանք 3 հաշիվ և ուրախացանք. վերջապես ամեն ինչ կստուգենք: Մենք գործարկեցինք սկանավորում, և առաջին բանը, ինչ AppScan-ն արեց, մտավ ադմինիստրատորի վահանակ, ծակեց բոլոր կոճակները, փոխեց տվյալների կեսը և այնուհետև ամբողջությամբ սպանեց սերվերն իր միջոցով: փոստի ձև- հարցումներ. Զարգացումը փորձարկման միջոցով ասաց.

- Տղերք, կատակո՞ւմ եք ինձ։ Մենք ձեզ հաշիվներ ենք տվել, իսկ դուք կանգնել եք:

Հաշվի առեք հնարավոր ռիսկերը: Իդեալում, պատրաստեք առանձին ստենդ՝ տեղեկատվական անվտանգության փորձարկման համար, որը գոնե ինչ-որ կերպ մեկուսացված կլինի մնացած միջավայրից և պայմանականորեն ստուգեք ադմինիստրատորի վահանակը, գերադասելի է ձեռքով ռեժիմում։ Սա պենտեստ է. ջանքերի մնացած տոկոսները, որոնք մենք հիմա չենք դիտարկում:

Արժե հաշվի առնել, որ դուք կարող եք դա օգտագործել որպես բեռի փորձարկման անալոգ: Առաջին փուլում դուք կարող եք միացնել դինամիկ սկաները 10-15 թելերով և տեսնել, թե ինչ է տեղի ունենում, բայց սովորաբար, ինչպես ցույց է տալիս պրակտիկան, ոչ մի լավ բան:

Մի քանի ռեսուրսներ, որոնք մենք սովորաբար օգտագործում ենք:

Արժե ընդգծել Burp Suite «Շվեյցարական դանակ» է անվտանգության ցանկացած մասնագետի համար: Այն օգտագործում են բոլորը, և դա շատ հարմար է։ Այժմ թողարկվել է ձեռնարկության հրատարակության նոր ցուցադրական տարբերակը: Եթե ​​նախկինում դա պարզապես առանձին կոմունալ ծրագիր էր փլագիններով, ապա այժմ մշակողները վերջապես պատրաստում են մեծ սերվեր, որից հնարավոր կլինի կառավարել մի քանի գործակալներ։ Սա հիանալի է, խորհուրդ եմ տալիս փորձել:

Գործընթացի ինտեգրում

Ինտեգրումը տեղի է ունենում բավականին լավ և պարզ. սկսեք սկանավորումը հաջող տեղադրումից հետո դիմումներ ստենդի համար և սկանավորում հաջող ինտեգրման փորձարկումից հետո.

Եթե ​​ինտեգրումները չեն աշխատում, կամ կան կոճղեր և ծաղրական գործառույթներ, դա անիմաստ է և անօգուտ. անկախ նրանից, թե ինչ օրինաչափություն ենք ուղարկում, սերվերը դեռ նույն կերպ կպատասխանի:

• Իդեալում, առանձին փորձարկման տակդիր:
• Նախքան փորձարկումը, գրեք մուտքի հաջորդականությունը:
• Վարչական համակարգի փորձարկումը միայն ձեռքով է:

պրոցես

Մի փոքր ընդհանրացված գործընթացի մասին ընդհանրապես և յուրաքանչյուր գործիքի աշխատանքի մասին, մասնավորապես: Բոլոր հավելվածները տարբեր են. մեկն ավելի լավ է աշխատում դինամիկ վերլուծությամբ, մյուսը՝ ստատիկ վերլուծությամբ, երրորդը՝ OpenSource վերլուծությամբ, pentests-ով կամ ընդհանրապես այլ բանով, օրինակ՝ իրադարձություններով վաֆ.

Յուրաքանչյուր գործընթաց վերահսկողության կարիք ունի։

Որպեսզի հասկանաք, թե ինչպես է աշխատում գործընթացը և որտեղ այն կարող է բարելավվել, դուք պետք է չափումներ հավաքեք այն ամենից, ինչ կարող եք ձեռք բերել, ներառյալ արտադրության չափումները, գործիքների չափումները և թերությունների հետագծերը:

Ցանկացած տեղեկություն օգտակար է: Պետք է տարբեր տեսանկյուններից նայել, թե որտեղ է ավելի լավ օգտագործվում այս կամ այն ​​գործիքը, որտեղ գործընթացը կոնկրետ թուլանում է։ Թերևս արժե դիտարկել զարգացման արձագանքման ժամանակները՝ տեսնելու համար, թե որտեղ կարելի է բարելավել գործընթացը՝ հիմնված ժամանակի վրա: Որքան շատ տվյալներ, այնքան ավելի շատ բաժիններ կարող են կառուցվել վերին մակարդակից մինչև յուրաքանչյուր գործընթացի մանրամասները:

Քանի որ բոլոր ստատիկ և դինամիկ անալիզատորներն ունեն իրենց սեփական API-ները, գործարկման իրենց մեթոդները, սկզբունքները, ոմանք ունեն ժամանակացույցեր, մյուսները չունեն, մենք գործիք ենք գրում: AppSec Orchestrator, որը թույլ է տալիս արտադրանքից ստեղծել մեկ մուտքի կետ ամբողջ գործընթացում և կառավարել այն մեկ կետից:

Մենեջերները, մշակողները և անվտանգության ինժեներներն ունեն մեկ մուտքի կետ, որտեղից նրանք կարող են տեսնել, թե ինչ է աշխատում, կարգավորել և գործարկել սկանավորումը, ստանալ սկանավորման արդյունքներ և ներկայացնել պահանջներ: Մենք փորձում ենք հեռանալ թղթաբանությունից, ամեն ինչ թարգմանել մարդկայինի, որն օգտագործվում է մշակման կողմից՝ էջեր միաձուլման կարգավիճակի և չափումների հետ, Jira-ի թերությունները կամ տարբեր թերությունների հետքերում կամ ինտեգրումը համաժամանակյա/ասինխրոն գործընթացին CI-ում: /CD.

Հիմնական տուփեր

Գործիքները գլխավորը չեն։ Նախ մտածեք գործընթացի միջոցով, ապա գործադրեք գործիքները: Գործիքները լավն են, բայց թանկ, այնպես որ դուք կարող եք սկսել գործընթացից և ստեղծել հաղորդակցություն և փոխըմբռնում զարգացման և անվտանգության միջև: Անվտանգության տեսանկյունից ամեն ինչ «դադարեցնելու» կարիք չկա, զարգացման տեսանկյունից, եթե կա ինչ-որ բարձր մեգա սուպերկրիտիկական բան, ապա այն պետք է վերացնել, այլ ոչ թե աչք փակել խնդրի վրա։

Ապրանքի որակը - ընդհանուր նպատակ ինչպես անվտանգություն, այնպես էլ զարգացում: Մենք մի բան ենք անում, փորձում ենք այնպես անել, որ ամեն ինչ ճիշտ աշխատի, հեղինակության ռիսկեր կամ ֆինանսական կորուստներ չլինեն։ Այդ իսկ պատճառով մենք խթանում ենք DevSecOps, SecDevOps մոտեցումը՝ բարելավելու հաղորդակցությունը և բարելավելու արտադրանքի որակը:

Սկսեք նրանից, ինչ արդեն ունեքպահանջներ, ճարտարապետություն, մասնակի ստուգումներ, դասընթացներ, ուղեցույցներ: Կարիք չկա անհապաղ կիրառել բոլոր պրակտիկաները բոլոր նախագծերում. շարժվել կրկնվող. Չկա մեկ ստանդարտ. փորձ և փորձեք տարբեր մոտեցումներ և լուծումներ:

Տեղեկատվական անվտանգության թերությունների և ֆունկցիոնալ թերությունների միջև կա հավասար նշան.

Ավտոմատացրեք ամեն ինչոր շարժվում է. Այն, ինչ չի շարժվում, տեղափոխեք այն և ավտոմատացրեք այն: Եթե ​​ինչ-որ բան արվում է ձեռքով, դա գործընթացի լավ մաս չէ: Թերևս արժե այն վերանայել և նաև ավտոմատացնել:

Եթե ​​IS թիմի չափը փոքր է, օգտագործել Security Champions.

Միգուցե այն, ինչի մասին ես խոսեցի, ձեզ չհամապատասխանի, և դուք ինքներդ ինչ-որ բան կգտնեք, և դա լավ է: Բայց ընտրեք գործիքներ՝ հիմնվելով ձեր գործընթացի պահանջների վրա. Մի նայեք, թե ինչ է ասում համայնքը, որ այս գործիքը վատն է, իսկ սա լավը: Թերևս հակառակը կլինի ձեր արտադրանքի համար:

Գործիքների պահանջները.

• Ցածր մակարդակի կեղծ դրական:
• Համապատասխան վերլուծության ժամանակ:
• Օգտագործման հեշտությունը.
• Ինտեգրումների առկայություն:
• Հասկանալով արտադրանքի զարգացման ճանապարհային քարտեզը:
• Գործիքների հարմարեցման հնարավորություն:

Յուրիի զեկույցն ընտրվել է որպես լավագույններից մեկը DevOpsConf 2018-ին։Ավելի հետաքրքիր գաղափարներին և գործնական դեպքերին ծանոթանալու համար մայիսի 27-ին և 28-ին եկեք Skolkovo։ DevOpsConf ներսում RIT++ փառատոն. Ավելի լավ է, եթե պատրաստ եք կիսվել ձեր փորձով, ապա դիմել հաշվետվության համար մինչեւ ապրիլի 21-ը։

Source: www.habr.com