Создание современной программы безопасности приложений

Списки OWASP Top Ten — это документы для повышения осведомлённости, призванные привлечь внимание к наиболее критичным рискам в рассматриваемой области. Они не претендуют на полноту и являются лишь отправной точкой. В предыдущих версиях списка мы рекомендовали запуск программы безопасности приложений как лучший способ избежать этих рисков и других проблем. В этом разделе мы расскажем, как начать и выстроить современную программу безопасности приложений.

Если у вас уже есть программа безопасности приложений, рассмотрите возможность оценки её зрелости с помощью OWASP SAMM (Software Assurance Maturity Model) или DSOMM (DevSecOps Maturity Model). Эти модели зрелости обширны и исчерпывающи, они помогут вам определить, на чём лучше всего сосредоточить усилия при расширении и развитии программы. Обратите внимание: вам не обязательно выполнять всё, что предусматривают OWASP SAMM или DSOMM, — они призваны направлять вас и предлагать множество вариантов. Они не устанавливают недостижимые стандарты и не описывают неподъёмные программы. Их обширность обусловлена желанием дать вам как можно больше идей и вариантов.

Если вы начинаете программу с нуля или находите OWASP SAMM или DSOMM «слишком масштабными» для вашей команды прямо сейчас, пожалуйста, ознакомьтесь со следующими рекомендациями.

1. Сформируйте портфельный подход, основанный на рисках:

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

2. Создайте прочную основу:

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

3. Интегрируйте безопасность в существующие процессы:

Определите и интегрируйте мероприятия по безопасной реализации и верификации в существующие процессы разработки и эксплуатации.
Мероприятия включают: моделирование угроз, безопасное проектирование и анализ проектных решений, безопасное программирование и ревью кода, тестирование на проникновение и устранение уязвимостей.
Обеспечьте командам разработки и проектным группам доступ к экспертам по предметной области и вспомогательным службам.
Проверьте текущий жизненный цикл разработки системы и все мероприятия по безопасности программного обеспечения, инструменты, политики и процессы, затем задокументируйте их.
Для нового программного обеспечения добавьте одно или несколько мероприятий по безопасности на каждый этап жизненного цикла разработки системы (SDLC). Ниже приведены многочисленные предложения. Следите за тем, чтобы эти новые мероприятия выполнялись в каждом новом проекте или программной инициативе — так вы будете уверены, что каждый новый продукт соответствует приемлемому уровню безопасности для вашей организации.
Выбирайте мероприятия таким образом, чтобы конечный продукт соответствовал допустимому уровню риска для вашей организации.
Для существующего программного обеспечения (иногда называемого legacy) необходим формальный план технического обслуживания. Ниже в разделе «Эксплуатация и управление изменениями» приведены идеи о том, как поддерживать безопасные приложения.

4. Обучение безопасности приложений:

Рассмотрите возможность запуска программы «чемпионов безопасности» или общей программы обучения безопасности для ваших разработчиков (иногда называемой программой адвокатуры или повышения осведомлённости), чтобы научить их всему, что вы хотите, чтобы они знали. Это поможет им быть в курсе событий, работать безопасно и создаст более позитивную культуру безопасности. Зачастую это также укрепляет доверие между командами и улучшает рабочие отношения. OWASP поддерживает вас в этом с помощью OWASP Security Champions Guide, который постоянно расширяется.
OWASP Education Project предоставляет учебные материалы для обучения разработчиков безопасности веб-приложений. Для практического изучения уязвимостей попробуйте OWASP Juice Shop Project или OWASP WebGoat. Чтобы быть в курсе событий, посещайте конференции OWASP AppSec, тренинги OWASP или встречи местных отделений OWASP.

5. Обеспечьте видимость для руководства:

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

Создание и использование повторяемых процессов безопасности и стандартных средств контроля

Фаза управления требованиями и ресурсами:

Соберите и согласуйте с бизнесом требования к приложению, включая требования по защите конфиденциальности, подлинности, целостности и доступности всех активов данных, а также ожидаемую бизнес-логику.
Составьте технические требования, включая функциональные и нефункциональные требования к безопасности. OWASP рекомендует использовать OWASP Application Security Verification Standard (ASVS) в качестве руководства для определения требований безопасности.
Спланируйте и согласуйте бюджет, охватывающий все аспекты проектирования, разработки, тестирования и эксплуатации, включая мероприятия по безопасности.
Добавьте мероприятия по безопасности в расписание проекта.
Представьтесь как представитель по безопасности на стартовом совещании проекта, чтобы команда знала, к кому обращаться.

Запрос предложений и заключение договоров:

Согласуйте требования с внутренними или внешними разработчиками, включая руководящие принципы и требования безопасности вашей программы безопасности, например SDLC, лучшие практики.
Оцените выполнение всех технических требований, включая фазу планирования и проектирования.
Согласуйте все технические требования, включая проектирование, безопасность и соглашения об уровне обслуживания (SLA).
Применяйте шаблоны и чеклисты, например OWASP Secure Software Contract Annex.
Примечание: Приложение предназначено для законодательства США, поэтому перед использованием проконсультируйтесь с квалифицированным юристом.

Фаза планирования и проектирования:

Согласуйте планирование и проектирование с разработчиками и внутренними заинтересованными сторонами, например со специалистами по безопасности.
Определите архитектуру безопасности, средства контроля, контрмеры и обзоры проектных решений, соответствующие потребностям в защите и ожидаемому уровню угроз. Это должно осуществляться при поддержке специалистов по безопасности.
Гораздо эффективнее с точки зрения затрат проектировать безопасность с самого начала, чем встраивать её в приложения и API впоследствии. OWASP рекомендует OWASP Cheat Sheets и OWASP Proactive Controls в качестве хорошей отправной точки.
Проводите моделирование угроз, см. OWASP Cheat Sheet: Threat Modeling.
Обучайте архитекторов программного обеспечения концепциям и паттернам безопасного проектирования и просите их применять их в своих разработках там, где это возможно.
Изучайте потоки данных вместе с разработчиками.
Добавляйте пользовательские истории по безопасности наряду со всеми остальными пользовательскими историями.

Жизненный цикл безопасной разработки:

Для улучшения процесса разработки приложений и API в вашей организации OWASP рекомендует OWASP Software Assurance Maturity Model (SAMM). Эта модель помогает организациям формулировать и реализовывать стратегию безопасности программного обеспечения с учётом специфических рисков их деятельности.
Обеспечьте разработчикам обучение безопасному программированию и любое другое обучение, которое поможет им создавать более надёжные и безопасные приложения.
Ревью кода, см. OWASP Cheat Sheet: Secure Code Review.
Предоставьте разработчикам инструменты безопасности, затем обучите их пользоваться ими, особенно средствами статического анализа, анализа состава ПО, поиска секретов и сканерами инфраструктуры как кода (IaC).
Создавайте «ограждения» для разработчиков (технические меры защиты, направляющие их к более безопасным решениям).
Создание надёжных и удобных средств контроля безопасности — сложная задача. По возможности предлагайте безопасные настройки по умолчанию и создавайте «проторенные дорожки» (делая самый простой способ сделать что-то одновременно наиболее безопасным и очевидно предпочтительным). OWASP Cheat Sheets — хорошая отправная точка для разработчиков, а многие современные фреймворки теперь поставляются со стандартными и эффективными средствами контроля безопасности для авторизации, валидации, защиты от CSRF и т.д.
Предоставьте разработчикам плагины для IDE, связанные с безопасностью, и поощряйте их использование.
Предоставьте им инструмент управления секретами, лицензии и документацию по его использованию.
Предоставьте им частный ИИ, в идеале настроенный с RAG-сервером, наполненным полезной документацией по безопасности, промптами, написанными вашей командой для лучших результатов, и MCP-сервером, вызывающим предпочтительные инструменты безопасности вашей организации. Обучите их безопасному использованию ИИ, потому что они всё равно будут его использовать, нравится вам это или нет.

Создание непрерывного тестирования безопасности приложений:

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

Ввод в эксплуатацию:

Введите приложение в эксплуатацию и при необходимости выполните миграцию с ранее используемых приложений.
Завершите всю документацию, включая базу данных управления изменениями (CMDB) и архитектуру безопасности.

Эксплуатация и управление изменениями:

Эксплуатация должна включать руководящие принципы по управлению безопасностью приложения (например, управление патчами).
Повышайте осведомлённость пользователей о безопасности и управляйте конфликтами между удобством использования и безопасностью.
Планируйте и управляйте изменениями, например переходом на новые версии приложения или других компонентов — ОС, middleware и библиотек.
Убедитесь, что все приложения внесены в инвентарь со всеми важными задокументированными деталями. Обновляйте всю документацию, включая CMDB и архитектуру безопасности, средства контроля и контрмеры, а также любые runbook или проектную документацию.
Обеспечьте журналирование, мониторинг и оповещение для всех приложений. Добавьте их там, где они отсутствуют.
Создайте процессы для эффективного и результативного обновления и применения патчей.
Создайте регулярные расписания сканирования (в идеале — динамического, статического, поиска секретов, IaC и анализа состава ПО).
SLA для исправления уязвимостей безопасности.
Предоставьте сотрудникам (и в идеале клиентам) способ сообщать об ошибках.
Создайте обученную команду реагирования на инциденты, понимающую, как выглядят атаки на программное обеспечение, с инструментами наблюдаемости.
Запускайте блокирующие или экранирующие инструменты для остановки автоматизированных атак.
Ежегодное (или более частое) ужесточение конфигураций.
Не реже одного раза в год — тестирование на проникновение (в зависимости от требуемого уровня надёжности приложения).
Разработайте процессы и инструменты для укрепления и защиты цепочки поставок программного обеспечения.
Создайте и обновляйте планы обеспечения непрерывности бизнеса и аварийного восстановления, включающие ваши наиболее важные приложения и инструменты, используемые для их поддержки.

Вывод из эксплуатации:

Необходимые данные должны быть заархивированы. Все остальные данные должны быть надёжно удалены.
Безопасно выведите приложение из эксплуатации, включая удаление неиспользуемых учётных записей, ролей и разрешений.
Установите статус приложения «выведено из эксплуатации» в CMDB.

Использование OWASP Top 10 в качестве стандарта

OWASP Top 10 — прежде всего документ для повышения осведомлённости. Тем не менее это не помешало организациям использовать его в качестве де-факто отраслевого стандарта AppSec с момента его появления в 2003 году. Если вы хотите использовать OWASP Top 10 как стандарт кодирования или тестирования, знайте: это абсолютный минимум и лишь отправная точка.

Одна из сложностей использования OWASP Top 10 в качестве стандарта заключается в том, что мы документируем риски AppSec, а не обязательно легко тестируемые проблемы. Например, A06:2025-Небезопасное проектирование выходит за рамки большинства форм тестирования. Другой пример — тестирование наличия, активности и эффективности журналирования и мониторинга, что возможно только через интервью и запрос выборки эффективных ответов на инциденты. Инструмент статического анализа кода может искать отсутствие журналирования, но определить, ведётся ли журналирование критических нарушений безопасности в бизнес-логике или контроле доступа, может быть невозможно. Тестировщики на проникновение могут лишь определить, что они спровоцировали реагирование на инциденты в тестовой среде, которая редко мониторируется так же, как производственная.

Вот наши рекомендации о том, когда уместно использовать OWASP Top 10:

Случай использования	OWASP Top 10 2025	OWASP Application Security Verification Standard
Повышение осведомлённости	Да
Обучение	Начальный уровень	Комплексный
Проектирование и архитектура	Иногда	Да
Стандарт кодирования	Минимум	Да
Ревью безопасного кода	Минимум	Да
Чеклист для ревью коллег	Минимум	Да
Модульное тестирование	Иногда	Да
Интеграционное тестирование	Иногда	Да
Тестирование на проникновение	Минимум	Да
Поддержка инструментов	Минимум	Да
Безопасная цепочка поставок	Иногда	Да

Мы рекомендуем всем, кто хочет принять стандарт безопасности приложений, использовать OWASP Application Security Verification Standard (ASVS), поскольку он разработан для возможности верификации и тестирования и может применяться на всех этапах жизненного цикла безопасной разработки.

ASVS является единственно приемлемым выбором для поставщиков инструментов. Инструменты не могут всесторонне обнаруживать, тестировать или защищать от всего OWASP Top 10 в силу природы ряда рисков, в частности A06:2025-Небезопасное проектирование. OWASP не рекомендует заявлять о полном покрытии OWASP Top 10, поскольку это попросту неправда.