Supply Chain Security на примере кофемашины: почему ваш код горчит

Меня зовут Максим Князев, старший системный инженер К2 Кибербезопасность ^[1]. Сегодня я хочу поговорить об атаках на цепочки поставок на примере того, что все хорошо понимают и любят.

Просто представьте, как вы заказываете эспрессо в проверенной кофейне. Зерна от известного обжарщика, бариста с опытом ^[2], кофемашина за миллион. И казалось бы, все идеально. Но потом выясняется, что кто-то подсыпал в зерна что-то лишнее еще на плантации. Вы не виноваты, кофейня не виновата, но пить это вы уже не хотите.

В разработке происходит ровно то же самое, только в роли зерен здесь выступают npm-пакеты. Плантация превращается в GitHub, а подозрительные примеси представляют собой вредоносный код в легитимном релизе. И вы узнаете о проблемах не по вкусу ^[3], а по инциденту в проде.

Давайте продолжим это сравнение под катом и разберемся, как не испортить компоненты, из которых складывается современная кибербезопасность.

Десять лет назад безопасность софта выглядела как «вовремя накати патч и настрой межсетевой экран», то сегодня эта схема на практике уже не особо работает. Конечно, мы все так же продолжаем искать и устранять различные угрозы, но проблема в том, что современные атаки все реже ломают код в лоб. Теперь хакеры чаще атакуют через то, из чего этот код собран.

В 2025 году по данным Cyble аналитики фиксировали ^[4] примерно 26–30 атак на программные цепочки поставок ежемесячно. Это почти вдвое больше, чем в 2024-м. Более чем в 70% организаций в течение года были серьезные инциденты, связанные с Supply Chain ^[5]. Причина довольно простая:

Сейчас практически никто не пишет сложное ПО с нуля. Софт собирают как конструктор LEGO из десятков, сотен, а иногда и тысяч чужих компонентов. Опенсорсные библиотеки, контейнерные образы, CI/CD тулчейны, плагины, SDK, скрипты — все это живет своей жизнью: обновляется, меняется, иногда внезапно исчезает или, что гораздо хуже, вдруг начинает вести себя странно.

И вот в этот момент поверхность атаки расширяется, и заодно приходит неприятное осознание. Даже если наш код идеален (что мало похоже на правду, но допустим), он все равно доезжает до пользователя по длинной и неочевидной цепочке поставок. И в этой цепочке мы контролируем далеко не все. Так и появляется понятие Supply Chain Security, или безопасность цепочки поставок. Подробнее об этом можно прочитать в публикации IBM ^[6].

Именно поэтому сегодня говорят не просто про уязвимости, а про происхождение кода, воспроизводимость сборок, подписи артефактов, контроль источников, логично ^[7] по-отдельности, но плохо укладывается в голове, когда начинаешь смотреть на систему целиком. Направление комплексное, и мозг ^[8] от него вскипает быстро. Так что попробуем разобраться в нем на примере чего-то осязаемого.

Удачный образ реально помогает понять концепцию, по крайней мере, если он представляет собой сопоставление отношений и структуры ^[9]. Это подтверждается многими исследованиями, например, статьей Мэри Л. Гик и Кейт Дж. Холиок ^[10]. Люди заметно чаще находят решение сложной задачи, если до этого сталкивались с аналогичной историей из другой области. Так что давайте вернемся к цепочке поставок и посмотрим, что уже есть на рынке метафор.

Supply Chain Security на пальцах

Возьмем SBOM. Чаще всего его сравнивают со списком ингредиентов на упаковке продукта, например, в статье Palo Alto Networks ^[11]. Этот подход продвигают сообщества вроде OpenSSF ^[12] и OWASP ^[13], где SBOM рассматривается как базовый элемент цепочки поставок.

При этом специалисты в области ИБ уже не раз отмечали, что такая аналогия объясняет лишь часть картины. Она хорошо описывает состав, но почти не говорит о процессе, о том, как именно эти компоненты попали в продукт, где их могли подменить и почему проблемы возникают задолго до финальной сборки. Эту мысль отлично разобрали в статьях на LinkedIn ^[14].

