Что включить в техническое задание, чтобы не получить небезопасный продукт

Руководство для CTO, Tech Lead и AppSec-инженеров: как превратить ТЗ из формальности в реальный барьер для уязвимостей

Введение: почему вопрос ТЗ — это вопрос безопасности

Большинство уязвимостей в готовом продукте не возникают на этапе написания кода — их корни уходят глубже: в неполные требования, отсутствие модели угроз и в то, что заказчик никогда не зафиксировал ожидания по безопасности письменно. Исполнитель разрабатывает то, за что его явно спросят на сдаче. Если в ТЗ нет требования "все пользовательские данные шифруются при хранении", никто не потребует это доказать — и скорее всего этого не будет.

Согласно данным IBM Systems Sciences Institute, исправление ошибки, найденной после релиза, обходится в 4–5 раз дороже, чем та же работа на этапе проектирования, и до 100 раз дороже, чем устранение проблемы на стадии требований [1]. Это не маркетинговая цифра — это прямое следствие того, что чем дальше уязвимость ушла по жизненному циклу, тем дороже её вытаскивать.

Параллельно ландшафт угроз растёт быстрее, чем организации успевают реагировать. В 2025 году было опубликовано около 48 000 новых CVE — в среднем более 130 в день [2]. По данным IBM, средняя стоимость утечки данных в 2024 году превысила 4,88 миллиона долларов, а в США достигла рекордных 10,22 миллиона [3]. При этом, по оценкам Gartner, 45% организаций к 2025 году столкнулись с атаками на цепочку поставок программного обеспечения [4].

В этой статье мы разберём, что конкретно включать в техническое задание, чтобы выйти из разработки с продуктом, который можно реально защитить.

Часть 1. Почему ТЗ без раздела безопасности — это не ТЗ

Функциональные требования не обеспечивают безопасность

Продукт, который "работает", не является автоматически безопасным. Это критически важное разделение: система может корректно выполнять все заявленные функции и при этом хранить пароли в открытом виде, принимать SQL-инъекции, передавать токены в URL, не ротировать сессии при логине — и ни одно из этих нарушений не будет противоречить функциональному ТЗ.

OWASP формулирует это прямо: требования безопасности создают общий язык между разработчиками, командой безопасности и бизнесом [5]. "Пароли должны быть надёжными" — не требование. "Все пользовательские пароли должны содержать не менее 12 символов и проверяться по базе скомпрометированных паролей" — требование, которое можно проверить тестом [5].

Нефункциональные требования: первоклассные граждане, не опция

Нефункциональные требования (NFR) — это спецификации того, как система работает, а не что она делает. Среди них безопасность занимает особое место: согласно ISO 25010 и FURPS-модели, неудовлетворённое нефункциональное требование по безопасности способно сделать всю систему непригодной к использованию [6].

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

Стоимость игнорирования: три уровня потерь

Первый уровень — прямые финансовые потери от инцидентов и штрафов за несоответствие регуляторным требованиям. Второй — технический долг: продукт с архитектурными уязвимостями потребует дорогостоящего рефакторинга, а не локальных патчей. Третий — репутационный ущерб и потеря клиентов. По данным Sophos, 63% инцидентов с ransomware в 2024 году начинались с эксплуатации программных уязвимостей — дефектов, которые не были устранены из-за того, что никто не сформулировал требование к патч-менеджменту [4].

Часть 2. Опорные стандарты: что взять за основу

Перед тем как переходить к конкретным пунктам ТЗ, важно понять, на какой нормативной базе они строятся. Выдумывать требования "с нуля" не нужно — профессиональное сообщество уже сделало эту работу.

OWASP ASVS 5.0 — каталог требований для веб и API

OWASP Application Security Verification Standard в версии 5.0, выпущенной в мае 2025 года, содержит около 350 детализированных требований, организованных в 17 глав — от аутентификации и управления сессиями до безопасности файловых операций и GraphQL [7]. Структура трёхуровневая: L1 — базовые контроли для любого приложения, L2 — для систем с конфиденциальными данными, L3 — для критически важных систем.

