Кампанія Google прадставіла фрэймворк SLSA (Supply-chain Levels for Software Artifacts), у якім абагульнены наяўны досвед па абароне інфраструктуры распрацоўкі ад нападаў, якія здзяйсняюцца на стадыі напісання кода, тэставанні, зборкі і распаўсюджванні прадукта.
Працэсы распрацоўкі становяцца ўсё больш складанымі і якія залежаць ад іншых інструментарыяў, што стварае спрыяльныя ўмовы для пасоўвання нападаў, злучаных не з выяўленнем і эксплуатацыяй уразлівасцяў у канчатковым прадукце, а з кампраметацыяй самога працэсу распрацоўкі (напады «supply chain», як правіла нацэленыя на ўкараненне шкоднасных змен у працэсе напісання кода, падмену распаўсюджваюцца кампанентаў і залежнасцяў).
Фрэймворк улічвае 8 выглядаў нападаў, звязаных з пагрозамі занясення шкоднасных змен на этапе распрацоўкі кода, зборкі, тэставанні і распаўсюджванні прадукта.
- A. Уключэнне ў зыходны код змен, якія змяшчаюць бэкдоры або ўтоеныя памылкі, якія прыводзяць да ўразлівасцяў.
Прыклад нападу: Hypocrite Commits спроба пасоўвання ў ядро Linux патчаў з уразлівасцямі.
Прапанаваны метад абароны: незалежнае рэцэнзаванне кожнай змены двума распрацоўшчыкамі.
- B. Кампраметацыя платформы кіравання зыходным кодам.
Прыклад нападу: укараненне шкоднасных коммітаў з бэкдорам у Git-рэпазітар праекту PHP пасля ўцечкі пароляў распрацоўнікаў.
Прапанаваны метад абароны: Падвышэнне абароны платформы кіравання кодам (у выпадку PHP напад была здзейснена праз мала кім выкарыстоўваны HTTPS-інтэрфейс, які дапушчаў адпраўку змен пры ўваходзе па паролі без праверкі SSH-ключа, пры тым, што для хэшавання пароляў ужываўся ненадзейны MD5).
- C. Унясенне змяненняў на этапе перадачы кода ў сістэму зборкі або бесперапыннай інтэграцыі (збіраецца код, які не адпавядае коду з рэпазітара).
Прыклад нападу: укараненне бэкдора ў Webmin шляхам занясення змен у зборачную інфраструктуру, якія прывялі да выкарыстання файлаў з кодам, адрозных ад файлаў у рэпазітары.
Прапанаваны метад абароны: Праверка цэласнасці і ідэнтыфікацыя крыніцы паступлення кода на зборачным серверы.
- D. Кампраметацыя зборачнай платформы.
Прыклад нападу: напад SolarWinds, падчас якой на этапе зборкі было забяспечана ўкараненне бэкдора ў прадукт SolarWinds Orion.
Прапанаваны метад абароны: укараненне пашыраных мер забеспячэння бяспекі зборачнай платформы.
- E. Прасоўванне шкоднаснага кода праз няякасныя залежнасці.
Прыклад нападу: укараненне бэкдора ў папулярную бібліятэку event-stream, праз даданне бяскрыўднай залежнасці з наступным уключэннем у адным з абнаўленняў гэтай залежнасці шкоднаснага кода (шкоднасная змена не было адлюстравана ў git-рэпазітары, а прысутнічала толькі ў гатовым MNP-пакеце).
Прапанаваны метад абароны: рэкурсіўнае ўжыванне патрабаванняў SLSA да ўсіх залежнасцяў (у выпадку event-stream праверка б выявіла зборку кода, не які адпавядае змесціва асноўнага Git-рэпазітара).
- F. Загрузка артэфактаў, не створаных у сістэме CI/CD.
Прыклад нападу: даданне шкоднаснага кода ў скрыпт CodeCov, які дазваляў зламыснікам здабываць інфармацыю, якая захоўваецца ў асяроддзі сістэм бесперапыннай інтэграцыі кліентаў.
Прапанаваны метад абароны: кантроль за крыніцай і цэласнасцю артэфактаў (у выпадку з CodeCov магло быць выяўлена, што скрыпт Bash Uploader, які аддаецца з сайта codecov.io, не адпавядае коду з рэпазітара праекта).
- G. Кампраметацыя рэпазітара пакетаў.
Прыклад нападу: даследнікам атрымалася разгарнуць люстэркі некаторых папулярных рэпазітараў пакетаў з мэтай распаўсюджвання праз іх шкоднасных пакетаў.
Прапанаваны метад абароны: Праверка, што артэфакты, якія распаўсюджваюцца, сабраны з заяўленых зыходных тэкстаў.
- H. Уводзіны ў замяшанне карыстача для ўсталёўкі не таго пакета.
Прыклад нападу: выкарыстанне тайпсквотынга (NPM, RubyGems, PyPI) для размяшчэння ў рэпазітарах пакетаў, падобных па напісанні на папулярныя прыкладанні (напрыклад, coffe-script замест coffee-script).
Для блакавання адзначаных пагроз SLSA прапануе набор рэкамендацый, а таксама прылад для аўтаматызацыі стварэння метададзеных для аўдыту. SLSA абагульняе тыпавыя метады нападаў і ўводзіць паняцце ўзроўняў абароны. Кожны ўзровень прад'яўляе пэўныя патрабаванні да інфраструктуры, якія дазваляюць гарантаваць цэласнасць артэфактаў, якія выкарыстоўваюцца пры распрацоўцы. Чым вышэй які падтрымліваецца ўзровень SLSA, тым больш сродкаў абароны ўкаранёна і тым лепш інфраструктура абаронена ад тыпавых нападаў.
- SLSA 1 - патрабуе, каб зборачны працэс быў цалкам аўтаматызаваны і генераваў метададзеныя («provenance») аб тым, як артэфакты сабраны, уключаючы звесткі аб зыходных тэкстах, залежнасцях і працэсе зборкі (для GitHub Actions прапанаваны прыклад генератара метададзеных для аўдыту). SLSA 1 не ўключае элементы абароны ад унясення шкоднасных змен, а толькі найпростай выявай ідэнтыфікуе код і падае метададзеныя для кіравання ўразлівасцямі і аналізу рызык.
- SLSA 2 - пашырае першы ўзровень патрабаваннем выкарыстання сістэмы кіравання версіямі і зборачных сэрвісаў, якія генеруюць аўтэнтыфікаваныя метададзеныя. Ужыванне SLSA 2 дазваляе адсачыць паходжанне кода і прадухіляе занясенне несанкцыянаваных змен у код, у выпадку ўжывання годных даверу зборачных сэрвісаў.
- SLSA 3 – пацвярджае, што зыходныя тэксты і зборачная платформа адпавядаюць патрабаванням стандартаў, якія гарантуюць магчымасць правядзення аўдыту кода і забеспячэнне цэласнасці прадстаўленых метададзеных. Прадугледжваецца, што аўдытары могуць сертыфікаваць платформы на прадмет адпаведнасці патрабаванням стандартаў.
- SLSA 4 - найвышэйшы ўзровень, які дапаўняе папярэднія ўзроўні наступнымі патрабаваннямі:
- Абавязковае рэцэнзаванне ўсіх змен двума рознымі распрацоўшчыкамі.
- Усе крокі зборкі, код і залежнасці павінны быць поўнасцю дэклараваны, усе залежнасці павінны быць асобна выняты і правераны, а працэс зборкі павінен выконвацца без доступу да сеткі.
- Ужыванне працэсу паўтаранай зборкі - магчымасць паўтарыць працэс зборкі саматугам і пераканацца, што выкананы файл сабраны з прадстаўленых зыходных тэкстаў.
Крыніца: opennet.ru