Техническое задание:
разработать,
проверить,
защитить

Два режима: лекция на проекторе и самостоятельное чтение

По умолчанию открыт режим слайдов с крупными шрифтами. Лонгрид нужен слушателю после занятия: поиск, копирование, печать и повторение.

Методичку можно скачать в формате Markdown

Раздаточный материал лежит рядом с лендингом и открывается без сервера, базы данных и внешних зависимостей.

От смысла ТЗ к проверке требований безопасности

Курс построен как инженерный маршрут: сначала понять продукт, потом написать требования, потом связать их с приемкой и РБПО.

ТЗ не заменяет проектирование. Оно фиксирует то, что уже понято

Если нет пользователя, сценариев, интерфейсов, архитектурных ограничений и модели угроз, документ будет имитировать определенность.

Виталий Александрович Пиков

Методолог, эксперт по информационной безопасности и разработке безопасного ПО (РБПО).

УЦ МАСКОМ: промышленная экспертиза в безопасности

Обучение проводится на базе одного из ведущих учебных центров страны в области защиты информации.

Обсудите ваш проект или обучение команды

Я открыт для предложений по аудиту ТЗ, внедрению процессов РБПО и корпоративному обучению.

Хорошее ТЗ пишется не для архива, а для разработки

В нем должны быть не красивые формулировки, а управляемые единицы работ: что реализуем, почему, как проверяем, кто принимает.

Фраза “все понятно” почти всегда означает, что требования еще не готовы

Понимание должно быть проверяемым: одинаковая трактовка у заказчика, аналитика, разработчика, тестировщика и специалиста по ИБ.

ТЗ связывает бизнес, разработку, испытания и эксплуатацию

Один и тот же пункт должен быть понятен разным участникам проекта, но в каждой роли он отвечает на свой вопрос.

Открывать шаблон ТЗ до проектирования — плохая привычка

Шаблон помогает оформить результат размышления. Он не должен подменять исследование продукта, пользователя, архитектуры и рисков.

Споры по ТЗ возникают не из-за объема текста, а из-за слабых требований

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

• Не смешивать пожелания и обязательства.
• Не оставлять субъективные слова без метрики.
• Не принимать требование без способа проверки.

Сначала продуктовая ясность, потом документная дисциплина

ТЗ фиксирует договоренности о продукте, а не заменяет обсуждение продукта.

Заказчик получает управляемую приемку, а не надежду

Качественное ТЗ заранее определяет, что будет считаться готовым результатом.

• Состав результата зафиксирован.
• Критерии приемки известны до разработки.
• Изменения проходят через понятный порядок.
• Скрытые работы безопасности становятся видимыми.
• Спорные трактовки можно разрешать по тексту.

Исполнитель получает границы ответственности

Четкое ТЗ защищает команду от ситуации, когда после реализации выясняется, что “имелось в виду другое”.

Неясное требование — это будущая переделка

Чем позже обнаружена неоднозначность, тем дороже ее исправление: меняется код, тесты, документация, сроки и доверие.

Безопасность нельзя “добавить потом” общим разделом

Требования безопасности должны появляться из угроз, регуляторики, архитектуры, состава компонентов и процессов разработки.

ТЗ не делает систему правильной само по себе

Документ задает проверяемую рамку. Качество появляется, когда требования связаны с архитектурой, кодом, тестами, сборкой и приемкой.

Хорошее ТЗ уменьшает неопределенность, а не увеличивает бюрократию

Если документ помогает понять, реализовать, проверить и принять результат, он работает. Если нет — это просто текст.

Нормативка не заменяет мышление, но задает проверяемый каркас

Стандарт помогает не забыть обязательные разделы, стадии, контроль и приемку. Но содержание требований все равно рождается из проекта.

ГОСТ 19.201-78: базовый язык ТЗ на программу

Подходит, когда основной объект разработки — программа, программное изделие или компонент.

ГОСТ 34.602-2020: когда важна не только программа, но и система

АС включает пользователей, процессы, данные, технические средства, интеграции, эксплуатацию и ввод в действие.