ASVS служит трём целям одновременно: как основа для разработки требований в ТЗ, как чеклист для разработчиков и как стандарт для аудиторов при приёмке [7]. Это означает, что ссылка на конкретный идентификатор требования ASVS (например, v5.0.0-2.1.3) создаёт однозначный трассируемый артефакт между ТЗ и тестовыми кейсами.

NIST SSDF — фреймворк для процессов разработки

NIST Special Publication 800-218 "Secure Software Development Framework" описывает не конкретные технические контроли, а практики безопасной разработки, которые должны быть интегрированы в жизненный цикл [8]. В декабре 2025 года NIST выпустил публичный черновик версии 1.2 SSDF, отражающий новые угрозы в цепочке поставок и требования Executive Order 14306 [8].

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

CISA Secure by Design — принципы для закупки

CISA совместно с 17 международными партнёрами сформулировала принципы Secure by Design: безопасность — это ответственность производителя, а не заказчика; конфигурация "из коробки" должна быть безопасной по умолчанию; прозрачность и CVE-политика — обязательны [9]. В августе 2024 года CISA выпустила отдельное руководство "Secure by Demand" — для покупателей ПО, с конкретными вопросами для оценки поставщика [9].

Практическое значение: включив в ТЗ требование о соответствии принципам Secure by Design, заказчик перекладывает ответственность за архитектурные решения туда, где она должна находиться — на исполнителя.

ГОСТ 34.602-2020 и локальный контекст

В России разработка ТЗ на автоматизированные системы регулируется ГОСТ 34.602-2020. Стандарт предусматривает раздел "Требования к надёжности" и "Требования безопасности", но их содержание заказчик определяет самостоятельно. Для систем, обрабатывающих персональные данные, дополнительно применяются приказ ФСТЭК № 21 и Постановление Правительства РФ № 1119, задающие состав технических мер защиты в зависимости от уровня защищённости [10].

Совмещение структуры ГОСТ с содержательными требованиями OWASP ASVS и NIST SSDF — рабочая модель для российских команд: форма соответствует локальному регулятору, содержание — международному стандарту.

Часть 3. Модель угроз как обязательное приложение к ТЗ

Почему ТЗ без модели угроз — это стрельба вслепую

Набор требований безопасности, написанный без анализа угроз конкретной системы, с высокой вероятностью будет либо избыточным в одних местах, либо содержать критические пробелы в других. Модель угроз отвечает на четыре вопроса: что мы строим, что может пойти не так, что мы будем с этим делать и достаточно ли мы это сделали [11].

STRIDE как рабочая методика для ТЗ

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) — это структурированный способ перебора угроз для каждого компонента системы на основе диаграммы потоков данных (DFD). Применение STRIDE не требует специализированного инструментария: достаточно начертить DFD на уровне компонентов и по каждой границе доверия задать шесть вопросов из акронима.

Для PASTA (Process for Attack Simulation and Threat Analysis) подход риск-ориентированный: анализ начинается с бизнес-целей и моделирования сценариев атак, что делает эту методику более удобной для сложных корпоративных систем [11].

Что фиксировать в ТЗ

В ТЗ следует зафиксировать требование о проведении модели угроз (кем, в каком формате, на каком этапе проекта) и о представлении её результатов заказчику для согласования. Минимальный состав артефакта: диаграмма потоков данных, перечень актуальных угроз с оценкой риска, перечень принятых контрмер и обоснование принятых рисков. OWASP рекомендует проводить моделирование угроз как часть дизайн-ревью и не реже чем раз в цикл при значительных архитектурных изменениях [12].

Часть 4. Конкретные блоки требований: что именно писать

Ниже — практические формулировки для основных доменов безопасности. Каждое требование должно быть измеримым, привязанным к стандарту и иметь критерий приёмки.

4.1 Аутентификация и управление сессиями

