Делаем безопасные приложения: зачем нужен DevSecOps

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

Василий Степаненко

Генеральный директор облачного провайдера Nubes

Что такое DevSecOps

DevSecOps образовано от слов development (разработка), security (безопасность) и operations (эксплуатация или операции). Это подход к разработке приложений, при котором безопасность учитывается на каждом этапе CI/CD, чтобы минимизировать стоимость и повысить скорость исправления ошибок. К нему относятся не только инструменты, по типу различных сканеров библиотек и кода, но и определённые договоренности между разработчиками, DevOpsами и безопасниками.

Разработка приложений сегодня похожа на приготовление салата: берутся овощи, мясо, масла и приправы, все смешивается — и получается блюдо. Если хоть один ингредиент окажется плохим, то весь салат будет испорчен. Разработчики не всё пишут сами: в DevOps из общедоступных репозиториев могут браться готовые библиотеки: их соединяют, и в результате получается приложение (тот самый салат).

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

Лицо врага

Не все библиотеки с открытым исходным кодом, выложенные в публичные репозитории, можно считать безопасными. Их авторы часто остаются неизвестными — это могут быть как энтузиасты, так и злоумышленники, включая хакеров или представителей недружественных государств. В итоге даже при использовании сложных систем защиты — межсетевых экранов, VPN, антивирусов, DLP и PAM — компания может оказаться уязвимой. Уязвимость может прийти изнутри — через стороннюю библиотеку, которая станет «троянским конём» и даст злоумышленникам доступ к данным, производственным процессам и критичной инфраструктуре.

Процент небезопасных приложений в исследованиях российских компаний, занимающихся защитой приложений, в разные годы отличается и зависит от отрасли. Так, про финансовую отрасль Positive Technologies в 2015 говорили о 90%, в 2016 г. — о 71%, а в 2017 – о 56%. Если замеченный Positive Technologies тренд защищенности приложений финансового сектора сохранился бы в тех же пропорциях, то сегодня процент был бы ещё меньше. Однако исследование «Стингрей Технолоджис» 2024 г. говорит о 56% опасных приложений в финтехе.

Ассоциация ФинТех проводила исследование, и в 2025 году 82% компаний назвали разработку на базе открытого исходного кода оптимальной с точки зрения сроков и удобства внедрения. При этом использование таких библиотек несёт в себе риски на протяжении всего жизненного цикла продукта, и риски для данных, которые используются в приложениях.

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

Какие есть риски для данных

Основные риски для данных обычно связаны с нарушением их конфиденциальности. В процессе разработки важно проводить тесты, а для этого нужны данные, причём не сильно отличающиеся от настоящих. Также важен их объём, иначе не получится провести нормальные нагрузочные тесты. Выгрузка реальных данных — самый заманчивый вариант. Но если для стендов Dev и Test используются облачные среды или в процессах разработки задействованы подрядчики, то некоторые организации могут на такое не решиться из-за требований к ИБ. И это логично, поскольку в Prod есть комплексный подход к защите, а на стендах Dev и Test меры защиты могут быть минимизированы.

Один из способов снизить риски — использовать системы маскирования: они помогают обезличить персональные и финансовые данные (например, номера карт и счетов). Сейчас действует приказ Роскомнадзора №996 от 2013 г., но, необходимо отметить, уже опубликован проект приказа Роскомнадзора «Об утверждении требований к обезличиванию персональных данных и методов обезличивания персональных данных», который его заменит.

Контейнеры стали стандартом для запуска приложений, но вместе с удобством они приносят и риски — особенно в защите данных. Да, контейнеризация улучшает доступность и масштабируемость, но не решает проблем с конфиденциальностью и целостностью «из коробки». На российском рынке уже существуют отечественные платформы контейнеризации, например, Штурвал, DeckHouse, в которых сразу учтены механизмы безопасности либо есть накладные средства для kubernetes от Luntry, PT, Kaspersky и т.д.

Как внедрять DevSecOps

DevSecOps — подход, при котором безопасность вшита в код на всех этапах. Уязвимости ищут не в самом конце, а прямо по ходу разработки: в pull request'ах, CI/CD и при работе с зависимостями. Такой подход требует, чтобы разработчики, DevOps и специалисты по безопасности работали как одна команда, а не передавали задачи «по цепочке» в последний момент.

При этом каждой компании может требоваться сугубо индивидуальный набор инструментов — всё зависит от зрелости команды и доступных ресурсов (особенно человеческих). Важно договориться о недопустимых событиях, об уровне риск-аппетита с бизнесом, разработать модель угроз. Некоторым клиентам нужно наличие собственного доверенного репозитория, а для других достаточно GitHub, GitLab и т.д.

После аудита начинается внедрение. На этом этапе команда определяет инструменты, выстраивает процесс проверки кода и решает, как именно безопасность будет встроена в разработку.

Cloud Native — это подход к разработке приложений, изначально ориентированных на работу в облачной среде и интеграцию с облачными сервисами. Сегодня большинство новых решений проектируются именно так. Для безопасной работы таких приложений важно не только адаптировать архитектуру под облако, но и выстраивать взаимодействие с провайдером: от заключения договора до работы с API. Облачные провайдеры часто предлагают инструменты, которые помогают встроить безопасность в процесс разработки. У многих есть готовые сервисы Kubernetes, в том числе с учётом требований информационной безопасности. Также доступны решения уровня WAF и инструменты анализа безопасности кода (например, SAST, DAST, SCA) — иногда по подписке, как в случае с некоторыми российскими платформами.

Начать можно с внедрения бесплатных решений — например, SAST, SCA и DAST, которые уже можно интегрировать в текущий DevOps-стек. Когда команда понимает ценность и пользу этих проверок, можно переходить к платным продуктам с расширенными возможностями.

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

Однако не стоит думать, что это финальная точка. DevSecOps — постоянный процесс: мониторинги, улучшения, обновления стандартов ИБ и поиски идеальных практик.

Цена вопроса

Вернемся к примеру с салатом. Все любят разное: кто-то — «цезарь», другой – «селёдку под шубой». Разные языки программирования, риск-аппетиты в командах в отношении принятия требований безопасности, цели внедрения DevSecOps (кому-то нужно в итоге получить сертификат, а кому-то страшно за конечный продукт и важно обеспечить реальную максимальную безопасность) — всё это не позволяет создать коробочный продукт с фиксированной ценой, хотя на рынке есть те, кто предлагает поставить 2-3 сканера и удовлетвориться этим, назвав DevSecOps.

При внедрении DevSecOps стоит учитывать затраты на разделение сред Dev, Test и Prod — это не входит в концепцию по западным лекалам. Однако от руководства компаний-клиентов нам часто поступают запросы на усиление безопасности разработки, поскольку разработчик перепутал стенд, после чего важнейшие системы компании пострадали. Вынести в облако Dev и Test и оставить у себя Prod кажется хорошей идеей (или наоборот). Для некоторых она способна полностью решить вышеупомянутую проблему.

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

Сканеры библиотек могут быть бесплатными и платными

Статический анализ кода (SAST) — может быть реализован через бесплатные инструментов, таких как SonarQube, semgrep, gitleaks/trufflehog, но есть и платные – PVS-Studio, Svace, Solar appScreener и т.д.

Динамический анализ кода (DAST) — можно осуществить с помощью бесплатных инструментов OWASP ZAP, Nuclei, NMAP, Burp Suite или платных, например, PT BlackBox.

И другие элементы DevSecOps (анализ мобильных приложений, API и т.д.) можно реализовать с использованием платных или бесплатных инструментов.

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

В процессы Ops можно также включить элемент безопасности WAF (Web Application Firewall). Доступны как бесплатные варианты (например, ModSecurity), так и платные (PTAF, Гарда WAF, Вебмониторэкс и т.д.).

Начинать стоит с бесплатных инструментов, поэтапно внедряя их в CI/СD, взаимодействуя с командой DevOps. По сути, DevSecOps – это консалтинг с возможностью применения платных инструментов, если к ним готова команда DevOps. И мы абсолютно уверены, что ради его внедрения точно не стоит жертвовать командой разработки. Кстати, для трактовки отчётов сканеров зачастую используются те же консалтеры, что внедряли DevSecOps.

Нельзя забывать и об обучении команды практикам безопасной разработки. Тут следует упомянуть, что сканеры типа CheckMarx наглядно демонстрируют эксплуатацию уязвимостей. Часто вендоры сводят DevSecOps к сканерам, консалтеры — к процессам, а про людей и их обучение — забывают.

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

Требования к безопасной разработке ПО

Уже сейчас требования по безопасной разработке (а если есть DevOps, то по сути это требования к внедрению DevSecOps) появились в:

• ГОСТ Р 57580.1-2017: СМЭ.6, СМЭ.7, ЖЦ.4, ЖЦ.5, ЖЦ.6, ЖЦ.7. ЖЦ.24; 
• PCI DSS 4.0.1: 6.2, 6.3, 6.5; 
• ГОСТ Р ИСО/МЭК 15408-3-2013: ALC_CMC, ALC_CMS, ALC_DEL, ALC_DVS, ALC_FLR, ALC_LCD, ALC_TAT.

Если речь идет о средствах защиты информации (СЗИ), которые нужно будет сертифицировать по требованиям ФСТЭК или ФСБ, важно помнить: инструменты, которые вы используете для сканирования кода, тоже должны быть сертифицированы. Иначе при испытаниях возникнут сложности — лаборатории не примут результаты без официальной документации.

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

Куда будет развиваться DevSecOps

Очевидно, что DevSecOps ждет намного более массовое внедрение и развитие — устранить проблемы на этапе разработки дешевле, чем позже латать пробоины в ИБ.

Скорость появления эксплоитов растёт — и это прямая угроза. Если раньше у команд была пара месяцев, чтобы закрыть уязвимость до начала атак, то теперь — всего несколько дней. Исследование Google показало: в 2018–2019 годах эксплойты появлялись в среднем через 63 дня после патча, в 2020 — через 44, в 2021 и 2022 — уже через 32, а в 2023 году — всего через 5 дней. А с развитием ИИ этот срок может сократиться ещё сильнее.

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

Уже существуют реестр отечественного ПО (ведется под патронажем Минцифры), реестр сертифицированных средств защиты ФСТЭК России, реестр ФСБ России, реестр отечественных ПАК (ведётся Минпромторгом). Чтобы попасть туда в ближайшие годы, разработчики должны будут не просто заявлять о безопасности, а доказывать на практике — в процессах, документации и архитектуре. Это станет драйвером роста: инструменты для безопасной разработки будут развиваться, а вместе с ними — и культура DevSecOps.