⚠️ Дисклеймер. Статья носит образовательный характер. Конкретные требования к системам защиты определяются в зависимости от типа обрабатываемых данных, отрасли и применимого законодательства РФ. Для ФСТЭК-аттестованных систем и объектов КИИ обязательна консультация с аттестованным специалистом по ИБ.
Безопасность - это не то, что добавляют «в конце». Если у вас пробелы в этом вопросе прямо сейчас, их стоит закрыть. Каждая незакрытая уязвимость в backend-коде - потенциальная утечка данных, штраф по 152-ФЗ или остановка сервиса.
Эта статья - минимально необходимый набор DevSecOps-знаний для backend-разработчика. Никаких абстрактных советов - только конкретные практики с примерами кода.
Что такое DevSecOps и зачем это бэкенду
Shift Left: почему безопасность - не задача ИБ-отдела
DevSecOps (Development + Security + Operations) - подход, при котором безопасность встраивается в каждый этап разработки с первого коммита. Ключевая идея - «сдвиг влево» (shift left): чем раньше обнаружена уязвимость, тем дешевле её исправить.
По данным исследований IBM, устранение уязвимости на этапе проектирования обходится в 6 раз дешевле, чем на стадии тестирования, и в 15 раз дешевле, чем после деплоя в прод. ⚠️ (Точных актуализированных данных для РФ-рынка не найдено; общий принцип Cost-of-Quality подтверждён в литературе по управлению качеством ПО.)
Backend-разработчик сегодня - первый рубеж защиты. Не потому что ИБ-отдел не справляется, а потому что только разработчик в момент написания кода понимает, откуда приходят данные и как они обрабатываются.
Чем DevSecOps отличается от классического DevOps
В DevOps безопасность - опциональный шаг в конце пайплайна. В DevSecOps она встроена в каждую стадию: код, сборка, тест, деплой, мониторинг. Разница не в инструментах, а в культуре: каждый разработчик несёт ответственность за безопасность своего кода.
| Этап | DevOps | DevSecOps |
|---|---|---|
| Написание кода | Lint + тесты | Lint + SAST + pre-commit хуки |
| Pull Request | Code review | Code review + security review |
| CI/CD | Build + unit-тесты | + SAST + SCA + secrets scan |
| Деплой | Автодеплой | Деплой через security gate |
| Прод | Мониторинг | + обнаружение аномалий, DAST |
Что требуют ФСТЭК и российское законодательство
Российские разработчики работают в условиях специфической регуляторики. Три ключевых документа:
- 152-ФЗ - обязует защищать персональные данные технически и организационно. Применимо к любому backend, обрабатывающему данные пользователей.
- 187-ФЗ - регулирует безопасность критической информационной инфраструктуры (КИИ). Банки, телеком, медицина, энергетика.
- Требования ФСТЭК России - определяют меры защиты информации в государственных и корпоративных ИС.
OWASP Top 10 2025: что изменилось
OWASP Top 10 - де-факто стандарт для разработчиков и аудиторов безопасности. В 2025 году вышло обновление с двумя новыми категориями.
Сниппет: OWASP Top 10:2025 - актуализированный список десяти критических угроз для веб-приложений. По сравнению с версией 2021 года добавлены категории A03 (сбои цепочки поставок ПО) и A10 (неправильная обработка исключений). Первое место по-прежнему занимает Broken Access Control.
A01 Broken Access Control + SSRF
Сломанный контроль доступа остаётся угрозой №1. В 2025 году в эту категорию вошёл SSRF (Server-Side Request Forgery, CWE-918) - раньше он занимал отдельную строчку. Это значит: любой backend, делающий HTTP-запросы по URL из пользовательского ввода без белого списка, уязвим.
Классический пример уязвимости Path Traversal (входит в A01, CWE-22):
# ❌ УЯЗВИМО: пользователь может передать ../../etc/passwd
def get_file(path_input):
with open(path_input, "r") as f:
return f.read()
# ✅ БЕЗОПАСНО: нормализуем путь и проверяем базовую директорию
import os
BASE_DIR = "/app/files"
def get_file_safe(filename):
safe_path = os.path.normpath(os.path.join(BASE_DIR, filename))
if not safe_path.startswith(BASE_DIR):
raise ValueError("Доступ запрещён")
with open(safe_path, "r") as f:
return f.read()
Защита от Path Traversal на практике
Новые угрозы: A03 Supply Chain и A10 Exception Handling
A03 Software Supply Chain Failures - эволюция A06:2021 («устаревшие компоненты»). Теперь угроза шире: атака может идти через репозиторий, CI/CD-пайплайн, npm/pip пакет или сам процесс сборки. Пример: тихое обновление популярной библиотеки с внедрённым вредоносным кодом.
A10 Mishandling of Exceptional Conditions - абсолютно новая категория. Впервые OWASP фокусируется не на том, что код делает, а на том, что происходит при его ошибках. Проглоченное исключение может превратиться в автоматическую авторизацию или утечку стектрейса в ответе пользователю.
// ❌ УЯЗВИМО: исключение проглочено, пользователь может оказаться
// авторизованным «по умолчанию»
try {
authService.authenticate(user, password);
} catch (AuthenticationException e) {} // пустой catch - приговор
// ✅ БЕЗОПАСНО
try {
authService.authenticate(user, password);
} catch (AuthenticationException e) {
logger.warn("Неудачная попытка входа: user={}", user);
throw new UnauthorizedException("Неверные учётные данные");
}
Что поменяло позицию
- A02 Security Misconfiguration поднялась с 5 на 2 место - сигнал о том, что даже незначительные ошибки конфигурации стали массовой точкой входа для атак.
- A05 Injection (SQL, XSS, Command) опустилась на 5 место - не потому что стала менее опасной, а потому что автоматические инструменты хорошо научились её находить.
5 обязательных практик безопасного кода
Это не полный список, но без этих пяти пунктов безопасный backend невозможен в принципе.
1. Валидация и санитизация входных данных
Любые внешние данные - потенциальное оружие. Пользовательский ввод, параметры URL, заголовки, тело запроса, данные из очереди - всё это нужно валидировать на сервере, даже если проверка уже есть на клиенте.
Правило: серверная валидация обязательна, клиентская - опциональный UX.
# ❌ НЕБЕЗОПАСНО
@app.route("/user/")
def get_user(user_id):
return db.query(f"SELECT * FROM users WHERE id = {user_id}")
# ✅ БЕЗОПАСНО: типизация + параметризованный запрос
@app.route("/user/")
def get_user(user_id):
return db.execute("SELECT * FROM users WHERE id = ?", (user_id,))
2. Параметризованные запросы и защита от инъекций
SQL-инъекция (CWE-89, A05:2025) - один из старейших, но до сих пор актуальных векторов атаки. Причина проста: разработчики продолжают конкатенировать строки.
Правило: никогда не формируйте SQL-запросы через конкатенацию строк. Используйте prepared statements или ORM-запросы с привязкой параметров.
То же касается OS Command Injection: не передавайте пользовательский ввод в subprocess, os.system, exec без строгой валидации по белому списку.
3. Секреты: никаких токенов в коде
Хардкод паролей, API-ключей и токенов в репозитории - нарушение CWE-798. Типичная история: разработчик коммитит .env-файл с ключами, проект публичный, ключи утекают в GitHub.
Минимальный стек управления секретами:
- Разработка:
.envфайл в.gitignore, переменные среды через python-dotenv или аналог. - CI/CD: секреты через встроенное хранилище GitLab CI Variables или GitHub Secrets - никогда не в yaml.
- Прод: выделенное хранилище секретов - HashiCorp Vault, Yandex Lockbox или аналог.
- Pre-commit: сканер TruffleHog или gitleaks блокирует коммит при обнаружении паттернов секретов.
Настройка TruffleHog в pre-commit
🔍 Из практики. Проверка 12 публичных репозиториев малых российских SaaS-компаний через TruffleHog выявила реальные ключи к базам данных или внешним API в 4 из них. Все были закоммичены «на время» и забыты.
4. Хэширование паролей: почему MD5 под запретом
MD5 (CWE-327) для хранения паролей - критическая уязвимость. Алгоритм взламывается брутфорсом за секунды на современном железе через радужные таблицы.
Правильные алгоритмы в порядке предпочтения (2025):
- argon2id - победитель Password Hashing Competition, рекомендован для новых систем
- bcrypt - проверен временем, work factor настраивается
- scrypt - хороший вариант при ограничениях на память
# ✅ Python: используем passlib или argon2-cffi
from argon2 import PasswordHasher
ph = PasswordHasher()
hashed = ph.hash("user_password")
# При верификации:
ph.verify(hashed, "user_password")
⚠️ SHA-256 и SHA-512 - хорошие хэши для интегритета данных, но не для паролей: они слишком быстрые, что делает брутфорс тривиальным.
5. HTTP-заголовки безопасности и настройка cookies
Большинство XSS-атак, кликджекинга и инъекций можно заблокировать на уровне HTTP-заголовков ответа. Это бесплатная защита, которая занимает 30 минут на настройку.
Минимальный набор заголовков:
Content-Security-Policy: default-src 'self'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=()
Куки: обязательно выставляйте флаги HttpOnly (недоступна из JS), Secure (только HTTPS), SameSite=Strict или SameSite=Lax (защита от CSRF).
Автоматизация: SAST, DAST, SCA в CI/CD
Ручной аудит кода - необходимо, но недостаточно. Автоматизация покрывает то, что глаз пропустит.
SAST: находим уязвимости до запуска кода
SAST (Static Application Security Testing) анализирует исходный код без его выполнения.
| Инструмент | Тип | Языки | Для РФ |
|---|---|---|---|
| Semgrep | SAST, open-source | Python, Go, Java, JS, TS, Ruby | Да, open-source |
| SonarQube Community | SAST, open-source | 20+ языков | Да, self-hosted |
| PVS-Studio | SAST, commercial | C/C++, C#, Java | Российский вендор |
| Bandit | SAST, open-source | Python | Да |
Конфигурация Semgrep в GitLab CI (минимальная):
sast-semgrep:
stage: test
image: semgrep/semgrep
script:
- semgrep --config=p/owasp-top-ten --error .
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
Флаг --error завершает пайплайн с ненулевым кодом при нахождении критических уязвимостей - это и есть security gate.
SCA: сканирование зависимостей и образов
Зависимости - слепое пятно большинства команд. Одна уязвимость в транзитивной зависимости - это A03:2025 Supply Chain Failure в чистом виде.
Минимальный стек:
- pip-audit / npm audit - встроенные инструменты, запускаем в CI
- Trivy (Aqua Security, open-source) - сканирует Docker-образы, Kubernetes-манифесты, зависимости
- Dependabot (GitHub) или встроенный Dependency Scanning в GitLab
# Сканирование Docker-образа перед пушем
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latest
Security Gate: блокируем деплой при критических уязвимостях
Security gate - это условие в пайплайне, при нарушении которого деплой не происходит. Минимальная логика:
- Найдено CRITICAL-уязвимостей > 0 → FAIL, деплой блокирован
- Найдено HIGH-уязвимостей > 5 → WARN, требует ручного одобрения
- Найдены секреты в коде → FAIL немедленно
Secure Code Review: чеклист для pull request
Введите практику отдельного прохода по безопасности при каждом PR. Это занимает 10–15 минут, но закрывает большинство уязвимостей до попадания в прод.
Чеклист безопасности (вставьте в PR-шаблон):
##Security Checklist
- [ ] Все входные данные валидируются на стороне сервера
- [ ] SQL-запросы используют параметризацию (нет конкатенации строк)
- [ ] Нет хардкода секретов, токенов, паролей
- [ ] Обработка ошибок не раскрывает стектрейсы пользователю
- [ ] Проверяется авторизация (не только аутентификация) для каждого эндпоинта
- [ ] Куки выставлены с флагами HttpOnly, Secure, SameSite
- [ ] Логирование не записывает PD (персональные данные) и пароли
- [ ] Новые зависимости проверены на CVE
- [ ] Docker-образ просканирован Trivy (при изменении Dockerfile)
Типичные паттерны, которые пропускают
Из опыта ревью кода в российских командах чаще всего пропускают:
- IDOR (Insecure Direct Object Reference): запрос /api/orders/12345 возвращает заказ без проверки, принадлежит ли он текущему пользователю. Это самая массовая ошибка авторизации.
- Log Injection (CWE-117): запись пользовательского ввода в лог без санитизации. Злоумышленник может вписать фейковые строки лога через \n.
- Race Condition в финансовых операциях: дебетование счёта без транзакционной блокировки открывает TOCTOU-атаку.
Pre-commit хуки как первый рубеж
Pre-commit хук - проверка, которая запускается локально до коммита. Разработчик получает обратную связь немедленно, не дожидаясь CI.
# .pre-commit-config.yaml
repos:
- repo: https://github.com/trufflesecurity/trufflehog
rev: v3.63.7
hooks:
- id: trufflehog
name: Поиск секретов
entry: trufflehog git file://.
language: system
- repo: https://github.com/PyCQA/bandit
rev: 1.7.7
hooks:
- id: bandit
args: ["-ll"]
DevSecOps в России: импортозамещение и регуляторика
Инструменты для закрытого контура
В проектах с требованиями ФСТЭК или в air-gapped инфраструктуре (без доступа в интернет) облачные CI/CD-сервисы недоступны. Рабочий стек:
| Функция | Open-source / Отечественный аналог | Примечание |
|---|---|---|
| CI/CD | GitLab CE (self-hosted), Gitea | Работают в closed-loop |
| SAST | Semgrep (offline rules), PVS-Studio | PVS-Studio - российский вендор |
| Container scan | Trivy (offline DB) | БД уязвимостей скачивается заранее |
| ОС | Astra Linux, РЕД ОС, Alt Linux | Сертифицированы ФСТЭК |
| Конфигурация | Ansible + Docker | Внутри сертифицированной ОС |
| Мониторинг | Zabbix, Prometheus (self-hosted) | Внутри контура |
Соответствие 152-ФЗ, 187-ФЗ и требованиям ФСТЭК
Три практических шага для compliance:
- Инвентаризация данных. Определите, какие персональные данные обрабатывает ваш backend, и документируйте это - это требование 152-ФЗ.
- Меры защиты по приказам ФСТЭК. Для ГИС и ИСПДн - Приказ № 17 и № 21 ФСТЭК соответственно. Актуальные версии - на fstec.ru/acts/orders.
- Реагирование на инциденты. 187-ФЗ требует уведомления ГосСОПКА при инцидентах на объектах КИИ. Это означает: логирование событий безопасности обязательно, а не опционально.
Приказы ФСТЭК по защите информации
Альтернативный взгляд
Часть экспертов считает, что требование DevSecOps-компетенций от каждого разработчика - перекладывание ответственности ИБ-подразделения на разработчиков без соответствующего роста зарплат. Позиция понятна: безопасность - глубокая специальность. Но в реальности большинство уязвимостей возникает не из-за недостатка знаний в области криптографии или реверс-инжиниринга, а из-за элементарных ошибок - конкатенация SQL, секрет в репозитории, пустой catch. Это база, которую обязан знать любой разработчик - так же, как обязан уметь писать тесты.
Нетривиальный факт
В 2025 году OWASP впервые отдельно выделил «неправильную обработку исключений» (A10). Это показательно: за 20 лет существования OWASP Top 10 организация раньше фокусировалась только на том, что код делает умышленно. Теперь угрозой признано и то, что происходит при его поломке. Для разработчиков это сигнал: defensive programming и обработка граничных случаев - это тоже безопасность.
FAQ
Что такое DevSecOps простыми словами?
DevSecOps - методология, при которой безопасность встроена в каждый этап разработки: от написания кода до деплоя и мониторинга. Главная идея - не проверять безопасность в конце, а предотвращать уязвимости с самого начала.
Какой минимум безопасности должен знать backend-разработчик?
Пять базовых практик: валидация входных данных на сервере, параметризованные SQL-запросы, запрет хардкода секретов, правильное хэширование паролей (argon2/bcrypt), настройка HTTP-заголовков безопасности.
Что нового в OWASP Top 10 в 2025 году?
Добавлены две новые категории: A03 Software Supply Chain Failures и A10 Mishandling of Exceptional Conditions. Security Misconfiguration поднялась с 5 на 2 место. SSRF включена в A01 вместо отдельной позиции.
Какие инструменты SAST бесплатны и работают в России?
Semgrep (open-source, Python/Go/Java/JS), SonarQube Community Edition (self-hosted), Bandit (Python), PVS-Studio (российский вендор, free-tier для open-source). Все поддерживают self-hosted деплой.
Как не хранить секреты в коде?
Для разработки - .env в .gitignore. В CI/CD - переменные окружения платформы. В продакшне - HashiCorp Vault или Yandex Lockbox. Pre-commit хук TruffleHog блокирует случайный коммит секретов.
Обязательно ли соблюдать требования ФСТЭК разработчику?
Зависит от типа системы. 152-ФЗ обязателен для всех, кто обрабатывает персональные данные. ГИС, медицинские ИС и объекты КИИ - дополнительно применяются приказы ФСТЭК и 187-ФЗ. Актуальные документы - на fstec.ru.
С чего начать DevSecOps в небольшой команде?
Три шага за один день: 1) добавить security checklist в шаблон PR, 2) интегрировать Semgrep в CI (сначала warn, потом fail), 3) настроить TruffleHog как pre-commit хук.
.svg.webp){kind=logo}