Размытые требования не работают. Вот примеры конкретных формулировок, основанных на OWASP ASVS 5.0 и Secure Coding Practices:

• Пароли пользователей хранятся исключительно в хешированном виде с использованием bcrypt, Argon2id или scrypt с минимальным cost-фактором, соответствующим актуальным рекомендациям NIST.
• При успешной аутентификации генерируется новый идентификатор сессии; старый идентификатор немедленно инвалидируется (защита от session fixation).
• Сессия завершается после периода неактивности не более 15 минут для привилегированных функций и не более 8 часов для обычных пользователей.
• Многофакторная аутентификация обязательна для административных функций и всех операций с персональными данными.
• Идентификаторы сессий не передаются в URL, не логируются и не включаются в сообщения об ошибках [13].

CISA Secure by Design дополнительно требует: MFA, SSO и журналирование должны быть доступны по умолчанию без дополнительной платы — это стало одним из семи целей Secure by Design Pledge [9].

4.2 Авторизация и принцип минимальных привилегий

• Каждый эндпоинт API и функция системы имеет явно задокументированную матрицу доступа по ролям (RBAC или ABAC).
• Проверки авторизации выполняются на серверной стороне при каждом запросе; клиентские проверки рассматриваются только как UX-улучшение, а не контроль доступа.
• Доступ к административным функциям требует отдельного токена или повторной аутентификации и фиксируется в журнале.
• Принцип "отказ по умолчанию": если разрешение явно не предоставлено, доступ запрещён.
• Горизонтальные проверки авторизации (Insecure Direct Object Reference) реализованы для всех операций с пользовательскими ресурсами.

4.3 Шифрование и защита данных

Требования должны указывать конкретные алгоритмы и параметры — без этого разработчик выберет "что-то работающее":

• Все чувствительные данные (персональные данные, платёжная информация, токены аутентификации) шифруются при хранении с использованием AES-256 [5].
• Передача данных осуществляется исключительно по TLS 1.2 или выше; TLS 1.0/1.1 и SSL запрещены.
• Ключи шифрования не хранятся рядом с зашифрованными данными; ротация ключей предусмотрена архитектурно.
• Секреты (API-ключи, пароли к базам данных, сертификаты) не помещаются в исходный код, конфигурационные файлы в репозитории или переменные окружения в образах контейнеров.
• Для управления секретами используется специализированное хранилище (Vault, AWS Secrets Manager или аналог) с аудит-логом всех операций.

4.4 Валидация входных данных и защита от инъекций

OWASP Top 10:2025 сохраняет инъекции в числе критических уязвимостей [12]. Требования в ТЗ:

• Все входные данные от пользователей валидируются по принципу "белого списка" (разрешено только то, что явно допустимо), а не "чёрного списка".
• Взаимодействие с базой данных осуществляется исключительно через параметризованные запросы или ORM; конкатенация строк SQL запрещена.
• Выходные данные, отображаемые в браузере, проходят контекстно-зависимое экранирование (HTML, JavaScript, URL — каждый контекст отдельно).
• Загружаемые файлы валидируются по MIME-типу через сигнатуру файла (не по расширению), хранятся вне веб-корня и обрабатываются в изолированном контексте.
• Размер и тип входных данных ограничены на уровне приложения и не только на уровне инфраструктуры.

4.5 Журналирование и мониторинг

Логи — единственный инструмент расследования инцидентов. Требования:

• Система журналирует все события безопасности: успешные и неуспешные аутентификации, изменения прав доступа, административные операции, критические ошибки приложения.
• Логи содержат: временну́ю метку (UTC), идентификатор пользователя или сессии, IP-адрес, тип события, результат. Пароли, секреты и полные номера карт в логах отсутствуют.
• Журналы защищены от модификации и удаления пользователями приложения; доступ к ним ограничен и аудируется.
• Предусмотрен механизм экспорта в SIEM; формат структурированный (JSON или CEF) [13].
• Критические события безопасности генерируют оповещения; порог срабатывания документирован.

