УИБ / учебный курс

{{>TOC}}

h1. Безопасность в разработке программного обеспечения

h2. Введение

По данным исследований, более 70% успешных кибератак эксплуатируют уязвимости в программном коде, а не в сетевой инфраструктуре. При этом устранение уязвимости на этапе проектирования обходится в 30--100 раз дешевле, чем после выпуска продукта.

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

bq. Безопасность в разработке (Secure Software Development)—это подход, при котором требования, практики и инструменты ИБ(Информационная безопасность) интегрируются в каждый этап жизненного цикла создания программного обеспечения, а не добавляются к уже готовому продукту.

Этот подход известен под несколькими названиями: Secure SDLC(Software Development Life Cycle), DevSecOps, «сдвиг влево» (Shift Left Security). По сути, все они описывают одно: безопасность должна присутствовать с первого дня разработки.

---

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

Жизненный цикл разработки ПО(Программное обеспечение) (SDLC) состоит из нескольких фаз. Ключевой принцип безопасного SDLC—на каждой фазе существуют специфические меры безопасности, которые дешевле и эффективнее применять именно здесь, а не переносить на более поздние этапы.

!clipboard-202606031233-fpe1i.png!

h3. Фаза 1. Требования

На этапе сбора требований к системе формулируются *требования безопасности*—наравне с функциональными и нефункциональными:

* какие данные обрабатывает система и какая классификация им присвоена

* каким регуляторным требованиям должна соответствовать система (152-ФЗ(Федеральный закон), ФЗ-187 о КИИ(Критическая информационная инфраструктура), ГОСТ(Государственный стандарт) серии 15408)

* каков требуемый уровень доверия к безопасности продукта (в частности, нужна ли сертификация по ОУД(Оценочный уровень доверия))

* применяется ли принцип Privacy by Design—конфиденциальность данных закладывается в архитектуру, а не добавляется потом

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

h3. Фаза 2. Проектирование

На этапе архитектурного проектирования применяется *моделирование угроз* (Threat Modeling)—систематический процесс выявления потенциальных угроз для проектируемой системы.

Наиболее распространённые методологии:

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

* *PASTA(Process for Attack Simulation and Threat Analysis)*—ориентированный на бизнес-риски подход с семью этапами, включая имитацию атак

* *DREAD(Damage, Reproducibility, Exploitability, Affected Users, Discoverability)*—методика количественной оценки угроз

По результатам моделирования угроз формируется архитектура безопасности системы: определяются границы доверия, точки входа/выхода, хранилища данных и потоки их передачи. Закладываются принципы *наименьших привилегий* и *эшелонированной защиты* (Defense in Depth).

h3. Фаза 3. Реализация (кодирование)

На этапе написания кода применяются:

*Стандарты безопасного кодирования*—задокументированные правила для разработчиков: как обрабатывать ввод пользователя, как работать с криптографией, как избегать конкретных классов уязвимостей. Примеры: CERT Coding Standards, OWASP Cheat Sheet Series.

*Code Review с фокусом на безопасность*—ручная проверка кода коллегами с анализом уязвимостей. Особенно эффективна для логических ошибок, которые не обнаруживают автоматические инструменты.

*SAST(Static Application Security Testing)*—статическое тестирование безопасности приложений. Инструменты анализируют исходный код без его выполнения, выявляя потенциальные уязвимости: SQL-инъекции, XSS(Cross-Site Scripting), небезопасное использование криптографии. Примеры инструментов: SonarQube, Checkmarx, Semgrep.

*SCA(Software Composition Analysis)*—анализ состава ПО. Выявляет уязвимые сторонние компоненты и библиотеки. Результатом является *SBOM(Software Bill of Materials)*—реестр всех компонентов продукта с версиями.

h3. Фаза 4. Тестирование

*DAST(Dynamic Application Security Testing)*—динамическое тестирование. Инструменты взаимодействуют с работающим приложением, имитируя действия злоумышленника: отправляют вредоносные запросы, проверяют реакцию системы. Находят уязвимости, незаметные при статическом анализе: проблемы конфигурации, логические ошибки в бизнес-процессах.

*Penetration Testing (пентест)*—ручная имитация атаки профессиональными специалистами. Наиболее глубокий вид тестирования, выявляет цепочки уязвимостей и бизнес-логические проблемы. Проводится перед значимыми релизами и не реже раза в год.

*Fuzzing*—автоматизированная подача случайных и некорректных данных на вход системы для обнаружения сбоев и уязвимостей. Эффективен для API(Application Programming Interface) и парсеров.

