Безопасная разработка » История » Редакция 5
Редакция 4 (С. Антошкин, 03.06.2026 09:35) → Редакция 5/12 (С. Антошкин, 03.06.2026 11:41)
{{>TOC}}
h1. Безопасность в разработке программного обеспечения
h2. Введение
По данным исследований, более 70% успешных кибератак эксплуатируют уязвимости в программном коде, а не в сетевой инфраструктуре. При этом устранение уязвимости на этапе проектирования обходится в 30--100 раз дешевле, чем после выпуска продукта.
Традиционный подход «сначала разработаем, потом проверим безопасность» перестал работать. Он порождает два хронических сбоя: безопасность приходит слишком поздно, когда архитектурные решения уже закреплены, и работает в режиме блокировщика, тормозя выпуск. Оба сбоя ведут к одному результату—безопасность игнорируется под давлением сроков.
bq. Безопасность в разработке (Secure Software Development)—это подход, при котором требования, практики и инструменты ИБ(Информационная безопасность) интегрируются в каждый этап жизненного цикла создания программного обеспечения, а не добавляются к уже готовому продукту.
Этот подход известен под несколькими названиями: Secure SDLC(Software Development Life Cycle), DevSecOps, «сдвиг влево» (Shift Left Security). По сути, все они описывают одно: безопасность должна присутствовать с первого дня разработки.
---
h2. Жизненный цикл разработки и меры безопасности
Жизненный цикл разработки ПО(Программное обеспечение) (SDLC) состоит из нескольких фаз. Ключевой принцип безопасного SDLC—на каждой фазе существуют специфические меры безопасности, которые дешевле и эффективнее применять именно здесь, а не переносить на более поздние этапы.
!clipboard-202606031235-9yttc.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
* Руководящий документ ФСТЭК России—Методология оценки безопасности ИТ (в части требований к ОУД)