Как «Группа Астра» выстраивает безопасную разработку ПО и почему это важно для бизнеса

«Группа Астра» подтвердила соответствие процессов разработки безопасного ПО требованиям ФСТЭК России. Для рынка, особенно для заказчиков из госсектора, промышленности, финансов, телекома и критической инфраструктуры, это не просто формальный статус — это значит, что безопасность встроена в сам процесс создания программных продуктов, а не ограничивается формальной проверкой накануне релиза. О том, как этот принцип реализуется в «Группе Астра», рассказывает Владимир Тележников, директор департамента анализа безопасности.

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

Мы в «Астре» строим РБПО как систему: начиная с постановки требований, моделирования угроз, формирования и контроля состава компонентов, анализа исходного и бинарного кода, фаззинг-тестирования, заканчивая развитием собственных (во многом уникальных) механизмов защиты от реальных компьютерных атак, поставкой инструментов и фидов для контроля безопасности выпускаемых продуктов на стороне клиентов, непрерывным взаимодействием с регуляторами, партнерами и профильными сообществами.

Безопасность начинается с процесса, а не с проверки

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

В «Астре» мы встраиваем безопасность в производственный цикл, чтобы уязвимости, ошибки проектирования и небезопасные конфигурации выявлялись как можно раньше — так их дешевле исправлять. Безопасность перестаёт быть внешним контролёром и становится частью инженерной практики: разработчики, тестировщики, аналитики кода, специалисты по уязвимостям и команды сопровождения работают в едином контуре, и критичные риски не накапливаются скрыто.

Моделирование угроз

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

Управление уязвимостями как постоянный процесс

В 2025 году наши специалисты проанализировали более 11 000 CVE, относящихся к пакетной базе Linux — это почти вдвое больше, чем годом ранее, — устранили и направили в Банк данных угроз ФСТЭК России паспорта для более 3 000 уязвимостей. Мы не ждём, пока проблема станет инцидентом у заказчика, а проактивно отслеживаем уязвимости, сопоставляем их с составом продуктов, оцениваем их актуальность и критичность, готовим исправления и передаём сведения регулятору.

Уязвимость опасна не сама по себе, а в контексте конкретной инфраструктуры: один дефект может быть критичным для доступного из сети сервера и незначимым для закрытого контура. Поэтому мы отвечаем не только на вопрос «существует ли проблема», но и на вопрос «насколько она опасна здесь и сейчас» — это отличает зрелую практику от формального реагирования.

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

Немаловажную роль в данном вопросе играет наличие и возможность применения механизмов защиты, входящих в состав ОС, как для борьбы с самими уязвимостями, так и с векторами атак, эксплуатация уязвимостей в которых зачастую является лишь одним из многочисленных шагов. В случае с ОС Astra Linux в дополнение к стандартным мерам защиты мы можем противопоставить применение расширенного комплекса средств обеспечения безопасности, включая мандатный контроль целостности (МКЦ), замкнутую программную среду (ЗПС), мандатное управление доступом (МРД), контроль съемных носителей информации и т.д. Если мы быстро объясняем заказчику, затрагивает ли уязвимость или вектор атаки используемую им ОС Astra Linux, какие версии в зоне риска, какие меры доступны до обновления и когда выйдет исправление, — он управляет ситуацией, а не реагирует на тревожные новости.

Контроль состава продукта и SBOM

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

Особое значение имеет SBOM (Software Bill of Materials) — машиночитаемая спецификация состава продукта, аналог ведомости материалов в промышленности. Без прозрачного состава нельзя быстро ответить, затрагивает ли продукт новая критическая уязвимость в популярной библиотеке. В 2025 году команда разработки Astra Linux выпустила более 20 обновлений безопасности с отправкой SBOM во ФСТЭК России — то есть безопасность продукта подтверждается не декларациями, а воспроизводимыми данными о его составе.

Артефакты безопасности

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

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

Статический и динамический анализ

Статический анализ кода находит дефекты до запуска программы: ошибки работы с памятью, некорректную обработку данных, небезопасные вызовы. Мы используем Svace, Clang Static Analyzer и собственные средства обработки результатов, включая SentinelAI. Здесь важно качество анализа: при избытке ложных срабатываний разработчики воспринимают его как шум. Использование машинного обучения и больших языковых моделей для разметки результатов сокращает трудозатраты, и команда быстрее устраняет реальные проблемы.

Но статический анализ не заменяет контроль поведения программного обеспечения при выполнении — часть ошибок проявляется только в динамике. Для этого мы применяем динамический анализ, санитайзеры и фаззинг и развиваем платформу AutoFuzz: в неё интегрировано более 350 проектов и используется более 5 000 оберток для непрерывного регрессионного тестирования. Фаззинг проверяет устойчивость программы к нестандартным и специально сформированным данным, имитируя поведение реального атакующего. Это особенно важно в инфраструктурном ПО, где один сбой в системной библиотеке или сетевом сервисе может повлиять на весь бизнес-процесс.

Инструментальная база и Bug Bounty

Безопасность нельзя строить на героизме отдельных экспертов — при больших масштабах разработки она должна опираться на автоматизацию и воспроизводимые практики. В «Астре» мы выстраиваем полный цикл управления уязвимостями на базе собственной платформы, любые изменения передаем на анализ Svace, ClangSA или другие специализированные инструменты, 24/7 обеспечиваем фаззинг-тестирование потенциальной поверхности атаки и механизмов защиты. Для повышения эффективности обработки результатов анализа развиваем собственную мультиагентскую ИИ-систему SentinelAI с дообученными нами моделями машинного обучения для разметки и приоритизации результатов статического и динамического анализа кода и предложения патчей по устранению подтвержденных дефектов. Важно их включение в общий контур: анализ выполняется регулярно, результаты попадают в трекеры задач, а большинство проверок интегрированы в CI. Это снижает зависимость от человеческого фактора, даёт предсказуемость релизов и позволяет масштабировать контроль на всю продуктовую линейку.

Для корпоративного и государственного рынка крайне важно отсутствие нежелательного, запрещённого или опасного контента в составе продукта. Мы в «Астре» проводим такие проверки и в 2025 году решили более 170 связанных с этим задач. Корпоративный продукт должен быть не только защищённым, но и юридически чистым: для регулируемых сегментов даже случайное попадание недопустимого содержимого создаёт правовые и репутационные риски. Мы трактуем безопасность широко — это и возможности выстраивания эшелонированной защиты от компьютерных атак, и прозрачность цепочки поставки, и «чистота» компонентов.

Внутренние процессы анализа безопасности дополняет программа Bug Bounty: независимые исследователи ищут уязвимости в продуктах «Астры» и сообщают о них по установленным правилам. Преимущество этой инициативы — в разнообразии взглядов исследователей и в неожиданных сценариях, что приближает проверку к реальным условиям. Когда компания выходит на Bug Bounty — это признак зрелости и всесторонней ответственности.

Почему принципы РБПО важны именно сейчас

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

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