Четырнадцать минут. Столько нужно автоматизированному сканеру, чтобы найти AWS-ключ, случайно закоммиченный в публичный репозиторий. Я видел этот сценарий трижды за последний год: джуниор коммитит
.env, бот подхватывает секрет, компания получает счёт за чужие вычислительные ресурсы. По MITRE ATT&CK это техника Credentials In Files (T1552.001, credential-access) - одна из самых массовых точек входа при атаках через репозитории кода (T1213.003, collection). И каждый раз одна и та же реакция: "Мы думали, это не про нас".DevSecOps для разработчиков в 2026 году - не абстрактная методология из презентации CTO. Это набор конкретных навыков: знать OWASP Top 10, прикрутить статический анализ кода и SCA в пайплайн, не допускать секреты в репозиторий. Ниже - что осваивать, какие инструменты выбрать и в каком порядке двигаться.
Безопасность разработчика: что работодатели ищут в вакансиях
Откройте hh.ru и вбейте "DevSecOps" или "application security developer". Количество таких вакансий за последние два года выросло кратно, и вот что интересно - требования по безопасности всё чаще появляются не у выделенных ИБ-специалистов, а в вакансиях для обычных backend- и fullstack-разработчиков грейда middle и выше. Habr Career показывает ту же картину: фильтр по навыку "безопасная разработка" даёт ощутимую выборку за 2025 год. Подробнее - в нашем материале про атаки на цепочку поставок.Типичный набор требований из реальных описаний вакансий на российском рынке:
- Понимание OWASP Top 10 и умение писать код без типовых уязвимостей
- Опыт работы хотя бы с одним SAST-инструментом (Semgrep, SonarQube, Checkmarx)
- Навыки интеграции безопасности в CI/CD - GitHub Actions или GitLab CI
- Понимание принципов управления секретами - без хардкода токенов и паролей
- Базовое знание SCA - проверка зависимостей на известные уязвимости
Для тех, кто переходит из чистой разработки, путь реалистичный: 4-8 месяцев на освоение базовых навыков ИБ для разработчика, первые задачи по secure code review в текущей команде, затем - переход на выделенную роль или совмещение. Дальше - что именно осваивать.
OWASP Top 10 и secure coding практики: три категории на старт
OWASP Top 10 - каталог реальных ошибок, которые разработчики допускают каждый день. Это основа secure SDLC - цикла безопасной разработки. Для старта хватит за глаза трёх категорий: A03 Injection, A06 Vulnerable and Outdated Components и A05 Security Misconfiguration.
A03: Injection - классика, которая по-прежнему попадает в продакшн. Пользовательский ввод подставляется в запрос без параметризации. По MITRE ATT&CK эксплуатация инъекции через публично доступное приложение - техника Exploit Public-Facing Application (T1190, initial-access).
Уязвимый код на Python:
Python:
# Уязвимо: ввод пользователя попадает в запрос напрямую
query = f"SELECT * FROM users WHERE name = '{user_input}'"
cursor.execute(query)
Python:
# Безопасно: параметризованный запрос
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (user_input,))' OR 1=1 -- конструкцию. Для тех кто в танке - параметризованный запрос не даёт пользовательскому вводу стать частью SQL-синтаксиса. Точка.A06: Vulnerable and Outdated Components - использование библиотек с известными уязвимостями. SCA-инструменты (о них ниже) автоматизируют обнаружение, но главное - привычка: обновлять зависимости регулярно, а не "когда что-то сломается". Атакующие целенаправленно бьют через уязвимые зависимости - MITRE ATT&CK выделяет это как Compromise Software Dependencies and Development Tools (T1195.001, initial-access).
A05: Security Misconfiguration - открытые дебаг-эндпоинты, дефолтные пароли, verbose error messages в продакшне. Чеклист для самопроверки:
DEBUG = Falseв продакшн-конфигурации- Дефолтные учётные записи заменены или отключены
- HTTP-заголовки безопасности настроены (HSTS, X-Content-Type-Options, X-Frame-Options)
- Endpoint-ы диагностики (
/metrics,/debug,/actuator) закрыты для внешнего доступа - Error messages не раскрывают стек вызовов и версии компонентов
SAST DAST инструменты для безопасной разработки ПО
Безопасная разработка ПО в 2026 году строится на трёх категориях инструментов. У каждой - свой класс находок и свои слепые зоны.
| Категория | Что находит | Когда запускать | Бесплатные варианты | Ограничения |
|---|---|---|---|---|
| SAST (статический анализ кода) | Уязвимости в исходном коде до запуска | На каждый коммит или PR | Semgrep, SonarQube CE | Высокий процент false positives; не видит runtime-проблемы |
| DAST | Уязвимости в работающем приложении | В staging / pre-production | OWASP ZAP | Не указывает, какой код вызвал проблему; медленный для CI |
| SCA | Уязвимые зависимости и библиотеки | На каждый коммит или PR | Dependabot, Trivy | Не находит уязвимости в вашем собственном коде |
Начинайте с SAST + SCA. DAST добавляйте, когда базовый пайплайн уже стабилен - иначе утонете в алертах, не настроив даже фундамент. По данным Contrast Security, SAST-инструменты генерируют заметный объём ложных срабатываний, и разработчики тратят часы на разбор каждого такого случая. Поэтому постепенное наращивание строгости правил практичнее, чем включение всех проверок разом (я это проверял на собственной шкуре - включили всё сразу, через неделю команда начала игнорировать алерты целиком).
Semgrep (репозиторий активен, 10K+ звёзд на GitHub, регулярные релизы в 2025) - мой выбор для старта. Правила пишутся на YAML, интеграция с GitHub Actions и GitLab CI настраивается за час. SonarQube Community Edition - альтернатива с дашбордом и историей сканирований, удобна для команд от пяти разработчиков. Но для одиночки Semgrep проще - меньше возни с инфраструктурой.
Интеграция безопасности в CI/CD: shift left security на практике
Shift left security - перенос проверок безопасности с финальных этапов разработки на ранние: каждый коммит или pull request проходит через автоматические сканеры. Три шага, которые реально внедрить за один рабочий день.Шаг 1: Pre-commit хук для секретов. gitleaks или GitGuardian перехватывают коммиты с токенами, паролями и API-ключами до попадания в репозиторий. Как отмечают в DefectDojo, "secrets leaked in git history are a major vector for compromise""Утечка секретных данных из истории Git является основным каналом компрометации" - TruffleHog умеет находить такие секреты глубоко в истории коммитов, не только в последней версии кода. Даже если секрет удалён из последнего коммита, он остаётся в истории Git. Навсегда. Это ловушка, в которую попадают все.
Шаг 2: SAST-проверка в пайплайне. Добавьте Semgrep как шаг в CI. Начните с набора правил
p/owasp-top-ten - покрывает критичные уязвимости без лишнего шума. Не включайте блокировку сборки сразу: 2-3 недели смотрите отчёты, разбирайте false positives, потом ужесточайте. Как справедливо замечает автор из Бастиона на Хабре, "систему контроля качества, как и все блокирующие практики, стоит внедрять только после того, как вы повысили качество кода другими методами".Шаг 3: SCA-проверка зависимостей. Dependabot (GitHub) или Trivy в CI-пайплайне автоматически находят библиотеки с известными CVE. Это защита от Compromise Software Dependencies and Development Tools (T1195.001, initial-access) - атакующие всё чаще идут через уязвимые зависимости, а не через ваш код.
Порядок принципиален: не начинайте с DAST и quality gates, если не настроен базовый SAST. Потренируйтесь на кошках.
Roadmap: навыки ИБ для разработчика за 12 месяцев
Месяц 1-3: фундамент secure coding
- Прочитайте OWASP Top 10 целиком - не формально, а с примерами кода на вашем стеке
- Пройдите бесплатные лабы OWASP Juice Shop - намеренно уязвимое приложение для отработки навыков
- Настройте pre-commit хук с gitleaks на своих рабочих проектах
- Начните code review с фокусом на безопасность: инъекции, захардкоженные секреты, отсутствие валидации ввода
Месяц 4-6: DevSecOps инструменты 2026 в пайплайне
- Внедрите Semgrep или SonarQube в CI/CD вашей команды
- Настройте Dependabot или Trivy для SCA-сканирования зависимостей
- Изучите OWASP ZAP на уровне запуска базового скана staging-среды
- Познакомьтесь с HashiCorp Vault или аналогом для управления секретами - замените хардкод переменными окружения, затем переходите на полноценный секрет-менеджер
Месяц 7-12: threat modeling для разработчиков
- Освойте базовый threat modeling - OWASP Threat Dragon поможет визуализировать модель угроз вашего приложения
- Изучите OWASP DevSecOps Maturity Model (DSOMM) для оценки зрелости процессов в команде
- Разберитесь в безопасности CI/CD: техника Poisoned Pipeline Execution (T1677, execution) по MITRE ATT&CK описывает атаки через вредоносные изменения конфигурации пайплайна - защита требует понимания, как работает ваш CI
- Рассмотрите курсы кибербезопасности для разработчиков с практической составляющей - теория без лаб забывается за неделю
Точка зрения: с чего начать прямо сейчас
Я вижу одну и ту же картину в командах: разработчики воспринимают ИБ как внешнее давление, "ещё одна бюрократия сверху". Но те, кто потратил два-три месяца на OWASP и базовые инструменты, начинают замечать баги безопасности в code review раньше, чем функциональные ошибки. Вместо "безопасность тормозит релиз" появляется "мы сами ловим проблемы до того, как о них узнает заказчик".
Главный антипаттерн - пытаться охватить всё: SAST, DAST, IAST, container security, runtime protection. Не надо так. Начните с pre-commit хука и одного SAST-сканера. Через три месяца эти проверки станут такой же привычкой, как линтер, и желание расширить стек появится само. На IB Basics (codeby.school) показываем, как джуны реально решают эти задачи на практике - если хочется пройти путь структурированно, а не собирать его по разрозненным статьям.
Последнее редактирование модератором:
