Google-ը ներկայացրել է SLSA (Supply-chain Levels for Software Artifacts) շրջանակը, որն ամփոփում է զարգացման ենթակառուցվածքը գրոհներից պաշտպանելու առկա փորձը, որոնք իրականացվել են կոդ գրելու, փորձարկելու, հավաքելու և արտադրանքի բաշխման փուլում:
Զարգացման գործընթացները գնալով ավելի բարդ են դառնում և կախված են երրորդ կողմի գործիքներից, ինչը բարենպաստ պայմաններ է ստեղծում հարձակումների առաջխաղացման համար, որոնք կապված են ոչ թե վերջնական արտադրանքի խոցելիության հայտնաբերման և շահագործման հետ, այլ հենց զարգացման գործընթացի վտանգի հետ (մատակարարման շղթայի հարձակումները, որոնք սովորաբար ուղղված են Կոդ գրելու, բաշխված բաղադրիչների և կախվածությունների փոխարինման գործընթացում վնասակար փոփոխությունների ներմուծում):
Շրջանակը հաշվի է առնում 8 տեսակի հարձակումներ՝ կապված արտադրանքի կոդերի մշակման, հավաքման, փորձարկման և բաշխման փուլում վնասակար փոփոխություններ կատարելու սպառնալիքի հետ։
- A. Ներառյալ սկզբնաղբյուրի փոփոխությունները, որոնք պարունակում են հետնադռեր կամ թաքնված սխալներ, որոնք հանգեցնում են խոցելիության:
Հարձակման օրինակ. «Կեղծավորը պարտավորվում է» - փորձ՝ խթանելու խոցելիություններով պատչերը Linux միջուկում:
Անվտանգության առաջարկվող մեթոդ. յուրաքանչյուր փոփոխության անկախ վերանայում երկու մշակողների կողմից:
- Բ. Կոդերի կառավարման հարթակի խախտում:
Հարձակման օրինակ. ծրագրավորողների գաղտնաբառերի արտահոսքից հետո PHP նախագծի Git պահոց հետին դռնով չարամիտ պարտավորությունների ներարկում:
Առաջարկվող պաշտպանության մեթոդ. Կոդի կառավարման հարթակի անվտանգության բարձրացում (PHP-ի դեպքում հարձակումն իրականացվել է քիչ օգտագործված HTTPS ինտերֆեյսի միջոցով, որը թույլ է տվել փոփոխություններ ուղարկել գաղտնաբառով մուտք գործելիս՝ առանց SSH ստեղնը ստուգելու, չնայած. այն փաստը, որ անվստահելի MD5-ն օգտագործվել է գաղտնաբառերը հաշելու համար):
- Գ. Փոփոխությունների կատարում կոդի կառուցման կամ շարունակական ինտեգրման համակարգին փոխանցելու փուլում (կառուցված է կոդ, որը չի համապատասխանում պահեստի կոդը):
Հարձակման օրինակ. Հետին դուռ ներարկել Webmin-ին՝ փոփոխություններ կատարելով build-ի ենթակառուցվածքում, որի արդյունքում օգտագործվում են կոդային ֆայլեր, որոնք տարբերվում են պահեստի ֆայլերից:
Առաջարկվող պաշտպանության մեթոդ. ամբողջականության ստուգում և հավաքման սերվերի կոդի աղբյուրի նույնականացում:
- Դ. Հավաքման հարթակի փոխզիջում:
Հարձակման օրինակ՝ SolarWinds գրոհը, որի ժամանակ ապահովվել է ետնամուտքի տեղադրումը SolarWinds Orion արտադրանքի մեջ հավաքման փուլում:
Առաջարկվող պաշտպանության մեթոդ. հավաքման հարթակի անվտանգության առաջադեմ միջոցառումների իրականացում:
- E. Վնասակար կոդի խթանում ցածրորակ կախվածությունների միջոցով:
Հարձակման օրինակ․ հետնադռան ներդրում հանրաճանաչ իրադարձությունների հոսքի գրադարանում՝ ավելացնելով անվնաս կախվածություն և այնուհետև վնասակար կոդ ներառելով այս կախվածության թարմացումներից մեկում (վնասակար փոփոխությունը չի արտացոլվել git պահոցում, այլ առկա է միայն պատրաստի MNP փաթեթում):
Առաջարկվող պաշտպանության մեթոդ. ռեկուրսիվորեն կիրառեք SLSA պահանջները բոլոր կախվածությունների նկատմամբ (իրադարձության հոսքի դեպքում ստուգումը կբացահայտի կոդի հավաքումը, որը չի համապատասխանում հիմնական Git պահեստի բովանդակությանը):
- Զ. CI/CD համակարգում չստեղծված արտեֆակտների վերբեռնում:
Հարձակման օրինակ. CodeCov սկրիպտին վնասակար կոդի ավելացում, որը հարձակվողներին թույլ է տվել կորզել հաճախորդների շարունակական ինտեգրման համակարգի միջավայրում պահվող տեղեկատվությունը:
Պաշտպանության առաջարկվող մեթոդ. արտեֆակտների աղբյուրի և ամբողջականության վերահսկում (CodeCov-ի դեպքում կարելի է պարզել, որ codecov.io կայքից ուղարկված Bash Uploader-ի սկրիպտը չի համապատասխանում նախագծի պահեստի ծածկագրին):
- G. Փաթեթի պահեստի փոխզիջում:
Հարձակման օրինակ. Հետազոտողները կարողացան տեղակայել որոշ հանրաճանաչ փաթեթների պահոցների հայելիներ՝ դրանց միջոցով վնասակար փաթեթներ տարածելու համար:
Առաջարկվող պաշտպանության մեթոդ. Ստուգում, որ բաշխված արտեֆակտները կազմված են հայտարարված սկզբնական կոդերից:
- Հ. Օգտատիրոջը շփոթեցնելով սխալ փաթեթ տեղադրել:
Հարձակման օրինակ. օգտագործել typosquatting (NPM, RubyGems, PyPI)՝ փաթեթներ տեղադրելու պահոցներում, որոնք գրավոր կերպով նման են հանրաճանաչ հավելվածներին (օրինակ՝ Coffe-script-ի փոխարեն coffee-script):
Նշված սպառնալիքները արգելափակելու համար SLSA-ն առաջարկում է մի շարք առաջարկություններ, ինչպես նաև գործիքներ՝ աուդիտի մետատվյալների ստեղծումը ավտոմատացնելու համար: SLSA-ն ամփոփում է հարձակման ընդհանուր մեթոդները և ներկայացնում անվտանգության շերտերի հայեցակարգը: Յուրաքանչյուր մակարդակ պահանջում է որոշակի ենթակառուցվածքային պահանջներ՝ մշակման մեջ օգտագործվող արտեֆակտների ամբողջականությունն ապահովելու համար: Որքան բարձր է SLSA-ի աջակցվող մակարդակը, այնքան ավելի շատ պաշտպանություններ են իրականացվում, և այնքան լավ ենթակառուցվածքը պաշտպանված է սովորական հարձակումներից:
- SLSA 1-ը պահանջում է, որ կառուցման գործընթացն ամբողջությամբ ավտոմատացված լինի և ստեղծի մետատվյալներ («ծագում») այն մասին, թե ինչպես են ստեղծվում արտեֆակտները, ներառյալ տեղեկություններ աղբյուրների, կախվածությունների և կառուցման գործընթացի մասին (Աուդիտի համար մետատվյալների գեներատորի օրինակ տրված է GitHub Actions-ի համար): SLSA 1-ը չի ներառում վնասակար փոփոխություններից պաշտպանության տարրեր, այլ պարզապես նույնացնում է կոդը և տրամադրում է մետատվյալներ խոցելիության կառավարման և ռիսկերի վերլուծության համար:
- SLSA 2 - ընդլայնում է առաջին մակարդակը՝ պահանջելով օգտագործել տարբերակների վերահսկման և հավաքման ծառայություններ, որոնք ստեղծում են վավերացված մետատվյալներ: SLSA 2-ի օգտագործումը թույլ է տալիս հետևել կոդի ծագմանը և կանխել կոդի չարտոնված փոփոխությունները վստահելի շինարարական ծառայությունների դեպքում:
- SLSA 3 - հաստատում է, որ սկզբնական կոդը և կառուցման հարթակը համապատասխանում են ստանդարտների պահանջներին, որոնք երաշխավորում են կոդը աուդիտի ենթարկելու և տրամադրված մետատվյալների ամբողջականությունը ապահովելու հնարավորությունը: Ենթադրվում է, որ աուդիտորները կարող են հավաստագրել հարթակները ստանդարտների պահանջներին համապատասխան:
- SLSA 4-ը ամենաբարձր մակարդակն է, որը լրացնում է նախորդ մակարդակները հետևյալ պահանջներով.
- Երկու տարբեր մշակողների կողմից բոլոր փոփոխությունների պարտադիր վերանայում:
- Կառուցման բոլոր քայլերը, կոդը և կախվածությունները պետք է ամբողջությամբ հայտարարված լինեն, բոլոր կախվածությունները պետք է առանձին հանվեն և ստուգվեն, իսկ կառուցման գործընթացը պետք է կատարվի անցանց:
- Կրկնվող կառուցման գործընթացի օգտագործումը թույլ է տալիս ինքներդ կրկնել կառուցման գործընթացը և համոզվել, որ գործարկվողը կառուցված է տրամադրված աղբյուրի կոդից:
Source: opennet.ru