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

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

Зачем вообще писать это в ТЗ

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

Разработчики ПО в Agile-командах годами фиксируют похожую проблему: нефункциональные требования (к которым относится и безопасность) хуже документируются, чем функциональные, легко теряются в бэклоге и проверяются только на словах [14]. NIST формулирует это с другой стороны: цель в том, чтобы требования безопасности были известны на всех этапах жизненного цикла разработки и не терялись при передаче между командами [1].

Для CTO, тимлида или человека, который заказывает разработку у подрядчика, практический вывод простой: если требование нельзя проверить при приёмке — оно не сработает как требование. Дальше — что именно стоит превратить в проверяемые пункты ТЗ.

Базовый принцип: безопасность как набор нефункциональных требований

Security — классический пример нефункционального требования (NFR): оно не описывает конкретную фичу, а задаёт качество системы в целом — производительность, масштабируемость, безопасность и удобство использования [15].

Здесь есть две крайности, и обе вредны для ТЗ:

1. Недоспецифицировать — оставить общую формулировку, понадеявшись на «здравый смысл» подрядчика.
2. Переспецифицировать — вписать сотни requirements уровня enterprise-банка в лендинг с формой обратной связи.

Профильные методологии прямо указывают на эту вилку: решение может оказаться слишком дорогим или нежизнеспособным, если требования переспецифицированы; если недоспецифицированы — система может оказаться непригодной для предполагаемого использования [13]. Поэтому правильный подход — не «максимум требований», а требования, соразмерные данным и рискам конкретного проекта.

Практический способ соразмерить требования — отталкиваться от уровня критичности. Например, OWASP ASVS изначально построен на уровнях верификации (L1/L2/L3) именно для того, чтобы не предъявлять к простому сайту требования уровня платёжной системы.

Берите за основу готовый стандарт, а не пишите список с нуля

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

NIST SSDF (SP 800-218). Framework описывает практики безопасной разработки на уровне процесса: какие требования к коду, инфраструктуре разработки и проверке уязвимостей должны быть определены до начала работы. Фреймворк организует практики в четыре группы: подготовка организации, защита программного обеспечения, производство защищённого ПО и реагирование на уязвимости [16]. Это хорошая база для раздела ТЗ «процессные требования к разработке»: кто отвечает за security review, как фиксируются и закрываются найденные уязвимости, какой статус у требований к моменту релиза.

OWASP ASVS. Это куда более прикладной документ — конкретные проверяемые требования к самому приложению: аутентификация, управление сессией, контроль доступа, обработка ошибок, работа с файлами, безопасность API и усиление конфигурации [4]. Организации используют его как спецификацию того, что значит «безопасно» в их среде. Версия 5.0 вышла в мае 2025 года и включает около 350 требований в 17 главах, разбитых по уровням строгости [17]. Для ТЗ не нужно копировать весь документ — достаточно сослаться на конкретные главы и уровень (L1 для типового продукта, L2–L3 для систем с финансовыми операциями или чувствительными данными) и включить выдержку требований приложением к ТЗ.

Важная техническая деталь: ASVS-требования можно прямо трассировать в спецификацию требований к ПО — требования выводятся из требований ASVS, связываются с ними через тип связи satisfaction, а покрытие применимых требований анализируется через матрицу трассируемости [18].

Что обязательно прописать по разделам

1. Обработка данных: классификация, шифрование, доступ

Прежде чем требовать «шифрование» вообще, нужно понять, какие данные система обрабатывает — это определяет, какие меры пропорциональны. Классификация данных назначает уровень чувствительности на основе регуляторного статуса, бизнес-влияния и требований доступа; каждый уровень привязывается к конкретным контролям — для данных ограниченного доступа это многофакторная аутентификация, шифрование при передаче и хранении, аудит-логирование [19].

Минимальный набор пунктов для ТЗ:

• какие категории данных обрабатываются (персональные, платёжные, коммерческая тайна) и их классификация;
• требование шифрования данных при хранении и при передаче, с указанием минимально допустимого протокола (например, TLS 1.2+);
• требования к управлению доступом по принципу наименьших привилегий;
• требование к логированию обращений к чувствительным данным.

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

2. Аутентификация, авторизация, управление сессиями