Иногда в качестве примера приводят и кофе, но в другом контексте. Например, в материалах Dark Reading ^[15] путь кофе от плантации до чашки иллюстрирует риски физической цепочки поставок: контроля качества, подмены сырья. Это наглядно, но слабо затрагивает инженерную сторону безопасности цепочки поставок.

Вдохновившись всем перечисленным, я решил использовать приготовление кофе как модель всей цепочки поставок ПО. Потому что в этом аналоговом процессе удивительно много общего с тем, как на самом деле собирается современный софт (а еще все мы любим кофе).

Процесс приготовления кофе как цепочка поставок

Представим обычную кофемашину. Не промышленного монстра из кофейни, а домашнюю, которая есть у каждого второго. А если мы говорим про айтишников, то у каждого первого. Вроде все понимают, как ею пользоваться: нажал кнопку, получил кофе, пошел разгребать таски. Процесс кажется простым, но только пока не попытаешься разобраться, откуда берется кофе и что происходит между нажатием кнопки и глотком из чашки.

Кофемашина, по сути своей, как и любое устройство, является системой. Так мы и будем ее рассматривать.

Зерна кто-то вырастил, собрал, упаковал, перевез и обжарил. Потом они попали к вам, прошли через жернова, фильтр, воду, пресс, температуру. И только в конце получился результат, которому вы доверяете настолько, что готовы выпить получившийся напиток. И ведь мы пьем кофе не потому, что лично проверили каждый этап и компонент, а потому, что доверяем всей цепочке целиком: производителю, поставщикам, бренду, стандартам (а в кофейне в эту цепочку входит еще и сторонний бариста). Мы не делаем химический анализ воды и не летим с проверкой на плантацию в Колумбию. Мы просто ожидаем, что кофе будет похож на кофе.

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

Исходники, зависимости, сборка, пайплайн, инфраструктура, окружение, конфигурация… Каждый шаг кажется логичным и безопасным сам по себе. Но вся система целиком становится сложной, хрупкой и зависимой от кучи вещей.

Проблема в том, что кофемашина хотя бы физическая. Ее можно потрогать, открыть, разобрать. А цепочка поставок софта имеет мало общего с осязаемым миром. Она размазана по репозиториям, реестрам, сторонним сервисам и людям, которых мы никогда не видели. Поэтому атаки на цепочку поставок так часто бывают успешными. Злоумышленник не пытается подмешать отраву в саму чашку. Он делает это значительно раньше. Там, где речи о готовом напитке еще не идет в принципе.

А теперь попробуем разобрать кофемашину на части и заглянем внутрь этой системы. Начнем с самого очевидного и самого уязвимого компонента.

Зерна: исходники и зависимости

Процесс приготовления кофе начинается с зерен. Можно сколько угодно говорить про умные функции кофемашины и дизайн корпуса, но если зерна окажутся гнилыми, вкус кофе будет, мягко говоря, так себе.

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

Open source библиотека выглядит безопасно. Тысячи звезд, активное комьюнити, свежие релизы. Но кто конкретно залил последний коммит? Почему версия обновилась именно так? Что еще попало в пакет, кроме заявленной функциональности? Ответы на эти вопросы обычно без четких ответов.

Чего только стоит свежий (хотя уже и прошлогодний) пример, когда в сентябре 2025 года злоумышленники получили доступ к аккаунтам мейнтейнеров и внедрили вредоносный код ^[16] в легитимные релизы популярных JavaScript-пакетов, в частности, в библиотеку @ctrl/tinycolor и другие широко используемые зависимости. По итогу эти модифицированные версии получили возможность красть токены и учетные данные разработчиков, а затем распространяться дальше по цепочке зависимостей. Аналитики даже описали кампанию как самораспространяющегося червя, затронувшего сотни npm-пакетов. И ведь все это через официальные релизы, которые казались обычными обновлениями.

В случае кофе это выглядело бы странно. Представьте, что вы покупаете зерна без указания страны, сорта и даты обжарки. Просто пакет с надписью «КОФЕ». Большинство людей такой пакет даже не откроют, а в разработке мы делаем это каждый день через npm install.

Отсюда и появляются классические проблемы цепочки поставок. Подмена пакетов, компрометация аккаунтов мейнтейнеров, вредоносные версии, которые живут неделями, прежде чем их кто-то заметит. Иногда достаточно одной опечатки в названии зависимости (typosquatting), чтобы вместо привычных зерен в кофемолку попало что-то совсем другое.

