О подходах США и Европейского союза к регулированию цепочек поставок программного обеспечения

На современном этапе глобальной цифровой трансформации технологии информационной отрасли динамично прогрессируют, а постепенный переход общества к цифровым решениям в различных секторах экономики стал следствием усложнения процесса разработки безопасных программных продуктов. Это повлекло за собой повышение сложности экосистем цепочек поставок программного обеспечения (Software Supply Chain, SSC) и усиление их кибербезопасности.

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

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

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

Последние два года специалистами по кибербезопасности фиксируется резкий рост числа и сложности целенаправленных атак на компоненты и репозитории ПО. Так, в 18-ом ежегодном отчете американской телекоммуникационной компании Verizon «О нарушениях безопасности данных» (Data Breach Investigations Report, DBIR) за 2025 год отмечается, что количество утечек данных, связанных с программным обеспечением третьих сторон, составило 30% от всех подтвержденных утечек (12 195 прецедентов в 139 странах), зафиксированных в отчетный период. А согласно отчету американской корпорации IBM «О стоимости утечек данных» (Cost of a Data Breach Report) за 2025 год, каждый такой инцидент обошелся потерпевшей стороне в среднем более четырех миллионов долларов США, что подчеркивает финансовый и репутационный ущерб, с которым сталкиваются организации.

Такой интерес злоумышленников к SSC и динамика ежегодного увеличения кибератак обусловлены тремя тенденциями, которые делают цепочки поставок ПО особенно уязвимыми:

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

2. Автоматизация в масштабе. Использование CI/CD программных решений, которые автоматизируют процессы непрерывной интеграции (Continuous Integration, CI) и доставки/развёртывания (Continuous Delivery/Continuous Deployment, CD) программного обеспечения, помогает ускорить разработку, повысить качество кода и снизить влияние человеческого фактора. Однако если конвейеры обновления ПО будут скомпрометированы, вредоносные изменения могут быстро распространиться по системе. Чаще всего злоумышленники используют комбинацию фишинга (для кражи учётных данных), похищения токенов доступа и злоупотребления правами жертвы (для передачи пакетов данных). Анализ известных инцидентов показал, что схема проведения кибератак постоянно повторяется: сначала взламывают аккаунты специалистов, отвечающих за развитие и сопровождение ПО (мейнтейнеров), или крадут токены репозитория (GitHub/npm), а затем через автоматические скрипты сборки внедряют вредоносный код.

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

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

Ключевые подходы и методы проведения атак:

1. Компрометация пакетов:

• загрузка злоумышленниками в репозиторий (например, npm, PyPI и т.п.) вредоносных пакетов или замена ими уже загруженных релизов;

• использование метода кибермошенничества «typosquatting», при котором злоумышленники регистрируют пакеты, внешне похожие на названия известных проектов или брендов, но с намеренными опечатками. Цель – перенаправить пользователей на вредоносный контент, воспользовавшись их невнимательностью, при вводе имени пакета. Например, вместо популярного пакета lodash можно по ошибке загрузить вредоносный пакет Iodash (смена первой строчной буквы на заглавную);

• Dependency Confusion/Substitution – подход, в котором используется конфликт имен между публичными и внутренними репозиториями. Многие компании используют внутренние (приватные) библиотеки с собственными названиями. Злоумышленник регистрирует в публичных репозиториях (например, PyPI, npm, NuGet Gallery, Maven Central) пакет с тем же именем, что и у приватного пакета организации. При этом у вредоносного пакета может быть более высокая версия, чем у легитимного. Менеджеры пакетов, стремясь получить последнюю версию, автоматически загружают и устанавливают «новую» с вредоносным кодом из публичного репозитория вместо внутреннего. Это может привести к тому, что вредоносный код автоматически и незаметно для разработчиков внедрится в итоговую сборку приложения, что повлечет за собой утечки данных, установку бэкдоров или другие угрозы безопасности.

