Компетенции разработчиков по безопасности: что требовать и как обучать
Это цикл об обучении разработчиков безопасности:
- Программа и ресурсы (этот раздел) — что требовать
- Оценка и отслеживание — как проверять
- Руководство по внедрению — как запустить программу
- Культура и коммуникация — как закрепить результат
Разработчики создают код, который атакуют. Каждая уязвимость в вашем продукте — результат решения, принятого при написании кода. Это не вопрос квалификации в целом: разработчик может быть отличным специалистом и при этом никогда не изучавшим безопасность. Именно поэтому ответственность за то, чтобы ваша команда знала основы ИБ, лежит на руководителе.
Требовать от команды безопасной разработки без соответствующего обучения — неэффективно и несправедливо. Этот раздел даёт вам как руководителю понятный ответ на вопрос: какие компетенции по безопасности должны быть у разработчиков, откуда их взять, сколько это стоит и как убедиться, что обучение работает.
Почему это выгодно бизнесу
Раннее исправление на порядок дешевле позднего. Уязвимость, найденная разработчиком при написании кода, требует минут на исправление. Та же уязвимость в продуктиве — это остановка работы, расследование, патч, тестирование, уведомление клиентов. Разница в стоимости — в десятки раз.
ИБ-команда не масштабируется до бесконечности. Даже если у вас есть специалист по безопасности, он физически не может проверить каждый коммит при команде из 10+ разработчиков. Разработчики с базовыми знаниями по безопасности — это первая линия защиты, которую вы получаете без дополнительного найма.
SAST, DAST и другие инструменты требуют понимания. Автоматические инструменты анализа кода на уязвимости (PT Application Inspector, Solar appScreener и другие) полезны ровно настолько, насколько разработчики умеют интерпретировать их результаты и исправлять выявленные проблемы. Без базовых знаний по безопасности предупреждения инструментов игнорируются или неверно оцениваются.
Это требование рынка. Клиенты и партнёры всё чаще задают вопросы об уровне безопасности при разработке — особенно если продукт обрабатывает персональные данные или является элементом критической информационной инфраструктуры.
Структура компетенций
Прежде чем запускать обучение, определите, какой уровень знаний вы ожидаете от каждой роли. Это позволит не тратить ресурсы на подготовку экспертов там, где достаточно базовой осведомлённости.
Уровни компетенций
| Уровень | Название | Описание | Кому нужен |
|---|---|---|---|
| У1 | Осведомлённый | Понимает основные концепции безопасности, узнаёт типичные уязвимости | Все разработчики |
| У2 | Практикующий | Стабильно пишет безопасный код, участвует в code review с фокусом на безопасность | Разработчики уровня Middle и выше |
| У3 | Эксперт | Проектирует безопасные архитектуры, ведёт моделирование угроз, наставничает | Тимлиды, архитекторы |
| У4 | Лидер безопасности | Формирует культуру безопасности в команде, представляет интересы ИБ в обсуждениях | лидер безопасности |
Минимальные требования по ролям
| Роль | Минимальный уровень | Приоритетные темы |
|---|---|---|
| Junior-разработчик | У1 | Основы безопасности, OWASP Top 10 |
| Middle-разработчик | У1–У2 | Безопасное кодирование, базовое тестирование |
| Senior-разработчик | У2 | Все области, code review, наставничество |
| Тимлид / архитектор | У2–У3 | Архитектура, моделирование угроз |
| QA-инженер | У1–У2 | Тестирование безопасности, верификация уязвимостей |
| DevOps-инженер | У2 | Безопасность инфраструктуры, CI/CD |
| Лидер безопасности | У3–У4 | Все области, лидерство в культуре |
Области компетенций
| Область | У1: осведомлённый | У2: практикующий | У3: эксперт |
|---|---|---|---|
| Безопасное кодирование | Знает OWASP Top 10 | Предотвращает уязвимости в своём коде | Проводит security review, создаёт паттерны |
| Аутентификация и авторизация | Понимает концепции | Корректно реализует | Проектирует системы аутентификации |
| Защита данных | Знает классификацию | Безопасно работает с данными | Проектирует стратегии защиты |
| Моделирование угроз | Понимает цели метода | Участвует в сессиях | Ведёт моделирование |
| Тестирование безопасности | Запускает готовые инструменты | Пишет тесты безопасности | Формирует стратегию тестирования |
| Работа с зависимостями | Обновляет по запросу | Мониторит и управляет | Формирует политику |
Что должна охватывать программа обучения
Ниже — перечень тем с описанием: зачем это бизнесу, какую роль это должно охватывать, где взять обучение.
Тема 1: основы безопасности
Зачем бизнесу: единый базовый словарь и понимание «зачем» — основа всего остального. Без этого обучение по конкретным уязвимостям воспринимается как набор правил без логики.
Кому: все разработчики (У1).
Что должны знать после обучения:
- Триада CIA (конфиденциальность, целостность, доступность) и её связь с конкретными решениями в коде
- Принцип минимальных привилегий — почему это касается не только прав пользователей, но и сервисных аккаунтов, баз данных, API-ключей
- Понятие поверхности атаки и как её уменьшение снижает риски
- Эшелонированная защита (defense in depth) — почему одного уровня защиты недостаточно
- Типовой ландшафт угроз для веб-приложений
Ресурсы (бесплатно):
- OWASP Web Security Testing Guide — методология тестирования безопасности
- OWASP Cheat Sheet Series — практические руководства по языкам и технологиям
- БДУ ФСТЭК России — отечественная база уязвимостей
Тема 2: OWASP Top 10 — критичные уязвимости
Зачем бизнесу: список OWASP Top 10 не менялся принципиально 20 лет. Инъекции SQL, XSS, проблемы авторизации — разработчики продолжают их вносить, потому что их не учат избегать. Это устранимый риск.
Кому: все разработчики (У1–У2).
Что должны знать:
| # | Уязвимость | Суть | Как предотвращать |
|---|---|---|---|
| A01 | Нарушение контроля доступа | Пользователи получают доступ к ресурсам, не предназначенным для них | Проверка авторизации на каждый запрос |
| A02 | Криптографические сбои | Чувствительные данные открыты из-за слабой криптографии | Сильное шифрование, правильное управление ключами |
| A03 | Инъекции | Недоверенные данные исполняются как код | Параметризованные запросы, валидация ввода |
| A04 | Небезопасный дизайн | Архитектурные недостатки, а не ошибки реализации | Моделирование угроз, безопасные паттерны проектирования |
| A05 | Небезопасная конфигурация | Настройки по умолчанию, лишние функции | Харденинг, минимальные права |
| A06 | Уязвимые компоненты | Библиотеки и зависимости с известными уязвимостями | SCA-сканирование, обновление зависимостей |
| A07 | Сбои аутентификации | Сломанные механизмы входа | MFA, безопасное управление сессиями |
| A08 | Сбои целостности данных | Доверие к недоверенным источникам | Проверка подписей, контроль целостности |
| A09 | Сбои журналирования** | Недостаточное логирование для обнаружения атак | Комплексное журналирование событий безопасности |
| A10 | SSRF | Сервер отправляет запросы к ресурсам, указанным атакующим | Валидация и фильтрация URL |
Практика: для самостоятельного освоения на практических примерах подходит OWASP Juice Shop — намеренно уязвимое приложение, развёртываемое локально. Это нейтральный открытый инструмент, который можно запустить без внешних зависимостей.
Тема 3: безопасное кодирование на конкретном языке
Зачем бизнесу: общие принципы безопасности нужно уметь применять в контексте конкретного стека. SQL-инъекция в Python реализуется иначе, чем в Java, а типичные ошибки frontend-разработчика отличаются от проблем backend.
Кому: разработчики соответствующего стека (У1–У2).
Ориентировочное время: 4–6 часов на язык.
Базовые темы по каждому языку — не глубокое изучение, а понимание типичных ошибок. Например:
- Для JavaScript/TypeScript — XSS и правила работы с DOM, безопасность npm-зависимостей, JWT и хранение токенов
- Для Python — SQL-инъекции при использовании ORM, инъекции в командную строку, безопасное хеширование паролей
- Для Java — XXE-уязвимости, небезопасная десериализация, настройка Spring Security
- Для PHP — загрузка файлов, XSS, управление сессиями, PDO вместо конкатенации строк в запросах
- Для Go — валидация ввода, безопасные HTTP-клиенты, работа с пакетом crypto
Ресурсы:
- OWASP Cheat Sheet Series — есть шпаргалки для каждого основного языка (бесплатно, на английском)
- Российские учебные центры: PT Education (Positive Technologies), Академия Касперского, «Информзащита», УЦ «Эшелон», BI.ZONE — предлагают курсы по безопасной разработке с учётом российской нормативной базы
Тема 4: аутентификация и авторизация
Зачем бизнесу: ошибки в реализации аутентификации и авторизации — одни из самых опасных. Доступ к чужим данным (IDOR), сломанные механизмы сброса пароля, уязвимые JWT — это прямой путь к утечке данных и нарушению требований 152-ФЗ.
Кому: backend- и fullstack-разработчики (У2).
Что должны знать:
- Разница между аутентификацией (кто вы?) и авторизацией (что вам разрешено?)
- Управление сессиями: продолжительность, инвалидация, защита cookie
- JWT: типичные ошибки (алгоритм «none», отсутствие проверки срока действия) и правильная реализация
- OAuth 2.0 и OpenID Connect: потоки авторизации, использование в enterprise-контексте
- Хранение паролей: bcrypt, Argon2 — и почему MD5/SHA1 неприемлемы
- RBAC (ролевая модель доступа) и ABAC (атрибутная модель)
- Паттерны аутентификации API
Ресурсы:
- OWASP Authentication Cheat Sheet и OWASP Authorization Cheat Sheet (бесплатно)
- OAuth 2.0 Simplified — понятное введение в протокол
- JWT.io — визуализация и объяснение структуры
Тема 5: тестирование безопасности
Зачем бизнесу: ответственность за безопасность не должна лежать только на специалистах по ИБ. Разработчики, умеющие писать тесты безопасности, выявляют проблемы раньше и исправляют их дешевле.
Кому: разработчики и QA-инженеры (У2).
Типы тестирования:
| Тип | Что проверяет | Когда применять | Инструменты |
|---|---|---|---|
| Unit-тесты безопасности | Отдельные функции защиты | Каждый коммит | Стандартные фреймворки тестирования |
| Интеграционные тесты безопасности | Потоки аутентификации, контроль доступа | Каждый PR | |
| SAST | Паттерны в исходном коде | CI/CD | PT Application Inspector, Solar appScreener, Semgrep |
| DAST | Работающее приложение | Staging-среда | OWASP ZAP |
| SCA | Известные CVE в библиотеках | Каждая сборка | CodeScoring, Solar appScreener |
Инструменты для российского рынка:
- PT Application Inspector (Positive Technologies) — SAST с поддержкой русскоязычной документации и актуальной базой угроз
- Solar appScreener (ГК «Солар») — SAST/DAST/SCA в одном решении
- CodeScoring — анализ состава ПО (SCA) и секретов в коде
- OWASP ZAP — open-source DAST, можно интегрировать в CI/CD
Тема 6: моделирование угроз
Зачем бизнесу: проблемы в архитектуре — самые дорогостоящие. Найти их на этапе дизайна (до написания кода) принципиально дешевле, чем переписывать готовый продукт. Тимлиды и архитекторы должны уметь моделировать угрозы — это управленческий инструмент, а не только технический.
Кому: Senior-разработчики, тимлиды, архитекторы (У2–У3).
Метод STRIDE:
| Угроза | Описание | Пример | Меры |
|---|---|---|---|
| Sподмена (Spoofing) | Выдача себя за другого | Кража учётных данных | Строгая аутентификация, MFA |
| Tамперинг (Tampering) | Изменение данных | Подмена суммы в заказе | Контроль целостности, подписи |
| Rепудиация (Repudiation) | Отрицание действий | «Я не делал этот платёж» | Журналирование аудита |
| Iнформационное раскрытие | Утечка данных | Дамп базы данных | Шифрование, контроль доступа |
| Dоступность (DoS) | Недоступность сервиса | DDoS-атака | Rate limiting, масштабирование |
| Eскалация привилегий | Неавторизованный доступ | Пользователь получает права администратора | Минимальные привилегии, RBAC |
Простой процесс моделирования угроз:
- Что мы строим? Нарисуйте диаграмму потоков данных: компоненты, хранилища данных, границы доверия
- Что может пойти не так? Применяйте STRIDE к каждому компоненту. Набросайте сценарии атак
- Что мы с этим сделаем? Приоритизируйте угрозы (вероятность × ущерб). Определите меры. Сформулируйте требования к безопасности
- Мы всё правильно сделали? Проверьте полноту модели. Убедитесь, что меры реализованы. Обновляйте модель при изменениях
Инструменты:
- OWASP Threat Dragon — open-source инструмент для диаграмм угроз (бесплатно, устанавливается локально)
- Microsoft Threat Modeling Tool — бесплатный инструмент с поддержкой STRIDE
Обучение QA-инженеров безопасности
QA-инженеры — естественные союзники в безопасности: они уже думают о граничных случаях и умеют «ломать» поведение. Базовое обучение тестированию безопасности расширяет их ценность без значительных дополнительных инвестиций.
Что должны уметь QA
| Модуль | Темы | Время |
|---|---|---|
| Основы тестирования безопасности | Типы уязвимостей, OWASP Top 10, мышление тестировщика безопасности | 4 часа |
| Ручное тестирование | Работа с HTTP-прокси (OWASP ZAP), проверка авторизации | 8 часов |
| Автоматизированное тестирование | OWASP ZAP в CI/CD, сканеры | 4 часа |
| Тестирование API | Уязвимости API, fuzzing | 4 часа |
| Написание отчётов | Оценка критичности, документирование уязвимостей | 2 часа |
Чек-лист тестирования безопасности для QA
Управленческое задание: попросите лидера безопасности разработать чек-лист тестирования безопасности и интегрировать его в процесс тестирования. Минимальный набор проверок:
Аутентификация:
- Проверка на неверные учётные данные
- Блокировка после нескольких неудачных попыток
- Таймаут сессии
- Возможность обойти процесс сброса пароля через подбор
Авторизация:
- Доступ к данным другого пользователя через изменение ID (IDOR)
- Доступ к функциям, недоступным для роли пользователя
- Доступ к данным после выхода из системы
Ввод данных:
- Специальные символы, SQL-паттерны в формах
- XSS-паттерны в текстовых полях
- Очень длинные строки, нулевые значения, неожиданные типы данных
Файлы:
- Загрузка исполняемых файлов
- Загрузка слишком больших файлов
- Обращение к файлам без авторизации
API:
- Запросы без токена аутентификации
- Rate limiting (есть ли ограничение запросов)
- Избыточное раскрытие данных в ответах
Учебные пути по уровням
Junior-разработчик (первый год)
Цель: достичь уровня У1 по всем областям.
Месяцы 1–3: фундамент
- Курс по основам безопасности (базовые концепции)
- OWASP Top 10 — теория и примеры
- Основы безопасного кодирования на своём языке
- Итоговая оценка: тест (порог прохождения 80%)
Месяцы 4–6: практика
- Самостоятельная работа с OWASP Juice Shop (найти 3 типа уязвимостей)
- Написание первых тестов безопасности
- Участие в code review с фокусом на безопасность под наставничеством
Месяцы 7–12: интеграция
- Применение знаний в ежедневной работе
- Участие в security code review
- Итоговая оценка: упражнение по code review
Middle-разработчик
Цель: достичь уровня У2.
Квартал 1:
- Углублённый курс по OWASP
- Глубокое погружение в аутентификацию и авторизацию
- Оценка: промежуточный тест
Квартал 2:
- Тестирование безопасности с помощью OWASP ZAP
- Безопасность API
- Оценка: самостоятельное тестирование тестового приложения
Квартал 3:
- Введение в моделирование угроз
- Участие в реальной сессии моделирования угроз
- Оценка: ведение моделирования для небольшой фичи
Квартал 4:
- Наставничество для junior-разработчика
- Вклад в документацию по безопасности
- Оценка: security code review
Целевой результат: У2, готовность к роли лидера безопасности.
Senior-разработчик и тимлид
Фокус: архитектура безопасности, лидерство в моделировании угроз, требования к безопасности новых проектов, наставничество.
Активности:
- Курс по моделированию угроз
- Проведение 3 и более сессий моделирования угроз для команды
- Архитектурный review с точки зрения безопасности для новых проектов
- Выступление на внутреннем техническом митапе по теме безопасности
- Участие в учебных учениях по реагированию на инциденты
Целевой результат: У3, работа совместно с лидером безопасности или в роли лидера безопасности.
Ресурсы для обучения разработчиков
Российские учебные центры
| Организация | Форматы | Особенности |
|---|---|---|
| PT Education (Positive Technologies) | Очно, онлайн | Курсы по безопасной разработке, анализу защищённости, работа с PT-инструментами |
| Академия Касперского | Онлайн, корпоративный формат | Техническая безопасность, обучение по продуктам Kaspersky |
| «Информзащита» | Очно, дистанционно | Лицензированный учебный центр, курсы по нормативной базе РФ и техническим дисциплинам |
| УЦ «Эшелон» | Очно, дистанционно | Специализация на сертификации по ФСТЭК, курсы по защищённой разработке |
| BI.ZONE | Корпоративный формат | Практические курсы, включая эмуляцию атак и защиту |
Открытые международные ресурсы
| Ресурс | Тип | Стоимость |
|---|---|---|
| OWASP Cheat Sheet Series | Справочные материалы | Бесплатно |
| OWASP Testing Guide | Методология тестирования | Бесплатно |
| OWASP Juice Shop | Практика (уязвимое приложение) | Бесплатно |
| OWASP WebGoat | Практика (обучающее приложение) | Бесплатно |
| OWASP Threat Dragon | Инструмент моделирования угроз | Бесплатно |
| CWE Top 25 | Каталог опасных ошибок программирования | Бесплатно |
OWASP (Open Web Application Security Project) — международная некоммерческая организация; её материалы нейтральны, открыты и широко используются в российской ИБ-практике.
Инструменты для практики (open-source)
| Инструмент | Назначение |
|---|---|
| Semgrep | SAST с открытым исходным кодом, интегрируется в CI/CD |
| OWASP ZAP | DAST, сканирование запущенных приложений |
| OWASP Dependency-Check | SCA, поиск уязвимостей в зависимостях |
| Bandit | SAST для Python |
| gosec | SAST для Go |
Для корпоративного использования рекомендуется дополнять open-source инструменты российскими решениями — PT Application Inspector, Solar appScreener, CodeScoring — которые сертифицированы и поддерживаются в соответствии с требованиями ФСТЭК России.
Что руководитель должен сделать, прежде чем запускать обучение:
- Определить требования к компетенциям для каждой роли в команде
- Провести базовую оценку текущего уровня знаний (следующий раздел курса)
- Выбрать учебные ресурсы под конкретный стек технологий
- Выделить защищённое время на обучение (не «в свободные от задач минуты»)
- Включить прохождение обучения и достижение компетенций в онбординг новых разработчиков
- Установить квартальный цикл оценки и обучения
- Убедиться, что лидер безопасности знает ресурсы и может помочь коллегам
Вопросы для контроля исполнения (задайте лидеру безопасности):
- Все ли разработчики прошли базовый курс по OWASP Top 10?
- Есть ли у команды доступ к практической среде для отработки навыков?
- Включены ли проверки безопасности в процесс code review?
- Интегрированы ли SAST/SCA инструменты в CI/CD?
Что дальше
Следующий раздел — оценка компетенций и отслеживание прогресса: как измерить текущий уровень команды, определить пробелы и убедиться, что обучение работает.