Па меры прасоўвання жыццёвага цыклу ланцужка паставак праграмнага забеспячэння ад зыходнага кода да выканальных артэфактаў, этап зборкі з'яўляецца крытычна важным момантам. Тым не менш, гэты трансфармацыйны этап таксама схільны да шэрагу пагроз, якія могуць паставіць пад пагрозу цэласнасць праграмнага забеспячэння і build securityГэтыя пагрозы могуць пранікаць у працэс зборкі рознымі метадамі, у тым ліку абыходзіць усталяваныя CI/CD pipeline, змяненне кода пасля кіравання зыходным кодам, парушэнне самога працэсу зборкі або маніпуляванне рэпазіторыямі артэфактаў. У гэтым пасце блога мы падрабязна разгледзім гэтыя пагрозы і разгледзім найбольш распаўсюджаныя атакі на зборку праграмнага забеспячэння. Гэты кантэнт працягвае нашу серыю блогаў, прысвечаную даследаванням software supply chain security ва ўсім SDLC.
Этап зборкі ў жыццёвым цыкле распрацоўкі праграмнага забеспячэння
Этап зборкі жыццёвага цыклу ланцужка паставак праграмнага забеспячэння ахоплівае працэс пераўтварэння зыходнага кода ў выканальныя артэфакты праграмнага забеспячэння. Гэты этап уключае кампіляцыю, кампаноўку і ўпакоўку зыходнага кода, а таксама стварэнне ўсталявальных пакетаў і файлаў канфігурацыі.
Build security Пагрозы — гэта ўразлівасці, якія могуць дазволіць зламысніку ўнесці несанкцыянаваныя змены ў праграмнае забеспячэнне падчас працэсу зборкі, не змяняючы зыходны код. Гэтыя пагрозы могуць быць уведзены рознымі метадамі, такімі як узлом асяроддзя зборкі або выкарыстанне ўразлівасцяў у інструментах зборкі.
Найбольш распаўсюджаныя пагрозы для ланцужкоў паставак праграмнага забеспячэння - атакі на зборкі
байпас CI/CD
Гэта адносіцца да практыкі абыходу ўстаноўленых CI/CD (бесперапынная інтэграцыя і бесперапынная пастаўка) pipeline непасрэдна ствараць і публікаваць праграмнае забеспячэнне без праходжання строгіх працэсаў тэсціравання, праверкі і аўдыту, якія звычайна выконваюцца афіцыйнымі pipelineГэта можна зрабіць, сабраўшы праграмнае забеспячэнне ўручную па-за межамі CI/CD асяроддзі або з дапамогай інструментаў ці скрыптоў, якія дазваляюць несанкцыянавана мадыфікаваць працэс зборкі. Прыкладам такога тыпу вектарнай атакі быў Атака ДжэнкінсаУ 2022 годзе хакеры праніклі ў зборку pipeline папулярнага праекта з адкрытым зыходным кодам пад назвай Jenkins. Хакеры ўкаранілі шкоднасны код у файл Jenkinsfile, які ўяўляе сабой скрыпт, што вызначае працэс зборкі. Шкоднасны код дазволіў хакерам абыйсці CI/CD pipelineправодзіць праверкі бяспекі і ўбудоўвае свой код у працэс зборкі. Затым гэты код выконваецца на сістэмах арганізацый, якія ўсталявалі праграмнае забеспячэнне.
Змяніць код пасля кіравання версіямі
Гэтая практыка прадугледжвае ўнясенне несанкцыянаваных змяненняў у зыходны код пасля таго, як ён быў commitдалучаны да даверанай сістэмы кантролю версій (SCS), а затым збіраюць праграмнае забеспячэнне з выкарыстаннем гэтага змененага кода. Гэта можна зрабіць, змяніўшы код непасрэдна на рабочай станцыі распрацоўшчыка або выкарыстоўваючы знешнія інструменты ці скрыпты для ўвядзення шкоднаснага кода ў працэс зборкі. Прыкладам такой вектарнай атакі была атака на GitLab у 2022 годзе. Хакеры праніклі ў сістэму зборкі pipeline of GitLabХакеры ўкаранілі шкоднасны код у GitLab. CI/CD pipeline, які з'яўляецца інструментам, які аўтаматызуе build security працэс. Шкодны код дазволіў хакерам змяняць код пасля таго, як ён быў правераны ў сістэме кантролю версій. Гэта дазволіла ім укараніць свой код у праграмнае забеспячэнне, якое затым выконвалася на сістэмах арганізацый, якія ўсталявалі праграмнае забеспячэнне.
Працэс кампраміснай зборкі
Гэта ўключае ў сябе маніпуляванне або змяненне самога працэсу зборкі, альбо праз прамы доступ да асяроддзя зборкі, альбо шляхам выкарыстання ўразлівасцяў у інструментах зборкі або залежнасцях трэціх бакоў. Гэта можа быць зроблена для ўкаранення шкоднаснага кода ў вынік зборкі, змены паходжання зборкі або поўнага парушэння працэсу зборкі. Найбольш вядомым прыкладам гэтай вектарнай атакі быў Атака SolarWindsЗламыснік атрымаў несанкцыянаваны доступ да платформы зборкі SolarWinds, сістэмы, якая выкарыстоўваецца для кампіляцыі і ўпакоўкі праграмнага забеспячэння SolarWinds Orion. Гэты скрыпт укараніў шкоднасны код у скампіляванае праграмнае забеспячэнне SolarWinds Orion. Калі карыстальнікі ўсталёўвалі ўзламанае праграмнае забеспячэнне, шкоднасны код выконваўся ў іх сістэмах, даючы зламысніку несанкцыянаваны доступ да іх сістэм. Зламыснік таксама змог украсці канфідэнцыйныя дадзеныя з іх сістэм, такія як уліковыя дадзеныя, інтэлектуальная ўласнасць і інфармацыя аб кліентах.
Кампраметаваны рэпазітар артэфактаў
Гэта адносіцца да несанкцыянаванага доступу або маніпуляцый з рэпазітарам артэфактаў, дзе захоўваюцца праграмныя пакеты і двайковыя файлы для распаўсюджвання ўнутраным або знешнім карыстальнікам. Зламыснікі могуць скарыстацца гэтай уразлівасцю для ўкаранення шкоднаснага кода, падробкі сапраўднасці праграмнага забеспячэння або парушэння працэсу разгортвання. Прыкладам такой вектарнай атакі была Рубінавыя самацветы ў 2022 годзеХакеры праніклі ў рэпазітар артэфактаў RubyGems. Хакеры замянілі легітымны артэфакт шкоднасным, які затым быў спампаваны тысячамі арганізацый, якія ствараюць праграмнае забеспячэнне з дапамогай Ruby on Rails. Шкоднасны артэфакт дазволіў хакерам выконваць адвольны код у сістэмах арганізацый, якія ўсталявалі праграмнае забеспячэнне. Гэта патэнцыйна магло дазволіць ім красці дадзеныя, усталёўваць шкоднасныя праграмы або парушаць працу.
Заключныя заўвагі
Паколькі арганізацыі працягваюць укараняць практыкі распрацоўкі праграмнага забеспячэння, якія робяць акцэнт на аўтаматызацыі і бесперапыннай пастаўцы, важнасць бяспекі працэсу зборкі праграмнага забеспячэння яшчэ ніколі не была такой вялікай. Укараняючы надзейныя меры бяспекі на працягу ўсяго этапу зборкі, арганізацыі могуць значна знізіць рызыку стаць ахвярай шкоднасных нападаў, якія могуць паставіць пад пагрозу цэласнасць і бяспеку іх праграмнага забеспячэння.
Стратэгіі, апісаныя ў гэтым пасце блога, і прыведзеныя прыклады служаць напамінам пра тое, што этап зборкі з'яўляецца ўразлівым пунктам у ланцужку паставак праграмнага забеспячэння. Арганізацыі павінны ўлічваць гэтыя пагрозы і ўкараняць неабходныя меры бяспекі для абароны свайго праграмнага забеспячэння ад нападаў. Робячы гэта, яны могуць гарантаваць цэласнасць, бяспеку і надзейнасць свайго праграмнага забеспячэння для сваіх карыстальнікаў і кліентаў.
Далучайцеся да нашага шляху да бяспечнай праграмнай экасістэмы
Не прапусціце гэтую магчымасць апярэдзіць падзеі і пазбегнуць пагроз у ланцужку паставак праграмнага забеспячэння. Падпішыцеся на наш блог сёння і першымі атрымайце нашы апошнія аналітычныя матэрыялы, якія гарантуюць, што ваша арганізацыя застанецца ўстойлівай і бяспечнай сярод новых пагроз. Разам мы можам стварыць больш надзейную і бяспечную экасістэму праграмнага забеспячэння для ўсіх.
Глядзіце нашу відэадэманстрацыю