Именно на этом этапе наиболее значимы требования стандарта ОУД 4, о котором подробно говорится ниже.

h3. Фаза 5. Выпуск и деплой

*Security Gates в CI/CD(Continuous Integration / Continuous Delivery)*—автоматические проверки, останавливающие выпуск, если найдены уязвимости выше заданного порога серьёзности. Это операциональное воплощение принципа «безопасность как код».

*Подпись артефактов*—криптографическая подпись собранных пакетов и образов контейнеров гарантирует целостность цепочки поставок (Supply Chain Security). Фреймворк SLSA(Supply-chain Levels for Software Artifacts) определяет четыре уровня зрелости этих практик.

*Hardened Configuration*—минимизация поверхности атаки: отключение неиспользуемых сервисов, применение принципа наименьших привилегий для сервисных учётных записей, шифрование данных в покое.

*Secrets Management*—секреты (пароли, токены, ключи API) не хранятся в коде или переменных среды, а управляются специализированными инструментами (HashiCorp Vault, AWS Secrets Manager).

h3. Фаза 6. Эксплуатация

*Patch Management*—систематический процесс отслеживания и своевременного применения обновлений безопасности для всех компонентов системы.

*WAF(Web Application Firewall) / RASP(Runtime Application Self-Protection)*—средства защиты работающего приложения от атак в режиме реального времени.

*Мониторинг безопасности приложения*—интеграция с SIEM(Security Information and Event Management), отслеживание аномалий, журналирование критических операций.

*VDP(Vulnerability Disclosure Policy) / Bug Bounty*—политика раскрытия уязвимостей и программы вознаграждения за найденные баги: организованные механизмы приёма сообщений от независимых исследователей.

---

h2. OWASP Top 10: наиболее критичные уязвимости веб-приложений

OWASP(Open Web Application Security Project)—некоммерческий фонд, публикующий открытые материалы по безопасности веб-приложений. Его наиболее известный документ—*OWASP Top 10*—список десяти наиболее критичных классов уязвимостей, обновляемый каждые 3--4 года.

Текущая версия OWASP Top 10 (2021):

|_.Код|_.Категория|_.Типичный пример|

|A01|Broken Access Control (нарушение контроля доступа)|Пользователь изменяет ID в URL и получает чужие данные|

|A02|Cryptographic Failures (криптографические сбои)|Пароли хранятся в открытом виде или с MD5|

|A03|Injection (инъекции)|SQL-инъекция через поле поиска|

|A04|Insecure Design (небезопасный дизайн)|Отсутствие ограничений на число попыток входа|

|A05|Security Misconfiguration (небезопасная конфигурация)|Открытый порт отладчика в продакшне|

|A06|Vulnerable Components (уязвимые компоненты)|Использование библиотеки с известной CVE(Common Vulnerabilities and Exposures)|

|A07|Authentication Failures (сбои аутентификации)|Сессионные токены не инвалидируются при выходе|

|A08|Software Integrity Failures (нарушение целостности ПО)|Загрузка обновлений без проверки подписи|

|A09|Logging Failures (проблемы с логированием)|Неудачные попытки входа не фиксируются|

|A10|SSRF(Server-Side Request Forgery)|Сервер делает запросы к внутренним ресурсам по URL из запроса|

OWASP также публикует специализированные Top 10 для API, мобильных приложений, LLM(Large Language Model)-приложений и других областей.

---

h2. ОУД 4 и Common Criteria

h3. Что такое Common Criteria

*Common Criteria* (CC, Общие критерии)—международный стандарт ISO/IEC 15408 для оценки безопасности информационных технологий. В России действует как ГОСТ Р ИСО/МЭК 15408. Стандарт определяет методологию оценки того, насколько продукт соответствует заявленным требованиям безопасности.

Common Criteria используются при сертификации средств защиты информации: межсетевых экранов, операционных систем, криптографических модулей, СУБД(Система управления базами данных) и других продуктов.

Оценка по Common Criteria состоит из двух ключевых документов:

* *Профиль защиты* (Protection Profile, PP)—типовые требования безопасности для класса продуктов, разрабатываемые независимо от конкретного изделия

* *Задание по безопасности* (Security Target, ST)—документ производителя, описывающий заявленные функции и механизмы безопасности конкретного продукта

h3. Оценочные уровни доверия (ОУД)

*Оценочный уровень доверия* (ОУД, Evaluation Assurance Level, EAL(Evaluation Assurance Level))—количественная оценка глубины проверки, проведённой в ходе сертификации. Чем выше уровень, тем тщательнее и дороже оценка.