2. Компрометация учётных записей мейнтейнеров: взлом e-mail/GitHub-аккаунтов, кража токенов двухфакторной аутентификации, использование скомпрометированных ключей для публикации вредоносных версий.

3. Атаки на CI/CD-пайплайны сборки ПО: включают внедрение вредоносных скриптов в шаги сборки, подмену артефактов в процессе сборки, компрометацию ключей/токенов.

4. Подмена артефактов после сборки ПО, а именно: готовых программ (бинарные файлы .exe, .dmg), образов контейнеров (например, Docker/OCI-образы), пакетов обновлений для операционных систем или приложений, установочных пакетов (например, .msi, .deb).

5. Атаки на реестры и инфраструктуру распределения ПО: официальные хранилища пакетов (например, Play Store или App Store для разработчиков), серверы обновлений или сети доставки контента (Content Delivery Network, CDN). В них злоумышленники взламывают сам сервер или получают к нему доступ. Затем, как только готовая программа попадает на сервер для скачивания пользователями, они подменяют её на вредоносную версию с тем же именем и версией, так что пользователь скачивает уже зараженную версию.

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

По данным GitHub Security, в среднем ежемесячно в различных публичных репозиториях выявляется более 10 000 вредоносных пакетов.

Одной из самых масштабных атак, совершенных на цепочку поставок ПО, стала атака на экосистему npm в сентябре 2025 года, получившая название Shai-Hulud.

Для её проведения киберпреступники использовали самовоспроизводящийся «червь», который скомпрометировал более 500 пакетов, включая популярные библиотеки, такие как @ctrl/tinycolor.

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

После получения доступа к учетным записям хакеры публиковали обновления с вредоносным кодом в популярных пакетах, таких как debug, chalk, ansi-styles и др. Эти пакеты имеют миллиарды загрузок еженедельно, что обеспечило широкое распространение вредоносного кода.

Особенности работы вредоносного ПО, так называемого «малваря» (сленговое от английского malicious software):

• Малварь использовал инструмент сканирования TruffleHog для поиска и кражи секретных данных, таких как токены npm, учетные данные GitHub и ключи доступа к облачным сервисам (AWS, GCP, Azure).

• Вредоносный код создавал скрытые рабочие процессы на платформе по разработке ПО GitHub Actions, которые позволяли злоумышленникам получать доступ к данным при каждом запуске CI/CD-пайплайна.

• Малварь автоматически публиковал зараженные версии других пакетов, к которым имел доступ, распространяясь по экосистеме npm.

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

Ключевые методы обеспечения безопасности, которые следует учитывать специалистам по безопасности:

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

• Регулярное проведение инструктажей сотрудников по технике безопасности.

• Усиление защиты всех подключенных устройств и конфиденциальных данных.

• Проверка поставщиков и контрагентов. Оценка рисков для установления уровеня кибербезопасности каждого поставщика.

• Регулярный мониторинг и обновление систем.

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

• Проверка уровня зависимости от сторонних поставщиков.

• Публикация и использование спецификации программного обеспечения Software Bill of Materials (SBOM).

• Введение требований по предоставлению артефактов, подтверждающих меры безопасности, уже заложенных в продукте (Supply-chain Levels for Software Artifacts, SLSA), которые включают в себя:

· Возможность подписывать программные продукты цифровой подписью для подтверждения их происхождения.

· Автоматизацию процессов и политик с использованием автоматизированных инструментов тестирования безопасности, таких как анализ состава программного обеспечения (Software Composition Analysis, SCA), статическое тестирование безопасности приложений (Static Application Security Testing, SAST) и динамическое тестирование безопасности приложений (Dynamic Application Security Testing, DAST).

· Внедрение в цифровые системы организаций архитектуры «нулевого доверия» (Zero Trust Architecture, ZTA).

На сегодняшний день оптимальным методом обеспечения безопасности считается сочетание двух основных стратегий: профилактики – внедрение защиты на этапе разработки и сборки продукции (CI/CD) – и реагирования – оперативное выявление угроз, а также использование актуальных SBOM-списоков для анализа компонентов ПО.

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

