Регуляторные и технологические предпосылки

Рынок разработки программного обеспечения в России сегодня формируется под влиянием сразу двух групп факторов — регуляторных требований и бизнес-реалий. С одной стороны — приказы ФСТЭК № 239, ФСБ № 114, федеральные законы о защите персональных данных и о безопасности критической инфраструктуры. Такой нормативный контур сделал использование требований к РБПО обязательным условием выхода на проекты в госсекторе и в стратегических отраслях. Своего рода, соответствие им — это знак качества, получение статуса «надежности» перед выходом в рынок решений.

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

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

К этому добавляется переход на отечественные стеки: операционные системы, СУБД, облачные платформы. Если у решений нет промышленной поддержки РБПО на всех стадиях жизненного цикла, к ним начинает снижаться доверие корпоративных пользователей и государства. К тому же, на месте заказчика закрывать большой пул своих задач у разных подрядчиков крайне неудобно: как технологически, так и операционно. Разбираемся дальше, что делать.

Узнайте как максимально точно контролировать нагрузку,

бюджеты и сроки проектов благодаря комплексной методологии «Девелоника Fusion».

Узнать подробнее

Agile и DevOps против ГОСТов: поиск баланса

Современная индустрия разработки привыкла работать в ритме Agile и DevOps, где непрерывная интеграция и доставка кода позволяют выпускать новые релизы каждую неделю или даже ежедневно. Однако действующие стандарты РБПО выросли из водопадных моделей. В них основой являются объемные проектные документы, последовательные проверки и глубокая валидация моделей угроз.

Возникает конфликт скоростей: требования к документации и формальным проверкам тормозят CI/CD и мешают гибкости разработки. Во многих отраслях это приводит к формализму: безопасность выполняется «для галочки», а не для реального снижения рисков.

На наш взгляд, вопрос не в том, чтобы навязать DevOps ГОСТам или наоборот. мы видим суть в поиске риск-ориентированной модели, где безопасность встроена в процесс и проверяется автоматически, а не живет отдельной «бюрократической» жизнью.

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

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

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

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

Конвейер РБПО и роль технологических альянсов

Построить и внедрить РБПО в полном цикле одна компания не может. Для этого нужны компетенции в разных зонах: безопасные среды разработки, сертифицированные IDE и компиляторы, инструменты анализа кода, тестирования и сертификации, механизмы доверенной поставки.Зачастую, в момент перестройки рынок фрагментирован. Поэтому складывается ситуация, что у одних игроков есть инструменты тестирования, у других лаборатории сертификации, у третьих платформы DevOps. В результате бизнес получает набор разрозненных решений. И работа идет поэтапно, часто растягивается срок, масштабируется команда, нередко увеличивается бюджет, но отступать — себе дороже.

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

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

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

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

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

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

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

Подробности о конвейерных решениях можно будет обсудить с нашими экспертами лично.

Узнать подробнее

Построение конвейера РБПО: роль разработчиков

Автоматизированные и интегрированные конвейеры качества и безопасности могут появиться только через кооперацию и адаптацию стандартов к современным методологиям. Безопасная разработка по ГОСТам уже начинает восприниматься как стратегическая инфраструктура цифровой экономики и это вопрос технологического суверенитета. В FabricaONE.AI (в частности в Девелонике и компаниях бренда) мы фокусируемся на создании и верификации таких конвейеров — наш вклад в будущее отрасли.

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

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

Источник