4.6 Обработка ошибок и информационная безопасность

• Сообщения об ошибках для конечного пользователя не содержат технических деталей: стек-трейсов, имён таблиц, внутренних путей, версий компонентов.
• Коды ошибок HTTP однотипны для несуществующих ресурсов и ресурсов с запрещённым доступом (нельзя определить факт существования объекта по коду ответа).
• Все исключения логируются на серверной стороне с полной диагностической информацией — только для внутреннего использования.

Часть 5. Безопасность цепочки поставок в ТЗ

Это тема, которую большинство ТЗ игнорируют полностью — и именно здесь сегодня сосредоточен один из самых высоких рисков.

Почему зависимости — это часть вашей ответственности

Атаки на цепочку поставок ПО выросли на 650% в период 2020–2021 годов, и тренд продолжается [4]. История с Log4Shell наглядно показала: организации, не имевшие инвентаризации зависимостей, тратили дни на выявление затронутых компонентов, тогда как команды с SBOM справлялись за минуты [14].

SBOM как обязательный артефакт

Software Bill of Materials (SBOM) — машиночитаемый реестр всех компонентов, библиотек и зависимостей программного продукта, включая транзитивные. С 2021 года SBOM включён в обязательные требования для ПО, поставляемого федеральным агентствам США (Executive Order 14028). Евросоюз через Cyber Resilience Act обязал производителей предоставлять SBOM с сентября 2026 года [15].

Что включать в ТЗ:

• Исполнитель обязан предоставить SBOM в формате SPDX или CycloneDX в конце каждого спринта и при релизе.
• SBOM включает прямые и транзитивные зависимости с указанием версии, лицензии и источника.
• Новые зависимости добавляются только после явного согласования с командой безопасности или согласно политике в пайплайне.
• Зависимости с известными критическими CVE (CVSS ≥ 9.0) блокируют сборку до устранения или явного принятия риска.

Требования к CI/CD-конфигурации

Конфигурационные файлы пайплайна, Dockerfile, Helm-чарты и IaC-скрипты — такой же код, который нужно контролировать. В ТЗ следует зафиксировать:

• SAST-инструмент интегрирован в CI/CD и проверяет каждый pull request; критические находки блокируют merge.
• SCA-инструмент сканирует зависимости на известные уязвимости при каждой сборке.
• Образы контейнеров сканируются перед деплоем; использование образов с критическими уязвимостями запрещено.
• Секреты не передаются через переменные окружения в манифестах сборки и не логируются в артефактах CI/CD.
• Изменения в конфигурации инфраструктуры проходят ревью безопасности наравне с кодом.

Именно здесь — в дифах, конфигах и зависимостях pull request — сегодня концентрируется риск, который часто не виден при поверхностном ревью. Инструменты вроде HighVibe решают эту задачу: анализируют конкретное изменение и связанный контекст перед merge, объясняют проблему простым языком и предлагают следующий шаг — без тотального сканирования всего репозитория без повода.

Часть 6. Требования к тестированию безопасности

Без критериев проверки ТЗ по безопасности невозможно принять работу. Раздел "Требования к тестированию" должен быть конкретным.

Состав обязательного тестирования

• SAST (статический анализ кода): проводится в CI/CD при каждом PR; результаты критических и высоких уязвимостей предоставляются заказчику; найденные критические issues закрываются до релиза.
• DAST (динамическое тестирование): проводится на staging-окружении перед каждым major-релизом; область покрытия согласована с заказчиком.
• Ревью конфигурации безопасности: проверка настроек TLS, HTTP Security Headers, политик CORS, конфигурации контейнеров.
• Penetration testing: для систем уровня L2 и выше по OWASP ASVS — ежегодно или после значительных архитектурных изменений.

Acceptance criteria: как формулировать критерии приёмки

Каждое требование безопасности должно иметь верифицируемый тест. Примеры из OWASP SAMM и ASVS [5]:

