Контакты
Подписка 2026

Автоматизация и экономика для обеспечения жизненного цикла безопасного ПО

Борис Позин, 30/10/24

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

Автор: Борис Позин, технический директор ЗАО "ЕС-лизинг", д.т.н., профессор базовой кафедры “Информационно-аналитические системы” МИЭМ НИУ ВШЭ, главный научный сотрудник ИСП РАН

ris1-Oct-30-2024-09-22-36-5256-AM

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

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

Нормативная база (ГОСТ Р 56939–2016 и последующие по этому направлению от ТК 362) и уровень освоения специалистами отрасли современных методов разработки предполагают, что существенное повышение качества обнаружения уязвимостей и недекларированных возможностей может быть достигнуто на основе применением комплекса инструментальных средств как разработчиками, так и специалистами, осуществляющими интеграцию, эксплуатацию и сопровождение прикладного ПО.

Стратегически внедрение автоматизированного технологического процесса позволит:

  1. Получить инструменты для быстрого и глубокого анализа наличия уязвимостей в разрабатываемом, сопровождаемом или развиваемом приложении, одновременно повысив квалификацию персонала, который этим занимается.
  2. Разработать и реализовать системное решение в области реализации доверенного ПО.
  3. Поставить под контроль количество и качество заимствованных компонентов свободного ПО и используемых библиотек Open Source.

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

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

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

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

Возможен ли другой подход?

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

Дополнительно можно получить от интегратора курсы переподготовки и пилотные проекты на собственных примерах.

Такое решение реализовано в рамках разработанной совместно компанией ЕС-лизинг (интегратор) и ИСП РАН автоматизированной системы "Центр Кибербезопасности" (АС ЦКБ). АС ЦКБ является результатом интеграции преимущественно отечественных инструментальных средств компаний ИСП РАН, "Профископ", работающих в средах ОС Альт и Astra Linux, а также включает необходимые официальные версии компиляторов С, С++, Java (Axiom JDK), Go, Python. В качестве СУБД используется PostgreSQL Enterprise.

АС ЦКБ оснащена комплектом документации, в том числе технологической. Разработаны учебные курсы по применению основных инструментальных средств, готовится их версия для преподавания специалистами МИЭМ НИУ ВШЭ с выдачей государственных сертификатов о прохождении программ обучения и переподготовки. В процессе обучения все участники работают на защищенном стенде и используют тестовые примеры на вышеуказанных языках общим объемом порядка 5,5 млн строк.

Темы:ИСП РАНБезопасная разработкаЖурнал "Информационная безопасность" №4, 2024РБПО
Практика защиты персональных данных в 2027 году: требования и инструменты. 14 октября на Форуме ITSEC 2026
Полное расписание мероприятий Форума ITSEC 2026 →

Программа мероприятий
для руководителей и специалистов
по защите информации

Посетить
Статьи по той же темеСтатьи по той же теме

  • SafeERP – новая архитектура защиты бизнес-приложений
    Римма Кулешова, менеджер продукта SafeERP компании “Газинформсервис”
    Признание ERP-систем частью КИИ меняет подход к безопасности бизнес-приложений. На первый план выходят вопросы непрерывного контроля, управления рисками и прозрачности процессов внутри 1С и SAP. Римма Кулешова рассказывает о новой модели защиты ERP и о том, почему безопасность бизнес-логики становится отдельным направлением ИБ.
  • Безопасность нельзя добавить постфактум. Практика DevSecOps от УЦСБ
    Евгений Тодышев, руководитель направления “Безопасная разработка” УЦСБ
    Безопасная разработка в промышленности требует постоянного поиска баланса между требованиями регуляторов, скоростью вывода продукта и жесткими ограничениями встраиваемых систем. Руководитель направления “Безопасная разработка” УЦСБ Евгений Тодышев рассказал, какие компромиссы неизбежны, а какие вредны, почему безопасность нельзя добавлять постфактум, как встроить DevSecOps в легаси и в каких случаях сервисная модель выгоднее собственной команды.
  • ИИ в аудите смарт-контрактов и проблема масштаба
    Александр Подобных, Независимый эксперт по ИБ в SICP.ueba.su
    Смарт-контракты пишутся быстрее, чем их успевают нормально проверять. Ошибки при этом каждый раз разные – от простых просчетов в логике до сложных сценариев с оракулами и внешними протоколами. Разбор каждого инцидента занимает время, а их становится все больше и больше. В какой-то момент проблема сводится уже не к сложности, а к объему: ручной аудит не успевает покрывать все, что появляется.
  • Когда платформа становится безопаснее, чем безопасник
    Александр Трифанов, руководитель направления Application Security, "Авито"
    В крупных компаниях стало слишком много инженерии. Команды растут, микросервисы множатся, инфраструктура усложняется, а вместе с ней – и стоимость ее поддержки. Поэтому идея внутренних платформ выглядит естественным ответом на хаос. То, что раньше требовало согласований и ручных настроек, теперь превращается в сервис – Platform as a Service, Publication as a Service, Admin as a Service.
  • Как инструменты разработки становятся средствами для кражи криптоактивов
    Дмитрий Пойда, аналитик по расследованиям AML/KYT провайдера “Шард”
    Количество атак на цепочку поставок программного обеспечения в прошлом году выросло на 156% по сравнению с годом ранее, по данным исследования Sonatype. Разберемся, как эта угроза проявляет себя в мире криптовалют, и почему привычные инструменты разработчика становятся орудием злоумышленников.
  • Почему DevSecOps не приживается в АСУ ТП и MES – и как его адаптировать
    Артем Пузанков, руководитель группы внедрения практик безопасной разработки Positive Technologies
    Внедрение DevSecOps стало нормой для ИТ-разработки, однако в промышленных системах этот подход сталкивается с серьезными ограничениями. Приоритеты в этих средах – надежность, непрерывность работы и соблюдение отраслевых стандартов – изначально противоречат динамике CI/CD и гибкости DevOps. Дополнительные препятствия создают закрытые контуры, устаревшие технологии и фрагментированная структура ответственности.

Хотите участвовать?

Выберите вариант!

КАЛЕНДАРЬ МЕРОПРИЯТИЙ 2026
ПОСЕТИТЬ МЕРОПРИЯТИЯ
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ АВТОРОМ
13-14 октября приглашаем экспертов и практиков выступить на Форуме ITSEC 2026!
Отправить заявку на участие →

More...
ТБ Форум 2026
13 октября. Защищенный удаленный доступ на Форуме ITSEC 2026
Регистрация открыта →

More...