Процессы безопасной разработки регулируются государственным стандартом ГОСТ Р 56939 с 2016 года, в конце 2024 года вступила в силу его обновлённая версия. Что означает это для разработки программных продуктов и для самих пользователей? Обеспечение безопасной разработки не разовая проверка программного кода, это постоянный процесс, охватывающий все этапы создания продукта — от разработки концепции и дизайна до завершения жизненного цикла (вывода из эксплуатации) программного обеспечения. В этой статье кратко разберём, откуда взялась безопасная разработка, в чём её отличие от старого подхода, рассмотрим требования ГОСТ и расскажем, как эти принципы реализуются в разработке экосистемы продуктов UBLinux.
Как изменился подход разработки и для чего нужна именно безопасная разработка?
В 1970–1990-х годах безопасность программного обеспечения не была ключевой задачей при разработке. Этот период характеризуется как эпоха «реактивной безопасности»: сначала происходило обнаружение уязвимости, затем ее устранение. Разработка велась в виде «монолитов», релизные циклы могли длиться год и более. Проверки безопасности проводились на заключительном этапе, подобно поиску дефектов в уже собранном устройстве. Такой подход был затратным, медленным и неэффективным.
В 1988 году произошел переломный момент — первый крупный инцидент с «червём Морриса», который использовал уязвимость переполнения буфера. Это событие заставило индустрию разработки программного обеспечения осознать важность системных проблем в коде. Однако до середины 1990-х поиск уязвимостей был в основном деятельностью энтузиастов, а единой методологии не было.
В начале 2000-х и 2010-х годов разработчики осознали, что реактивный подход к обеспечению безопасности становится неэффективным. Такие компании как Microsoft, внедрили формализованные процессы безопасной разработки (SDL), интегрируя защиту на всех этапах жизненного цикла продукта. В то же время индустрия разработки программного обеспечения перешла на гибкие методологии разработки и непрерывную доставку (CI/CD), при которых релизы могли выпускаться до нескольких раз в день. Традиционный контроль безопасности в конце цикла уже не мог справляться с такими темпами.
Начиная с 2010-х годов защита информации окончательно стала приоритетной составляющей процесса создания программных продуктов. Широкое распространение получили методики DevSecOps, а вместе с ними — подход Shift Left, предполагающий перенос проверок на максимально ранние стадии, вплоть до момента, когда код только пишется. Автоматизация здесь выступает центральным элементом: анализаторы SAST и DAST встраиваются непосредственно в конвейеры CI/CD.
Эволюция угроз: как одиночки превратились в киберпреступную индустрию
В 1980–1990-е годы атаки на программное обеспечение оставались по большей части разрозненными, а явная экономическая выгода в них отсутствовала. Однако уже с 2000-х картина стала меняться очень быстро. Место простых хакеров заняли организованные группы, а к середине 2010-х сформировались влиятельные киберпреступные синдикаты. Нападения обернулись хорошо выстроенным бизнесом, где финансовые и политические цели обозначены предельно ясно.
Изменились и задачи, которые ставят перед собой киберпреступники. Данные вышли на первое место по значимости: сведения о клиентах, охраняемые законом секреты бизнеса, программные исходники, а также возможность управлять корпоративной инфраструктурой. Практически в каждом случае самой уязвимой точкой выступает брешь в программном коде приложения. Если злоумышленнику удастся через неё проникнуть, под его контролем окажется вся внутренняя сеть организации. По этой причине защищённость кода стала ключевым направлением противостояния.
В нашей стране постепенно складывается собственная методология, позволяющая выпускать программные продукты без рисков для пользователей. В отличие от практик, принятых за рубежом, данный подход с самого начала разрабатывался с оглядкой на нормативы ФСТЭК России. Кроме того, он учитывал задачу по обеспечению защиты объектов критической информационной инфраструктуры государства.
На сегодняшний день при подборе решений для отечественных компаний безопасная разработка ПО входит в число главных критериев.
В чем заключаются отличия обычной разработки от безопасной?
Ключевым различием безопасной разработки по сравнению с традиционной является распределение ответственности и сам момент с которого ведутся работы по обеспечению защищённости.
При традиционной разработке проверка на безопасность кода выполняется специалистами ИБ перед релизом либо уже после него. При безопасной разработке работа по информационной безопасности ведется на каждом этапе разработки от анализа требований к разрабатываемому ПО до процесса внедрения заказчику, интеграции с другими продуктами, технической поддержки продукта. В этот процесс вовлечены не только специалисты по ИБ но и разработчики, аналитики, менеджеры проектов.
На этапах разработки ведется прокативые поиск и устранение уязвимостей программного обеспечение, производится приоритезация рисков. При этом используется комплексный стек инструментов: SAST, DAST, SCA, фаззинг, анализ состава зависимостей.
Это приводит в том числе и к сокращению издержек при разработке за счет устранения уязвимостей еще на этапах проектирования и разработки продуктов.
Важность ГОСТ по безопасной разработке
В России безопасную разработку регламентирует ГОСТ Р 56939 «Защита информации. Разработка безопасного программного обеспечения». С конца 2024 действует его актуальная редакция ГОСТ Р 56939-2024. Данный ГОСТ это не свод запретов, общее руководство по построению системы управления рисками- он помогает структурировать процесс разработки, сделать его прозрачным.
Использование стандарта является добровольным, но от этого он не теряет значимость. По факту следование положениям ГОСТ Р 56939 является обязательным для успешной сертификации ФСТЭК России, а также является важным для положительного решения о включения программного продукта в реестр отечественного программного обеспечения. Без выполнения требований ГОСТ продукт не будет рассматриваться государственными и крупными корпоративными заказчиками.
Основные положения стандарта
В ГОСТ Р 56939-2024 описаны 25 процессов, которые для минимизации рисков появления уязвимостей должны быть реализованы разработчиком на различных этапах жизненного цикла продукта:
Моделирование угроз и анализ рисков на этапе пректирования архитектуры программного продукта.
Использование безопасных функций, управление конфигурацией, безопасность среды сборки на этапе разработки продукта.
Обязательное применение статического SAST и динамического DAST анализа, тестирование на проникновение на этапе тестирования.
Регулярный поиск уязвимостей и управление инцидентами, в уже выпущенных версиях продукта при его эксплуатации.
Обучение сотрудников безопасной разработке продукта, основам социальной инженерии.
Как команда UBLinux реализует и соблюдает положения стандарта
Наша команда строго выполняет все 25 процессов безопасной разработки в соответствии с положениями ГОСТ Р 56939-2024:
ГОСТ не предписывает конкретные средства, но определяет требования к их возможностям и характеристикам. Статический анализ (п. 5.10) и динамический анализ (п. 5.11) должны выполняться с использованием анализаторов, отвечающих требуемым параметрам. Мы руководствуемся этими требованиями при подборе инструментов и консультируемся с испытательными лабораториями. Проводим совместные аудиты и консультации, в результате используем набор средств и инструментов, соответствующий требованиям безопасной разработки и сертификационным критериям.
Ведется постоянное обучение сотрудников. Разработаны курсы по безопасной разработке, включающие теорию и практику. Программы предназначены не только для технических специалистов, но и для сотрудников смежных подразделений. Курсы назначаются и отслеживаются автоматическом режиме, что обеспечивает их обязательное прохождение сотрудниками. По завершении каждого курса проводится тестирование и оценка полученных знаний и навыков.
Утверждены внутренние стандарты, на основе которых ведется разработка. Все настройки средств и инструментов, сценарии применения и методики анализа проходят предварительную проверку и закрепляются в документации. Это гарантирует единообразие результатов и их воспроизводимость, позволяет оперативно включаться новым сотрудникам в процессы разработки.
Реагирование на информацию об уязвимостях (п. 5.23) и поиск уязвимостей при эксплуатации (п. 5.24). Раньше аналитики вручную анализировали базы уязвимостей (BDU, MITRE), другие источники. В настоящее время этот процесс автоматизировался: используется сервис-агрегатор, который сканирует источники информации о уязвимостях в автоматическом режиме. Если новая уязвимость затрагивает компоненты, используемые в продукте, автоматически заводится соответствующая задача. Это значительно сокращает время реакции на обнаруженные уязвимости до нескольких часов или минут.
Актуальные практики безопасной разработки в отрасли
Время не стоит на месте эволюционируют как угрозы, так и методы защиты и противодействия.
Все активнее в процессы разработки UBLinux интегрируется искусственный интеллект. Его основная задача- автоматизация рутинных операций, для высвобождения ресурсов экспертов и направления их на решение более значимых и сложных задач.
Используется инструментарий на основе машинного обучения, которые позволяют выходить за рамки известных паттернов уязвимостей. Проводится анализ контекста и логики выполнения кода, это позволяет выявлять нестандартные конструкции и отклонения от стандартных сценариев использования, что может сигнализировать о скрытых уязвимостях. Также, ИИ классифицирует результаты работы статических анализаторов, отсеивая ложные срабатывания.
Накопленные данные об инцидентах и паттернах атак, их анализ с помощью инструментов ИИ, позволяет прогнозировать, какие типы уязвимостей с высокой вероятностью будут эксплуатироваться различных архитектурах приложения и его элементов. Это позволяет командам, ответственным за конкретные проекты, заранее фокусироваться наиболее рискованных компонентах системы и предотвращает появление в них уязвимостей.
Тестирование и использование автоматизированных анализаторов
Инструментарий автоматизированного анализа программного кода и среды его исполнения образуют технологический фундамент, на котором в дальнейшем выстраиваются процессы безопасной разработки. Основные классы таких инструментов:
Static Application Security Testing (SAST) статический анализ исходного кода программного кода, выполняется без запуска самого приложения. Инструменты этого класса производят поиск уже известных уязвимых паттернов (SQL-инъекции, переполнение буфера и т.д.) в файлах конкретного проекта разработки. За счет полного доступа к внутренней структуре и логике продукта, SAST показывает большую эффективность на ранних этапах жизненного цикла продукта.
Dynamic Application Security Testing (DAST) — динамический анализ работающего приложения. По сравнению со статическим анализом, DAST проводит исследования программ используя их внешние интерфейсы, он не имеет к структуре и исходному коду приложений. Инструменты, относящиеся к данному классу, моделируют возможные действия злоумышленников, выявляют потенциальные уязвимости, которые проявляются в процессе исполнения программ. Наибольшую результативность DAST показывает на этапах тестирования приложений и их API.
Пентесты — ручная или автоматизированная комплексная проверка защищённости продукта, ее выполняют специалисты по информационной безопасности. Как непосредственно члены нашей команды, так и сторонние эксперты. Эксперты при проведении тестов не ограничиваются поиском уязвимостей по известным сигнатурам, а моделируют поведение злоумышленника, учитывая архитектуру, специфику бизнес-логики и верятные цепочки атак. Этим пентесты выгодно отличаются от исопльзования автоматических сканеров уязвимостей. Основная задача не только найти уязвимости, но убедиться в их эксплуатационности и спрогнозировать потенциальный ущерб в случае их использования злоумышленником.
Использование принципов DevSecOps
DevSecOps является технологической и организационной практикой для обеспечения встраивания задач ИБ в процесс непрерывной интеграции, доставки и развертывания (CI/CD). Этот подход позволяет распределить ответственность за защищённость продукта между всеми участниками команды проекта, от процесса разработки до эксплуатации. Позволяет задействовать в решении вопросов информационной безопасности не только специалистов по ИБ.
Такой подход включает обязательные компоненты: статический анализ исходного кода (SAST) на этапе каждого изменения продукта, анализ состава зависимостей (SCA) позволяет выявлять уязвимости в сторонних компонентах и библиотеках, динамический анализ приложения в процессе работы (DAST) на инфраструктуре тестовых стендов, проверку инфраструктуры и контейнерных сред, их конфигураций на соответствие требованиям безопасности, автоматизированную проверку качества (Quality Gates), блокирующую развёртывание при обнаружении уязвимостей.
Реализация перечисленных принципов позволяет превратить безопасность из разрозненных финальных проверок приложения в обязательную часть постоянных рабочих команды UBLinux. Это реализует постоянный и качественный контроль защищённости программных продуктов, повышает надежность разрабатываемого программного обеспечения в каждом отдельном релизе.
Для чего необходимо безопасное программное обеспечение
Государственный сектор, системы критической инфраструктуры- уязвимости и функциональные ошибки в программном обеспечении, используемом в критической информационной инфраструктуре могут вызвать значительные негативные последствия для систем как регионального так и национального масштаба. Включая возможную остановку отдельных технологических процессов и предприятий в целом, до риска возникновения техногенных аварийных ситуаций.
Банки и финансовые компании несут ответственность за операции с финансовыми средствами и конфиденциальными данными клиентов. Разглашение или сбой в таких инструментах, к примеру в платёжной системе, мгновенно приводят к значительным репутационным и финансовым потерям.
Крупные коммерческие компании, ретейл. Торговые платформы, онлайн-магазины работают с большими массивами данных о операциях, финансовой информацией. Прекращение работы или утечки данных о клиентской базе могут вылиться в значительные финансовые потери и утрату доверия клиентов.
Безопасность программного кода в продуктах, используемых в этих, а также многих других отраслях, является обязательным условием для обеспечения защищённости информации и непрерывности бизнес-процессов, позволяет сохранить доверие партнёров и клиентов.
Итог- безопасная разработка это необходимый и непрерывный процесс
Безопасность процесса разработки программного обеспечения является сложным и непрерывным процессом, который требует системного подхода. В него входят постоянное повышение квалификации сотрудников, документирование процессов, внедрение современных инструментов и средств автоматизации, а также постоянная работа внутри команды над культурой безопасности. Только такой подход позволяет создавать надёжное программное обеспечение, способное противостоять постоянно эволюционирующим угрозам безопасности. Команда разработки экосистемы продуктов UBLinux придерживается этих принципов, это позволяет пользователям наших продуктов быть уверенными в их качестве и безопасности.