Безопасность цепочек поставок стала вопросом совета директоров: что нужно знать CSO

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

Изменение нормативно-правовой базы стало ключевым фактором, привлекшим внимание высшего руководства, поскольку такие законодательные акты, как Европейский закон о киберустойчивости (CRA), предусматривают штрафы за несоблюдение до 2,5% от мирового оборота. Кроме того, широкое распространение программного обеспечения с открытым исходным кодом в сочетании со сложными глобальными цепочками поставок создало идеальный шторм, трансформирующий подход директоров по безопасности (CSO) к защите цепочек поставок.

Всепроникающий характер ПО с открытым исходным кодом перевернул ландшафт безопасности. Согласно отчету Synopsys’ 2025 Open Source Security and Risk Analysis report, 97% коммерческих приложений содержат ПО с открытым исходным кодом, при этом  86% содержат уязвимости, из которых 81% классифицируются как высокорисковые или критические. Пять лет назад подобная статистика была незнакома советам директоров, но теперь это данные, лежащие в основе требований.

Уязвимость Log4Shell в 2021 году высветила эту проблему. Критический дефект в компоненте с открытым исходным кодом Apache Log4j 2 Java library позволил злоумышленникам удаленно выполнять код, затронув миллионы приложений, облачных сервисов и физических конечных точек, включая серверы. Хакеры использовали эту уязвимость для кражи данных, установки программ-вымогателей и захвата устройств для ботнетов с поразительной скоростью. Это развеяло предположение о безопасности открытого исходного кода, поскольку ситуация подчеркнула взаимосвязанность программных экосистем и скорость распространения эксплуатации одной уязвимости. Если, как и я, вы отвечали за какие-либо продукты во время Log4Shell, вы можете почувствовать мою боль. Это было очень похоже на проблему Y2K, но без предварительного предупреждения. И кто еще внезапно задумался, не пора ли отключить корпоративный веб-сайт?

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

Законодательные изменения подняли безопасность из технической плоскости в плоскость бизнеса. CRA рассматривает безопасность программного обеспечения как вопрос безопасности продукта, и штрафы отражают эту реальность. Федеральное законодательство, включая EO14028, требует от ведомств ведения полного учета программного и аппаратного обеспечения и разработки политик обеспечения безопасности. Аналогичные нормативные акты разрабатываются или уже приняты в таких странах, как Индия и Южная Корея. Одним из примеров отраслевого регулирования является требование FDA к медицинским устройствам предоставлять спецификации материалов программного обеспечения (SBOM), признавая, что безопасность ПО напрямую влияет на безопасность пациентов. До введения требования FDA о предоставлении SBOM была обнаружена уязвимость в одобренном FDA кардиомониторе. Это устройство никогда бы не вышло на рынок без устранения дефекта, если бы был предоставлен SBOM и сопоставлен с базами данных уязвимостей.

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

Скрытая сложность, которая подавляет команды безопасности

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

Обнаружение проблемы — это только начало; необходимо определить, затрагивает ли уязвимость вашу реализацию. Например, если библиотека SSL содержит 100 функций, а ваше приложение использует 60 из них, и дефект находится в одной из неиспользуемых 40, риска нет. Однако традиционные инструменты сканирования могут пометить это как критическое, и ваша команда потратит время на расследование несуществующей проблемы. Для сравнения, Корнелл обнаружил, что инструменты анализа уязвимостей кода имеют 97,5% ложноположительных срабатываний. Любой, кто хоть немного работал в сфере кибербезопасности, знает, что ложные срабатывания — это бич нашего существования, будь то анализ оповещений брандмауэра, EDR или корреляция уязвимостей библиотек. Важно отметить, что даже если риска нет, вы все равно должны опубликовать эту информацию, чтобы ваши клиенты знали, что вы подтвердили отсутствие уязвимости.

Это требует значительных ресурсов: разработчики тратят 3,5 часа в неделю на ручную проверку результатов сканирования безопасности из-за ложных срабатываний. Это задерживает выпуск новых функций и замедляет выход на рынок. Команды безопасности теряют авторитет, разработчики становятся равнодушными и отмахиваются от оповещений как от шума, а реальные угрозы могут затеряться. Усталость от оповещений — это реальная проблема.

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

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

Что CSO должны требовать от своих инструментов и процессов

Проведение сравнительных испытаний как минимум трех решений жизненно важно для нахождения правильного варианта. Крайне важно тестировать на собственном коде для подтверждения точности, а не полагаться на образцы от поставщика. Цель состоит в том, чтобы понять, как каждый потенциальный вариант работает в вашей среде. Один из аспектов, который следует учитывать, — где будет работать программное обеспечение или прошивка: в Windows, Linux, Android или другой богатой ОС? Или это bare metal, как часто встречается в условиях ограниченного пространства или в промышленных средах? Для последнего доступно не так много инструментов анализа прошивок, поэтому в таких средах могут предпочесть инструменты на основе исходного кода или сборки, хотя бинарный анализ часто лучше подходит для прошивок в богатых ОС.

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

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

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

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

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

Путь вперед

Проблема безопасности цепочек поставок будет только обостряться. FDA не могло определить, что такое SBOM 18 месяцев назад; теперь это обязательное условие для одобрения медицинских устройств. Аналогичные нормативные акты появляются в разных отраслях и юрисдикциях по мере того, как цепочки поставок программного обеспечения признаются критически важными для безопасности продуктов.

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