• "Система генерирует новый идентификатор сессии при аутентификации" → тест: выполнить вход, зафиксировать session ID до и после логина, убедиться в их различии.
• "SQL-инъекции блокируются" → тест: выполнить стандартные инъекционные payload против всех форм ввода, убедиться в корректной обработке.
• "Чувствительные данные не попадают в логи" → тест: создать запрос с полем пароля, проверить логи приложения на наличие значения.

Привязка требований к конкретным тест-кейсам — это то, что превращает раздел безопасности ТЗ из декларации в операциональный документ.

Часть 7. Требования к инфраструктуре и деплойменту

Конфигурация по умолчанию должна быть безопасной

CISA и международные партнёры зафиксировали это как принцип: продукт должен поставляться в безопасной конфигурации "из коробки" [9]. В ТЗ это переводится в конкретные требования:

• Отладочные режимы, verbose-логирование и development-конфигурации отключены в production-сборке по умолчанию.
• Неиспользуемые порты, сервисы и функции отключены — не "могут быть отключены", а именно отключены в поставляемом продукте.
• Учётные записи по умолчанию удалены или требуют обязательной смены пароля при первом входе.
• Документация к конфигурации безопасности предоставляется в составе поставки.

Патч-менеджмент и жизненный цикл обновлений

Требования, которые часто упускают:

• Исполнитель предоставляет гарантированный срок поддержки безопасных обновлений (не менее 12/24/36 месяцев — в зависимости от типа системы).
• Критические уязвимости устраняются в течение 72 часов с момента публикации CVE; высокие — в течение 30 дней.
• Процесс раскрытия уязвимостей (vulnerability disclosure policy) описан и доступен.
• Зависимости актуализируются согласно регламенту (не реже чем раз в квартал для некритических, немедленно для критических).

Часть 8. Типичные ошибки при написании требований безопасности

Ошибка 1: Требования-намерения без измеримых критериев

"Система должна быть защищена от несанкционированного доступа" — это не требование. У него нет критерия выполнения, нет теста, нет ответственного за верификацию. Каждое требование должно следовать принципу SMART [16]: конкретное, измеримое, достижимое, релевантное, ограниченное сроком.

Ошибка 2: Безопасность как отдельный раздел, а не сквозной принцип

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

Ошибка 3: Отсутствие класса конфиденциальности данных

Перед написанием требований к защите необходимо классифицировать данные: какие данные система обрабатывает, какова их чувствительность, какие регуляторные рамки применяются. Требования к системе, работающей с платёжными данными (PCI DSS), принципиально отличаются от требований к внутреннему корпоративному инструменту без персональных данных.

Ошибка 4: Игнорирование supply chain и зависимостей

Подавляющее большинство ТЗ не содержит ни слова об управлении зависимостями, SBOM или политике использования open source. Это критический пробел в 2025 году — атаки на supply chain стали стандартным вектором, а не экзотикой [4].

Ошибка 5: Безопасность только как технический раздел, без организационных требований

Технические контроли неполны без операционных: обучение разработчиков, процесс code review с участием security champion, регламент обработки инцидентов, ответственные за каждую категорию требований. Если этого нет в ТЗ, это не будет сделано.

Часть 9. Decision framework: с чего начать

Практический порядок работы с ТЗ на безопасность:

1. Классифицировать данные: определить, какие данные обрабатывает система, их чувствительность и применимое регулирование (ФЗ-152, PCI DSS, HIPAA и т.д.).
2. Определить уровень ASVS: L1 для большинства систем, L2 для систем с конфиденциальными данными, L3 для финансовых/медицинских/критических систем.
3. Провести или заказать модель угроз: STRIDE для технических команд, PASTA для риск-ориентированного подхода.
4. Написать требования по доменам: аутентификация, авторизация, шифрование, валидация входных данных, логирование, supply chain, конфигурация.
5. Для каждого требования — критерий приёмки и тест.
6. Зафиксировать требования к тестированию безопасности: SAST в CI/CD, DAST перед релизом, pentest по расписанию.
7. Добавить операционные требования: SBOM, патч-менеджмент, обучение, инцидент-менеджмент.
8. При работе с внешним исполнителем: запросить соответствие NIST SSDF, наличие AppSec-процессов и политики раскрытия уязвимостей.

