Разработка ПО строится сейчас на сложных цепочках поставок (supply chain), где каждая сторонняя библиотека или сервис — источник риска. Уязвимости в них могут парализовать тысячи компаний. Эксперты AM Live отмечают: контроль таких рисков требует строгого аудита, мониторинга и внедрения практик DevSecOps.
- Введение
- Источники киберугроз для цепочек поставок
- Чему научила практика прошлых лет в сфере цепочек поставок ПО?
- Как выбрать поставщика сторонних компонентов ПО?
- Как подходить к приоритизации усилий и процессу оценки сторонних компонентов?
- Какие меры эффективны для минимизации рисков?
- Нужно ли проверять обновления?
- Рекомендации экспертов по защите цепочек поставок и итоги эфира
- Выводы
Введение
Современные цифровые экосистемы полагаются на сложные цепочки поставок, используя множество сторонних компонентов: библиотеки, фреймворки, SaaS-решения и даже открытое ПО. Однако чем больше зависимостей такого рода, тем выше риски. Уязвимости в стороннем коде, скрытые бэкдоры, нарушения условий лицензирования и преднамеренные атаки через поставщиков — все это превращает цепочку поставок ПО в критический вектор угроз.
Примеры громких кибератак наглядно показывают, как уязвимость одного звена в этой цепочке может поставить под удар любую организацию. При этом традиционные методы безопасности часто фокусируются на внутренней инфраструктуре, упуская риски, привнесенные извне.
Как же минимизировать эти угрозы? В рамках прямого эфира эксперты разобрали ключевые подходы к контролю рисков в цепочке поставок ПО: от анализа зависимостей и перечней компонентов (Software Bill of Materials, SBOM) до внедрения практик DevSecOps и аудита.
Рисунок 1. Эксперты в студии AM Live
Участники эфира:
- Павел Ашарин, сооснователь компании RebrandyCo.
- Андрей Абашев, руководитель по направлению методологии и развития ИБ, «Норильский никель».
- Анастасия Калугина, руководитель направления безопасной разработки и инфраструктуры, ИнфоТеКС.
- Александр Лысенко, ведущий эксперт по безопасной разработке, «К2 Кибербезопасность».
- Илья Борисов, директор департамента защиты данных, «Билайн».
- Алексей Смирнов, основатель и генеральный директор CodeScoring (по видеосвязи).
Ведущий и модератор эфира — Илья Шабанов, генеральный директор «АМ Медиа».
Источники киберугроз для цепочек поставок
Алексей Смирнов объяснил, что атаки на цепочки поставок связаны с эксплуатацией всех компонентов, а не только созданием и выпуском ПО. Даже если изначально был разработан хороший продукт, злоумышленники могут реализовать проникновение уже в процессе его использования. Ключ кроется в разработке: нужно понимать, из чего складывается ваше ПО. На цепочку поставок может повлиять, например, наличие секретов в коде, которые случайно оставил программист.
Контроль должен быть многоуровневым: необходимо проверять как собственный, так и сторонний код — всю цепочку поставки. Со временем в выпущенном ПО обнаруживаются уязвимости, за этим необходимо следить, поэтому процесс контроля не останавливается после релиза продукта. Классическая «петля» DevOps и DevSecOps здесь тоже актуальна.
Алексей Смирнов, основатель и генеральный директор CodeScoring
Павел Ашарин уверен, что заказчики должны проверять, насколько безопасно выстроена разработка у подрядчиков и их исполнителей. В софте, который разрабатывается вендорами, часто безопасная разработка не реализована — она очень дорогая, в ней велико влияние человеческого фактора. Часто проблемой становится интеграция, через которую можно взломать конечного заказчика. Один из последних таких примеров — взлом криптобиржи, где сделали подмену кода веб-приложения, в результате чего деньги пользователя уходили злоумышленникам.
Андрей Абашев считает, что количество уязвимостей и их опасность в опенсорсе даже больше, чем в проприетарном ПО вроде Windows. Цепочка поставок — это не только ПО, но и оборудование: стоит вспомнить, например, историю с пейджерами на Ближнем Востоке; а также поставщики услуг, для оказания которых может происходить взаимодействие с информационными системами или данными компании-заказчика . Глубина проверки контрагента зависит от типа производимого ПО и его критической значимости для бизнес-операций.
Илья Борисов уточнил, что есть разница между обычным и вендорским открытым кодом. Опенсорс — это модель распространения, лицензирования. Много опенсорса пишут большие вендоры, например Google. В этих случаях открытый код не хуже проприетарного по качеству, он живёт в той же производственной среде с теми же контролями. Часто слышно об уязвимостях в опенсорсе, возможно, потому, что они более заметны и чаще выявляются сообществом. Кроме того, в последние годы часто обсуждается тема «тихого» патчинга (Silent Patching) со стороны вендоров, когда о найденных уязвимостях не заявляется, а разработчики пытаются максимально незаметно их закрыть. С опенсорсом это сделать сложнее.
Илья Борисов, директор департамента защиты данных, «Билайн»
Анастасия Калугина согласилась, что опенсорс, который разрабатывается крупными организациями со своими выстроенными процессами безопасной разработки — это отдельная плоскость. Но чаще всего основное внимание разработчиков направлено в сторону функциональности, а не безопасности.
Александр Лысенко добавил, что когда используется вендорское решение, ответственность за защищённость перекладывается на вендора. Это неправильный подход — нельзя пренебрегать своими политиками безопасности и теми подходами, которые уже есть в компании для того, чтобы интегрировать вендорское решение. Часто, например, в документации к продукту содержится запрос на излишние права доступа, которые потребуется приложению внутри инфраструктуры. К этому нужно относиться критически и обязательно проверять вендорские продукты.
Чему научила практика прошлых лет в сфере цепочек поставок ПО?
Илья Борисов считает, что при выборе сложных продуктов всегда будет иметь место определённый уровень доверия. Оценка защищённости — не дешёвый процесс, она требует экспертизы, инструментария, процессов ИБ. Многие компании не располагают достаточными ресурсами и вынуждены заимствовать много кода, библиотек, приложений, не имея других вариантов. Полноценная их защита невозможна. В этом случае нужно смотреть в сторону безопасных репозиториев, точек доверия, где такие компании смогут брать безопасные продукты с определённым уровнем доверия. Это можно реализовать вне вендора — на уровне государства или отрасли.
Александр Лысенко дополнил, что на практике часто видна ситуация, когда начинают выстраивать информационную безопасность, исходя из произошедшего инцидента. Такой подход обречён на неудачу. Нужно оценить риски, которые есть в компании, и выстраивать ИБ, исходя из этих рисков. Чтобы оценить риски, нужно понимать, какие уязвимости уже есть — для этого нужно провести инвентаризацию. В этом случае будет реализовываться цепочка — управление активами (Asset Management), уязвимостями (Vulnerability Management) и рисками (Risk Management). В итоге получится построить эффективную систему управления рисками, оценить, какие есть риски и насколько они существенны.
Александр Лысенко, ведущий эксперт по безопасной разработке, «К2 Кибербезопасность»
Анастасия Калугина уверена, что защита должна быть проактивной, комплексной. Если проседают процессы и методологическая составляющая, нет обученных людей, автоматизации, конвейера, не выстроено общение с поставщиком — при наличии этих проблем полноценно обеспечить безопасность разрабатываемых продуктов невозможно. Стоит ориентироваться на ГОСТ Р 56939 — это один из немногих практически применимых документов по разработке безопасного ПО.
В первом опросе зрители ответили, существует ли в их компании практика оценки поставщика ПО, оборудования или услуг с точки зрения информационной безопасности: да — 51%, нет — 29%, в процессе разработки — 10%.
Рисунок 2. Существует ли в вашей компании практика оценки поставщика ПО с точки зрения ИБ?
Как выбрать поставщика сторонних компонентов ПО?
Андрей Абашев считает, что не нужно придумывать проблемы, которой нет. Всё решается через управление уязвимостями. В разрезе аудиторских практик и подходов проблема заключается в том, что «внутрь» ПО и компании-контрагента не пускают, так как нет договора на аудиторские услуги, или может отсутствовать бюджет на такие проверки. Чаще всего всё ограничивается коротким набором вопросов, что не может дать полной картины. Эффективнее внутри использовать комплексные подходы, которые дадут определённую гарантию управляемости присущими рисками, и на этом остановиться. Глубокая проверка поставщиков может оказаться неэффективной с точки зрения затрат для бизнеса.
Андрей Абашев, руководитель по направлению методологии и развития ИБ, «Норильский никель»
Илья Борисов уверен, что есть вещи, которыми нельзя управлять, но это не значит, что не нужно о них беспокоиться. Даже если на какую-то часть цепочки нельзя повлиять, общие требования всё равно важны. Хорошая практика — предъявлять к внешним поставщикам те же требования, что и к внутренним командам с точки зрения того, как поставляется продукт, как проходит сборка и доведение до продуктива. Если нельзя попасть в «бинарники», можно посмотреть контейнеры.
Павел Ашарин добавил, что важно понимать, какая стоит цель — сэкономить деньги в моменте закупки или снизить риски на перспективу. Если при выборе поставщика софта важно сохранить деньги, при таком подходе появляются риски. Если крупный заказчик ставит в приоритет безопасность, то он может для развития мелких нишевых вендоров выстраивать процессы для повышения безопасности. Вендоры при этом будут расти.
Во втором опросе зрители поделились, как они проверяют безопасность закупаемого ПО:
- Смотрят сертификаты и лицензии ФСТЭК России — 40%.
- Делают несколько или все проверки из списка — 35%.
- Смотрят данные о найденных уязвимостях — 15%.
- Изучают SBOM — 10%.
Рисунок 3. Как вы проверяете безопасность закупаемого ПО?
Насколько полезен перечень компонентов (SBOM)?
Андрей Абашев заметил: для использования SBOM потребуется нанять группу аналитиков, которые должны провести анализ, насколько состав компонент устарел и как уязвимости внутри устаревших компонент могут быть использованы злоумышленником, а затем заставить вендора доработать. При этом, может появиться другая проблема - несовместимость обновленных компонентов, вследствие чего стоимость возрастёт из-за дополнительной доработки ПО.
Павел Ашарин уверен, что осуществляя проверку своих поставщиков, заказчик воспитывает в них уверенность, что они могут развиваться и со временем выйти на более крупных заказчиков, внедрив безопасную разработку как часть корпоративной культуры.
Как подходить к приоритизации усилий и процессу оценки сторонних компонентов?
Илья Шабанов считает, что нужно начинать с минимизации площади атаки: проверить, действительно ли все компоненты ПО нужны, можно ли от чего-то отказаться, если оно не используется или дублируются функции.
Илья Шабанов, генеральный директор «АМ Медиа»
Илья Борисов согласился, что чем меньше площадь атаки, тем лучше. В ПО может быть избыточный код, которым никто не пользуется. Часто его удаление оказывается слишком затратным. Безопасность — это некий баланс между стоимостью риска, который потенциально может реализоваться, и затратами на избежание этого риска. Нужно обязательно использовать подходы, которые уменьшают площадь атаки, закрывают уязвимые места. Для этого есть не один способ, и у каждого свои плюсы и минусы.
Илья Шабанов добавил, что можно использовать харденинг — не избавляться от компонентов ПО как таковых, а блокировать потенциальные уязвимости на уровне конфигурации.
Александр Лысенко тоже считает, что нужно провести базовый харденинг инфраструктуры. Первое, что нужно сделать — провести микросегментацию сети, построить «нулевое доверие» (Zero Trust) внутри компании, перевести коммуникации на более безопасные протоколы. Далее можно выполнять инвентаризацию, переходить к оценке рисков.
Павел Ашарин добавил, что для бизнеса важны деньги, которые можно потерять при изменении процессов. Также стоит учитывать человеческий фактор.
В третьем опросе выяснилось, как зрители проводят регулярную оценку безопасности используемого ПО:
- Сканируют на уязвимости — 35%.
- Проводят статический и динамический анализ кода — 10%.
- Проводят пентесты и проверки по методу Red Teaming — 9%.
- Делают всё из списка выше — 38%.
- Ничего не делают — 8%.
Рисунок 4. Как вы проводите регулярную оценку безопасности используемого ПО?
Какие меры эффективны для минимизации рисков?
Андрей Абашев уверен, что из представленных подходов наиболее эффективны регулярные проверки по методу Red Teaming: в кастомизированном ПО или заказной разработке сканер не увидит известных ему уязвимостей, а в ПО с закрытым исходным кодом могут быть дополнительные трудозатраты при использовании динамических сканеров. Илья Борисов, однако, считает, что Red Teaming подходит не всем. В зависимости от специфики компании могут быть разные акценты, но в целом нужно использовать максимальный объём практик, которые есть.
Александр Лысенко добавил, что статический и композиционный анализ дает хорошие результаты, показывает большую часть уязвимостей, в том числе тех, которые вряд ли когда-либо были бы проэксплуатированы. Однако это сложный процесс, он требует триажа, много ресурсов и людей. Red Teaming тоже дорогой процесс. Самый простой вариант — сканер уязвимостей.
Анастасия Калугина назвала две наиболее эффективные, на свой взгляд, практики — композиционный анализ и моделирование угроз. Большинство векторов атак достаточно типовые, разработчики часто ошибаются в одних и тех же местах.
Анастасия Калугина, руководитель направления безопасной разработки и инфраструктуры, ИнфоТеКС
Павел Ашарин добавил, что большинство хакеров идут туда, где проще взломать. Можно усложнить процесс взлома с помощью СЗИ, таким образом отфильтровать большую часть злоумышленников.
Нужно ли проверять обновления?
Илья Шабанов считает, что обновляться нужно — это первый шаг управления уязвимостями. Но проблема в том, что во время обновления теряется контроль. Проверять обновления долго, дорого и сложно. Есть ли какое-то решение?
Александр Лысенко объяснил, что вся ИТ-индустрия активно переходит к автоматизации своих процессов, в том числе можно использовать автоматизацию проверки. Всеобщая автоматизация управления инфраструктурой — это первый плюс в информационной безопасности, и сотрудники ИБ больше всего должны это продвигать. Преимущества: меньше людей работают с деплоем, стандартный описанный процесс, ролевая модель. Сюда же можно встроить проверки, использовать песочницу, динамический анализ. Проверять обновления — это нормально и нужно.
Павел Ашарин напомнил, что иногда используется старый софт, старые решения АСУ ТП, которые заказчик не может заменить. Из-за несоответствия софта могут быть проблемы с бизнес-процессами. Управление патчами (Patch Management) — рекомендуемая, но на практике часто затруднительная задача. Она требует глубокой проработки.
Павел Ашарин, сооснователь компании RebrandyCo
Рекомендации экспертов по защите цепочек поставок и итоги эфира
Павел Ашарин:
«Нужно выстраивать качественный Asset Management, использовать поиск информации в открытых источниках, киберразведку, внедрять методики OSINT, чтобы ИБ-специалист видел больше за периметром. Также нужно обращать внимание на тестирование безопасности с точки зрения непрерывности этого процесса. Компания должна выстраивать цепочку рисков и применять те инструменты, которые может себе позволить».
Андрей Абашев:
«Помимо проверок, которые дают условную уверенность, что всё в порядке, мы включили в договоры требования по ИБ к нашим подрядчикам, включая ответственность подрядчика за их нарушение. Ещё есть страховка остаточных рисков — то, что нельзя проконтролировать. Цепочка поставок — это не только софт, а более масштабная проблема».
Анастасия Калугина:
«Внутри организации должна быть выстроена безопасная цепочка от точки входа до попадания в конечный продукт. Это должно касаться процессов, механизмов передачи, всего сборочного конвейера. Не должно быть возможности влияния в цепочке в целом. Так же и за пределами организации — от поставщика компонента и в обратную сторону».
Александр Лысенко:
Цепочка поставок — один из ключевых векторов атаки. Об этом следует помнить на каждом этапе, во всех направлениях ИБ. Нужно минимизировать права и доступы».
Илья Борисов:
«Важно думать о безопасности цепочек поставки, и это должна быть не только задача ИБ».
Алексей Смирнов:
«Сейчас популярно написание кода с помощью ИИ. Это несёт риски, новые векторы угроз. Должен быть контроль и нужно быть готовым к новым вызовам».
Четвёртый опрос показал, как зрители оценивают защищённость своей компании от атак на цепочку поставок после эфира: убедились, что всё делают правильно — 36%, будут усиливать процессы и внедрять лучшие практики — 29%, узнали много нового, будут разбираться дальше — 14%, считают избыточным для себя — 7%.
Рисунок 5. Как оцениваете защищённость компании от атак на цепочку поставок после эфира?
Выводы
В современных условиях цифровой трансформации безопасность цепочки поставок ПО перестает быть второстепенной задачей — она становится критически важным элементом стратегии защиты данных. Инциденты последних лет доказали, что даже крупные организации уязвимы из-за скрытых рисков в сторонних компонентах. При этом традиционные подходы к кибербезопасности уже не справляются с динамично меняющимися угрозами.
Эффективное управление рисками требует не только технологических решений, но и изменения корпоративной культуры. Необходим переход от разовых проверок к системному мониторингу, где безопасность встраивается на каждом этапе — от выбора поставщика до развертывания кода. Особую роль играет прозрачность: понимание состава программного обеспечения позволяет быстрее обнаруживать и устранять уязвимости.
Устойчивость к киберугрозам определяется не отсутствием атак, а способностью их предвидеть и минимизировать последствия. Инвестиции в безопасность цепочки поставок — это инвестиции в репутацию компании, непрерывность бизнеса и доверие клиентов.
Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка ИБ и ИТ. Будьте в курсе трендов и важных событий. Для этого подпишитесь на наш YouTube-канал. До новых встреч!
