Атаки через цепочки поставок программного кода — не выдумки и не гипотезы, прецеденты уже были. Технологии безопасной разработки дают возможность не допустить такие атаки или выявить их на ранней стадии. О трендах и лучших практиках говорили на днях на конференции «День безопасной разработки ПО».
- Введение
- Долгий путь к стандартам
- Практический опыт проектов
- Основные трудности и пути их решения
- Что дает внедрение
- Выводы
Введение
Сторонний код используется в большей части программных продуктов. Это в равной степени относится как к мировому, так и к российскому рынку. Так, по данным исследования компании Tidelift, только компоненты с открытым исходным кодом применяются в 92% разработок.
Оценки ситуации в России разнятся. Так, руководитель комитета по информационной безопасности АРПП «Отечественный софт», директор по стратегии и развитию технологий Axiom JDK Роман Карпов, открывая конференцию «День безопасной разработки ПО», привел данные, согласно которым доля заимствованного кода в Java-проектах составляет около 90%, тогда как среди кода на C / C++ она лишь около 60%. Заместитель начальника второго управления Федеральной службы по техническому и экспортному контролю (ФСТЭК России) Ирина Гефнер заявила о том, что 90% сертифицированных средств защиты информации содержат открытый код.
Следовательно, заимствованный код может быть использован для атак. Так, за 2022–2023 годы участники сообщества «Техдирский клуб» выявили без малого 40 программных компонентов, которые содержали недекларируемые возможности (НДВ), активизируемые тогда, когда запуск производился на территории России или Белоруссии. Некоторые из этих НДВ были деструктивными, например, шифрование или удаление данных.
Не стоит забывать и об уязвимостях, которых тоже немало. Директор центра оценки соответствия и тестирования НПО «Эшелон» Сас Арустамян привел статистику, согласно которой только критические уязвимости содержатся в 47% ИТ-систем объектов критической информационной инфраструктуры. Согласно данным ФСТЭК России, в 100 государственных информационных системах содержится более 1000 уязвимостей, причем большая их часть относится к высокому и критическому уровням (рис. 1).
Рисунок 1. Результаты работы ФСТЭК России по повышению защищенности ГИС
Использование технологий безопасной разработки позволяет выявлять риски на ранней стадии. Это уже вполне зрелая технология, внедрение которой приносит реальную пользу.
Как подчеркнул заведующий лабораторией ИСП РАН, член ТК 362, к.ф.-м.н. Вартан Падарян на конференции «День безопасной разработки ПО», что необходимо контролировать не только заимствованный свободный, но и проприетарный код, в том числе созданный внутри компании ранее (рис. 2). Ситуация с его качеством также оставляет желать лучшего.
Рисунок 2. Цепочки поставок в процессе разработки ПО
Серьезным новым вызовом является использование искусственного интеллекта (ИИ) для работы с кодом. Как оказалось, генеративный ИИ выдает очень низкокачественный код, воспроизводя ошибки и уязвимости. Основатель компании CodeScoring Алексей Смирнов на конференции «День безопасной разработки ПО» привел результаты целого ряда исследований, согласно которым ИИ-ассистенты воспроизводят до трети уязвимостей. Кроме того, результатом галлюцинаций ИИ при работе с кодом становятся ссылки на несуществующие библиотеки, причем в 58% случаев они воспроизводятся заново. Это открывает весьма широкие возможности для злоумышленников. А участники круглого стола на конференции OS Day 2025 обратили внимание на склонность ИИ к логическим ошибкам.
Долгий путь к стандартам
Первые версии стандартов по безопасной разработке появились на рубеже 2000-х и 2010-х годов. Чуть раньше вышла первая версия американского стандарта от NIST, чуть позже — от OWASP, где тон задают европейцы.
Первая версия российского стандарта ГОСТ 56939 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» (часто просто РБПО) была утверждена в 2016 году. Как признала заместитель начальника 2-го управления ФСТЭК России Ирина Гефнер в эфире AM Live «Как внедрить процессы разработки программного обеспечения», отрасль встретила его, скорее, с непониманием. Однако ИБ-вендоры стандарт приняли и начали использовать.
В 2022 году началась работа над новой версией стандарта. В ходе работы было внесено без малого 560 различных предложений и дополнений, из которых более 300 было принято. Самым значительным новшеством стал обязательный внешний аудит.
Как отметила руководитель центра сертификации и соответствия стандартам «Лаборатории Касперского» Карина Нападовская, выступая на IX конференции OS Day 2024, основной акцент был сделан на процессы, а не на меры. Также новая версия направлена на соответствие требованиям регуляторов, причем не только российских, и учитывает лучшие практики. Вартан Падарян на том же мероприятии сравнил новшества с тем, как если бы поваров не просто заставляли мыть руки, а следили за их реальной чистотой.
Ирина Гефнер на конференции «День безопасной разработки ПО» довольно высоко оценила то, как идет процесс разработки стандартов в области безопасной разработки. Росстандарт утвердил 5 стандартов в данной сфере, и еще 4 находятся в высокой степени готовности (рис. 3). Они будут утверждены или до конца 2025 года, как методические рекомендации и требования по композиционному анализу кода, или в самом начале 2026.
Рисунок 3. Результаты работы Подкомитета ТК 362
Практический опыт проектов
Как отметил Вартан Падарян, с технической точки зрения проект внедрения безопасной разработки сводится к трем задачам:
- Построение перечня зависимостей, файлов, библиотек и других элементов, имеющих отношение к конкретному сервису или инфраструктуре целиком (Software Bill of Materials, SBoM). Оно может проводиться вручную или с помощью инструментария.
- Подтверждение изолированной сборки.
- Создание контролируемого репозитория.
Однако, по его словам, наибольший объём работ связан с подготовкой разнообразной документации, прежде всего описаний внутренних процессов, компонентов инфраструктуры и разрабатываемого ПО. Отдельного описания требуют сведения о договорных обязательствах со сторонними поставщиками и элементы инфраструктуры, вероятные с точки зрения НДВ, включая элементы, зависящие от сторонних поставщиков.
По мнению зрителей эфира AM Live, среди всех технологических средств, используемых в ходе безопасной разработки, наиболее эффективны средства композиционного, статического и динамического анализа (рис. 4). Больше всего голосов собрал статический анализ (28% голосов). Владелец продукта SASTAV (ITD Group) Антон Михайлов в ходе эфира AM Live отметил, что многие при внедрении технических средств ограничиваются только такими инструментами.
Рисунок 4. Какая из технологий РБПО в наибольшей степени повышает качество процессов?
Многие компании начинают работы по проекту с аудита существующей инфраструктуры разработки, который проводит независимая специализированная компания. По результатам такого обследования, который проводят специалисты, у которых, что называется, не замылен глаз, становятся видны многие узкие места.
«Начать лучше с проведения независимого аудита процессов безопасной разработки, результатами которого могут быть независимая оценка количества реализованных процессов РБПО и степени их внедрения, а также рекомендации по устранению недостатков, рекомендации по совершенствованию процессов РБПО», — порекомендовал начальник отдела безопасной разработки «Кода Безопасности» Дмитрий Подшибякин, делясь опытом построения процесса безопасной разработки в компании.
Технический директор «Ростелеком ИТ» Кирилл Пихтовников поделился опытом создания внутреннего репозитория ПО «РТК Феникс» в компании. Он особо отметил, что для внутренних разработчиков, особенно если их много, далеко не всегда целесообразно разворачивать полноценный комплекс средств безопасной разработки. Это нужно делать только для тех, кто занят написанием действительно критического ПО. Для остальных групп разработчиков это часто долго и дорого, причем реальная отдача не покрывает издержек.
Однако развертывание репозитория позволило решить задачу проверки внешнего ПО с открытым кодом на наличие программных зловредов и прочих угроз. В итоге в продуктивную среду попадают только проверенные пакеты.
Рисунок 5. Репозиторий «РТК Феникс» в инфраструктуре разработки ПО в «Ростелекоме»
Основные трудности и пути их решения
Как отмечали практически все участники конференции, процесс внедрения технологий безопасной разработки является объективно сложным и довольно длительным. Нередко он занимает полтора–два года. Самый быстрый проект занял около 9 месяцев.
Как подчеркнула Ирина Гефнер, далеко не все компании объективно готовы к процессу сертификации процесса разработки. Кроме того, он действительно сложный и трудоёмкий. Количество ошибок в процессе внедрения очень велико, при этом они в основном типовые.
Сас Арустамян назвал главными препятствиями на пути внедрения РБПО следующие:
- Нехватка компетенций (в частности, выстраивать модель угроз и определять возможную площадь атаки) и специалистов.
- Отсутствие финансирования.
- Неправильно настроенные политики ИБ.
- Неверная расстановка приоритетов между сроками и безопасностью.
- Сопротивление разработчиков из-за усложнения процессов.
Выходом тут является вовлечение руководства в процесс внедрения безопасной разработки. Только так можно добиться выделения финансирования и ответственных за проект.
Не менее важно, как подчеркнула ведущий специалист по РБПО, руководитель группы аудита «НТЦ Фобос-НТ» Елена Быханова, определить цель проекта. Для этого она предложила честно ответить на вопрос о том, для кого делается внедрение, для регулятора или для себя. От ответа на него зависит расстановка приоритетов в ходе проекта, что очень сильно влияет на его успех. При этом, как обратила внимание Елена Быханова, сама ФСТЭК России исходит из того, что компания осуществляет внедрение прежде всего для собственных нужд, а не потому, что так установил регулятор.
Серьезной проблемой является дефицит кадров. Как отметил начальник отдела безопасной разработки СИГМА (внутреннего ИТ-подрядчика «Интер РАО») Виталий Насонов, за последние два года потребность бизнеса в специалистах по безопасности приложений выросла на 48%, тогда как выпуск соответствующих специалистов практически не увеличился. На рынке образовательных услуг мало соответствующих курсов.
В таких условиях единственным выходом оказалось готовить специалистов самостоятельно. Как отметил Виталий Насонов, уже через 3 месяца новичка без опыта работы можно научить решать реальные задачи в области безопасной разработки (рис. 6). Но этого можно добиться только при условии наличия ментора. Он может быть как внутренним специалистом, так и приглашенным. Не менее важно учить на реальных задачах, от этого зависит 80% успеха.
От самого кандидата требуется, прежде всего, умение учиться. Важны также умения реализовывать инициативы и доносить собственное видение ситуации. Они, как подчеркнул Виталий Насонов, могут оказаться решающими при общении как с бизнесом, так и с разработчиками.
Рисунок 6. Этапы обучения молодого специалиста навыкам безопасной разработки
Для плохо подготовленных кадров серьезной сложностью может оказаться также большой поток предупреждений о возможных ошибках и уязвимостях. Это часто усугубляет непонимание между командами разработки и группой AppSec. Между тем, как отметил руководитель безопасной разработки Yandex Cloud Алексей Вишняков, поток таких сообщений можно многократно снизить правильной настройкой сканеров. Как отметил представитель Yandex Cloud в выступлении на «Дне безопасной разработки», в «Яндексе» выделили критически важные контроли, а остальные деактивировали в настройках сканеров. В результате количество срабатываний снизилось в 5 раз.
Однако практически все участники форума АРПП «Отечественный софт» сетовали на большое количество ложных срабатываний, и отделение их от реальных проблем является сложной и трудоемкой работой. А в случае применения инструментов фаззингового анализа количество ложноположительных срабатываний еще больше, чем дают средства статического анализа.
Что дает внедрение
Как отметил технический директор «Кода Безопасности» Дмитрий Зрячих, основной результат внедрения средств безопасной разработки в том, что стоимость устранения ошибки на стадии разработки даже не в разы, а как минимум на порядок ниже, чем если она будет обнаружена в процессе эксплуатации.
Елена Быханова добавляет к этому еще такие выгоды, которые может дать компании внедрение методов безопасной разработки:
- Повышение качества контроля над процессами.
- Сокращение релизного цикла в среднем в 3–4 раза.
- Повышение качества кода, и, как следствие, повышение конкурентоспособности компании.
Алексей Вишняков назвал среди эффектов внедрения также снижение операционных затрат, а также упрощение интеграции новых механизмов контроля в процесс разработки.
С точки зрения генерального директора «Аладдин Р.Д.» Сергея Груздева, создание среды безопасной разработки выводит процесс создания ПО на новый уровень, максимальный для существующих условий. Тут безопасность ПО, включая заимствованный код, подтверждает третья сторона. Пока наличие такого подтверждения требуется для объектов критической информационной инфраструктуры, нужд обороны и предприятий ОПК, но уже в самом скором будущем такие же требования придется соблюдать тем, кто является исполнителями работ по построению государственных информационных систем. Также схожие требования начинают предъявлять многие крупные компании.
Однако, как предупредила Елена Быханова, отдача от внедрения начнет превышать затраты на выстраивание мер по безопасной разработке лишь спустя приблизительно два года после старта работ по проекту. Причем двухгодичный срок — довольно оптимистичная оценка, особенно если брать за точку отсчета замысел проекта, а не формальное начало его реализации.
Выводы
Внедрение технологий безопасной разработки является важным шагом, который позволит не только вывести ситуацию с обеспечением ИБ на принципиально новый уровень, но и решить целый ряд довольно насущных проблем, которые стоят перед разработчиками. Прежде всего, это повышение качества кода. Не менее значимо, особенно для ИБ-вендоров, сокращение сроков сертификации продукции.
Кроме того, заказчики, особенно государственные и крупные корпоративные, для защиты цепочек поставок уже в ближайшем времени начнут требовать от подрядчиков гарантий безопасности кода. Их дать может только подтвержденное регулятором или аудитором соответствие стандартам РБПО.