ГОСТ Р 59792-2021 связывает ТЗ с опытной эксплуатацией и приемкой

Если ТЗ не переводится в программу и методику испытаний, оно не готово к управлению результатом.

ГОСТ Р 56939-2024 добавляет в ТЗ процессы РБПО

Для безопасной разработки мало описать функции продукта. Нужно предъявить требования к процессам разработки, сборки, анализа, компонентов и поддержки.

Для НИР/ОКР процессы ГОСТ Р 56939 предъявляются явно

В ТЗ нужно не ссылаться на стандарт общими словами, а перечислять процессы, условия применимости и состав подтверждающих артефактов.

• Перечислить процессы.
• Описать условия применимости.
• Указать регламенты и проектные артефакты.
• Связать с ПМИ и приемкой.

ГОСТ Р 58412 помогает превратить угрозы в требования безопасности

Модель угроз нужна не для приложения к ТЗ, а для вывода конкретных мер, ограничений и критериев проверки.

OWASP и CWE дают язык требований для веб, API и типовых уязвимостей

Эти источники полезны, когда ГОСТ задает процесс, а проекту нужны конкретные требования к аутентификации, авторизации, сессиям, журналам и API.

Для C/C++ требования безопасности должны учитывать память, API и неопределенное поведение

В проектах системного ПО и САПР нельзя ограничиться веб-чеклистом. Нужны правила безопасного C/C++ и контроль компиляции.

• CERT C/C++ — ошибки памяти, целочисленные переполнения, обработка ошибок, API.
• MISRA C/C++ — ограничение опасных конструкций и повышенная предсказуемость кода.
• SAST и sanitizers — инструментальная проверка требований к коду.
• Compiler hardening — требования к сборочной конфигурации.

NIST SSDF помогает описывать безопасную разработку как управляемый процесс

Рамка полезна для сопоставления российских требований РБПО с понятными практиками secure software development.

ISO/IEC 27001 и 27034 связывают ТЗ с управлением безопасностью

Требования продукта должны жить в системе управления: роли, риски, контроль изменений, поставщики, инциденты и улучшения.

Выбор ГОСТа зависит от объекта: программа, система или безопасная разработка

Часто нужен не один документ, а комбинация: структура ТЗ по ГОСТ 19/34 плюс процессы безопасности по ГОСТ Р 56939.

Стандарт задает форму. Качество задает содержание

ТЗ сильное тогда, когда нормативный каркас соединен с реальными сценариями, угрозами, ограничениями и проверками.

Бизнес-цель отвечает на вопрос “зачем”

Без цели требования превращаются в набор несвязанных пожеланий. Цель задает границы, приоритеты и критерии успеха.

Пользователь — это роль, контекст и сценарий, а не абстрактный “клиент”

Требование должно быть связано с тем, кто выполняет действие, зачем и в какой ситуации.

Как <роль>, я хочу <действие>, чтобы <ценность/результат>.
Критерий: сценарий можно продемонстрировать и принять.

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

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

• Основной сценарий.
• Альтернативные сценарии.
• Ошибочные ситуации.
• Права доступа.
• Связанные данные и статусы.
• События аудита.

Интерфейс — это место, где требование становится видимым

Для UI, API и интеграций нужно заранее понимать точки взаимодействия и контракты.

Внутренняя работа системы тоже должна быть требованием

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

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

ТЗ должно отражать активы, нарушителей, поверхность атаки и меры защиты, иначе раздел безопасности будет декларативным.

Требование должно быть выполнимым в заданной архитектуре

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

• Операционные системы и платформы.
• Языки и технологический стек.
• Сетевой контур и интернет-доступ.
• Контейнеры, сборочная среда и репозитории.
• Ограничения поставки, сертификации и эксплуатации.

Минимальный комплект входов перед написанием ТЗ

Если этих материалов нет, ТЗ будет строиться на догадках и быстро начнет конфликтовать с реальностью проекта.

Если команда заполняет разделы ГОСТа без понимания продукта, ТЗ имитирует работу

Визуально документ выглядит солидно, но не отвечает на вопросы разработки и приемки.

• Нет цели — нет приоритетов.
• Нет сценариев — нет функций.
• Нет интерфейсов — нет проверяемых контрактов.
• Нет модели угроз — нет настоящей безопасности.

Семь шагов до первой версии ТЗ

Эта последовательность удерживает документ от преждевременной формализации.

1. Зафиксировать проблему и измеримый результат.
2. Описать заинтересованные стороны и роли пользователей.
3. Собрать пользовательские сценарии и бизнес-правила.
4. Разделить функциональные, нефункциональные и требования безопасности.
5. Определить интерфейсы, данные и ограничения.
6. Провести первичное моделирование угроз.
7. Согласовать критерии приемки до передачи в разработку.

ТЗ начинается не с титульного листа, а с ясности продукта

Когда входные артефакты собраны, документ становится инструментом фиксации, а не средством коллективного угадывания.

Формулировка должна задавать обязанность

Описание текущего состояния, пожелание или рассуждение не являются требованием.

Один пункт — одно требование

Если пункт нельзя проверить одним тестом или одной связанной группой проверок, его надо разделить.

• Одна функция.
• Одно свойство.
• Один критерий приемки.
• Один источник или управляемая связка источников.

Термины должны допускать одну трактовку

Если заказчик, разработчик и испытатель понимают слово по-разному, требование не готово.

У каждого требования должен быть способ проверки

Проверка может быть тестом, демонстрацией, измерением, анализом или инспекцией. Без проверки это не требование, а пожелание.

Требование должно быть выполнимым в заданных ограничениях

Реализуемость зависит от технологий, сроков, квалификации, регуляторики, контуров эксплуатации и инструментов.

• Проверить технологическую возможность.
• Проверить ресурсы и квалификацию.
• Проверить сроки и зависимость от внешних поставщиков.
• Проверить конфликт с безопасностью и архитектурой.

У требования должен быть источник

Источник объясняет, почему требование существует и кто имеет право его изменить.

Требования должны закрывать сценарий без лишнего дублирования

Пробелы создают догадки, а дубли создают конфликты при изменениях.

Требования должны смотреться как система

Конфликт может быть функциональным, архитектурным, безопасностным, эксплуатационным или договорным.

• Проверить конфликты доступа.
• Проверить конфликты производительности и безопасности.
• Проверить конфликты форматов и интерфейсов.
• Проверить конфликт сроков и состава работ.

Требование должно иметь путь от источника до приемки

Трассируемость нужна не для красоты. Она отвечает на вопрос: почему это есть, кто делает, где проверяется и чем подтверждено.

Приоритет помогает принимать инженерные решения

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

Карточка требования делает пункт управляемым

Минимальные поля должны позволять найти источник, понять формулировку, проверить выполнение и управлять статусом.

Пример: регистрация неуспешных попыток входа

Одно требование, один источник, один критерий приемки и понятный метод проверки.

SEC-REQ-014
Источник: модель угроз TM-03; ГОСТ Р 56939-2024 п. 5.3
Формулировка: система должна регистрировать все неуспешные попытки аутентификации
с указанием идентификатора пользователя, времени, IP-адреса и причины отказа.
Критерий приемки: запись появляется в журнале аудита и доступна роли администратора безопасности.
Метод проверки: функциональное испытание + инспекция журнала.
Приоритет: High.

Статус требования должен быть виден и управляем

В авторской лекции по РБПО отдельно звучит мысль: требования безопасности имеют статусы, даты, ответственных и историю изменений.

Антипаттерны нужно показывать красным

В лекции такие моменты полезно визуально выделять: аудитория должна увидеть, где начинается риск будущего спора.

Перед передачей в разработку требование проходит мини-gate

Не надо ждать конца проекта. Слабое требование дешевле исправить до постановки задач.

• Есть ID.
• Есть источник.
• Формулировка задает обязанность.
• Термины определены.
• Требование атомарно.
• Есть критерий приемки.
• Есть метод проверки.
• Нет конфликта с другими требованиями.

Качественное требование — это маленький договор внутри большого договора

Оно сообщает, что нужно сделать, почему это нужно, как проверить и как управлять изменениями.

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