Заключение: безопасный продукт начинается с текста документа

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

Хорошее ТЗ по безопасности — это не 50 страниц запретов. Это набор конкретных измеримых требований по каждому домену, привязанных к стандартам (OWASP ASVS, NIST SSDF, CISA Secure by Design), с критериями приёмки и тест-кейсами. Именно такой документ можно использовать при сдаче работ, аудите и расследовании инцидентов.

Сегодня, когда AI-кодинг ускоряет разработку, а pull request никто не дочитывает до конца — контроль на уровне изменений становится необходимым дополнением к требованиям ТЗ. Инструменты вроде HighVibe встраиваются в этот процесс: анализируют конкретный дифф и зависимости перед merge, дают короткий понятный сигнал команде и останавливают только действительно критичные изменения — не заменяя AppSec-стек, а работая как дополнительный слой контроля до слияния и релиза.

Безопасный продукт начинается не в коде — он начинается с текста документа.

Источники

[1] Black Duck (Synopsys) — "Cost to Fix Bugs During Each SDLC Phase" — https://www.synopsys.com/blogs/software-security/cost-to-fix-bugs-during-each-sdlc-phase.html

[2] Expert Insights — "Software Vulnerability Statistics and Trends 2025" — https://expertinsights.com/network-management/software-vulnerability-statistics-and-trends-2025

[3] AppSec Santa — "Software Vulnerability Statistics 2026" — https://appsecsanta.com/research/software-vulnerability-statistics

[4] Fortinet — "Top Cybersecurity Statistics: Facts, Stats and Breaches for 2025" — https://www.fortinet.com/resources/cyberglossary/cybersecurity-statistics

[5] Codific — "Software Security Requirements Explained: Why It Matters and How to Implement It Effectively" — https://codific.com/mastering-owasp-samm-security-requirements-explained/

[6] Ardura Consulting — "Non-functional Requirements" — https://ardura.consulting/glossary/non-functional-requirements/

[7] Security Compass — "What Is OWASP ASVS?" — https://www.securitycompass.com/blog/what-is-owasp-asvs/

[8] NIST — "Secure Software Development Framework (SSDF) Version 1.2 is Available for Public Comment" — https://www.nist.gov/news-events/news/2025/12/secure-software-development-framework-ssdf-version-12-available-public

[9] CISA — "Secure by Design" — https://www.cisa.gov/resources-tools/resources/secure-by-design

[10] b-152.ru — "Разработка технического задания на создание системы защиты информации" — https://b-152.ru/razrabotka-tekhnicheskogo-zadaniya-na-sozdanie-sistemy-zashchity-informacii

[11] Glabit.ru — "Методики построения модели угроз информационной безопасности" — https://glabit.ru/blog/metodiki-postroeniya-modeli-ugroz-informatsionnoy-bezopasnosti

[12] OWASP — "Establishing a Modern Application Security Program — OWASP Top 10:2025" — https://owasp.org/Top10/2025/0x03_2025-Establishing_a_Modern_Application_Security_Program/

[13] OWASP — "Secure Coding Practices Checklist" — https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/05-checklist

[14] Wiz — "SBOM: How it Works, What it Includes, and How to Implement" — https://www.wiz.io/academy/application-security/software-bill-of-material-sbom

[15] OpenSSF — "Global Alignment on SBOM Standards: EU CRA and OpenSSF" — https://openssf.org/blog/2025/10/22/sboms-in-the-era-of-the-cra-toward-a-unified-and-actionable-framework/

[16] Perforce — "Non-Functional Requirements: Tips, Tools, and Examples" — https://www.perforce.com/blog/alm/what-are-non-functional-requirements-examples