!clipboard-202606031234-qvhrt.png!

Семь уровней ОУД:

|_.Уровень|_.Название|_.Суть проверки|_.Применение|

|*ОУД 1*|Функционально протестированный|Базовое тестирование функций безопасности|Минимальная уверенность|

|*ОУД 2*|Структурно протестированный|Тестирование + базовый анализ проекта|Коммерческие продукты без исходного кода|

|*ОУД 3*|Методично протестированный и проверенный|Тестирование + анализ проекта + поиск уязвимостей|Широко применяемые коммерческие продукты|

|*ОУД 4*|Методично спроектированный, протестированный и проверенный|Полный анализ проекта, независимое тестирование, поиск уязвимостей|*Максимальный коммерчески оправданный уровень*|

|*ОУД 5*|Полуформально спроектированный и протестированный|Полуформальные методы описания проекта|Высокозащищённые системы|

|*ОУД 6*|Полуформально верифицированный проект и протестированный|Полуформальная верификация всего проекта|Системы обработки государственной тайны|

|*ОУД 7*|Формально верифицированный проект и протестированный|Полная математическая формальная верификация|Военные и разведывательные системы|

h3. Почему ОУД 4 является практическим максимумом

ОУД 4 часто называют «практическим максимумом для коммерческих продуктов»—и это не условность, а следствие экономики оценки.

Начиная с ОУД 5, стандарт требует *полуформальных методов* описания проекта и верификации. Это означает применение специальных математических нотаций для описания архитектуры, что кратно увеличивает стоимость и сроки оценки—до нескольких лет для крупного продукта. Поддерживать такой продукт в актуальном состоянии при быстром темпе разработки практически невозможно.

ОУД 4 при этом требует:

* полной спецификации функций безопасности на уровне проекта

* независимого тестирования разработчика оценщиком

* анализа уязвимостей (vulnerability analysis) с поиском очевидных уязвимостей

* анализа исходного кода критических функций безопасности

* тестирования глубины покрытия (coverage testing)

Это достаточно строгие требования, которые реально улучшают качество продукта. Именно поэтому большинство коммерческих средств защиты информации, проходящих сертификацию по ФСТЭК(Федеральная служба по техническому и экспортному контролю) России или в рамках Common Criteria, получают сертификат ОУД 4.

bq. Для понимания: сертификация по ОУД 4 не означает, что продукт «абсолютно безопасен». Она означает, что процесс его разработки и тестирования соответствует строгим требованиям стандарта, а заявленные функции безопасности независимо проверены.

---

h2. OWASP Software Security Framework (SSF)

*OWASP Software Security Framework* (SSF(Software Security Framework))—это структурированный набор практик безопасной разработки, разработанный OWASP как практическое руководство для DevSecOps-организаций, стремящихся систематизировать свои усилия по безопасности ПО.

!clipboard-202606031235-nqfup.png!

SSF организован вокруг трёх направлений:

h3. Secure Supply Chain (безопасность цепочки поставок)

Современное ПО в значительной мере состоит из сторонних компонентов: в среднем более 70--80% кода в коммерческих приложениях—это open-source библиотеки. Атаки на цепочку поставок (Supply Chain Attacks) нацелены именно на этот вектор.

Ключевые практики:

* *SCA (Software Composition Analysis)*—автоматическое сканирование зависимостей на известные уязвимости (CVE)

* *SBOM (Software Bill of Materials)*—документированный реестр всех компонентов продукта с версиями и лицензиями; позволяет быстро оценить влияние новой уязвимости на продукт

* *SLSA (Supply-chain Levels for Software Artifacts)*—фреймворк Google для обеспечения целостности артефактов сборки; определяет уровни от 1 до 4

* Политика использования только доверенных реестров пакетов

* Мониторинг CVE-баз для используемых компонентов в режиме реального времени

h3. Secure Development (безопасная разработка)

Это практики, которые разработчики применяют непосредственно в процессе написания кода:

* Моделирование угроз (Threat Modeling) для каждого значимого функционального изменения

* Стандарты безопасного кодирования, закреплённые в документах и в правилах линтеров

* SAST-анализ, интегрированный в IDE(Integrated Development Environment) и CI-конвейер

* Security-ориентированный Code Review—разработчики обучены искать конкретные классы уязвимостей

* Security unit tests—автоматические тесты, проверяющие, что конкретные механизмы безопасности работают корректно

* Программы обучения разработчиков (Secure Coding Training): знание OWASP Top 10, типовых ошибок, специфичных для используемого стека технологий