А ведь самое страшное даже не в этом. Если проблема в вашем коде, она ограничена вашим продуктом. Если проблема в популярной зависимости, она автоматически распространяется на тысячи проектов. Это уже не индивидуальная ошибка ^[17], а массовое отравление партии.

И да, в этот момент часто звучит аргумент «ну мы же доверяем open source». И это действительно так, но фразу «доверяй, но проверяй» никто не отменял. Особенно когда от этих зерен зависит не только вкус кофе, но и здоровье потребителей вместе с репутацией бизнеса.

Как выбирать зерна?

Безопасность цепочки поставок начинается с понимания того, какие зерна вы используете, откуда они пришли и можно ли вообще пить кофе, сваренный из этих ингредиентов.

На практике это означает довольно приземленные вещи:

• Не запрещать open source, но перестать относиться к зависимостям как к чему-то безопасному по умолчанию.

• Проверять, кто поддерживает библиотеку и как давно она обновлялась.

• Смотреть не только на звезды, но и на историю релизов, частоту коммитов и реакцию ^[18] на инциденты.

• Фиксировать версии. Автообновления до latest выглядят удобно, но в реальности это привычка покупать новый пакет зерен не глядя, потому что «в прошлый раз было нормально».

• Контролировать источники. Зависимости должны приходить из проверенных репозиториев. Если есть возможность проверять подписи и хэши, то делайте это. Иначе вы просто рискуете не заметить, когда атака вообще произошла.

И, наконец, полезно заранее знать ответ на простой вопрос: что у нас вообще используется? Не в момент инцидента, не после письма от вендора, а заранее. Потому что когда кофе уже разлит по чашкам, выяснять состав напитка обычно поздно (и довольно странно).

Хорошо, с зернами разобрались. Но ведь даже если сами зерна отличные, это еще далеко не конец истории. Их можно испортить дальше по цепочке, например, на этапе обжарки.

Обжарка: сборка и CI/CD

По сути, на этом этапе сырье превращается в продукт, но даже самые качественные зерна легко испортить. Слишком высокая температура даст горечь, слишком низкая сделает напиток более кислым. Время обжарки тоже необходимо учитывать.

В мире софта обжарку можно сравнить со сборкой и CI/CD. Это тот самый момент, когда исходники и зависимости превращаются в бинарь, контейнер или артефакт, который поедет дальше по цепочке. И на этом этапе нужно быть особенно ответственным.

CI/CD часто воспринимается как техническая деталь, как этакая труба между кодом и продом. На самом деле — это одна из самых чувствительных точек всей цепочки поставок. Если атакующий контролирует этап сборки, он может добавить что угодно, и это будет выглядеть абсолютно легитимно.

Компрометация билд-сервера не требует взлома вашего приложения. Достаточно доступа к раннеру, токену, секрету или плагину. Инъекция происходит до релиза, и дальше вредоносный код распространяется уже под вашей подписью и вашим именем.

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

С CI/CD есть еще одна проблема — автоматизация. Пайплайны работают быстро, часто без участия человека. Это их сила и их слабость. Ошибка или компрометация множится мгновенно и уезжает дальше по цепочке еще до того, как кто-то успеет это заметить.

Добавим сюда общие раннеры, устаревшие плагины, доступы «на всякий случай», секреты, которые живут годами, и получим идеальную среду для атак. Не зря большинство громких инцидентов, связанных с цепочкой поставок, так или иначе затрагивали этап сборки. В том же 2025 году злоумышленники модифицировали популярный GitHub Action tj-actions/changed-files ^[19], используемый во множестве CI/CD workflow. Вредоносная версия позволяла выводить память ^[20] раннеров, потенциально включая секреты и токены.

Поэтому контроль «обжарки» безумно важен: изолированные сборки, минимальные доступы, воспроизводимость, контроль того, что попало в артефакт.

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

Фильтр: SBOM как список ингредиентов

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