Оно проверяется демонстрацией сценария или функциональным тестом.

FT-AUTH-001.
Система должна предоставлять пользователю возможность входа
по адресу электронной почты и паролю.

Нефункциональное требование задает измеримое качество или ограничение

Слова “быстро”, “удобно”, “надежно” должны быть переведены в метрики, условия и способ измерения.

NFT-PERF-001.
Время ответа API поиска не должно превышать 500 мс
для 95 процентиля запросов при нагрузке 100 одновременных пользователей.

Требование безопасности связывает угрозу, меру и проверку

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

SEC-AUTH-003.
Система должна блокировать учетную запись на 15 минут после
5 последовательных неуспешных попыток аутентификации в течение 10 минут.

Один экран — три вопроса

Если участники путаются, возвращаемся к трем диагностическим вопросам.

Требования безопасности должны иметь понятные источники

Лучше показать источники на слайде, чем оставлять безопасность как “общий раздел”.

Поверхность атаки помогает понять, где нужны требования

Требования безопасности должны закрывать реальные точки взаимодействия, а не абстрактную “защищенность”.

• Внешние API и веб-интерфейсы.
• Файловые импорты и экспорты.
• Административные операции.
• Сетевые протоколы и интеграции.
• Плагины, скрипты, макросы.
• Секреты, ключи и учетные записи.

Для C/C++ безопасность начинается с требований к коду и сборке

Если продукт пишется на C/C++, ТЗ может и должно задавать требования к SAST, sanitizers, compiler hardening и правилам кодирования.

Компоненты тоже являются частью требований безопасности и поставки

Без SCA и SBOM заказчик не понимает, что входит в продукт, какие лицензии используются и какие уязвимости уже известны.

“Безопасность добавим потом” — это архитектурный долг

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

Безопасность должна иметь критерии приемки, как и функциональность

Отчет SAST, SBOM, протокол тестирования, журнал исправлений и решение о риске — это приемочные артефакты, а не внутренние заметки команды.

• Нет неисправленных Critical/High без согласованного решения.
• Есть SBOM/PPK и отчет SCA.
• Секреты не присутствуют в репозитории и поставке.
• Сборка воспроизводима и промаркирована.
• Результаты SAST разобраны и имеют статусы.

Тип требования определяет способ проверки

Пока тип не определен, команда спорит не о реализации, а о самом смысле пункта.

5.3: формирование и предъявление требований безопасности к ПО

Это центральный процесс для темы ТЗ: требования безопасности должны быть сформированы, предъявлены, отслежены и пересмотрены.

Регламент определяет состав, порядок, ответственность и контроль

В лекции отдельно подчеркивается: регламент не должен быть формальностью, он описывает, кто, что, как и когда делает.

• Область действия процесса.
• Порядок выполнения задач.
• Ответственные лица и полномочия.
• Необходимые ресурсы и инструменты.
• Критерии качества процесса.
• Порядок контроля и эскалации.

Требование безопасности должно быть управляемой записью

ГОСТовая логика требует не только текст, но и атрибуты жизненного цикла.

Набор требований безопасности должен пересматриваться по критериям

Пересмотр нужен не только по расписанию, но и при событиях: изменениях архитектуры, угроз, компонентов, назначения ПО.

У процесса должны быть входы, действия и выходные артефакты

Вопрос аудитора: что было на входе, что сделали, что получили и где это проверяется.

Управление конфигурацией защищает требования от хаоса

Если меняется код, сборка, инструмент или требование, это должно быть управляемым изменением.

• Правила ветвления и защиты веток.
• Маркировка сборок и версий.
• Состав поставки и исходных материалов.
• Связь требований, задач и коммитов.
• Контроль изменений инструментов анализа и сборки.

Дефекты и запросы на изменение должны иметь понятный жизненный цикл

Иначе требования безопасности теряются между трекером, перепиской и устными договоренностями.

Статический анализ должен быть требованием, а не добровольной практикой

В ТЗ нужно указать профиль правил, периодичность, пороги, разбор срабатываний и финальный отчет.

Безопасная сборка — часть доверия к поставке