Это одна из самых проработанных областей в ASVS — и одна из самых частых причин реальных инцидентов. В ТЗ стоит явно зафиксировать: политику паролей и MFA, корректную работу с сессиями (таймауты, инвалидация при выходе), модель ролей и разграничение доступа на уровне сервиса, а не только интерфейса. Пример формулировки уровня требования — из практики применения ASVS в проде: если строится приложение с разными ролями пользователей, разработчики проверяют требования главы V4 ASVS вроде того, что приложение применяет правила контроля доступа на доверенном уровне сервиса, и проектируют систему соответствующим образом [20].

3. Supply chain и зависимости

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

Базовый инструмент здесь — SBOM (Software Bill of Materials), машиночитаемый список компонентов с версиями. SBOM должен включать базовую информацию о каждом компоненте: поле данных для каждого компонента, включая имя поставщика, имя компонента, версию, зависимости, автора данных SBOM и временную метку [6]. NTIA и последующие регуляторные требования формализуют это как минимальный набор полей и форматов — приемлемые стандартные форматы в настоящее время включают SPDX, CycloneDX и SWID [5].

Что стоит включить в ТЗ по этому блоку:

• требование предоставить SBOM для релиза (или генерировать его автоматически в CI);
• требование на фиксацию версий зависимостей (lock-файлы) и запрет на «плавающие» версии в проде;
• регулярное сканирование зависимостей на известные уязвимости (SCA) как часть процесса релиза, а не разовая проверка;
• ответственность за обновление компонентов с критическими уязвимостями в оговорённый срок.

4. Отдельно — риски ИИ-кодинга и халлюцинированные зависимости

Если в проекте используются AI-ассистенты для написания кода (а это сегодня почти любой проект), в ТЗ стоит явно отразить специфичный для этого риск. Исследование 2025 года, охватившее около 576 000 сгенерированных образцов кода на Python и JavaScript, показало, что примерно в 20% случаев рекомендованные пакеты не существовали [7]. Это создало новый класс атаки — slopsquatting, когда злоумышленники заранее регистрируют пакеты с именами, которые модели склонны «придумывать»: следующий разработчик, использующий ИИ-ассистента и получивший ту же рекомендацию, не увидит ошибки — вместо этого его сборка успешно скачает зависимость; с точки зрения разработчика код «магически» заработал, но под капотом был установлен вредоносный пакет [21].

Риск усиливается практикой «vibe coding», когда сгенерированный код принимается с минимальной проверкой: культурный сдвиг в сторону vibe coding, когда разработчики описывают желаемую функциональность ИИ-инструментам и принимают сгенерированные реализации с минимальной ручной проверкой, существенно усугубляет профиль риска слопсквоттинга [8]. Профильные рекомендации по митигации прямые: фиксация lock-файлов и верификация хешей пакетов должна применяться во всех CI/CD-пайплайнах, а ИИ-агентам с возможностью управления пакетами должно быть запрещено устанавливать пакеты без проверки человеком или allowlist-проверки [8].

Что добавить в ТЗ:

• требование проверять существование и происхождение пакета перед добавлением в проект, особенно если зависимость предложена ИИ-ассистентом;
• запрет на автоматическую установку новых зависимостей агентом без review;
• включение AI-сгенерированных зависимостей в общий процесс SCA/SBOM наравне с остальными.

Здесь уместно сделать отступление: именно в этой точке — между «PR выглядит рабочим» и «PR безопасен» — обычно теряется контроль. HighVibeкак раз про этот разрыв: он анализирует конкретные изменения в коде, новые и обновлённые зависимости и контекст релиза, чтобы заметить риск до merge, а не после. Это не замена SCA или SAST в CI, а дополнительный слой проверки именно того диффа, который иначе прочитают по диагонали.

5. CI/CD и секреты

Конвейер сборки и доставки часто обладает доступом к продакшен-инфраструктуре, при этом защищён хуже самого продакшена. CI/CD пайплайн часто является наиболее привилегированной системой во всей инфраструктуре: у него есть доступ к деплою в продакшен, доступ к системам управления секретами и возможность изменять работающие сервисы — и тем не менее у него зачастую более слабый контроль доступа, меньше мониторинга и меньше укрепления безопасности, чем у продакшен-систем, которые он разворачивает [10].

Базовое правило для ТЗ — относиться к CI/CD как к продакшен-среде: укрепляйте его, патчите и защищайте лежащую в основе инфраструктуру и сервисы [9].

Конкретные пункты:

• секреты не хранятся в коде и конфигурационных файлах пайплайна, а берутся из менеджера секретов;
• доступ к продакшен-секретам ограничен конкретными ветками/окружениями;
• изменения в конфигурацию пайплайна проходят review так же, как изменения в коде — требуйте одобрения merge request для любых изменений в определениях пайплайна и мониторьте вывод пайплайна на предмет утечки секретов [10];
• логи и вывод пайплайна не должны содержать секреты в открытом виде.

6. Логирование, мониторинг, реакция на инциденты

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

7. Регуляторные требования: если есть персональные данные — это отдельный трек

Если проект для российского рынка обрабатывает персональные данные, ТЗ на разработку должно быть состыковано с требованиями 152-ФЗ — это не «дополнение», а параллельный обязательный документ. На практике речь идёт о пакете: модель угроз безопасности персональных данных, акт установления уровня защищённости персональных данных, техническое задание на создание системы защиты персональных данных [11]. Основание мер защиты — статья закона: оператор обязан обеспечить безопасность персональных данных техническими и организационными мерами, в том числе использование антивирусов, шифрования, контроль доступа к базам данных [23]. Методическую базу для оценки актуальных угроз задаёт ФСТЭК: приказ ФСТЭК № 21 от 18.02.2013 определяет меры по защите информации в информационных системах, а методика определения актуальных угроз безопасности персональных данных помогает оценить риски, связанные с защитой информации [12].

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

Карта аргументов: что точно, что вероятно, что спорно

Что подтверждено стандартами и документацией:

• NIST SSDF и OWASP ASVS — общепринятые публичные источники требований безопасности разработки, на них можно ссылаться напрямую в ТЗ.
• SBOM имеет устоявшийся набор минимальных полей и форматов (SPDX, CycloneDX, SWID).
• CI/CD-секреты — зона повышенного риска, это признано индустрией как факт, а не предположение.

Что показывают исследования, но требует осторожности в обобщении:

• Цифра ~20% халлюцинированных пакетов получена на конкретном наборе моделей и языков (Python/JavaScript) в исследовании 2025 года; реальный процент для конкретного стека и конкретной модели может отличаться.

Что является рыночной практикой, а не жёстким стандартом:

• Конкретный набор уровней ASVS (L1/L2/L3), который выбрать для проекта — решение команды, стандарт не диктует это однозначно.
• HighVibe и подобные инструменты — рыночный, а не нормативный слой контроля; они дополняют, но не заменяют SAST/SCA/SBOM-практики.

Что является дискуссионным вопросом, а не фактом:

• Сколько требований безопасности фиксировать заранее в ТЗ, а сколько оставлять на итеративный пересмотр — предмет методологического спора между «secure by design с самого начала» и Agile-подходом, по которому нефункциональные требования обычно пересматриваются как часть definition of done для каждой итерации, инкремента или релиза [24].

Практический чек-лист для раздела ТЗ «Безопасность»

1. Классификация данных проекта и соответствующие требования к шифрованию (at rest / in transit).
2. Требования к аутентификации, MFA, управлению сессиями, ролевой модели — со ссылкой на конкретные главы ASVS.
3. Требование к SBOM на каждый релиз и формату (SPDX/CycloneDX).
4. Требование к SCA-сканированию зависимостей в CI с порогом критичности для блокировки релиза.
5. Политика для AI-сгенерированного кода: проверка существования пакетов, запрет автоустановки без review.
6. Требования к CI/CD: хранение секретов, доступ по окружениям, review изменений пайплайна.
7. Требования к логированию и мониторингу инцидентов с перечнем обязательных событий.
8. Ссылка на нормативную базу (для РФ — 152-ФЗ, приказы ФСТЭК), если проект обрабатывает персональные данные.
9. Критерии приёмки по безопасности как отдельный пункт в definition of done, а не общая фраза.
10. Процедура пересмотра требований безопасности на протяжении проекта, а не только на старте.

Частые ошибки

• Общая формулировка вместо проверяемого требования («обеспечить защиту данных» вместо конкретного протокола шифрования и списка событий логирования).
• Смешение «работает» и «безопасно» в критериях приёмки — функциональный тест проходит, а security review не предусмотрен вовсе.
• Игнорирование supply chain: фокус только на собственном коде команды, без контроля зависимостей и их происхождения.
• Отсутствие явной политики по AI-сгенерированному коду, хотя ассистенты уже массово используются в разработке.
• Требования безопасности фиксируются один раз на старте проекта и не пересматриваются, хотя проект и угрозы меняются.

Что делать дальше

