Всем привет! В этой статье наши эксперты – Паша Попов, руководитель направления инфраструктурной безопасности, и Леша Астахов, директор по продуктам WAF-класса с огромным опытом развития продуктов Application Security в Positive Technologies, – разбираются, что такое подход Secure by Design, является ли он волшебной таблеткой для разработчиков и ИБ-специалистов, в чем разница между Secure by Design, AppSec и DevSecOps, а также какое будущее ждет безопасную разработку.
Представьте, что мы строим город и изначально, еще на этапе проекта, ставим задачу сделать его максимально безопасным для будущих жителей: продумываем систему наблюдения, оповещения и реагирования на инциденты, проектируем широкие улицы с автономным освещением, заранее разделяем транспортные и пешеходные потоки. Такой подход, при котором безопасность закладывается в фундамент, а не добавляется постфактум в виде «заборов и камер», кардинально снижает вероятность происшествий. Именно эту философию — проектировать систему изначально безопасной, будь то город, цифровой продукт или любая сложная инфраструктура, — и олицетворяет собой концепция Secure by Design. В разработке это означает, что думать об уязвимостях, контроле доступа и защите данных важно еще до написания первой строчки кода.
Secure by Design — не просто набор практик, а философия проектирования, где безопасность закладывается в продукт на этапе замысла, а не добавляется постфактум. Однако это не волшебная таблетка, которая отменяет необходимость тестирования или мониторинга. Скорее это – их основа.
Secure by Design vs. AppSec vs. DevSecOps
В мире безопасной разработки много терминов, и их часто путают. Давайте разберемся:
Secure by Design — идеология. Это про то, как думать о безопасности до начала разработки.
AppSec (Application Security) — область знаний, которая охватывает весь жизненный цикл приложения - от планирования до эксплуатации, с фокусом на безопасность самих приложений, не инфраструктуры, в которой они развернуты. AppSec - про долгосрочные стратегии безопасности и архитектурные решения.
DevSecOps —подход к разработке приложений, который ориентирован на раннее устранение уязвимостей. DevSecOps – про то, как добавить AppSec в жизненный цикл разработки приложений.
Secure by Design vs. Vulnerability Management
На первый взгляд, Secure by Design и управление уязвимостями (Vulnerability Management, VM) решают одну задачу — минимизируют риски. Но разница в подходе.
Vulnerability Management — это реактивная модель и работа постфактум. К примеру, сканер находит уязвимость, которую злоумышленники могут эксплуатировать прямо сейчас, и теперь ИБ-специалистам нужно срочно ее устранить.
Secure by Design — проактивный подход. ПО проектируется так, чтобы в нем изначально не было уязвимостей или их было крайне сложно использовать.
И это не взаимоисключающие вещи, потому что безопасность — многослойная система.
В нашем решении – MaxPatrol VM – мы уже частично используем инструменты, которые разрабатывает команды AppSec. Например, метод анализа безопасности программного обеспечения SAST, а также анализ защищенности веб-приложений и контейнеров. Однако решение не заменяет подход безопасной разработки, а помогает выявить уязвимости в уже существующей, работающей инфраструктуре.
Secure by Design— серебряная пуля?
В идеальном мире разработчики сами пишут безопасный код, а специалисты по кибербезу помогают инструментами. Однако в реальности бывает так, что безопасность — «головная боль» только ИБ-команды, и тогда философия Secure by Design остается утопией. Но есть примеры, когда CTO или архитекторы делают безопасность частью культуры — тогда она перестает быть допнагрузкой и становится естественным этапом разработки.
Secure by Design тесно переплетается с вопросами качества кода — по сути, многие уязвимости являются особым видом критичных дефектов. Допустим, если приложение падает от неожиданного ввода пользователя — это баг. Если этот же ввод позволяет списать деньги — это уже уязвимость.
Разница лишь в последствиях, а не в природе ошибки.
Именно поэтому философия Secure by Design предполагает, что разработчики и тестировщики должны рассматривать потенциальные угрозы как часть обычного процесса контроля качества при создании надежного продукта. В идеале безопасный код — это просто хороший код, где учтены не только функциональные требования, но и возможные злоупотребления.
Однако Secure by Design не защитит ваш код от всех угроз раз и навсегда. Это скорее стратегия, которая минимизирует риски, но не устраняет их полностью. Почему? Потому что безопасность — это не статичное состояние, а постоянный процесс.
Время — главный враг безопасности.
Допустим, вы написали «идеально безопасный» код. Но мир не стоит на месте: появляются новые уязвимости, методы атак, эксплойты для старых библиотек. То, что было безопасно вчера, сегодня может оказаться дырой. И если вы изначально не заложили механизмы для быстрого обнаружения и исправления таких проблем, даже самые продвинутые инструменты вроде Web Application Firewall (WAF) или сканеров уязвимостей будут затыкать дыры, а не предотвращать их. А в случае атаки на бизнес-логику – и вовсе окажутся бессильны.
Уязвимости бизнес-логики — это уязвимости, позволяющие пропускать шаги бизнес-процесса или вызывать методы API в обход условий выполнения. Контроль процессов и условий должен быть согласован для исключения фрод-схем или некорректного вызова методов.
Их сложно искать автоматизированно, потому что необходимо хорошо понимать, как приложение «должно» работать. Классический пример — изменение суммы оплаты: если пользователь на этапе нажатия кнопки «оплатить» может поправить итоговую сумму, а сервис доверяет пользовательскому вводу, появляется уязвимость. Чтобы такое найти, нужно понимать, как должен работать сайт и какая у продукта логика принятия решений, — именно на неё и идёт атака.
Комплексный подход и комбинация методов защиты
Для защиты продукта на всех этапах его жизненного цикла нужна система, которая начинается с кода и не заканчивается на продакшене. Secure by Design — это фундамент, который работает в связке с другими практиками.
Так, к примеру, крупные технологически зрелые компании не ждут, пока сканер или пентест выявят проблему. Они встраивают безопасность в процесс разработки: проводят моделирование угроз, используют статический анализ кода, а затем дополняют это участием в bug bounty-программах, чтобы ловить то, что ускользнуло.
Сегодня команды AppSec обычно комбинируют инструменты, покрывающие разные уровни риска:
Статический анализ кода (Static Application Security Testing, SAST) ищет уязвимости в коде еще до запуска приложения (в Positive Technologies это PT Application Inspector).
Анализ внешних зависимостей (Software Composition Analysis, SCA) отслеживает уязвимости в библиотеках, которые использует приложение (в Positive Technologies это PT Application Inspector).
Динамический анализ - (Dynamic Application Security Testing, DAST) ищет уязвимости в уже запущенном приложении (в Positive Technologies это PT BlackBox)
Решения класса Container Security анализируют и образы контейнеров, и мониторит рантайм-окружение для выявления атак на наиболее ранних этапах (в Positive Technologies это PT Container Security).
Межсетевой экран уровня веб-приложений страхует на этапе эксплуатации, особенно когда код уже нельзя быстро исправить, например, при уязвимостях в legacy-системах или купленном ПО (в Positive Technologies это PT Application Firewall).
К этому списку также можно добавить поиск секретов в коде (токены, пароли, ключи API) и анализ конфигураций.
ML в безопасной разработке: помощь или риск?
Когда разработчик использует ИИ-инструменты вроде GitHub Copilot, никто не гарантирует, что в сгенерированном коде не будет уязвимостей. Слепо копировать код без понимания его логики – все равно что списывать курсовую: преподаватель, а в нашем случае пентестер или совсем неприятное – хакер, быстро найдет слабые места. Поэтому пока без экспертизы человека не обойтись.
Но есть и обратная сторона: ML можно использовать для поиска уязвимостей, особенно в сложных сценариях вроде атак на бизнес-логику. Традиционные инструменты работают на уровне формальной логики, анализируя код или поведение приложения. Искусственный интеллект же способен подняться на другой уровень— понять контекст, выявить аномалии и предложить исправления. Так, к примеру, ИИ может помочь в приоритизации угроз, выделив действительно критичные среди тысяч срабатываний сканера.
Пока ML — скорее дополнение к существующим практикам, но в будущем такой инструмент может стать мостом между безопасностью и разработкой, особенно если научится объяснять, почему тот или иной код опасен и предлагать способ исправления.
Будущее инструментов безопасности: оркестрация и бесшовная интеграция
Сейчас для многих AppSec и DevSecOps – это про разбор огромного количества сообщений об уязвимостях или недочетах от разрозненных инструментов выделенным специалистом. Для этого используют продукты класса ASOC (Application Security Orchestration and Correlation), они объединяют данные из SAST, DAST, SCA, контейнерных сканеров и даже программ bug bounty, и стараются уязвимости из этих отчетов объединять.
Вместо ручного анализа тысяч срабатываний ASOC должен автоматически коррелировать и помогать недопускать угрозы: например, если статический анализ обнаружил уязвимость в библиотеке, а динамический тест подтвердил её эксплуатацию — это критичный кейс, требующий немедленного исправления – вот изменение в коде или списке зависимостей.
Но важно не просто исправление уязвимости, важно – ее недопущение. Это будет работать, если инженер знает что именно допускать нельзя и есть удобные инструменты под руками, которые ему в этом помогают. Ключевое тут «под руками» - разработчик пишет код в редакторе, там и должна быть информация про уязвимость и предложение по исправлению. Даже если про уязвимость мы узнали только после того, как запустили код в тестовом окружении. А не через тикеты в Jira
Навыки безопасной разработки — must-have для программистов?
Сегодня многие компании ищут специалистов, которые не просто умеют писать работающий код, а способных сразу учитывать риски вроде инъекций, неправильной аутентификации или утечек данных. Это не значит, что каждый разработчик должен быть экспертом в кибербезе — но базовые принципы вроде проверки ввода, безопасной работы с памятью и грамотного использования сторонних библиотек становятся нормой. ИБ-инструменты упрощают этот процесс, но без осознанного подхода остаются лишь костылями.
Именно поэтому зрелые компании так активно вовлекают своих разработчиков в вопросы безопасности. Они понимают, что один только инструмент не поможет — нужна культура. Обучают, помогают внедрять практики, обеспечивают инструментарием, интегрируют безопасность в процесс тестирования. В результате инженеры по тестированию начинают активно думать и работать на опережение, находя уязвимости до выпуска кода в продакшен. Так и получается настоящий shift-left, когда безопасность становится неотъемлемой частью жизненного цикла разработки, а не запоздалой мыслью.