Проект

Общее

Профиль

Действия
История

Wiki » ISM »

Безопасная разработка » История » Редакция 1

Редакция 1/12 | Следующее »
С. Антошкин, 03.06.2026 09:34

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

Введение

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

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

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

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

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

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

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

На этапе сбора требований к системе формулируются требования безопасности—наравне с функциональными и нефункциональными:
  • какие данные обрабатывает система и какая классификация им присвоена
  • каким регуляторным требованиям должна соответствовать система (152-ФЗ(Федеральный закон), ФЗ-187 о КИИ(Критическая информационная инфраструктура), ГОСТ(Государственный стандарт) серии 15408)
  • каков требуемый уровень доверия к безопасности продукта (в частности, нужна ли сертификация по ОУД(Оценочный уровень доверия))
  • применяется ли принцип Privacy by Design—конфиденциальность данных закладывается в архитектуру, а не добавляется потом

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

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

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

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

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

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

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

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

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

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

SCA—анализ состава ПО. Выявляет уязвимые сторонние компоненты и библиотеки. Результатом является SBOM—реестр всех компонентов продукта с версиями.

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

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

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

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

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

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

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

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

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

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

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

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

WAF / RASP—средства защиты работающего приложения от атак в режиме реального времени.

Мониторинг безопасности приложения—интеграция с SIEM, отслеживание аномалий, журналирование критических операций.

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

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

OWASP—некоммерческий фонд, публикующий открытые материалы по безопасности веб-приложений. Его наиболее известный документ—*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
A07 Authentication Failures (сбои аутентификации) Сессионные токены не инвалидируются при выходе
A08 Software Integrity Failures (нарушение целостности ПО) Загрузка обновлений без проверки подписи
A09 Logging Failures (проблемы с логированием) Неудачные попытки входа не фиксируются
A10 SSRF Сервер делает запросы к внутренним ресурсам по URL из запроса

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

ОУД 4 и Common Criteria

Что такое Common Criteria

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

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

Оценка по Common Criteria состоит из двух ключевых документов:
  • Профиль защиты (Protection Profile, PP)—типовые требования безопасности для класса продуктов, разрабатываемые независимо от конкретного изделия
  • Задание по безопасности (Security Target, ST)—документ производителя, описывающий заявленные функции и механизмы безопасности конкретного продукта

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

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

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

Уровень Название Суть проверки Применение
ОУД 1 Функционально протестированный Базовое тестирование функций безопасности Минимальная уверенность
ОУД 2 Структурно протестированный Тестирование + базовый анализ проекта Коммерческие продукты без исходного кода
ОУД 3 Методично протестированный и проверенный Тестирование + анализ проекта + поиск уязвимостей Широко применяемые коммерческие продукты
ОУД 4 Методично спроектированный, протестированный и проверенный Полный анализ проекта, независимое тестирование, поиск уязвимостей Максимальный коммерчески оправданный уровень
ОУД 5 Полуформально спроектированный и протестированный Полуформальные методы описания проекта Высокозащищённые системы
ОУД 6 Полуформально верифицированный проект и протестированный Полуформальная верификация всего проекта Системы обработки государственной тайны
ОУД 7 Формально верифицированный проект и протестированный Полная математическая формальная верификация Военные и разведывательные системы

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

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

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

ОУД 4 при этом требует:
  • полной спецификации функций безопасности на уровне проекта
  • независимого тестирования разработчика оценщиком
  • анализа уязвимостей (vulnerability analysis) с поиском очевидных уязвимостей
  • анализа исходного кода критических функций безопасности
  • тестирования глубины покрытия (coverage testing)

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

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

OWASP Software Security Framework (SSF)

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

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

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-баз для используемых компонентов в режиме реального времени

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

Это практики, которые разработчики применяют непосредственно в процессе написания кода:
  • Моделирование угроз (Threat Modeling) для каждого значимого функционального изменения
  • Стандарты безопасного кодирования, закреплённые в документах и в правилах линтеров
  • SAST-анализ, интегрированный в IDE и CI-конвейер
  • Security-ориентированный Code Review—разработчики обучены искать конкретные классы уязвимостей
  • Security unit tests—автоматические тесты, проверяющие, что конкретные механизмы безопасности работают корректно
  • Программы обучения разработчиков (Secure Coding Training): знание OWASP Top 10, типовых ошибок, специфичных для используемого стека технологий

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

Практики на этапе выпуска и эксплуатации:
  • DAST и пентест как обязательные условия выпуска значимых версий
  • Управление секретами (Secrets Management): никаких паролей и ключей в коде или переменных среды
  • Infrastructure as Code (IaC) Security—сканирование конфигураций Terraform, Helm-чартов на ошибки безопасности
  • Security Gates—автоматические условия блокировки релиза при обнаружении уязвимостей выше порога
  • Runtime Protection: WAF, RASP, защита контейнерных окружений
  • Политика ответственного раскрытия уязвимостей (VDP)—организованный канал для приёма сообщений от внешних исследователей

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

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

  • OWASP SAMM (Software Assurance Maturity Model)—модель зрелости практик безопасности ПО; позволяет оценить текущий уровень и выстроить дорожную карту улучшений
  • BSIMM (Building Security In Maturity Model)—эмпирическая модель, основанная на данных реальных организаций
  • NIST SSDF (Secure Software Development Framework, SP 800-218)—руководство NIST по практикам безопасной разработки
  • Требования ОУД 4 в части анализа уязвимостей и тестового покрытия прямо соответствуют практикам SSF в направлении Secure Development

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

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

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

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

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

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

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

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

  1. Безопасность как финальный шлюз. Тестирование безопасности только перед релизом превращает его в блокировщик и создаёт давление на «закрытие» уязвимостей любой ценой.
  1. Только автоматизация без экспертизы. SAST и DAST генерируют много ложных срабатываний. Без аналитика, разбирающегося в приоритетах, команды начинают игнорировать весь поток предупреждений.
  1. Игнорирование сторонних компонентов. Команды тщательно тестируют собственный код, но не отслеживают CVE в зависимостях. Log4Shell (CVE-2021-44228) затронула тысячи продуктов именно по этой причине.
  1. Отсутствие обучения разработчиков. Инструменты без знаний бесполезны. Разработчик, не понимающий, что такое SQL-инъекция, не исправит её, даже когда SAST об этом сообщит.
  1. «Сертификат ОУД 4 = продукт безопасен». Сертификация фиксирует состояние продукта на момент оценки. Новые уязвимости появляются постоянно. Сертификат—это оценка процесса, а не гарантия отсутствия уязвимостей навсегда.
  1. Модель угроз делается один раз. Threat Modeling должен пересматриваться при каждом значимом изменении архитектуры или бизнес-логики.

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

  • ISO/IEC 15408-1:2022 (ГОСТ Р ИСО/МЭК 15408)—Общие критерии оценки безопасности информационных технологий
  • OWASP Top 10 2021
  • OWASP Software Security Framework
  • OWASP SAMM v2 Assurance Maturity Model
  • NIST SP 800-218—Secure Software Development Framework (SSDF)
  • SLSA Framework 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
  • Руководящий документ ФСТЭК России—Методология оценки безопасности ИТ (в части требований к ОУД)

Обновлено С. Антошкин 1 день назад · 12 изменени(я, ий)