CRA-ի պատրաստվածությունը սկսվում է կոդբազից. 7 հարց՝ խոցելիությունները բացահայտելու համար

Կիբերկայունության ակտը (CRA) հաճախ դիտվում է որպես քաղաքական կամ հաշվետվողական մարտահրավեր, սակայն թվային տարրերի արտադրողների համար դրա ազդեցությունը շատ ավելի վաղ է ի հայտ գալիս՝ pull request-ներում, build pipeline-ներում, թողարկման հաստատման և թեստերի հավաքածուներում։ Ընկերությունը չի կարողանա օգտագործված խոցելիության վերաբերյալ վստահելի հաշվետվություն ներկայացնել, եթե նախապես չկարողանա պատասխանել պարզ ինժեներական հարցերի՝ որ տարբերակներն են տուժել, որ բաղադրիչն է ռիսկ ստեղծել և արդյոք ուղղումն աշխատել է իրական արտադրանքում։

Ժամկետներ, որոնք արդեն ուժի մեջ են մտել

CRA-ի շրջանակներում թվային տարրերի արտադրողները պարտավոր են Եվրամիության հաշվետվողականության գործընթացի միջոցով տեղեկացնել ակտիվորեն օգտագործվող խոցելիությունների և լուրջ միջադեպերի մասին։ Այս պահանջը գործում է ընթացիկ տարվա սեպտեմբերի 11-ից, իսկ մնացած պարտավորությունների մեծ մասը ուժի մեջ կմտնի 2027 թվականի դեկտեմբերին։ Ժամկետները կարևոր են, սակայն ինժեներական ղեկավարների համար ավելի օգտակար հարցն այն է՝ կարո՞ղ է արդյոք ծրագրային ապահովման մատակարարման համակարգը գրանցել հուսալի անվտանգության արդյունքներ և դրանք ապացուցել։ Պատասխանը հազվադեպ է թաքնվում առանձին անվտանգության գործիքում կամ վերջին պահին անցկացված աուդիտում։

Քաղաքականությունից դեպի դիտարկելի վերահսկում

Շատ կազմակերպություններ արդեն ունեն անվտանգ զարգացման կանոններ։ Դժվարությունն այն է, որ քաղաքականությունը և կոդբազի, pipeline-ի ու թողարկման ապացույցները հաճախ չեն համընկնում։ Խոցելիությունը գտնելու գործնական ուղին յուրաքանչյուր վերահսկում չորս մակարդակով գնահատելն է՝ չհիմնավորված, անկայուն, ստանդարտ և պարտադիր։ Ստանդարտ մակարդակը կարևոր սահման է. մեկ ինժեներից կամ աղյուսակից կախված վերահսկումը չի դիմանում ժամանակակից տեմպին, իսկ պարտադիր վերահսկումը վտանգավոր փոփոխությունը ավտոմատ կանգնեցնում է։

Յոթ հարց, որոնք բացահայտում են խոցելիությունները

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

Առաջնահերթացում ըստ ռիսկի և AI-ի ազդեցությունը

Գնահատման արդյունքը պետք է լինի ըստ ռիսկի դասավորված պլան. ինտերնետին բաց արտադրանքում բացակայող անվտանգ լռելյայն պարամետրն ավելի հրատապ է, քան ցածր ռիսկի ներքին բաղադրիչի ավտոմատացման թերությունը։ Հաշվի են առնվում արտադրանքի բաց լինելը, ֆունկցիայի կրիտիկականությունը, շահագործման հնարավորությունը և տուժած տարբերակների քանակը։ Սրան գումարվում է ագենտային զարգացման աճը. Sonar-ի հետազոտության մեջ մշակողների 96%-ը նշում է, որ AI-ի գրած կոդին ամբողջությամբ չի վստահում, սակայն միայն 48%-ն է այն միշտ ստուգում commit-ից առաջ։ Այս տարբերությունը ավտոմատ վերահսկումը անփոխարինելի է դարձնում՝ անկախ նրանից՝ կոդը պատկանում է մարդուն, թե ագենտին։

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