В безопасности цепочки поставок роль фильтра играет SBOM ^[21]. По сути, это список ингредиентов вашего продукта: что именно в него вошло, в каких версиях, откуда взялось и как связано друг с другом. Без SBOM софт все равно что кофе из картонного стакана с крышечкой. Он горячий, пахнет знакомо, вроде бы бодрит, но содержимое остается загадкой. И в момент инцидента эта загадка превращается в проблему.

Происходит уязвимость в популярной библиотеке. Или компрометация пакета. Или отзыв версии. И тут возникает простой вопрос: «у нас это есть или нет?». Без SBOM ответ обычно звучит как «сейчас посмотрим», а дальше начинаются поиски вручную, grep по зависимостям и попытки восстановить картину задним числом.

С фильтром все иначе. SBOM не предотвращает проблему напрямую. Он не устранит уязвимости и не остановит атакующего. Но он резко сокращает путь от момента, когда стало понятно, что «что-то пошло не так», до момента, когда вы хотя бы понимаете, касается это вас или нет. В нашей аналогии это выглядит предельно понятно. Если мы знаем точный состав напитка, мы можем быстро понять, опасен он или нет. А вот если мы этого не знаем, остается только надеяться, что пронесет.

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

Хорошо. Допустим, мы уверены в том, что зерна у нас качественные. Обжарили мы их правильно. Фильтр есть. Состав ингредиентов известен. Но ведь и это еще не все. И тут мы подходим к следующему компоненту, вроде бы самому очевидному, но одному из самых недооцененных.

Вода: окружение и инфраструктура

Можно взять идеальные зерна, правильно их обжарить и аккуратно пропустить через фильтр. Но если вода плохая, кофе все равно будет отвратительным: с привкусом, запахом ^[22] или странным послевкусием. И виноваты вроде бы не зерна, и не кофемашина, а результат все равно пить не хочется.

В контексте софта вода — это окружение и инфраструктура: хосты, контейнеры, базовые образы, Kubernetes, registry, рантайм, системные библиотеки.

Инфраструктура редко воспринимается как часть цепочки поставок. Ее считают чем-то вторичным, обслуживающим, но по факту она напрямую влияет на безопасность финального продукта. Уязвимый базовый образ, старый OpenSSL, скомпрометированный registry или общий namespace могут являться угрозой.

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

Особенно коварна инфраструктура тем, что она масштабирует проблемы. Один уязвимый образ может использоваться десятками команд, а один небезопасный registry при этом является источником бед для сотен сервисов.

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

Но даже идеально фильтрованная вода не гарантирует, что кофемашина заработает, ведь есть еще один элемент, который часто становится источником неожиданных проблем.

Бариста: люди и процессы

Даже самая умная кофемашина не работает сама по себе. Кто-то засыпает зерна, чистит фильтр и решает, когда пора обслуживать аппарат.

В цепочке поставок мы можем рассмотреть баристу как людей и процессы. Разработчики, DevOps-инженеры, безопасники, менеджеры релизов. А еще регламенты, дедлайны, доступы, договоренности.

На этом этапе возникает парадокс ^[23]. Почти каждый инцидент, связанный с цепочкой поставок, на бумаге выглядит как сугубо техническая проблема, но если копнуть глубже, почти всегда выясняется, что имел место человеческий фактор. Скажем, секрет, который «временно» закоммитили, или токен, выданный «случайно». Какой-нибудь раннер под root, потому что так быстрее и никто не жаловался. Проверка, которую отключили, потому что она тормозила релиз.

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

Люди устают, ошибаются, спешат, доверяют и переоценивают собственный контроль над ситуацией. Поэтому процессы важны не меньше инструментов. И это нужно контролировать через минимальные доступы, явные процессы, проверки и культуру, в которой безопасность является частью самого продукта.

Плохой бариста может испортить даже идеальный кофе. Но хороший способен спасти ситуацию, даже если что-то пошло не так на предыдущих этапах.

И вот теперь, когда мы разобрали всю внутреннюю начинку, самое время посмотреть на результат.

Чашка на выходе: что в итоге пьет пользователь

Пользователь никогда не видит зерна. Он не знает, как именно их обжаривали, какой фильтр использовали, и кто сегодня ему этот кофе сварил. Он просто получает чашку с напитком. Горячую, ароматную и, как он надеется, безопасную для здоровья.

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

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

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

