Необходимо ввести цифровой паспорт для разработчиков критических ИТ-систем – глава комитета по ИБ ассоциации «Отечественный софт»

Отказ в обслуживании как реализованный риск

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

Второй удар — взрывной рост атак. Россия на определенном этапе стала самой атакуемой страной в мире. Ряд громких атак в этом году, в том числе на крупнейшую авиакомпанию страны, сети аптек и клиник показали, что модель угроз поменялась, и безопасность сегодня становится драйвером импортозамещения. Как отметила Наталья Касперская, председатель правления АРПП «Отечественный софт», президент ГК Infowatch, теперь вопрос «если вдруг нас взломают» кажется устаревшим. Надо вопрос ставить по-другому: «Что мы будем делать, когда положат нашу сеть и отключат наши сервисы или сервера?”

Многие атаки были политизированы, направлены на дестабилизацию работы организаций, особенно связанных с государством или критической инфраструктурой. Поэтому безопасная разработка (Secure-by-Design, DevSecOps, РБПО) перестала быть «рекомендацией» — и стала базовой необходимостью.

Ключевая атака сегодня — атака на цепочку поставок

Ни для кого не секрет, что типичный современный ИТ-продукт содержит тысячи зависимостей. Это библиотеки, пакеты, модули, фреймворки, — компоненты, созданные сторонними командами. Они ускоряют разработку, но создают огромную поверхность атаки.

В последние годы мы видим целенаправленные попытки внедрить вредоносный код в открытые библиотеки: от незаметных вставок в системные утилиты Linux (как в истории с XZ Utils), до компрометации криптографических модулей JavaScript, использовавшихся в финансовых сервисах и блокчейн-платформах. Мир open source перестал быть полностью нейтральным: в нём появились инструменты геотаргетинга, вредоносные модули, срабатывающие только в продуктивной среде, и компоненты с «отложенным эффектом».

ФСТЭК еще пять лет назад начал обязательные проверки средств защиты информации и расширяет требования к разработчикам. Это важный шаг: многие ошибки, которые сегодня приводят к уязвимостям, можно было бы предотвратить при корректной проверке кода.

Кто под ударом: финансы, госсектор и критическая инфраструктура

С точки зрения злоумышленников идеальная цель — топливно-энергетический комплекс. По данным АНО «Цифровая экономика», общее количество объектов КИИ в России превышает 50 тыс., причем более 70% из них расположены на предприятиях ТЭК. Иными словами, защищенность объектов КИИ участников рынка ТЭК означает безопасность почти ¾ всей экономики РФ. Остановка генерации энергетики парализует всё: от бытовой сферы до государственного управления. Однако АСУ ТП работают в закрытых контурах, что усложняет атаки, хотя и не делает их невозможными.

Второй приоритет — финансы. Здесь злоумышленников привлекают и данные транзакций, и клиентские профили, и доступ к операциям. В целом под ударом находятся все предприятия КИИ — транспорт, связь, коммерческая деятельность, телеком. Недавний кейс Тюменской области, пережившей сотни миллионов попыток атак без единого успешного инцидента, показывает: в России уровень киберустойчивости растёт, но давление нарастает ещё быстрее.

Отдельная группа риска — отрасли, которые раньше не считались высокозащищёнными: ритейл, SaaS-сервисы, разработчики пользовательского ПО. Многие из них сталкиваются с DDoS-атаками, кражами данных, внедрением вредоносных зависимостей. Но финансовая логика некоторых компаний ещё не изменилась: штрафы по-прежнему сравниваются с затратами на защиту. Оборотные штрафы должны изменить эту математику.

Безопасная разработка как обязательный производственный процесс

Сегодня подход к безопасной разработке должен строиться на модели TCO (Total Cost of Ownership, совокупная стоимость владения): цена исправления ошибки на этапе разработки и цена той же ошибки на этапе эксплуатации отличаются в десятки раз.

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

Российский рынок активно наращивает инструментарий. Например, ИСП РАН в дополнение к популярному Svace создаёт динамические анализаторы («Блесна», Crusher) и решения для построения поверхности атаки (Natch). Но универсального динамического инструмента пока нет — стек технологий слишком разнообразен. Многие компании вынуждены разрабатывать собственные фаззеры и методы тестирования для высоконагруженных систем. Например, для фазинг-тестирования отечественных Java-технологий используется инструмент Jazzer.

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

Почему проблема уязвимостей растет даже при росте расходов на ИБ

На рынке наблюдается парадокс: с одной стороны, затраты на ИБ увеличиваются, но с другой — количество уязвимостей в корпоративных продуктах растёт. Причин тут можно выделить несколько:

 – лавинообразный рост количества продуктов на открытом ПО,
 – нехватка экспертизы у разработчиков, использующих сторонний код,
 – медленное обновление внутренних систем (79% кода обновляется крайне редко),
 – переоценка «защищенности» закрытых контуров.

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

Именно доверенные репозитории и экспертиза разработчиков в используемых компонентах программного обеспечения помогут снять проблему. Цифровой паспорт ПО (так называемая в мировой практике концепция композиционного анализа SBOM – Software Bill of Materials) позволяет оценить уязвимости и управлять рисками. Поэтому необходимо создать единые правила наполнения и использования доверенных репозиториев ПО и ввести требование цифрового паспорта для разработчиков критических информационных систем.

Почему импортозамещение в ИБ невозможно без импортозамещения в инфраструктуре

Невозможно построить безопасный контур, если фундамент системы зависит от иностранных технологий, чьи обновления, репозитории, ключи подписи и механизмы доставки могут быть недоступны или изменены в любой момент. Речь идёт не только о специализированных средствах защиты, но также о среде исполнения и серверах Java-приложений, операционных системах, контейнеризации, CI/CD-платформах, гипервизорах и системных библиотеках.

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

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

Что дальше: прогнозы на 3–5 лет

1. Рост рынка ИБ будет устойчивым: по результатам 2025 года, объем рынка, по нашим оценкам, достигнет 1 млрд рублей.
   
   
2. Консолидация: сформируется пул основных игроков, предлагающих комплексные экосистемы ПО и безопасности.
   
   
3. Автоматизация и ИИ: необходимая мера при кадровом дефиците и растущей скорости атак.
   
   
4. Укрепление культуры безопасности: кибергигиена, тренинги и моделирование атак станут обязательным элементом защиты.
   
   
5. DevSecOps и РБПО по ГОСТ Р 56939-2024 станут базовым стандартом для всех отраслей.