Если сборка не описана и не воспроизводима, трудно доказать, что поставлен именно проверенный результат.

• Описание сборочной среды.
• Состав компиляторов, инструментов и версий.
• Журналы сборки.
• Контроль целостности артефактов.
• Правила доступа к pipeline и секретам.

Доступ к исходному коду и результатам анализа должен быть ограничен

В лекции отдельно звучит вопрос: кто может читать, менять, удалять и передавать исходный код и результаты проверки.

Секреты не должны попадать в код, сборку и поставку

Требование должно описывать хранение, доступ, ротацию и проверку секретов.

• Запрет секретов в исходном коде.
• Secret scanning до merge и перед поставкой.
• Разделение тестовых и продуктивных секретов.
• Порядок ротации и отзыва.
• Журнал доступа к секретам.

Композиционный анализ показывает реальный состав продукта

ТЗ должно требовать перечень компонентов, лицензии, версии, источники, уязвимости и статус реагирования.

Функциональное тестирование должно быть связано с требованиями

Тесты не должны жить отдельно. Каждое требование получает проверку, а каждый тест имеет ожидаемый результат.

После поставки нужен порядок приема и обработки уязвимостей

Без регламента поддержки уязвимость превращается в переписку без владельца, срока и решения.

• Канал приема сообщений.
• Регистрация и triage.
• Оценка критичности.
• План исправления.
• Уведомление заказчика.
• Выпуск обновления и контроль установки.

Даже конец жизненного цикла должен быть управляемым

Пользователь должен понимать, когда прекращается поддержка, как мигрировать и что происходит с уязвимостями после EOL.

РБПО принимается по артефактам, а не по обещанию

В ПМИ нужно включить документарный контроль регламентов, отчетов, журналов и решений по рискам.

• Регламенты процессов предоставлены.
• Реестр требований безопасности актуален.
• Отчеты SAST/SCA приложены.
• SBOM/PPK сформирован.
• Журналы сборки и маркировка поставки есть.
• Отклонения имеют владельца, срок или решение о принятии риска.

РБПО в ТЗ — это перечень процессов, условий и артефактов

Если процесс не назван и артефакт не указан, приемка безопасности будет спорной.

Матрица трассируемости делает приемку управляемой

Она связывает ID требования, источник, метод проверки, пункт ПМИ и ожидаемый результат.

Метод проверки выбирается под тип требования

Нельзя все проверять демонстрацией. Безопасность и качество часто требуют анализа, измерения и инспекции.

ТЗ можно передавать в разработку только после проверки готовности

Gate нужен не для бюрократии, а для защиты проекта от неясных требований и неуправляемой безопасности.

• Цель проекта и границы работ зафиксированы.
• Роли пользователей и заинтересованные стороны описаны.
• Функциональные, нефункциональные и требования безопасности разделены.
• У каждого требования есть ID, источник и критерий приемки.
• Термины вынесены в глоссарий.
• Для ОКР процессы ГОСТ Р 56939 перечислены явно.
• Составлена матрица трассируемости ТЗ → ПМИ.

После занятия слушатель должен уйти с рабочим маршрутом

Лендинг не только показывает слайды, но и ведет к материалам, шаблонам, чек-листам и примерам.

1. Скачать методичку Markdown.
2. Открыть чек-лист качества ТЗ.
3. Выбрать шаблон под тип проекта.
4. Заполнить пять слоев продукта.
5. Сформировать требования с ID и критериями.
6. Отдельно выделить безопасность и РБПО.
7. Проверить связку ТЗ → ПМИ.

Раздаточные материалы остаются рядом с лендингом

Слушатель может открыть Markdown, чек-листы, шаблоны и примеры прямо с сайта.

Если требование нельзя принять, его нельзя отдавать в разработку

Перед финалом лекции это удобно выделить красным: аудитория должна унести строгий критерий готовности.

ТЗ — это инженерная договоренность, а не литературный документ

Курс соединяет продуктовую ясность, нормативную дисциплину, качество требований, РБПО и приемку.

Спасибо за внимание

Авторский курс по техническим заданиям, ГОСТ и разработке безопасного программного обеспечения.