Бұл үшінші эпизод мақалалар топтамасы бағдарламалық жасақтама жеткізу тізбегіне шабуылдардың ең көп таралған түрі туралы: мемлекеттік тізілімді теріс пайдаланатындар Ашық көзі бағдарламалық жасақтама компоненттері. Алдыңғы эпизодта талдау жасағаннан кейін «Зиянды пакеттердің анатомиясы: трендтер қандай?«Зұлым әрекеттер жаңа немесе бұрыннан бар жарияланған компоненттерге зиянды мінез-құлықты қалай енгізетініне байланысты, біз өрт сөндіру киімдерімізді киіп, осылайша жеткізілетін зиянды бағдарламалық жасақтаманы қалай сәтті бұғаттауға болатынын немесе дұрыс емес тәсіл қолданғандықтан ықтимал күрделі кибероқиғамен қалай күресуге болатынын қарастыруға дайынбыз».
Қауіпсіздікті білетін мамандардың көпшілігі бұл қауіпті қалай шешуге болатыны туралы ойлары бар. Біз қауіпсіздік менеджерлерінің бұлай деп ойламағанын естідік. SCA құралдар пакет нұсқасы зиянды бағдарлама болған кезде сізге қазірдің өзінде хабарлайды. Немесе олар кез келген зиянды бағдарлама тез анықталып, жойылатын белгілі, жоғары бағаланған бағдарламалық жасақтама компоненттеріне тәуелді. Олар осалдықтарды автоматты түрде түзету үшін ашық кішігірім/патч нұсқаларын пайдаланады, және бұл ашық бастапқы кодқа тәуелділіктердегі қауіпті азайтудың дұрыс, ұсынылған тәсілі, «ерте жамау, жиі жамау»Принципі.
Бұл эпизодта біз бұл идеялардың неліктен қате екенін және мұндай қате түсініктердің осы шабуыл механизмінің танымалдылығына және ұйымдар бастан кешіріп жатқан үлкен тәуекелге қалай ықпал ететінін қарастырамыз. Біз не жұмыс істейтінін және қайсысы жұмсалатын күш пен ресурстар екенін қарастырамыз.
Жалпы қате түсініктер
Бағдарламалық жасақтама қауіпсіздігі саласындағы сапарымыз барысында біз шабуыл әдістерінің дамып келе жатқанын және қауіпсіздікке мән беретін адамдардың кең ауқымды идеяларын көрдік. Ұйымдар көбінесе бұл қауіпке қарсы не жұмыс істейтінін дұрыс түсінбейді, сондықтан алдымен біз не жұмыс істемейтінін қарастырамыз, оны келесі толық емес қате түсініктер тізімінде қысқаша баяндаймыз.
Қате түсінік №1: SCA құралдар зиянды компоненттер туралы хабарлап жатыр
Шынында! Бірақ фактіден кейін... Егер элемент бағдарламалық жасақтама құрастыруында пайдаланылған болса және зиянды әрекеттер әзірлеушіде немесе CI/CD хост. Құпиялар фильтрден шығарылған, қосымша зиянды бағдарламалар жүктелген және орнатылған болуы мүмкін, және қарсылас бүйірге жылжып, басқа жерден қол жеткізген болуы мүмкін.
Бағдарламалық жасақтама құрамын талдау (SCA) құралдары әлеуетті белгілі осалдықтарды анықтау үшін жасалған. Қазіргі заманғы құралдар сигнал-шу қатынасын арттыру арқылы керемет жұмыс істейді, осалдыққа шынымен қол жеткізуге болатынын немесе пайдалануға болатынын анықтайды. Бірақ олар жаңа зиянды бағдарламаларға қарсы пайдасыз. Зиянды компонентті нөлдік күндік осалдық деп ойлаңыз: Тек оның зиянды әрекеті анықталған кезде ғана компонент туралы холдингтік тізілімге хабарланады, ол қауіпсіздік тобының шолуынан кейін зиянды деп расталады және тізілімнен жойылады. [1].
Сол кезде әлем (соның ішінде SCAs) компонентті (немесе бар компоненттің кейбір нұсқаларын) орнату немесе пайдалану жақсы нәрсе емес екенін біледі. Бірақ бұл компонент тізілімнен қолжетімді болмаған кезде болады.Үшінші тарап компоненттерінде немесе тіпті тізілім зиянды деп санаған компоненттерде осалдықтарым бар екенін білу жақсы, бірақ өкінішке орай SCA немесе кең таралған аудит құралдары бұл жағдайда көмектеспейді. Болмаса SCA/audit құралы компоненттің ұйымыңызда пайдаланылмас бұрын зиянды екенін алдын ала біле алады.
Есіңізде болсын, зиянды ашық бастапқы кодты компоненттерге қарсы кез келген шешім оларды анықтауы керек ұшу кезінде, компонент тізілімінде жарияланған уақыт пен компонент (нұсқа) сіздің ұйымыңызда алғаш рет пайдаланылған уақыт аралығында. Бұған транзитивті компоненттер де кіреді.
Қате түсінік №2: Орнату сценарийлерін құрастыру кезінде басқару ашық бастапқы кодты компоненттерден келетін зиянды әрекеттердің алдын алады
Әртүрлі пакет менеджерлері сценарийлерді іске қосу мүмкіндігін ұсынады (tarball компонентіне кіреді) [2]), заңды себептермен, мысалы, әртүрлі платформаларда қажетті элементтерді компиляциялау, кодты генерациялау немесе тесттерді іске қосу, және егер зиянды сценарийлер тарболға енгізілген болса немесе шабуылдаушы жақсы сценарийдің орнына зиянды сценарийді іске қоса алса, оларды зиянды әрекеттер теріс пайдалануы мүмкін екенін бәріміз білуіміз керек.
Мұны біле отырып, біз пакет менеджерін сценарийлерді елемеуге конфигурациялай аламыз. Мысалы, NPM көмегімен –ескерту-скрипттері жалауша (немесе конфигурация қасиеті .npmrc file) орнату кезінде сценарийлерді өткізіп жібереді. Бұл кейбір мәселелерді тудыруы мүмкін, себебі сценарийлерді іске қосу көптеген экожүйелерде кең таралған: Кейбір пакет менеджерлері тіпті сценарийдің орындалуын өшіруге рұқсат бермейді (кеңес: «Қандай пакет менеджерлері орнату сценарийлерінің орындалуын өшіруге рұқсат бермейді?«Сіздің сүйікті жасанды интеллектіңізде). Бірақ бұл жалпы қорғамайды (біз өткізіп жіберуді өшіру конфигурациясының барлық жерде болуын қамтамасыз етуіміз керек).
Ал зиянды әрекет орнату сценарийлерінде емес, орындалу уақытында орындалатын бағдарламалық жасақтамада болған кезде, бұл опция бізді қорғамайды.
Қате түсінік №3: Нұсқаны бекіту зиянды компоненттердің орнатылуына жол бермейді
Ерте патч жасау мен жиі патч жасау арасында айырмашылық бар ашық нұсқалар (қауіпсіздік түзетулері қолжетімді болған кезде пакет менеджеріне жаңа жаңартуларды автоматты түрде орнатуға мүмкіндік беру) және нұсқаны бекіту (бағдарламалық жасақтаманың бекітілген нұсқасындағы барлық тікелей және транзитивті тәуелділіктерге ие). Қауіпсіздік қағидалары қатал және кейде қарама-қайшы, мысалы, «ерте түзету, жиі түзету» және «Жаңартуды жеңіл-желпі қарастыруға болмайды»Кейбір пакет менеджерлері сервер диапазондарымен ұсынылған тәсілмен автоматты жаңартуларды жасайды. Зиянды жаңартуларды да алғыңыз келсе, тамаша! Иә, осалдықтарды мүмкіндігінше тезірек жабатын қауіпсіздік түзетулерін алу үшін компоненттерді жаңарту қажет, бірақ ... пакет менеджеріне мұны автоматты түрде жасауға ешқашан жол бермеңіз.
Қате түсінік №4: Сенімді компоненттерді пайдалану қауіпсіз. Кез келген зиянды нұсқа тез арада табылып, анықталып, жойылады.
Неліктен компонентке сенімді? Мүмкін, ол өте танымал болғандықтан, көптеген көздер осалдықтарды іздейді, техникалық қызмет көрсетуге көптеген үлес қосады, барлық компоненттерді мұқият қарап шығатын бірнеше негізгі техникалық қызмет көрсетушілер бар. pull requestsШындық мүлдем басқаша. Кейбір маңызды компоненттерді бір ғана, ақысыз әзірлеуші қолдайды. Кеңінен қолданылатын фреймворктар бірнеше тұрақты үлес қосушыларсаны тез азайып бара жатқанда, commits әрбір қолдаушыға (танымал жобаларда кейбір диск арқылы орындайтын үлес қосушылардың ұзын тобы бар commit және ешқашан қайтып оралмайды). Және бір ғана қолдаушысы бар танымал жобалар көп.
Өзіңіздің былай деп тұрғаныңызды елестетіп көріңізші «О, біз Spring Boot / Angular / React / PyTorch / ресми Docker базалық кескіндерін пайдаланып жатырмыз, сондықтан сіз айтып отырған қауіп өте төмен.» Мүмкін, бұл рас шығар, біз, қауіпсіздік жеткізушілері, үнемі қорқытып-үркітіп жүреміз, ал даулы тәуекелді азайту үшін әзірлеуші топтарға араласу - бұл мағынасыздық. Сіз тәуекелді қабылдау абзацына (келесі бөлімде) секіріп, бәрі дайын болуы мүмкін. Өкінішке орай, ең танымал компоненттер - жаман әрекеттердің нысаналары, мысалы, танымал PyTorch кітапханасына шабуыл жасалды баяғыда.
«Дереу табылды, ашылды және жойылды». Жаңа зиянды компоненттің жалпыға қолжетімді тізілімнен жойылуы үшін бірнеше күн қажет. Тізілімдер компонент нұсқасын жоюға сақтықпен қарайды, бұл жақсылық үшін. Біздің тәжірибеміз бойынша, біздің тарапымыздан хабарланғаннан кейін, тізілімнің зақымдалған нұсқаны жоюға жұмсайтын орташа уақыты 39 сағатты құрайды, бұл бір жарым күннен астам уақытты құрайды. Жою алдында тізілімде алғашқы хабарлаудан кейін бір аптадан кейін болатын зиянды компоненттер бар. Ал кейбір жағдайларда компонент тек жәбірленуші немесе оқиғаларға жауап беру компаниясы компонентке қатысты оқиға туралы хабарлағаннан кейін ғана жойылады.
Зиянды компоненттерге қарсы не жұмыс істемейді
Кез келген нақты емес тәсіл сәтсіздікке ұшырайды. Бұл сөзсіз, сіз осы қауіппен байланысты тәуекелге тиімді қарсы шараларды ұсынбайсыз.
Дәстүрлі SCA құралдар сізге белгілі зиянды бағдарламалар туралы хабарлайды, бірақ үлкен әсер ету терезесіне ие. Егер олар зиянды компоненттерді мәжбүрлеп бұғаттау арқылы зиянды бағдарламаларды анықтауды белсенді түрде жүзеге асырмаса, олар бұл қауіпке қарсы жұмыс істемейді.
Орнату сценарийлерін өшіру көмектесе алады, бірақ компонент орнатылуы қажет барлық жерде орындалуы керек. Нұсқаларды бекіту де солай, себебі нұсқаларды бастапқы қауіпсіз күйден мәңгілікке бекіту мүмкін емес.
Танымал компоненттерге жеткілікті назар аударылады және оларды жеткізу тізбегіндегі шабуыл кезінде кез келген зақымды болдырмау үшін лезде анықтаусыз кездейсоқ әрекеттермен енгізу мүмкін емес деп есептеу - бұл аңғалдық және қауіпті. Сіз шетінде өмір сүргіңіз келмейді, солай ма?
Егер сіз осы жерде тоқтасаңыз, онда тәуекелді қабылдау сіз жасай алатын жалғыз нәрсе: бұлcisтәуекел моделіңізде/тәуекелді бағалауда құжатталуы қажет ион, соның ішінде тәуекелді қабылдау негіздемесі және оның ықтимал салдары. Басшылыққа және басқа да тиісті тараптарға хабарлау арқылы хабардарлықты арттырыңыз. Кейбіреулері төтенше зиянды компонент бағдарламалық жасақтамаңызға орнатылған немесе қосылған кезде жоспарлануы мүмкін, бірақ бұл қиын, себебі шабуылдаушылар көптеген жолдармен жүруі керек. Зиянды компонентті пайдалануға негізделген жеткізу тізбегіне шабуылдың егжей-тегжейлері оқиғаның жариялылығын түбегейлі өзгертеді, бұл сіздің ұйымыңыздың нормативтік базасы бойынша міндетті болуы мүмкін. Сіз сондай-ақ мыналарға жүгіне аласыз өтемақылық басқару элементтері or аудару тәуекелі мысалы, сақтандырумен.
Дегенмен, қауіпті жоюға бағытталған бақылау шаралары бар және егер сіз тәуекелді қабылдауға қанағаттанбасаңыз, оларды ескеру қажет. Оқуды жалғастырыңыз.
Зиянды компоненттерді пайдаланатын шабуылдарға қарсы не жұмыс істейді
Тұрақты нұсқаны өңдеу
Зиянды бағдарламаларды алмай осалдықтарды жою қажеттілігін теңестіру үшін нұсқаны бақыланатын және хабардар етілген нұсқалармен бекіту - ең дұрыс жол. Бірақ №3 қате түсінікті есте сақтаңыз: жаңа нұсқалардан келетін зиянды кодты бұғаттау үшін нұсқаны бекітудің өзі жеткіліксіз, себебі болашақта кез келген тікелей немесе жанама тәуелділікте нұсқаларды жаңарту қажет болады. Сол кезде сізге барлық өзгертілген нұсқаларда зиянды бағдарлама жоқ екеніне жеткілікті дәлел қажет.
Ерте ескерту
Зиянды компоненттер мәселесіне бір тәсіл - ерте ескерту жүйесі (мұнда былай деп аталады) Зиянды бағдарлама туралы ерте ескерту немесе MEW), мұнда жарияланған жаңа нұсқалар (жаңа немесе бар компоненттер үшін) анықтау жүйесімен талданады, бұл жеткілікті дәлелдер табылған кезде жаңа нұсқаны ықтимал зиянды деп жіктеуі мүмкін.
Автоматтандыру мұнда өте маңызды, себебі қазіргі жариялау қарқынымен барлық жаңа компоненттерді қолмен қарап шығу мүмкін емес. Сондықтан анықтау механизмі әртүрлі әдістерді, соның ішінде статикалық, динамикалық және мүмкіндіктерді талдауды, пайдаланушы беделін және компонент метадеректері мен tarball мазмұны арасындағы немесе tarball мен компоненттің бастапқы репозиторийі арасындағы сәйкессіздіктерден туындайтын дәлелдерді біріктіруі керек.
бұл бар қараңғы аймақ жариялау уақыты мен қозғалтқыш компоненттің мазмұнын талдаған уақыт арасындағы уақыт аралығы, бірақ ол бірнеше минуттан аспауы керек. Схеманы өзгертуге болады, мысалы, жаңа компоненттерді орнатуға және бағдарламалық жасақтама құрастыруында пайдалануға рұқсат бермес бұрын олардың талдануын күту арқылы. pipelineнемесе қажет болған жағдайда оларды талдаңыз. Берілген нұсқадағы компонент өзгермейді [3], сондықтан оны тек бір рет талдау қажет.
Толық автоматтандыру мүмкін емес, сондықтан зиянды компоненттердің қауіпсіздігін тексеру қажет. Сандық емді жақтаушылардан сақ болыңызКүдікті компонентте зиянды бағдарлама бар-жоғын растауға келгенде, жасанды интеллект және машиналық оқыту соңғы сөзді айту үшін жеткілікті түрде дамымаған. Әрине, машиналық оқыту анықтау механизмінде кіріс компонентін алынған шикі дәлелдерден жіктеуде маңызды рөл атқарады, бірақ компонент «карантинге» қойылғаннан кейін, соңғы сөз зиянды компоненттермен жұмыс істеу тәжірибесі бар қауіпсіздік тобының қолмен қарауында болады. Бұл кез келген ықтимал зиянды бағдарламаны растайды немесе оны қауіпсіз деп қайта жіктейді. Ал уақыт кезеңі сағат диапазонында.
Тізілім зиянды нұсқа/компонент туралы хабарлайды; содан кейін тізілім растау үшін шолу жасайды және жария етуге және тізілімнен алып тастауға көшеді. Кейбір тізілімдер қауіпсіздік пакетін сақтайды. Мұндағы уақыт диапазоны жарияланғаннан бергі күндер немесе апталар болып табылады, бұл «уақыт тұру'немесе'экспозиция терезесізиянды компоненттердің көпшілігі үшін.
Компонент нұсқасының зиянды екенін білу мүмкін бе?
Сондықтан ерте ескерту үшін біз мына сұраққа қанағаттанарлық жауап беруіміз керек: Кітапхананың немесе буманың зиянды (емес) екенін қалай білуге болады? Зиянды мінез-құлықтың жеткілікті дәлелдерін қалай жинауға болады? Мүмкін, бірақ қиын, себебі қарсыластар анықтаудан аулақ болу үшін көп тапқырлық танытады. Әртүрлі тәсілдер бар, олардың әрқайсысының артықшылықтары мен кемшіліктері бар.
Статикалық талдау барлық орындау жолдарын тексере алады, компонентті іске қоспай-ақ шабуылдаушылар қолданатын әдістерді тексере алады және деобфускация немесе шифрды ашу сияқты алдын ала өңдеу тапсырмаларын орындай алады. Шабуылдаушылар өздерінің зиянды әрекеттерін жасыруға тырысқан кезде, бұрмалау әрекеттері зиянды бағдарламаның дәлелі болып табылады (бірақ заңды компоненттер зияткерлік меншікті сақтау үшін кодты бұрмалайтынын және «қайшы келетінін» ескеріңіз).ашық бастапқы"). Күшті обфускциясы бар өте күрделі шабуылдардың аз бөлігі ғана құмсалғышты қажет етеді, бірақ мұндай күшті обфусация зияндылықтың айқын белгісі болып табылады. Дәстүрлі екенін ескеріңіз SAST құралдар бэкдор сияқты зиянды ниет үшін емес, байқаусызда осалдықтарға арналған.
Динамикалық талдау компонентті іске қосады және орындау уақытын құралдармен басқару арқылы жауапты тексереді, әдетте құм жәшігінде орналасқан ортаны қамтамасыз ету арқылы. Белгілі бір жағдайларда іске қосылған зиянды әрекеттер байқалмай қалуы мүмкін: зиянды бағдарлама сияқты жалтару әдістерін қолдануы мүмкін екенін ескеріңіз. Виртуалдандыру/құм жәшігінен жалтару тек тексерілмеген кезде ғана белсендіру, сондай-ақ кез келген статикалық талдау қозғалтқышы үшін зиянды әрекеттің айқын белгісі.
Мүмкіндіктерді талдау компоненттің не істейтінін қарастырады: қайда қосылатынын, қандай файлдарға кіретінін, қандай командалар немесе бағдарламалар іске қосылатынын, терминалдың немесе құрылғының енгізу/шығаруы орындалатынын немесе қандай жүйелік шақырулар шақырылатынын. Бұл мінез-құлықтың саусақ ізін (бар компонент үшін) нұсқалар бойынша салыстыруға болады, сондықтан күтпеген мінез-құлық анықталған кезде, бұл дәлелдер жаңа нұсқада енгізілген ықтимал зиянды әрекетке күдік тудыруы мүмкін. Бұл тәсіл қауіпсіздік талдаушылары ықтимал зиянды бағдарламамен бетпе-бет келгенде орындайтын сұрыптау қадамдарын орындайды: тексеруді қолдана отырып. жолдар немесе осыған ұқсас құралдар. Бұл тәсіл іске қосу жағдайларына қарамастан зиянды әрекеттерді анықтайды және бастапқы код қолжетімді болмаған кезде жұмыс істейді.
Мәтінмәндік талдау компоненттің қалай және кім жариялағаны туралы ақпарат жинайды. Жаман әрекеттердің науқандары көбінесе қатаң тексеру процесіне бағынбайтын жаңа пайдаланушы тіркелгісін (тіркелгілерін) пайдаланады. Өткен әрекеттерді бақылау негізгі пайдаланушы туралы түсінік бере алады, көбінесе ықтимал ымыраға келуге нұсқайтын ауытқулар үшін. Беделге ие болу өте қиын, ал жоғалту өте оңай! Өткен әрекеттері жоқ пайдаланушы бейтарап, бірақ карма зиянкестерді қудалайды. Хакерлік әрекеттерді немесе жариялау деректері ұрланған қарапайым пайдаланушыларды мұқият бақылау керек.
Тағы бір контекстік ақпарат - компонент tarball жасау үшін пайдаланылған деп болжанатын бастапқы репозиторий мен tarball мазмұны арасындағы кез келген сәйкессіздік. Сондай-ақ, жалпы тізілімде жарияланған компонент нұсқаларына сәйкес келетін бастапқы репозиторийде тегтер немесе шығарылымдар жасау сияқты жақсы тәжірибелерді сақтау. Бастапқы репозиторий белгілі бір жерде болған кезде commit шығарылыммен белгіленеді, содан кейін кенеттен бір нұсқасы оны орындамайды, бұл компоненттің бүлінуі мүмкін екендігінің айқын дәлелі: жаман әрекет етуші компонентті жариялау үшін пайдаланылған тіркелгіні бұзған болуы мүмкін, бірақ бастапқы код репозиторийінде жазу рұқсаттары жоқ). Көптеген шабуылдар осы ережелерді қолдану арқылы үнемі анықталады: мысалы, Леджер шабуылы осы бағытта оңай анықталуы мүмкін. Сондықтан контекстік талдау жариялау процесіндегі мұндай ауытқуларды анықтайды.
Тәуелділік брандмауэрі
Басқа тәсіл - кез келген құрастыруда бағдарламалық жасақтамаңызда қолданылатын барлық тәуелділік графиктері үшін компоненттердің толық ақ тізімін жасау. pipeline ұйымыңызда тек бекітілген компонент нұсқаларын ғана орнатуға және пайдалануға болады.брандмауэр«рұқсат етілген компонент нұсқаларына арналған тарболдар қызмет көрсетілетін (кэштелген немесе проксиленген) ішкі тізілімді пайдаланып орындалады. Кез келген ақ тізім жұмыс істемейтінін ескеріңіз, егер сізде кез келген жаңа нұсқаны ақ тізімге қосуға болатындай қауіпсіз деп жіктеу технологиясы болмаса.
Ескерту: Ерте ескерту (жаңа нұсқа жарияланғаннан кейін мүмкіндігінше тез анықтау) құрастыруға әсер ететін компонентті бұғаттау үшін сол ақпаратты алдын ала пайдаланудың қандай да бір тәсілімен біріктірілуі керек. pipelineнемесе әзірлеушілердің машиналары [4]Біз мұны «тәуелділік брандмауэрі«: автоматтандырылған құрастыруларды зиянды пакеттерден қорғауға арналған карантиндік механизм. Ішкі пакеттер мен кескін тізілімдері ұйымдарды сыртқы зұлымдықтан оқшаулау үшін жақсы, бірақ карантинді тиімді ету үшін жеткілікті күшті дәлелдер қажет.
Орындалу уақытындағы құмсалғыш
Жариялау кезінде анықтаудың балама тәсілі - орындау уақытындағы мінез-құлықты талдау. Идея - бағдарламалық жасақтамадан күтілетін мінез-құлықты анықтау және табылған кез келген ауытқуларды анықтау (немесе бұғаттау). Бұл әрекет бағыты мониторинг немесе бұғаттау үшін орындау уақытын құралмен жабдықтау мәселесін тудырады және бұл зиянды компонент зиянкестеріне қарсы қорғаныс механизмдерінің арсеналына қосылатын перспективалы идея.
Кешенді стратегияны белгілеу
Ұсынылған стратегия бағдарламалық жасақтаманы әзірлеу процесінде әртүрлі әдістерді біріктіріп, кіретін зиянды компоненттерді бұғаттау үшін нұсқа жаңартуларын бақылауды өз қолымызға алуы керек. Маңызды осалдықтарды түзету үшін жаңарту нұсқаларымен автоматты түрде жұқтыруды болдырмау үшін нұсқаларды бекітуді ескеруіміз керек; нұсқаларды жаңарту кезінде тікелей және жанама тәуелділіктерді жылдам және тиімді бағалау, олардың зиянды бағдарламалармен зақымдалмағанына жеткілікті дәлел болуы керек. Белгілі зиянды компоненттерге тәуелді бағдарламалық жасақтаманың құрастырылымдарын бұғаттау керек. Және барлығы орындалуы керек.
Мүмкіндігінше, нұсқаны бекітуді пайдаланыңыз, себебі бұл құрылымдарды қайталауды жеңілдетеді. Басқарылатын, қолмен бекітілген нұсқа көтерілулерімен нұсқаны бекіту, және көмекші технологияның көмегімен, жаңарту зиянды бағдарлама әкелетінін немесе бағдарламалық жасақтаманы бұзатынын бағалауы және осалдықтарды түзету үшін жаңартуды зиянды бағдарламаның инфекциясын болдырмаумен үйлестіруі керек. Құралдар мұнда көмектесе алады, (1) қандай осалдықтардың шынымен маңызды екеніне басымдық беру (шабуылдаушылардың нысанасына айналу қаупі жоғары), (2) ағымдағы компонентті пайдаланумен үйлесімді және бағдарламалық жасақтаманы бұзбайтын мақсатты нұсқаларды таңдау, (3) зиянды әрекеттері жоқ мақсатты нұсқаларды таңдау және (4) тікелей және жанама тәуелділіктер үшін нұсқаны жаңартуды тез арада манифест файлдарындағы өзгерістерді ұсыну арқылы. (3) қадам зиянды компоненттер туралы нақты ақпаратты олардың жарияланған уақытына мүмкіндігінше жақын жерде қажет етеді.
Тәуелділіктерді жаңарту процесі болуы керек күші бар және тексерілді барлық жерде. Процесс құжатталуы керек және барлық қатысушы тараптар оқытылуы керек, себебі көбінесе бағдарламалық жасақтаманы әзірлеу және құру/орналастыру сыртқы ортаға жіберіледі. CI/CD pipelines сәйкесінше өзгертілуі керек, сондықтан автоматтандыру зиянды жанама тәуелділіктің құрастыруға енуіне жол бермейді: guardrails Тәуелділікте зиянды бағдарламаның болуы мүмкін екендігі туралы жеткілікті дәлел болған жағдайда құрастыруды бұғаттау ұсынылады.
Егер сіздің ұйымыңызда рұқсат етілген компонент нұсқаларын сақтауға арналған қауіпсіздік проксиі ретінде әрекет ететін ішкі тізілім болса, сұралған компонентті рұқсат тізіміне қоспас бұрын тексеру үшін зиянды компоненттер туралы ақпарат алуыңыз керек (басқа критерийлерден басқа).
Ашық бастапқы кодты бағдарламалық жасақтаманы қауіпсіздікпен пайдалану оңай емес, сондықтан зиянды бағдарлама факторын толығымен ескеру қажет, осалдықтарды өңдеуге де осындай күш жұмсалуы керек.
Бір соңғы ескерту: Дереккөздің шығу тегі, компонентті құру кезінде жасалған бағдарламалық жасақтама аттестациялары түрінде, артефактіні (компонент тарболын) оны жасаған көздермен және құру процесімен байланыстыру әрекетіндегі тағы бір маңызды бөлік болып табылады. Бастапқы сурет + құру ортасы мен байланысты бағдарламалық жасақтама артефактісінің (сенімді құрастыру жүйесімен қол қойылған) арасындағы бұл байланыс компонентте зиянды әрекеттердің болмауына кедергі келтірмейтінін, бірақ зиянкестердің зиянды бағдарламаларды енгізуін қиындататынын ескеріңіз. Ал шығу тегін тексеруді ашық бастапқы кодты компоненттерді тұтыну үшін жалпы талап ету ұзақ уақытты алады және тек жақында NPM-ге қосылдыСенiмдi құрастыру және орналастыру жүйелерiн бұзудан қорғау немесе құрастырудағы кез келген бұзуды анықтауды қамтамасыз ету - бұл жазбаның аясынан тыс басқа мәселе.
Қосымша оқу
Келесі эпизод Ашық бастапқы кодты зиянды пакеттер: Xygeni тәсілі Xygeni компаниясында біз ұстанатын стратегияны ұсынады Зиянды бағдарлама туралы ерте ескерту (MEW) жүйесі. Жалпыға қолжетімді пакеттер мен кескін тізілімдеріндегі жаңа пакет нұсқалары сканерленеді және статикалық, динамикалық, мүмкіндіктер және контекстік талдаудың тіркесімін пайдалану арқылы дәлелдемелер алынады. Дәлелдемелер пайдаланушы беделімен және бастапқы код репозиторийлеріндегі өзгерістер тарихымен біріктіріліп, компонентті жоғары қауіпті және зиянды санаттарға толығымен автоматтандырылған түрде жіктеуге мүмкіндік береді. Жүйе жалған оң нәтижелерді минимумға дейін азайту үшін пакеттерден жиналған бұрынғы дәлелдерден сабақ алады.
Зиянды нұсқа жіктелген кезде, жазылған ұйымдар тікелей немесе жанама түрде пайдаланып жатқан компоненттері туралы ескерту хабарламасын алады. Содан кейін біздің талдаушыларымыз жіктеуді растайтын немесе қабылдамайтын қолмен талдау жүргізеді. Расталған зиянды бағдарлама үшін қоғамдық тізілімге хабарланады, осылайша ол өз талдауын жүргізе алады және әдетте зиянды нұсқаны жоя алады немесе пайдаланушы тіркелгісін бұғаттау немесе жою сияқты қосымша әрекеттерді жасай алады.
Біз NPM, PyPI, GitHub және ашық бастапқы кодты экожүйедегі басқа да негізгі инфрақұрылымдарға жаңа зиянды компоненттің зиянды бағдарлама екені расталғанға және тізілімнен жойылғанға дейін белсенді болып қалу уақытын қысқартуға қалай көмектесіп жатқанымызды түсіндіреміз. Және ұйымдар MEW жүйесінен ашық бастапқы кодты компоненттерді қамтитын бағдарламалық жасақтама жеткізу тізбегінің шабуылдарынан әлдеқайда жақсы қорғаныс алу үшін қалай пайда көре алады.
- [1] Қалай болғанда да, компонент пайдаланушылары компоненттің тарболының кэштелгенін немесе бір жерде, мысалы, ішкі тізілімде тіркелгенін тексеруі керек, осылайша ауру жойылады.
- [2] Қапталған компонент құрамында мазмұны мен метадеректерін, бастапқы немесе компиляцияланған кодын, орнату сценарийлерін және сынақ жиынтықтары сияқты қосымша элементтерді қаптама форматына сәйкес және әдетте сығылған түрде жариялайтын манифест бар. Бұл «компонент тарболы» деп аталады.
- [3] Зиянкес әрекет тізілімдегі бұзушылыққа байланысты жарияланған компонентті өзгерте алса да, қарапайым криптографиялық дайджест талдау жүргізілгеннен кейін тарболдағы кез келген өзгерісті анықтай алады.
- [4] Кейбір зиянды компоненттер орнату кезінде іске қосылатынын есте сақтаңыз, сондықтан ол X зиянды компоненті бар «npm install X» пәрменін байқаусызда іске қосатын әзірлеуші түйіндерге әсер етуі мүмкін.
