Российские компании активно внедряют технологии безопасной разработки. Причём явной тенденцией последнего года стало подключение к данному процессу подрядчиков и партнёров. Всё это обсуждали участники очередного «Дня безопасной разработки ПО».
- Введение
- Открытый код как элемент атаки
- РБПО как предохранитель от атак на цепочки поставок
- Неочевидный эффект от РБПО
- Препятствия и ограничения
- Выводы
Введение
«День безопасной разработки ПО» является отраслевой ежегодной конференцией, традиционно проводимой на площадке Открытой конференции Института системного программирования РАН им. В. П. Иванникова. В текущем году она проводилась в пятый раз.
Как отметил модератор форума, глава комитета по информационной безопасности Ассоциации разработчиков программных продуктов (АРПП) «Отечественный софт» и — он же — директор по стратегии и развитию технологий Axiom JDK Роман Карпов, масштаб мероприятия заметно расширился в последние годы. За это время уровень проникновения технологий разработки безопасного ПО (РБПО) вырос почти на порядок. Вырастало не только количество компаний, приступивших к внедрению, но и глубина проникновения технологий и подходов.
В итоге, по оценке Романа Карпова, около 20 % российских разработчиков достигло полной интеграции технологий DevSecOps (Development, Security, Operations) в конвейер разработки. Особенно это касается таких сегментов, как создание ИБ-продуктов и системного ПО, где уровень проникновения РБПО практически полный.
Причин для роста практического интереса к технологиям РБПО много. Это и требования регуляторов, и совершенствование стандартов, ставших более понятными и выполнимыми, и необходимость контроля кода от внешних поставщиков, будь то заказные разработки партнёров или библиотеки с открытым кодом. Однако остаётся много проблем, не всегда легко решаемых.
Открытый код как элемент атаки
По данным АРПП «Отечественный софт», которые были озвучены на конференции, в России 77 % разработок использует готовые компоненты. Это, что называется, средняя температура по больнице. Удельный вес заимствованного кода, по некоторым данным, превышает 90 %.
Однако в стороннем коде часто скрываются различные проблемы, главные из которых – уязвимости и разные недекларируемые возможности. Эти проблемы одинаково опасны. Однако их можно и нужно устранять, для чего технологии безопасной разработки и применяются.
В России резкий рост интереса к РБПО начал проявляться с 2022 года, когда резко участились случаи политически мотивированных недекларируемых возможностей (НДВ), которые разработчики включали в разнообразные компоненты с открытым кодом. Первым стал Брендон Нозаки Миллер (Brandon Nozaki Miller), который внедрил в один из популярных модулей Node.js компоненты, которые уничтожали данные в том случае, если компонент запускался на территории России или Беларуси (рис. 1). Многие ограничивались выводом политических лозунгов и видеороликов.
По данным сообщества «Техдирский клуб», всего было обнаружено около 40 пакетов с такими НДВ. Среди них были и вредоносные, например, уничтожающие данные или передающие их на удалённый сервер.
Рисунок 1. Сообщение из пакета Peacenotwar Брендона Нозаки Миллера
Впрочем, многие атаки с использованием заражённых компонентов были направлены на неопределённый круг людей и компаний. До 40 % проектов в экосистеме JavaScript сталкивались с попытками загрузки вредоносных пакетов.
В ноябре 2025 года началась атака, названная Shai-Hulud 2. Она поражает разработчиков и инфраструктуру для работы с кодом по всему миру. Ей охвачено, по данным исследователей компании Wiz, более 30 тыс. репозиториев (рис. 2).
Рисунок 2. Распространённость следов атаки Shai-Hulud 2 на основных репозиториях кода
Основатель CodeScoring Алексей Смирнов оценил рост количества вредоносных версий пакетов за 2025 год в 1000 %.
Дополнительным фактором риска, который активно используют злоумышленники, стали галлюцинации генеративного искусственного интеллекта. Применительно к разработке они проявляются в том, что ассистенты предлагают использовать несуществующие библиотеки, что происходит с каждой пятой рекомендацией. Но эти галлюцинации в 58 % случаев ссылаются на одни и те же библиотеки, чем пользуются злоумышленники, подсовывая вредоносные компоненты под нужными названиями, которые хорошо известны.
Не менее остро, по оценке Алексея Смирнова, обстоит дело с уязвимостями. Так, например, от библиотек с неустранённой уязвимостью Log4Shell, обнаруженной ещё в 2021 году, до сих пор зависит более 15 тыс. пакетов. С уязвимостями, которые были выявлены позже, ситуация ещё более тяжёлая.
РБПО как предохранитель от атак на цепочки поставок
Как отметил Алексей Смирнов, для того, чтобы предохраниться от атак на цепочки поставок при использовании компонентов с открытым кодом, необходимо как минимум фиксировать версии используемых библиотек. Однако использование технологий разработки безопасного ПО — более гибкое, и позволяет закрыть существенно больше потенциальных рисков (рис. 3, 4).
Рисунок 3. Пути предотвращения атак на цепочки поставок ПО
Рисунок 4. Основные категории угроз процесса разработки (источник – Cloud.ru)
Что немаловажно, внедрение РБПО позволяет выстроить культуру безопасности в компании. Без этого, как подчеркнул директор центра оценки соответствия и тестирования НПО «Эшелон» Сас Арустамян, невозможно добиться того, чтобы ПО было безопасным изначально.
Он обратил внимание на то, что РБПО является процессом, а не технологией (рис. 5). Как предупредил Сас Арустамян со ссылкой на личный опыт, без осознания ценности в создании безопасного кода разработчики будут совершать ошибки. И в целом проверка кода должна стать естественной частью деятельности разработчика, что требует серьёзных организационных усилий, включая вовлечение высшего руководства. Однако, несмотря на все вложения, инвестиции в РБПО полностью окупаются.
Рисунок 5. РБПО как процесс и его элементы
К своему РБПО-конвейеру можно подключать не только внутренних разработчиков, но и подрядчиков. О таком опыте рассказал начальник отдела цифровой надёжности ПО компании «Гринатом» Дмитрий Павлов. В их организации проект внедрения технологий безопасной разработки стартовал ещё в 2022 году во время массовых атак на цепочки поставок. Со временем пришли к тому, чтобы подключить к выстроенной технологической платформе внешних разработчиков. Как отметил Дмитрий, на это ушло меньше усилий, чем на то, чтобы преодолеть сопротивление собственного персонала. Именно его он назвал основным препятствием в ходе реализации таких проектов.
Тем не менее внедрение технологий безопасной разработки позволило добиться заметных успехов. В частности, созданный ещё в 2023 году Консорциум для совместных исследований безопасности ядра Linux, куда вошли более 20 компаний, объединил усилия отечественных разработчиков общесистемного ПО, что быстро дало положительный эффект.
«Сначала шла дискуссия о том, что надёжнее: западный вендор или open source. Со временем пришло осознание, что зарубежные продукты несут риски и могут использоваться для атак и встраивания деструктивных элементов. На этом фоне важную роль сыграл open source, поддерживаемый российскими разработчиками. Импортозамещение стало чем-то большим: сегодня создаются решения на отечественных компонентах, и делается это безопасно. В этом большая заслуга сообщества, которое объединилось вокруг создания российского ядра Linux при ИСП РАН, и многих участников АРПП, поддерживающих принципы безопасной разработки», — отметил директор Центра компетенций по импортозамещению в сфере ИКТ Илья Массух.
Неочевидный эффект от РБПО
Одним улучшением качества кода и устранением уязвимостей эффект от внедрения РБПО не ограничивается. В ходе выступления, посвящённого выработке единых рекомендаций по безопасной разработке для нефтегазовой отрасли, руководитель по развитию АНО «Консорциум технологической независимости ИПО» Борис Изюмов назвал сохранение коммерческой тайны одной из ключевых задач кибербезопасности.
Между тем разработчики не всегда понимают, что данные, которые составляют коммерческую тайну, сотрудник без нужного уровня допуска может без больших усилий получить, собрав их по частям. На предотвращение такой ситуации направлены в том числе усилия «Консорциума технологической независимости ИПО» по адаптации технологий безопасной разработки.
Рисунок 6. Возможные пути получения данных, составляющих коммерческую тайну
Также Борис Изюмов напомнил, что отрасль относится к сфере критической информационной инфраструктуры (КИИ). Плюс ко всему, в ней активно внедряется искусственный интеллект, и необходимо обеспечить широкий спектр задач по ML SecOps (Machine Learning Security Operations, операции по безопасности машинного обучения), включая защиту данных от возможного «отравления».
Лидер направления «ИТ в фармацевтике» передовой инженерной школы МГУ им. Ломоносова, участник ИЦК «Химия и Фармацевтика» Оксана Гаврилова рассказала о том, как можно применить подходы РБПО к построению безопасных компьютеризированных систем (рис. 7) по стандартам, регламентирующим работу высокорегулируемых отраслей. К таким отраслям относятся фармацевтика, химическая промышленность и все виды транспортного машиностроения (автомобиле-, авиа-, судостроение, производство железнодорожной техники).
Рисунок 7. Основные компоненты компьютеризированной системы в высокорегулируемых отраслях
Как отметила Гаврилова, требования государственных и отраслевых регуляторов направлены не только на защиту от киберугроз, но и на то, чтобы вся система корректно и предсказуемо работала в любых условиях, не влияя на технологические процессы и сводя к минимуму последствия ошибок. Для фармацевтики, например, многие такие моменты регламентирует группа стандартов GxP, для авиации — ARP4754A, DO-178C и DO-254. Эксперт призвала к унификации отраслевых стандартов и использованию их при создании ПО для высокорегулируемых отраслей. Такая унификация позволит повысить качество ПО и будет способствовать его безопасности от внешних угроз.
Надо отметить, что проблема уязвимостей в ПО для автомобилей также стоит остро. В 2024 году были выявлены серьёзные недочёты в бортовых системах автомобилей Kia, которые позволяли получить доступ ко многим данным владельцев. В России компания «ГЛОНАСС» обнаружила опасные уязвимости в электробусах и грузовиках, которые позволяют вмешиваться в управление ТС или вызывать возгорание батарей.
Препятствия и ограничения
По мнению участников конференции, основными проблемами при внедрении РБПО являются нехватка кадров и сопротивление персонала в ходе проектов. Плюс ко всему, проекты внедрения РБПО — сложные и длительные. Технические проблемы — например, большое количество ложных срабатываний — оказались вполне решаемы.
Кадровая проблема — существенно более сложная. Как напомнила представитель органа по сертификации ИСП РАН Елена Маньжова, любой проект внедрения РБПО должен начинаться с разработки регламентов. Во многих компаниях с этим хроническая проблема из-за жёсткого дефицита технических писателей. Поэтому так важна методическая помощь, в том числе подготовка типовых пакетов документов, которые организации могут самостоятельно доработать под свою специфику. Выступление Елены как раз было посвящено представлению такого типового пакета документов.
Выступление руководителя продукта AppSec.Track компании AppSec Solutions Константина Крючкова было посвящено экономике проектов создания защищённого репозитория кода. Константин разделил уровень затрат на 2 компоненты: денежную и потребность в дополнительном персонале (рис. 8). В итоге он рекомендовал хорошо подумать перед тем, как идти на такой шаг, ведь это действие целесообразно только для крупных компаний или консорциумов. Минимальные затраты на создание подобного репозитория составляют 5 млн рублей, что посильно далеко не для всех компаний, даже в меру крупных.
Рисунок 8. Затраты на создание защищённого репозитория кода
Сразу несколько выступающих назвали основным препятствием для внедрения РБПО не сопротивление, а непонимание персонала. Дмитрий Павлов в своём выступлении особо отметил, что многие разработчики до сих пор не прошли все стадии принятия изменений по модели Кюблер-Росс, несмотря на то что процесс идёт уже четвёртый год. Именно это, по его оценке, стало главным препятствием.
Сас Арустамян назвал не менее значимым фактором позицию руководителей нижнего и среднего звена. Именно они, по оценке эксперта, вынуждают пропускать тестирования под предлогом возможного срыва сроков. Также многие руководители привыкли считать само выявление уязвимости чем-то из ряда вон выходящим и начинают устраивать разносы тем, кто обнаружил проблему. И донести до них то, что это естественный процесс, бывает не всегда просто, особенно в начале проекта. Тут важна позиция руководства, в том числе высшего.
Выводы
Внедрение технологий разработки становится всё более популярно в России, несмотря на все сложности и препятствия. Применение технологий РБПО помогает решить множество проблем, связанных с обеспечением качества кода, причём не только своего, но и заимствованного, а также заметно упрощает и ускоряет процедуры сертификации. Будет способствовать распространению таких подходов влияние заказчиков и партнёров, а также отраслевое регулирование в целом ряде секторов (химия, фармацевтика, все виды транспортного машиностроения).
Основные сложности — дефицит кадров, сопротивление персонала, довольно высокая стоимость и долгие сроки проектов. Более того, значимость кадровой проблемы рискует вырасти из-за повышения страховых взносов, вследствие чего многие компании прекратили на данный момент наращивать штат.