Если продолжать нашу кофейную аналогию, это как партия кофе, которая на вкус нормальная, но вызывает проблемы спустя время. Пользователь не может определить это самостоятельно. Он может только перестать приходить в эту кофейню.

В таком случае возникает закономерный вопрос. Если пользователь видит только чашку, а все проблемы прячутся раньше по цепочке, то как вообще выглядят атаки на процесс приготовления кофе? Давайте пофантазируем в части аналогии и рассмотрим реальные инциденты, связанные с цепочкой поставок.

Как ломают цепочку поставок?

Неприятная особенность атак на Supply Chain в том, что они редко выглядят, как кибератаки в привычном понимании. Ничего не падает, алерты не вылезают, сервисы работают корректно. Злоумышленник не ломает систему целиком, а выбирает момент, когда можно незаметно влезть в процесс. Иногда еще до того, как «зерна» вообще попали на кухню.

Есть замечательная фраза: “It takes a thief to catch a thief”. Чтобы поймать преступника, нужно думать как преступник. Так давайте подумаем, как атаковать процесс приготовления кофе:

1. Подмена зерен (Dependency Confusion / Typosquatting). Если бы я хотел испортить кофе, я бы подменил нормальные зерна на плохие. В софте это компрометация популярной зависимости, захват аккаунта мейнтейнера, вредоносное обновление. Снаружи все легитимно, а внутри — сюрприз. Причем часто это делается не ради немедленного взлома, а ради тихого присутствия, чтобы использовать получившуюся лазейку в будущем.

2. Атака на обжарку (CI/CD Injection). Я бы постарался влезть в процесс прожарки зерен. Это атаки на билд-скрипты, плагины, раннеры. Вредоносный код попадает в компонент автоматически и распространяется сам. Вспомните SolarWinds. Тогда компрометация процесса сборки привела к тому, что вредоносное обновление уехало к тысячам клиентов ^[24].

3. Отравление воды (Infra Compromise). Можно скомпрометировать registry или базовый образ. Код качественный, сборка корректная, а в рантайме приложение получает лишние возможности, которых не планировалось.

4. Человеческий фактор. Токен в публичном репо. Временный доступ, ставший постоянным. Такие вещи выглядят как целенаправленная атака, но именно через них проблемы цепочек поставок эксплуатируются по полной.

Как защитить цепочку поставок

После всех этих историй первая реакция обычно у всех одинакова. Срочно все зашифровать, все подписать и перестать кому-либо доверять. Импульс понятный, но в реальности он чаще приводит не к безопасности, а к ступору. Так ни кофе приготовить не получится, ни софт разработать. Смысл безопасности цепочки поставок не в том, чтобы заморозить процесс. Он в том, чтобы сделать его понятным и управляемым.

1. Все начинается с источников. С понимания, откуда берутся зависимости, какие из них допустимы, а какие — нет на уровне конкретных репозиториев, владельцев и версий. Это кажется чем-то не особо важным ровно до первого инцидента, после которого вопросы внезапно появляются у всех.

2. Дальше идет сборка. Она должна быть изолированной, воспроизводимой и как можно меньше опираться на окружение. CI/CD здесь является не столько удобным инструментом, сколько важным участком самой цепочки поставок. Как любила говорить моя преподавательница по математическому анализу: «Не занимайтесь самообманом».

3. SBOM представляет собой культуру, а не просто отчетность. К нему регулярно должны обращаться разработчики.

4. Инфраструктура — как вода в кофе. Базовые образы, registry, кластеры и рантайм нельзя считать чьей-то второстепенной зоной ответственности. Они либо осознанная часть цепочки поставок, либо готовая точка входа для злоумышленника.

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

Если вам нужен конкретный ориентир и нет желания изобретать велосипеды, смотрите в сторону моделей вроде SLSA (Supply-chain Levels for Software Artifacts) ^[25]. Может, кофе вы варить лучше и не научитесь, но цепочку поставок сможете сделать куда более безопасной.

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

---

Цепочка поставок не заканчивается на этой статье. Чтобы ваш кофе код оставался без примесей, подписывайтесь на мой ТГ-канал ^[26]. Там я разбираю атаки на Supply Chain, свежие уязвимости, безопасность IoT и делюсь историями из практики.