Так, за последние четыре года США и Европейский союз (ЕС) сформировали два эффективных, но принципиально различных регуляторных механизма в сфере безопасности SSC.

В то время как США начали процесс перехода от жестких универсальных требований к риск-ориентированной модели, приняв указ №14028 о модернизации практик кибербезопасности в федеральных учреждениях США (Improving the Nation’s Cybersecurity) от 2021 года, который фактически стал основой обновленной национальной стратегии кибербезопасности и некоторых законов и нормативных актов, регулирующих сферу кибербезопасности в США, ЕС напротив, ввел юридически обязательные и детализированные требования путем принятия «Закона о киберустойчивости» (Cyber Resilience Act, CRA).

Указ №14028, способствовал повышению осведомленности о SBOM в отрасли и стал отправной точкой в разработке «фреймворка» для безопасного ПО – Secure Software Development Framework (SSDF), а также принятию меморандума M-22-18, предписывающего федеральным агентствам США получать от поставщиков ПО самоаттестацию (self-attestation) о соответствии стандарту SSDF.

В январе 2026 года Административно-бюджетное управление США (Office of Management and Budget, OMB) выпустило новый меморандум M-26-05, который полностью отменил предыдущий – M-22-18. Причиной отмены называлась «универсальная форма аттестации, отвлекающая агентства от разработки индивидуальных требований к обеспечению безопасности и не учитывающая угрозы от небезопасного цифрового оборудования».

Целями нового документа являются:

• Внедрение риск-ориентированного подхода к обеспечению безопасности программного обеспечения и оборудования.

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

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

Также новый меморандум требует от федеральных агентств:

• Ведения и периодического обновления полного реестра программного и аппаратного обеспечения.

• Разработки собственных политик и процессов обеспечения безопасности, основанных на оценке рисков и потребностях.

При этом агентства могут требовать от поставщиков ПО спецификации SBOM по запросу, но это не является универсальным требованием. Использование единой формы аттестации (Common Form), разработанной CISA, стало необязательным.

Такое ослабление требований распространяется не на все отрасли.

В отличие от общего смягчения, в строго регулируемых отраслях требования только ужесточаются:

• Управление по санитарному надзору за качеством пищевых продуктов и медикаментов (Food and Drug Administration, FDA) на протяжении нескольких лет требует предоставления полного SBOM для всех цифровых устройств при подаче заявки на допуск к рынку. Последнее обновление руководства состоялось в июне 2025 года и стало строгим условием для всех поставщиков.

• В «Закон о продуктах питания, лекарствах и косметике» (Federal Food, Drug, and Cosmetic Act) был добавлен раздел 524B, целью которого является защита безопасности пациентов, конфиденциальности и целостности их данных. Он направлен на снижение рисков, связанных с кибербезопасностью медицинских устройств, которые могут быть подвержены кибератакам.

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

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

Законодательная инициатива ЕС – «Закон о киберустойчивости» (Cyber Resilience Act 2024/2847, CRA), который официально вступил в силу 11 декабря 2024 года, дополняет «Директиву 2022/2555 о мерах по обеспечению высокого общего уровня кибербезопасности на территории ЕС» (Network and Information Security Directive, NIS2) в части, касающейся обеспечения кибербезопасности производимой и реализуемой на территории ЕС цифровой продукции, включая программное обеспечение.

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

CRA охватывает широкий спектр устройств, которые выводятся на рынок и предназначены для европейских потребителей, независимо от места их производства, включая устройства Интернета вещей (Internet of Things, IoT), портативные компьютеры и смартфоны, а также компоненты, предназначенные для интеграции в эти продукты.

