Как защитить DevOps | Блог Касперского

[KL FC Bot]

В прошлом году на новостных IT-сайтах появилась информация об «отравлении» репозитория RubyGems, официального канала распространения библиотек для языка Ruby. Некий злоумышленник загружал на этот ресурс поддельные сборки кода, дополненные вредоносным скриптом. То есть все программисты, которые использовали этот код в своих разработках, невольно заражали компьютеры своих пользователей зловредом, подменяющим адреса криптовалютных кошельков.

Разумеется, это не первая атака на цепочку поставок, проведенная через открытые репозитории. Но сейчас такой сценарий, похоже, набирает популярность. И это неудивительно — ведь в результате одной успешной атаки можно скомпрометировать десятки или сотни тысяч пользователей. Все зависит только от популярности ПО, разработчики которого воспользуются кодом из «отравленного» репозитория и станут звеньями в цепи.

Как вредоносные пакеты оказываются в репозиториях?

В случае с RubyGems злоумышленник создал в репозитории множество проектов с именами, похожими на популярные легитимные сборки кода. Эта техника называется typosquatting: она подразумевает, что разработчик может опечататься при вводе названия пакета и загрузить вредоносный, или, получив несколько пакетов в ответ на поисковой запрос, не понять, какой из них подлинный. Эту тактику злоумышленники применяли и при атаках через Python Package Index, и при загрузке фальшивых образов на Docker Hub. Да и вообще это самый распространенный метод «отравления».

В инциденте с криптокошельками Copay, о котором мы писали некоторое время назад, злоумышленники использовали библиотеку, репозиторий которой размещался на GitHub. Ее создатель потерял интерес к своему детищу и был только рад, когда какой-то новичок попросил права администратора, чтобы продолжить работу. В результате популярная библиотека, которую использовали многие разработчики в своих продуктах, была скомпрометирована.

Иногда злоумышленникам удается воспользоваться учетной записью легитимного разработчика без его ведома и заменить пакеты поддельными. Так случилось в инциденте с ESLint, библиотеки которого размещались в онлайновой базе данных npm (Node Package Manager).

Компрометация среды компиляции

Не следует забывать также, что компании, разрабатывающие программные продукты, всегда были интересными целями для операторов APT-атак. Инциденты, в ходе которых киберпреступники охотятся на клиентов таких компаний, периодически привлекают внимание экспертов по безопасности:

• В августе 2017 года в инструменты, созданные компанией NetSarang, были встроены вредоносные модули. По одной из версий — злоумышленники как-то скомпрометировали серверы сборки ПО.
• В 2018 году каким-то злоумышленникам удалось инфицировать сервер сборки приложений компании Piriform, после чего программы CCleaner с чистым исходным кодом при компиляции получали в довесок вредоносное ПО.
• В 2019-м наши эксперты рассказали об APT-кампании ShadowHammer, в ходе которой в код нескольких компаний был встроен бэкдор. Согласно результатам расследования, атаковавшие либо имели доступ к исходному коду, либо внедряли вредоносный код на этапе компиляции.

Успешная компрометация среды компиляции позволяет не просто «заразить» конечный продукт — это приводит к выпуску вредоносных программ с легитимной цифровой подписью достойного доверия разработчика. Именно поэтому процесс разработки нуждается в усиленной защите от постороннего вмешательства.

Корень проблемы

На самом деле опасность представляет собой не использование публичных репозиториев, а несовершенство современного подхода к разработке ПО — методологии DevOps. Это набор практик,  цель которых — ускорить цикл разработки программы и доставки ее на рынок без потери качества. Давно известно, что безопасность и удобство находятся на разных чашах весов. А в современных условиях, для того чтобы оставаться конкурентоспособными, разработчикам необходимо оперативно выпускать новые версии программ. Так что любая «просадка» в удобстве выливается либо в падение качества, либо в задержки с выходом на рынок (TTM). В результате разработчики стараются минимизировать или полностью обойти вмешательство безопасников в свою деятельность.

Это приводит к тому, что информационная безопасность практически выпускает из рук эту часть инфраструктуры. Но ведь по факту и разработка, и IT, и безопасность делают одно дело — работают на то, чтобы клиент своевременно получил качественный и безопасный продукт. Самое распрекрасное обновление не обрадует конечного пользователя, если в нем будет бэкдор или шпион. Поэтому, на наш взгляд, для процесса создания качественного и безопасного софта индустрия должна перейти к методологии DevSecOps.

DevSecOps — это попытка подружить безопасность и разработку, внедрив культуру кибербезопасности и практическое применение проверок на всех стадиях процесса создания ПО без ущерба для гибкости и скорости. И мы знаем, как обеспечить техническую сторону этого процесса.

Наше решение

На рынке сейчас не так много инструментов, которые созданы специально для защиты процесса разработки программного обеспечения. Поэтому при обновлении нашего решения Kaspersky Security для виртуальных и облачных сред мы учли потребности программистов. В результате мы снабдили его компоненты технологиями, позволяющими интегрировать в процесс разработки инструменты безопасности, работающие без ущерба для производительности. И в первую очередь — технологии для сканирования репозиториев, образов и контейнеров, как раз для предотвращения атак через цепочку поставок.

Теперь благодаря Kaspersky Security для виртуальных и облачных сред разработчики могут добавить дополнительные шаги проверки в процессы непрерывной интеграции (CI) и непрерывной доставки (CD), в том числе и с использованием инструментов TeamCity и Jenkins. Причем интеграция возможна как при помощи командной строки, так и через программный интерфейс приложения (API).

Разумеется, это не все, что мы изменили в нашем решении. Узнать больше о Kaspersky Security для виртуальных и облачных сред и в целом о защите процесса DevOps можно на странице продукта.

View the full article