h3. Secure Deployment (безопасный деплой)

Практики на этапе выпуска и эксплуатации:

* DAST и пентест как обязательные условия выпуска значимых версий

* Управление секретами (Secrets Management): никаких паролей и ключей в коде или переменных среды

* Infrastructure as Code (IaC) Security—сканирование конфигураций Terraform, Helm-чартов на ошибки безопасности

* Security Gates—автоматические условия блокировки релиза при обнаружении уязвимостей выше порога

* Runtime Protection: WAF, RASP, защита контейнерных окружений

* Политика ответственного раскрытия уязвимостей (VDP)—организованный канал для приёма сообщений от внешних исследователей

h3. Связь SSF с другими стандартами и фреймворками

SSF хорошо сочетается с другими стандартами безопасной разработки:

* *OWASP SAMM* (Software Assurance Maturity Model)—модель зрелости практик безопасности ПО; позволяет оценить текущий уровень и выстроить дорожную карту улучшений

* *BSIMM* (Building Security In Maturity Model)—эмпирическая модель, основанная на данных реальных организаций

* *NIST SSDF* (Secure Software Development Framework, SP 800-218)—руководство NIST(National Institute of Standards and Technology) по практикам безопасной разработки

* Требования ОУД 4 в части анализа уязвимостей и тестового покрытия прямо соответствуют практикам SSF в направлении Secure Development

---

h2. DevSecOps: операционализация безопасной разработки

*DevSecOps*—это культура и практика интеграции безопасности в DevOps-процессы, при которой каждый член команды разработки несёт ответственность за безопасность, а проверки автоматизированы и встроены в конвейер доставки.

Ключевые принципы:

*Shift Left* («сдвиг влево»)—выявлять и устранять проблемы безопасности как можно раньше в цикле разработки. Чем позже обнаружена уязвимость, тем дороже её исправление.

*Security as Code*—политики безопасности выражаются в форме кода: правила SAST, конфигурации WAF, пороги Security Gates. Это обеспечивает воспроизводимость, версионирование и автоматизацию.

*Security Champion*—разработчик внутри команды, проходящий углублённое обучение по безопасности и помогающий коллегам применять практики безопасного кодирования в ежедневной работе.

*Metrics-Driven Security*—измеримые показатели: MTTR(Mean Time to Remediate) уязвимостей (среднее время устранения), плотность уязвимостей на 1000 строк кода, процент покрытия тестами безопасности.

---

h2. Типичные ошибки при внедрении безопасной разработки

# *Безопасность как финальный шлюз.* Тестирование безопасности только перед релизом превращает его в блокировщик и создаёт давление на «закрытие» уязвимостей любой ценой.

# *Только автоматизация без экспертизы.* SAST и DAST генерируют много ложных срабатываний. Без аналитика, разбирающегося в приоритетах, команды начинают игнорировать весь поток предупреждений.

# *Игнорирование сторонних компонентов.* Команды тщательно тестируют собственный код, но не отслеживают CVE в зависимостях. Log4Shell (CVE-2021-44228) затронула тысячи продуктов именно по этой причине.

# *Отсутствие обучения разработчиков.* Инструменты без знаний бесполезны. Разработчик, не понимающий, что такое SQL-инъекция, не исправит её, даже когда SAST об этом сообщит.

# *«Сертификат ОУД 4 = продукт безопасен».* Сертификация фиксирует состояние продукта на момент оценки. Новые уязвимости появляются постоянно. Сертификат—это оценка процесса, а не гарантия отсутствия уязвимостей навсегда.

# *Модель угроз делается один раз.* Threat Modeling должен пересматриваться при каждом значимом изменении архитектуры или бизнес-логики.

---

h2. Список литературы и стандартов

* ISO/IEC 15408-1:2022 (ГОСТ Р ИСО/МЭК 15408)—Общие критерии оценки безопасности информационных технологий

* "OWASP Top 10 2021":https://owasp.org/Top10/

* "OWASP Software Security Framework":https://owasp.org/www-project-software-security-framework/

* "OWASP SAMM v2":https://owaspsamm.org/—Software Assurance Maturity Model

* NIST SP 800-218—Secure Software Development Framework (SSDF)

* "SLSA Framework":https://slsa.dev/—Supply-chain Levels for Software Artifacts

* McGraw G.—Software Security: Building Security In. Addison-Wesley, 2006

* Kim G., Humble J., Debois P.—The DevOps Handbook. IT Revolution Press, 2016

* Руководящий документ ФСТЭК России—Методология оценки безопасности ИТ (в части требований к ОУД)