Исключения коснутся только определенных категорий, в отношении которых уже действуют строгие требования кибербезопасности: это медицинское оборудование, системы безопасности транспортных средств, гражданской авиации, оборудование для обеспечения национальной безопасности и военного сектора. Аналогичные исключения также относятся к облачным сервисам, таким как «программное обеспечение как услуга» (Software as a Service, SaaS), и к бесплатному программному обеспечению с открытым исходным кодом (Free and open-source software, FOSS), которые были разработаны или поставлялись вне коммерческой деятельности.

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

Также законом предусматривается создание единой централизованной платформы сбора данных по отчетности, упрощающей процесс обмена информацией об инцидентах между CSIRT государств-членов ЕС.

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

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

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

Категория «критически важных» продуктов подразделяется на два класса:

· К первому классу относятся: браузеры, менеджеры паролей, антивирусные программы, межсетевые экраны, виртуальные частные сети (VPN), средства управления сетью, системы, физические сетевые интерфейсы, маршрутизаторы и микросхемы, используемые для оборудования, подпадающего под действие Директивы NIS2. В эту же категорию входят все операционные системы, микропроцессоры и промышленные устройства IoT, не относящиеся ко второму классу.

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

Для продуктов первого класса производители обязаны получить сертификат кибербезопасности в соответствии с европейской системой сертификации кибербезопасности и законом ЕС о кибербезопасности (EU Cybersecurity Act).

Оценку продуктов второго класса будут проводить независимые органы по оценке соответствия (Conformity Assessment Bodies, CAB).

Несоблюдение закона влечет за собой наказание в виде наложения административных штрафов:

· Максимальный штраф за нарушение основных требований (включая обязательства по отчетности) составляет сумму до 15 млн евро или, в случае предприятия, до 2,5% от общего мирового годового оборота за предыдущий финансовый год;

· Предоставление недостоверной, неполной или вводящей в заблуждение информации уполномоченным органам и органам надзора за рынком может повлечь за собой административные штрафы в размере до 5 млн евро или, в случае предприятия, до 1% от его общего мирового годового оборота за предыдущий финансовый год;

· Другие нарушения требований закона могут повлечь за собой административные штрафы на сумму до 10 млн евро или, в случае предприятия, до 2% от его общего мирового годового оборота за предыдущий финансовый год.

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

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

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

Важнейший нюанс для американских компаний: CRA имеет экстерриториальный характер, и если компания поставляет ПО (включая SaaS и мобильные приложения) на рынок ЕС – независимо от места своей регистрации – она обязана соблюдать требования CRA. Это означает, что американские стартапы, продающие приложения в App Store Европы, подпадают под действие европейского закона.

Для всех компаний, поставляющих ПО на территорию ЕС:

• После 11 сентября 2027 года продукция без соответствия «Закону о киберустойчивости» просто не сможет быть реализована;

• К сентябрю 2026 года компаниям необходимо разработать процессы и методы сообщения об инцидентах и обработки уязвимостей:

· Предупреждение в течение 24 часов после обнаружения.

· Полное уведомление в течение 72 часов.

· Итоговый отчет в течение 14 дней после выпуска исправления (для активно эксплуатируемых уязвимостей).

Таким образом, США движутся по пути смягчения и дерегуляции (отказ от универсальной аттестации), в то время как ЕС создает один из самых строгих в мире режимов регулирования цепочек поставок ПО с обязательной оценкой соответствия.

Крупный бизнес больше не сможет позволить себе единую глобальную IT-инфраструктуру. Придется поддерживать разделение на два стека и подстраиваться под требования нормативной среды для США и ЕС.

Несмотря на то, что спецификация SBOM в США стала опциональной (по запросу) для федеральных агентств, в ЕС она является жестким требованием для допуска на рынок. Поставщики, ориентированные на глобальный рынок, вынуждены будут внедрять автоматическую генерацию и верификацию SBOM уже в 2026 году, чтобы успеть к полному вступлению в силу «Закона о киберустойчивости» в 2027 году.

Для стартапов и среднего бизнеса (особенно американского, не привыкшего к европейской регуляторике) CRA может стать непреодолимым барьером входа на рынок ЕС.