Не пытайтесь скопировать весь ASVS или весь SSDF в ТЗ — выберите уровень, соразмерный данным и масштабу проекта, сошлитесь на конкретные главы и пункты, и зафиксируйте их как критерии приёмки, а не пожелания. Отдельно пропишите supply chain и CI/CD — это области, которые чаще всего выпадают из обсуждения, хотя именно там чаще всего и происходит реальная компрометация. Если в разработке участвует ИИ — добавьте явный пункт про проверку зависимостей, это уже не гипотетический, а задокументированный риск.

Источники

[1] Chainguard Academy — "SSDF Table Practices Tasks Notional Implementation Examples References" — https://edu.chainguard.dev/software-security/secure-software-development/ssdf/

[2] Wiz — "The Secure Software Development Framework (SSDF)" — https://www.wiz.io/academy/application-security/secure-software-development-framework-ssdf

[3] CISA — "NIST SP 800-218, Secure Software Development Framework V1.1" — https://www.cisa.gov/resources-tools/resources/nist-sp-800-218-secure-software-development-framework-v11-recommendations-mitigating-risk-software

[4] Apiiro — "What Is OWASP ASVS? Key Security Requirement & How To Use" — https://apiiro.com/glossary/owasp-asvs/

[5] NIST — "Software Security in Supply Chains: Software Bill of Materials (SBOM)" — https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20

[6] Cycode — "Software Bill of Materials (SBOM): Enhancing Transparency and Security in Supply Chains" — https://cycode.com/blog/software-bill-of-materials/

[7] BleepingComputer — "AI-hallucinated code dependencies become new supply chain risk" — https://www.bleepingcomputer.com/news/security/ai-hallucinated-code-dependencies-become-new-supply-chain-risk/

[8] Cloud Security Alliance — "Slopsquatting: AI Code Hallucinations Fuel Supply Chain Risk" — https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/CSA_research_note_slopsquatting-ai-supply-chain_20260419-csa-styled-1.pdf

[9] OWASP Cheat Sheet Series — "Secrets Management Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

[10] Infisical — "OWASP Secrets Management Cheat Sheet: What You Need to Know" — https://infisical.com/blog/owasp-secrets-management-cheat-sheet

[11] "Подготовка по 152-ФЗ «О персональных данных» — под ключ" — https://комплаенс.рф/podgotovka-po-152-fz/

[12] Staffcop — "Как выполнить требования 152-ФЗ — закона о персональных данных" — https://www.staffcop.ru/blog/kak-vypolnit-trebovaniya-152-fz-zakona-o-personalnykh-dannykh/

[13] Scaled Agile Framework — "Nonfunctional Requirements" — https://framework.scaledagile.com/nonfunctional-requirements

[14] arXiv — "An Approach for Reviewing Security-Related Aspects in Agile Requirements Specifications of Web Applications" — https://arxiv.org/pdf/1906.11432

[15] Medium (Praveen Sharma) — "Understanding Functional vs. Non-Functional Requirements in Agile" — https://medium.com/@sharmapraveen91/understanding-functional-vs-non-functional-requirements-in-agile-a-comprehensive-guide-7204b19e91a5

[16] Secure-by-Design Handbook — "NIST SP 800-218 (SSDF)" — https://www.securebydesignhandbook.com/docs/standards/us/nist-sp-800-218-ssdf-overview

[17] Codific — "OWASP ASVS: A Comprehensive Overview" — https://codific.com/owasp-asvs-a-comprehensive-overview/

[18] ReqView — "OWASP Application Security Verification Standard (ASVS) Template" — https://www.reqview.com/doc/asvs-template/

[19] Cyberhaven — "Data Classification Policy: What It Is and How to Build One" — https://www.cyberhaven.com/infosec-essentials/data-classification-policy

[20] Aikido — "OWASP ASVS Explained: Web App Security Verification Standard" — https://www.aikido.dev/learn/compliance/compliance-frameworks/owasp-asvs

[21] FOSSA — "Slopsquatting: AI Hallucinations and the New Software Supply Chain Risk" — https://fossa.com/blog/slopsquatting-ai-hallucinations-new-software-supply-chain-risk/

[22] Oligo Security — "OWASP Top 10: Cheat Sheet of Cheat Sheets" — https://www.oligo.security/academy/owasp-top-10-cheat-sheet-of-cheat-sheets

[23] IC-Tech — "Перечень документов по 152-ФЗ для организации в 2025 году" — https://ic-tech.ru/blog/knowledge-base/pdn-152fz-2025/

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