AppSec-ում ավտոմատ շտկումը խոցելիությունները ավտոմատ կերպով հայտնաբերելու և շտկելու գործընթաց է անմիջապես մշակման աշխատանքային հոսքում՝ առանց ձեռքով միջամտության: Ժամանակակից ծրագրային ապահովման թիմերի համար սա ակնհայտ հաջորդ քայլն է թվում։ Աշխատանքների կուտակումները շարունակում են աճել, թողարկման ցիկլերը՝ կրճատվել, և քիչ կազմակերպություններ կարող են իրենց թույլ տալ ամեն օր իրականացնել իրենց ծրագրերը։ SAST գտնում, կախվածության խնդիր, գաղտնի արտահոսք կամ IaC սխալ կարգավորում լիովին ձեռքով շտկման հերթում։
Սակայն կա մի խնդիր։ Թիմերը ցանկանում են շտկել խոցելիությունները ավելի արագ, բայց նրանք չեն ցանկանում ավտոմատացում, որը աննկատելիորեն ներմուծում է ռեգրեսիաներ, խզում է կախվածությունները կամ ստեղծում է անկայունություն CI/CDԱյդ լարվածությունն այժմ հավելվածների անվտանգության կենտրոնական խնդիրներից մեկն է։ OWASP- ը բացահայտորեն վերաբերվում է CI/CD որպես անվտանգության ոլորտ՝ իր սեփական հիմնական ռիսկի կատեգորիաներով, մինչդեռ NIST-ի անվտանգ ծրագրային ապահովման մշակման շրջանակը հստակեցնում է, որ անվտանգ մշակման պրակտիկաները պետք է ինտեգրվեն SDLC փոխարենը վերջում ամրացված լինելու։
Ահա թե ինչու ավտոմատ շտկում Սա պարզապես ապրանքի առանձնահատկություն չէ։ Այն գործառնական մոդել է։ Վատ կատարված դեպքում այն ստեղծում է աղմուկ, ռիսկ և խափանված կառուցվածքներ։ Լավ կատարված դեպքում այն լրացնում է հայտնաբերման և վերականգնման միջև եղած բացը, կրճատում է շտկման ժամանակը և օգնում է անվտանգությանը համապատասխանել DevOps-ի արագությանը։ Այս ուղեցույցում մենք կանդրադառնանք, թե իրականում ինչ է նշանակում ավտոմատ շտկումը։ AppSec, որտեղ է այն ձախողվում, ինչպիսին պետք է լինի անվտանգ ավտոմատացված վերականգնումը և ինչպես այն իրականացնել այնպես, որ մշակողները իրականում վստահեն։
Ի՞նչ է Autofix-ը AppSec-ում:
Հիմնական մակարդակում, ավտոմատ շտկում նշանակում է, որ ծրագիրը ոչ միայն անվտանգության խնդիրը նույնականացնում է, այլև առաջարկում, ստեղծում կամ կիրառում է շտկման միջոց։ Այլ կերպ ասած, գործիքը «սա է խնդիրը»-ից անցնում է «սա է լուծումը»-ի։
Դա հնչում է պարզ, բայց գործնականում այն ընդգրկում է մի քանի շատ տարբեր աշխատանքային հոսքեր:
In SAST, ավտոմատ ուղղումը սովորաբար նշանակում է կոդի մակարդակի փոփոխություններ կատարել այնպիսի խոցելիությունների համար, ինչպիսիք են SQL ներարկումը, միջկայքային սկրիպտավորումը, անվտանգ դեսերիալացման օրինաչափությունները, թույլ մուտքային վավերացումը կամ անվտանգ նույնականացման տրամաբանությունը։ SCA, դա սովորաբար նշանակում է կախվածությունների թարմացումների խորհուրդ տալ կամ կիրառել, ավելի անվտանգ տարբերակների ամրագրում կամ ստեղծել pull requests որոնք տեղափոխում են փաթեթները թարմացված թողարկումների մեջ։ Գաղտնիքների անվտանգություն, ավտոմատ ուղղումը կարող է նշանակել հավատարմագրերի չեղարկում և փոխարինում, այլ ոչ թե պարզապես դրանց նշում։ IaC, դա կարող է նշանակել անապահով Terraform-ի, Kubernetes-ի կամ ամպային կոնֆիգուրացիայի ձևանմուշների վերաշարադրում ավելի անվտանգ լռելյայն կարգավորումների։
Կարևոր տարբերությունն այն է, որ ավտոմատ ուղղումը նույնը չէ, ինչ հուշումը: Անվտանգության շատ գործիքներ կարող են առաջարկել ընդհանուր շտկում: Քիչ թվով մարդիկ կարող են ստեղծել մշակողի համար պատրաստի փոփոխություն: Դեռ ավելի քիչ թվով մարդիկ կարող են այդ շտկումը գործարկել իրական առաքման աշխատանքային հոսքի միջոցով, վավերացնել այն և ներկայացնել մշակողին որպես աղբյուրի կառավարման վերանայելի փոփոխություն:
Այդ տարբերությունը կարևոր է, քանի որ ժամանակակից ինժեներական թիմերը չեն գործում PDF ֆայլերում և տոմսերում։ Նրանք գործում են pull requests, քաղաքականություններ, ստուգումներ և pipelines.
Ինչու՞ ավանդական վերականգնումը չի տարածվում
Ավտոմատ շտկման օգտին փաստարկները սկսվում են ցավալի իրականությունից. ավանդական շտկման գործընթացները չեն համապատասխանում ժամանակակից ծրագրային ապահովման մատակարարմանը։
Կազմակերպությունների մեծ մասն արդեն իսկ ունի բավարար սկանավորում։ Նրանք չունեն բավարար լուծաչափ։ Ստատիկ վերլուծությունը, կախվածությունների սկանավորումը, գաղտնիության հայտնաբերումը և ենթակառուցվածքների ստուգումները անընդհատ արդյունքներ են տալիս։ Միևնույն ժամանակ, ինժեներական թիմերը ճնշման տակ են՝ գործառույթները մատակարարելու, արտադրության ժամկետները ցածր պահելու և արտադրությունը անկայունացնելուց խուսափելու համար։
Արդյունքը բացահայտման և գործողության միջև եղած բացն է։
Նախ, կա պարզ ահազանգերի ծավալ։ Որքան ավելի հասուն է դառնում AppSec ծրագիրը, այնքան ավելի շատ արդյունքներ է այն հակված ստեղծել։ Դա միշտ չէ, որ բարելավում է անվտանգությունը։ Շատ միջավայրերում դա պարզապես կուտակումներ է առաջացնում։ Xygeni-ի արտադրանքի նյութերը սա դիտարկում են որպես աղմուկի և առաջնահերթության խնդիր, և այդ շրջանակը համապատասխանում է ավելի լայն արդյունաբերական իրականությանը. շատ ծրագրեր դժվարանում են առաջնահերթություն տալ, այլ ոչ թե միայն հայտնաբերում։
Երկրորդ, ձեռքով լուծումը նախագծված է դանդաղ։ Մշակողը պետք է կարդա խնդիրը, մեկնաբանի սկաների արդյունքը, անհրաժեշտության դեպքում վերարտադրի խնդիրը, մշակի լուծում, ներդնի այն, անցկացնի թեստեր, բացի... pull request, և սպասեք վերանայման: Սա կարող է ընդունելի լինել մեկ կարևոր խնդրի համար: Այն ընդունելի չէ հարյուրավոր միջին ծանրության հայտնաբերումների, կրկնվող կախվածությունների արդիականացման կամ բազմաթիվ պահոցներում գաղտնի տվյալների կրկնվող արտահոսքերի համար:
Երրորդ, անվտանգությունն ու ինժեներիան հաճախ օպտիմալացնում են տարբեր արդյունքներ: Անվտանգությունը ցանկանում է նվազեցնել ռիսկերը: Ինժեներական ոլորտը ցանկանում է, որ փոփոխությունները ներդրվեն անվտանգ և կանխատեսելի կերպով: Այդ տարբերությունը կառավարելի է, երբ արդյունքների հոսքը փոքր է: Այն վնասակար է դառնում, երբ թիմերը լցված են խնդիրներով, և գոյություն չունի որևէ մեխանիզմ՝ վավերացված արդյունքները անվտանգ, քիչ խնդրահարույց լուծումների վերածելու համար:
Ահա թե որտեղ է ավտոմատացումը սկսում անհրաժեշտ թվալ։ Եվ այնուամենայնիվ, անհրաժեշտությունն ինքնին ավտոմատացումը անվտանգ չի դարձնում։
Naive Autofix-ի խնդիրը
Ոչ բոլոր ավտոմատ լուծումներն են լավ ավտոմատ լուծումներ։ Իրականում, մշակողների կողմից անվտանգության ավտոմատացման վերաբերյալ ունեցած առարկություններից շատերը ավտոմատացման դեմ առարկություններ չեն։ Դրանք վատ ավտոմատացման դեմ առարկություններ են։
Միամիտ ավտոմատ շտկման շարժիչը սովորաբար ունենում է չորս խնդիրներից մեկը։
Առաջինն այն է, որ այն բոլոր խնդիրները դիտարկում է որպես հավասարապես շտկելի։ Սկաները տեսնում է խոցելի կախվածություն և պարզապես առաջարկում է հաջորդ թարմացված տարբերակը։ Կոդային շարժիչը տեսնում է անվտանգ չլինող օրինաչափություն և փոխարինում է այն պահածոյացված տարբերակով։ Սա կարող է աշխատել որոշ պարզ դեպքերում։ Այն արագորեն խափանվում է իրական համակարգերում, որտեղ կոդի բազան, ճարտարապետությունը, կատարման ժամանակը և կախվածության գրաֆիկը բոլորը կարևոր են։
Երկրորդը՝ այն անտեսում է կատարման համատեքստը։ Մեկուսացված ճիշտ տեսք ունեցող ուղղումը կարող է անտեղի, անբավարար կամ ռիսկային լինել իրական կոդի ուղիների վրա կիրառվելիս։ Սա շահագործման ազդանշանների այդքան կարևորության պատճառներից մեկն է։ FIRST-ի EPSS-ը գոյություն ունի նախկինում։cisքանի որ միայն խոցելիության ծանրությունը հուսալի ցուցիչ չէ այն բանի, թե արդյոք խոցելիությունը մոտ ապագայում կշահագործվի: EPSS-ը տրամադրում է CVE-ների շահագործման ակտիվության ամենօրյա հավանականության գնահատական, ինչը օգնում է թիմերին սահմանափակ վերականգնման կարողությունները կենտրոնացնել հարձակման ենթակա խոցելիության վրա:
Երրորդն այն է, որ միամիտ ավտոմատ ուղղումը անտեսում է փոփոխության ռիսկը։ Սա հատկապես վտանգավոր է SCAԿախվածության թարմացումը կարող է վերացնել CVE-ն և միևնույն ժամանակ առաջացնել API անհամատեղելիություններ, հեռացված մեթոդներ, վերանվանված դասեր, փոփոխված պայմանագրեր կամ աննշան աշխատանքային ժամանակի վարքագծի փոփոխություններ։
Չորրորդը գերավտոմատացումն է։ Երբ գործիքը բացում է ցածր արժեքի հոսք pull requests, որոնցից շատերը չեն հաջողվում փորձարկումներում կամ ստեղծում են միաձուլման խնդիրներ, մշակողները սովորում են անտեսել դրանք։ Սա վերականգնման արագացում չէ։ Սա վերականգնման սպամ է։
Հետևաբար, ճիշտ հարցը այն չէ, թե արդյոք թիմերը պետք է ավտոմատացնեն վերականգնման աշխատանքները: Ճիշտ հարցն այն է, թե ինչպիսի ավտոմատացում է նվազեցնում ռիսկը՝ առանց մեծացնելու շահագործման ցավը:
Ճգնաժամային փոփոխությունները իրական վստահության խնդիրն են
Երբ մշակողները ասում են, որ չեն վստահում ավտոմատ շտկմանը, նրանք հաճախ նկատի ունեն մեկ շատ կոնկրետ բան. նրանք չեն վստահում, որ այն ինչ-որ բան չի խափանի։
Այդ վստահության խնդիրն առավել տեսանելի է կախվածության վերացման մեջ։
Խոցելի փաթեթը կարող է ունենալ թարմացված տարբերակ, բայց դա չի նշանակում, որ թարմացումը անվտանգ է: Թարմացված թողարկումը կարող է հեռացնել ձեր ծրագրի կողմից օգտագործվող մեթոդը: Այն կարող է վերանվանել API-ը: Այն կարող է խստացնել տիպի պայմանագիրը: Այն կարող է փոփոխել վարքագիծը այնպես, որ այն անցնի միավորային թեստերը, բայց առաջացնի արտադրության հետընթաց: Շատ թիմերում վերականգնման իրական արժեքը թարմացման կիրառումը չէ: Այն պայթյունի շառավղի ուսումնասիրությունն է:
Դիտարկենք Java-ում պարզ օրինակ։ Կոդային բազան կախված է գրադարանից, որտեղ 1.x տարբերակում գոյություն ունի ընդհանուր մեթոդ, բայց 2.x տարբերակում այն հեռացված է։
// Before upgrade
MyService service = new MyService();
service.foo();
Թարմացումից հետո, foo() այլևս գոյություն չունի։ Խոցելիությունը կարող է վերացած լինել, բայց կառուցվածքը խափանված է։
Ահա թե ինչու «պարզապես թարմացնել շտկված տարբերակին» ճարտարագիտական ռազմավարություն չէ։ Այն ռիսկ է։
OWASP-ի CI/CD ուղեցույցը տեղին է այստեղ, քանի որ ժամանակակից առաքումը pipelines-ը և՛ արագացման մեխանիզմներ են, և՛ հարձակման մակերեսներ: Անվտանգության կառավարման միջոցներ, որոնք ստեղծում են անկայուն փոփոխություններ կամ անվերահսկելի pipeline վարքագիծը լուծում է մեկ խնդիր՝ ստեղծելով մեկ այլ խնդիր։ CI/CD Պաշտպանությունները պահանջում են հոսքի վերահսկողություն, վավերացում և քաղաքականության կիրառում, այլ ոչ թե պարզապես արագ փոփոխությունների ներարկում։
Անվտանգ ավտոմատ շտկումը պետք է հաշվի առնի այդ իրականությունը։ Այն պետք է հասկանա ոչ միայն, թե արդյոք խոցելիությունը կարելի է շտկել, այլև թե արդյոք այդ շտկումը կարող է ներդրվել առանց խախտելու այն ծրագրային ապահովման կենսական ցիկլը, որը նախատեսված է պաշտպանելու համար։
Ինչպիսի՞ն պետք է լինի անվտանգ ավտոմատ շտկումը
Անվտանգ ավտոմատ ուղղումը «ավտոմատ փոփոխությունների ստեղծում» չէ։ Անվտանգ ավտոմատ ուղղումը վերահսկվող ավտոմատացված վերականգնում.
Դա նշանակում է հինգ բան։
Նախ, շտկումները պետք է հաշվի առնեն համատեքստը: Անվտանգ առաջարկը, որը անտեսում է շրջակա կոդը, շրջանակային կոնվենցիաները, տվյալների հոսքը կամ կախվածության վարքագիծը, բավարար չէ: Ուղղումը պետք է համապատասխանի ծրագրին, այլ ոչ թե միայն խոցելիության դասին:
Երկրորդ, շտկումները պետք է հաշվի առնեն ռիսկը։ Ահա թե որտեղ է կարևոր շտկման ռիսկի վերլուծությունը։ Լավ ավտոմատ շտկման համակարգը պետք է կարողանա պատասխանել հիմնական ինժեներական հարցին՝ փոփոխություն առաջարկելուց առաջ. ո՞րն է այս շտկման կողմից ներդրվելու հավանականությունը։ խախտում փոփոխություններ?
Երրորդ, շտկումները պետք է առաջնահերթություն ունենան։ Լավագույն ավտոմատ շտկման ծրագրերը չեն փորձում ամեն ինչ միանգամից շտկել։ Դրանք շտկումը համապատասխանեցնում են շահագործման, հասանելիության և գործառնական ազդեցության հետ։ Սա համապատասխանում է նրան, թե ինչպես են հասուն AppSec ծրագրերը զարգանում ավելի լայնորեն։ CISA-ի հայտնի շահագործված խոցելիությունների կատալոգը գոյություն ունի նախկինումcisհեշտությամբ օգնել կազմակերպություններին ներառել շահագործման ապացույցները վերականգնման գործընթացումcisիոններ, ոչ միայն ծանրության գնահատական։
Չորրորդ, ավտոմատ շտկումը պետք է աշխատի իրական առաքման աշխատանքային հոսքերի ներսում։ Եթե շտկման մեխանիզմը չի կարող աշխատել pull requests, ստուգումներ, քաղաքականություններ և թեստեր, այն համահունչ չէ այն բանին, թե ինչպես են ժամանակակից թիմերը մատակարարում ծրագրային ապահովումը։
Հինգերորդ՝ մշակողները պետք է շարունակեն վերահսկողությունը։ Մշակողների կողմից հաստատված փոփոխությունները ավտոմատ շտկման թույլ կողմը չեն։ Դրանք այն մեխանիզմն են, որը ավտոմատացումը դարձնում է հուսալի արտադրական ճարտարագիտական միջավայրերում։
Այլ կերպ ասած, անվտանգ վերականգնումը պահանջում է վերահսկողություն, այլ ոչ թե միայն ավտոմատացում։
Նաիվ ավտոմատ շտկում ընդդեմ անվտանգ ավտոմատ շտկման
Ստորև ներկայացված է աշխատանք ստեղծող ավտոմատացման և այն վերացնող ավտոմատացման միջև գործնական տարբերությունը։
| Կերպարանք | Պարզ ավտոմատ շտկում | Անվտանգ ավտոմատ շտկում |
|---|---|---|
| Ուղղման ռազմավարություն | Կիրառում է ընդհանուր շտկումներ կամ թարմացումներ, հենց որ խոցելիություն է հայտնաբերվում | Ստեղծում է համատեքստից կախված շտկումներ՝ հիմնված կոդի, կախվածության վարքագծի և աշխատանքային հոսքի վավերացման վրա։ |
| Կախվածության թարմացումներ | Առաջարկում է հաջորդ թարմացված տարբերակը՝ առանց փոփոխության ազդեցության վերլուծության | Գնահատում է թարմացման ուղիները և ստուգում է խախտող փոփոխությունները, նախքան շտկում առաջարկելը |
| Առաջնահերթություն | Գործում է միայն ծանրության վրա | Համատեղում է խստությունը շահագործելիության, հասանելիության և գործառնական ազդեցության հետ |
| Pipeline անվտանգություն | Կարող է բացել PR-ներ, որոնք ձախողվում են կառուցման կամ փորձարկման մեջ | Հաստատում է ուղղումները՝ CI/CD ստուգումներ և վերանայման դարպասներ |
| Մշակողի դերը | Մշակողները մաքրում են ավտոմատացման հետևանքները | Մշակողները վերանայում են անվտանգ, միավորման պատրաստ շտկման առաջարկները |
| Արդյունք | Ավելի շատ աղմուկ, ավելի շատ ռեգրեսիաներ, ավելի ցածր վստահություն | Ավելի արագ շտկում, ավելի քիչ հետընթացներ, ավելի բարձր կիրառում |
Եթե ուզում եք այս սեղանից ինչ-որ բան քաղել, ապա սա է. Ավտոմատ շտկման որակը որոշվում է դրա համատեքստի և կառավարման տարրերի որակով.
Ինչպես է աշխատում ավտոմատ ուղղումը ժամանակակից DevSecOps-ում Pipeline
Հասուն միջավայրում, ավտոմատ շտկումը մեկ գործողություն չէ։ Այն կառուցվածքային շտկման աշխատանքային հոսք է, որը ինտեգրված է CI/CD.
Ձեռքով, անջատված շտկումների փոխարեն, ժամանակակից pipelines-ը հետևում են անընդհատ հոսքի՝
Ինչպես է աշխատում ավտոմատ ուղղումը ժամանակակից DevSecOps-ում Pipeline
Հասուն միջավայրում, ավտոմատ շտկումը մեկ գործողություն չէ։ Այն կառուցվածքային շտկման աշխատանքային հոսք է, որը ինտեգրված է CI/CD.
Ձեռքով, անջատված շտկումների փոխարեն, ժամանակակից pipelines-ը հետևում են անընդհատ հոսքի՝
Քայլ առ քայլ ավտոմատ շտկման աշխատանքային հոսք
- Հայտնաբերում
Պահոցներ, pull requests, տարաներ կամ IaC Արտեֆակտները սկանավորվում են՝ օգտագործելով SAST, SCA, Գաղտնիքներ կամ ենթակառուցվածքների ստուգումներ։ - Առաջնահերթություն
Բոլոր խոցելիությունները հավասարապես չեն դիտարկվում։ Ավտոմատ շտկման համակարգերը առաջնահերթություն են տալիս՝ օգտագործելով.- Հասանելիության վերլուծություն
- Շահագործելիության ազդանշաններ, ինչպիսիք են EPSS-ը
- Հայտնի շահագործված խոցելիություններ (KEV)
- Տեղակայման համատեքստ
- Ուղղել գեներացիան
Համակարգը ստեղծում է շտկման գործողություններ՝ հիմնվելով խնդրի տեսակի վրա.- Կոդի շտկումներ SAST խոցելիություններ
- Կախվածության թարմացումներ SCA
- Գաղտնի չեղարկում և ռոտացիա
- IaC կոնֆիգուրացիայի ուղղումներ
- Pull Request Ստեղծում
Լրացումները փաթեթավորված են մշակողի համար նախատեսված աշխատանքային հոսքերում, սովորաբար որպես pull requests հետ:- Կոդի տարբերությունները
- Համատեքստ և հիմնավորում
- Առաջարկվող փոփոխություններ
- Հաստատում CI/CD
Միաձուլումից առաջ շտկումները ավտոմատ կերպով վավերացվում են հետևյալի միջոցով՝- Միավորի և ինտեգրման թեստեր
- Կառուցեք չեկեր
- Անվտանգության քաղաքականություն
- Մշակողի հաստատում և միաձուլում
Մշակողները վերանայում, հաստատում կամ մերժում են փոփոխությունները նախքան արտադրության մեջ միանալը։
Արդյունքում, ավտոմատ շտկումը չի շրջանցում մշակման կյանքի ցիկլը։ Այն գործում է դրա ներսում։
Այն անխափան ինտեգրվում է այնպիսի հարթակների հետ, ինչպիսիք են GitHub-ը, GitLab-ը և Azure DevOps-ը՝ ապահովելով, որ խոցելիության վերացումը դառնում է մատակարարման աշխատանքային հոսքի մի մասը, այլ ոչ թե առանձին գործընթաց։
Տարբեր խոցելիության դասերի ավտոմատ շտկում
Ավտոմատ շտկման զրույցի ամենատարածված սխալներից մեկն այն է, որ բոլոր շտկումները նույն կերպ են վարվում։ Բայց դրանք այդպես չեն։
Ավտոմատ շտկում SAST
Կոդի մակարդակի ավտոմատ շտկումը այն գործընթացն է, երբ շատերն առաջին անգամ հանդիպում են այս հայեցակարգին: Սկաները գտնում է SQL ներարկում, արտացոլված XSS ընդունիչ կամ անապահով վավերացման ձևանմուշ և առաջարկում է անվտանգ փոխարինում: Սա հաճախ ավտոմատ շտկման ամենաինտուիտիվ ձևն է, քանի որ շտկումը տեսանելի է սկզբնական կոդում և կարող է վերանայվել ինչպես ցանկացած այլ փոփոխություն:
Xygeni-ի արտադրանքի նյութերը AI AutoFix-ը այս տարածքում դիրքավորում են որպես համատեքստից կախված շտկող միջոց, որը ստեղծում է մշակողի համար պատրաստ շտկումներ և pull requests XSS-ի և SQL ներարկման նման խնդիրների համար։ Հիմնական ուղերձը կարևոր է նույնիսկ ապրանքի պնդումից այն կողմ. լավ SAST Ավտոմատ շտկումը պետք է հաշվի առնի կոդը, այլ ոչ թե միայն կանոնները։
Ավտոմատ շտկում SCA
Կախվածության ավտոմատ լուծումը, անկասկած, ավելի կարևոր է գործառնական առումով, քանի որ խոցելի փաթեթները հայտնվում են անընդհատ, իսկ ձեռքով կախվածության պահպանումը չի տարածվում։ Բայց նաև այստեղ է, որ վստահությունը ամենադժվարն է վաստակել, քանի որ կախվածության թարմացումները հենց այնտեղ են, որտեղ խախտում փոփոխություններ դառնալ ամենացավոտը։
Վստահելի SCA Հետևաբար, ավտոմատ շտկման հնարավորությունը պետք է անի ավելին, քան պարզապես գտնել թարմացված տարբերակը։ Այն պետք է գնահատի արդիականացման անվտանգությունը, պայթյունի շառավիղը և համատեղելիությունը։
Գաղտնիքների ավտոմատ շտկում
Գաղտնիքների վերականգնումը ավելի շատ կապված է կոդի վերաշարադրման հետ, քան պահպանման հետ։ Եթե բացահայտվում է ակտիվ գաղտնիք, ապա իդեալական պատասխանը տոմս չէ, որը խնդրում է ինչ-որ մեկին այն հաջորդ շաբաթ փոխարինել։ Իդեալական պատասխանը անհապաղ չեղարկումն է, փոխարինումը և հստակ հետևումը։ Ահա թե ինչու գաղտնի անվտանգության ավտոմատ շտկումը հաճախ տարբերվում է կոդի ավտոմատ շտկումից։ Արժեքը արագությունն ու վստահությունն է։
Ավտոմատ շտկում IaC
Ենթակառուցվածքների սխալ կարգավորումները հաճախ կրկնվող են։ Դա դրանք դարձնում է ավտոմատացման համար ուժեղ թեկնածուներ։ Եթե թիմերը կարողանան standardTerraform-ի, Kubernetes-ի, ARM-ի կամ CloudFormation-ի համար անվտանգ օրինաչափություններ ստեղծելը, ապա ավտոմատ շտկումը կարող է այդ օրինաչափությունները կիրառել շատ ավելի վաղ փուլում։ pipelineNIST-ի SSDF-ի շեշտը յուրաքանչյուրի մեջ անվտանգ գործելակերպերի ինտեգրման վրա է SDLC իրականացումն այստեղ ուղղակիորեն տեղավորվում է. անվտանգությունն ամենաուժեղն է, երբ այն ներդրված է աշխատանքային հոսքում, այլ ոչ թե հետաձգվում է հետագա փուլերի համար։
Ինչպես խուսափել կառուցվածքների խափանումից Autofix-ի միջոցով
Սա թեմայի հիմնական խոստումն է, և այն արժանի է անմիջական քննարկման։
Ավտոմատ շտկման միջոցով կառուցվածքների խափանումներից խուսափելու համար թիմերը պետք է վավերացնեն շտկումը նույն կերպ, ինչպես վավերացնում են արտադրության հետ կապված ցանկացած այլ փոփոխություն։ Սա նշանակում է.
- փոփոխությունը կիրառելուց առաջ վերլուծեք կախվածությունը և կոդի ազդեցությունը
- հաստատեք ուղղումը CI/CD թեստերի և քաղաքականության հետ
- սահմանափակել ավտոմատացված հեռադիտակը, որտեղ պայթյունի շառավիղը բարձր է
- պահանջել մշակողի կողմից նյութական փոփոխությունների վերանայում
- օգտագործեք փուլային ներածություն բարձր ազդեցության թարմացումների համար
Ահա թե ինչու է վերականգնման ռիսկերի վերլուծությունն այդքան արժեքավոր։ Այն հարցը «կա՞ արդյոք լուծում» հարցից փոխում է «սա՞ է ամենաապահով լուծումը»։ Սա շատ ավելի լավ ինժեներական հարց է։
Սա նաև այն կետն է, որտեղ շատ ավտոմատացման ծրագրեր ձախողվում են։ Դրանք օպտիմալացնում են թողունակությունը և անտեսում փոփոխությունների անվտանգությունը։ Մշակողները դա անմիջապես նկատում են։
Ի հակադրություն, վստահելի ավտոմատ շտկման համակարգը հարգում է նույն փոփոխությունների կառավարման կարգապահությունը, որն արդեն իսկ կիրառում են ուժեղ ինժեներական թիմերը գործառույթների մշակման համար՝ վերանայում, փորձարկում, վավերացում, միավորում:
Ավտոմատ շտկման ներդրման լավագույն փորձը
Եթե դուք կառուցում կամ զարգացնում եք ավտոմատ շտկման ծրագիր, նպատակը պետք է լինի կիրառումը, այլ ոչ թե նորարարությունը: Թիմերը կօգտագործեն ավտոմատ շտկումը, երբ այն մշտապես խնայում է ժամանակ՝ առանց մաքրման աշխատանք ստեղծելու:
Սկսեք քաղաքականությունից։ Որոշեք, թե որ խնդիրների դասերն են անվտանգ ավտոմատացնելու համար նախ։ SAST Լավ հասկացված վերաշարադրումներով, սահմանված տարբերակների միջակայքերի ներսում կախվածությունների թարմացումներով կամ գաղտնի չեղարկման աշխատանքային հոսքերով կաղապարները հաճախ լավ վաղ թեկնածուներ են։
Այնուհետև նեղացրեք շրջանակը։ Մի փորձեք ամեն ինչ ավտոմատացնել մեկ թողարկման մեջ։ Սկզբում կենտրոնացեք այն խնդիրների վրա, որոնք և՛ տարածված են, և՛ բարձր վստահության արժանացած։ Դա սովորաբար ավելի լավ վստահության ձևավորման ռազմավարություն է, քան լայնածավալ, բայց աղմկոտ լուծումների ներդրումը։
Ինտեգրեք շտկումները մշակողների առկա աշխատանքային հոսքերի մեջ։ Եթե ձեր ինժեներական թիմերը բնակվում են pull requests և ճյուղերի պաշտպանությունները, ավտոմատ շտկումը նույնպես պետք է իրականացվի։
Չափեք արդյունքները։ Ճիշտ չափանիշները միայն «ստեղծված շտկումների քանակը» չեն։ Դրանք են՝ միաձուլման հաճախականությունը, ռեգրեսիայի հաճախականությունը, խնայված ժամանակը, կեղծ դրական արդյունքների կրճատումը և շտկման ժամանակը։
Վերջապես, պահպանեք մարդկային հաստատման շերտ այնտեղ, որտեղ դա կարևոր է: Անվտանգ ավտոմատ շտկումը չի վերացնում մշակողի դատողությունը: Այն բարձրացնում է այն՝ վերացնելով կրկնվող աշխատանքը և կենտրոնացնելով ուշադրությունը ավելի բարձր արժեք ունեցող վերանայման վրա:
Հայտնաբերումից մինչև վերականգնում. ցիկլի փակում
AppSec-ի հնացած գործիքակազմի ամենամեծ թույլ կողմերից մեկն այն է, որ գործընթացը շատ շուտ է ավարտվում։ Հայտնվում է հայտնաբերում։ Ստեղծվում է տոմս։ Այնուհետև համակարգը սպասում է։
Դա փակ ցիկլ չէ։ Դա փոխանակում է։
Ժամանակակից AppSec ծրագիրը պետք է կարողանա անցնել հայտնաբերումից մինչև առաջնահերթության սահմանում և ապա շտկում՝ հնարավորինս քիչ ձեռքով կազմակերպմամբ։ Սա է ավտոմատ շտկման իրական խոստումը։ Այն ոչ միայն արագացնում է շտկումը։ Այն փոխում է, թե որտեղ է տեղի ունենում շտկումը, ինչպես է այն ներդրվում և ով պետք է կատարի կրկնվող աշխատանքը։
Ահա թե ինչու է թեման կարևոր առևտրային առումով, այլ ոչ թե միայն տեխնիկական։ Գնորդները այլևս չեն ցանկանում միայն հայտնաբերման որակը։ Նրանք ցանկանում են չափելի կրճատել կուտակված գործերը և ավելի արագ անցնել խնդիրների հայտնաբերումից մինչև դրանց լուծումը։
Ինչպես է Xygeni-ն հնարավորություն տալիս անվտանգ ավտոմատ շտկման
Xygeni-ի նյութերը իրենց ավտոմատ շտկման հնարավորությունը դասում են երեք թեմաների շուրջ՝ համատեքստ, ավտոմատացում և առաքման ինտեգրացիա։
Կոդի կողմից, Քսիգենի արհեստական բանականություն SAST AutoFix-ը ստեղծում է մշակողի համար պատրաստի շտկումներ՝ փոխարինելով ռիսկային օրինաչափությունները անվտանգ այլընտրանքներով և այդ շտկումները մատուցելով pull requests վերացական առաջարկությունների փոխարեն։ Այն անմիջապես վերացնում է խոցելիությունները, ինչպիսիք են XSS-ը կամ SQL ներարկումը, և կիրառում է անվտանգ կոդավորման լավագույն փորձը անմիջապես մշակողի աշխատանքային հոսքում։
Սակայն Xygeni-ում ավտոմատ շտկումը գերազանցում է SAST. Այն նաև ներառում է Գաղտնիքների ավտոմատ շտկում, որը հայտնաբերում է արտահոսած մուտքային տվյալները և ավտոմատ կերպով չեղարկում դրանք՝ օգտագործելով նախապես կառուցված playbooks AWS, GCP կամ GitLab જેવી հարթակներում: Սա հնարավորություն է տալիս անհապաղ զսպել տվյալները, վերացնել ձեռքով արձագանքման ուշացումները և նվազեցնել հավատարմագրերի չարաշահման ռիսկը:
Կախվածության կողմում, Քսիգենիի SCA Ավտոմատ շտկում հնարավորություն է տալիս զանգվածային ավտոմատ շտկման՝ խոցելի կախվածությունների համար շտկումներ ստեղծելով և դրանք մասշտաբային կիրառելով: Թիմերը կարող են ակտիվացնել ավտոմատացված թարմացումներ, ստեղծել pull requests արդիականացված տարբերակներով և ինտեգրել շտկումը անմիջապես CI/CD pipelineառանց մատակարարումը խաթարելու։
Բացի այդ, այս հնարավորությունները տարածվում են մինչև Ենթակառուցվածքը որպես կոդ (IaC) և pipeline կոնֆիգուրացիաներ՝ ապահովելով, որ սխալ կոնֆիգուրացիաները և ռիսկային ենթակառուցվածքային մոդելները նույնպես շտկվեն նույն ավտոմատացված աշխատանքային հոսքի շրջանակներում։
Սա ռազմավարական կետն է։ Անվտանգ ավտոմատ շտկումը չի գործում մեկուսացված։ Այն ընդգրկում է կոդ (SAST), կախվածություններ (SCA), գաղտնիքներ և ենթակառուցվածքներ (IaC), ապահովելով հետևողական շտկումներ ամբողջ ծրագրային ապահովման մատակարարման շղթայում: Ավելին, այն լավագույնս աշխատում է, երբ համակցվում է շահագործելիության վրա հիմնված առաջնահերթության, կախվածության գրաֆիկների վերլուծության և CI/CD վավերացում, որպեսզի շտկումները ոչ միայն ավտոմատացված լինեն, այլև անվտանգ, համապատասխան և արտադրության համար պատրաստ։
Արագ պատասխան. Ինչպե՞ս անվտանգ կերպով շտկել խոցելիությունները ավտոմատ շտկման միջոցով:
Ավտոմատ շտկման միջոցով խոցելիությունները անվտանգ կերպով շտկելու համար թիմերին անհրաժեշտ են համատեքստից կախված շտկումներ, շահագործելիության վրա հիմնված առաջնահերթություն, շտկման ռիսկի վերլուծություն, CI/CD վավերացում և մշակողի հաստատում միաձուլումից առաջ։
Դա կարճ պատասխանն է։
Դրանից պակաս ցանկացած բան կարող է դեռևս ավտոմատացում լինել, բայց դա այն տեսակի ավտոմատացում չէ, որին մշակողները կվստահեն արտադրության մեջ։
ՀՏՀ
Ի՞նչ է ավտոմատ ուղղումը AppSec-ում։
AppSec-ում ավտոմատ շտկումը անվտանգության խնդիրների, ինչպիսիք են կոդի թերությունները, խոցելի կախվածությունները, բացահայտված գաղտնիքները կամ ենթակառուցվածքների սխալ կարգավորումները, շտկման փոփոխությունների ավտոմատ ստեղծումն ու իրականացումն է։
Կարո՞ղ է արդյոք ավտոմատ շտկումը խափանել կառուցվածքները։
Այո։ Ավտոմատ շտկումը կարող է խափանել կառուցվածքները, երբ կախվածության թարմացումները ներմուծում են անհամատեղելի փոփոխություններ, երբ շտկումները անտեսում են ծրագրի համատեքստը կամ երբ փոփոխությունները կիրառվում են առանց վավերացման։
Ինչպե՞ս կարելի է ավտոմատ կերպով շտկել խոցելիությունները՝ առանց ռեգրեսիաներ ստեղծելու։
Օգտագործեք ավտոմատ շտկում վերահսկվող աշխատանքային հոսքի ներսում. առաջնահերթություն տվեք շահագործելիության և հասանելիության հիման վրա, վերլուծեք վերականգնման ռիսկը, վավերացրեք փոփոխությունները CI/CDև պահպանել մշակողի հաստատման քայլը։
Ինչո՞վ է անվտանգ ավտոշտկումը տարբերվում պարզ ավտոշտկումից։
Անվտանգ ավտոմատ շտկումը հաշվի է առնում համատեքստը, ռիսկերը և pipeline-գիտակից։ Պարզ ավտոմատ շտկումը պարզապես առաջարկում կամ կիրառում է փոփոխություններ՝ առանց հասկանալու համատեղելիությունը, աշխատանքի վրա ազդեցությունը կամ ճարտարագիտական աշխատանքային հոսքը։
Արդյո՞ք արհեստական բանականության ավտոմատ ուղղումը հուսալի է։
Հնարավոր է, բայց հուսալիությունը կախված է վավերացումից և կառավարումից: Gartner-ը հստակորեն խորհուրդ է տալիս, որ արհեստական բանականության վրա հիմնված կազմակերպությունները... code security Ասիստենտները շարունակում են օգտագործել ավանդական AST-ը և կոդի վերանայումը որպես հավասարակշռող կառավարման միջոցներ, քանի որ արհեստական բանականության օպտիմիզատորները կարող են գերշտկել կամ բաց թողնել կատարողականության, հուսալիության և կոդի որակի հետ կապված խնդիրները։
Վերջնական takeaway
Ավտոմատ ուղղումը այլևս նորություն չէ AppSec-ում։ Այն դառնում է գործնական պահանջ այն թիմերի համար, որոնք պետք է կրճատեն կուտակված աշխատանքները՝ առանց աշխատակիցների թվաքանակը մեծացնելու կամ առաքումը դանդաղեցնելու։
Իրական խնդիրը շտկման ավտոմատացումը չէ, թե ոչ։ Խնդիրն այն է, թե արդյոք այդ ավտոմատացումը հաշվի է առնում, թե ինչպես է իրականում ստեղծվում և մատակարարվում ծրագիրը։
Եթե ձեր ավտոմատ շտկման ռազմավարությունը անտեսում է համատեքստը, առաջնահերթությունը և վավերացումը, ապա այն ավելի շատ խնդիրներ կստեղծի, քան արժեք։ Եթե այն մշակված է մշակողի աշխատանքային հոսքերի, շտկման ռիսկի և CI/CD կառավարման կետերում, այն կարող է էապես բարելավել ինչպես անվտանգության արդյունքները, այնպես էլ ճարտարագիտական արագությունը։
Դա է standard նպատակ դնելը արժե։
Հեղինակի մասին
Համահիմնադիր և տեխնիկական տնօրեն
Ֆաթիմա Said մասնագիտացած է AppSec, DevSecOps և այլ մշակողների համար նախատեսված բովանդակության մեջ։ software supply chain securityՆա բարդ անվտանգության ազդանշանները վերածում է հստակ, գործնական ուղեցույցի, որը օգնում է թիմերին ավելի արագ որոշել առաջնահերթությունները, նվազեցնել աղմուկը և ուղարկել ավելի անվտանգ կոդ։
