Процесс безопасной разработки для небольшой команды

В крупных компаниях процесс безопасной разработки строится с отдельной командой, длинными документами и дорогими инструментами. В команде из трёх-десяти человек на это нет ни времени, ни людей. В итоге безопасность попадает в список «посмотрим после релиза» и возвращается в отчёте официальной экспертизы десятком находок сразу.

В этой статье предлагаем минимальный процесс, который небольшая команда действительно может выполнять: пятнадцатиминутный анализ угроз при планировании, короткий список для code review, гигиена секретов, автоматические проверки в CI и контроль перед релизом. Каждый шаг встраивается в существующий рабочий процесс и не требует отдельного «этапа безопасности».

В чём проблема

Типичная ситуация в небольших командах:

• решения по безопасности нигде не записаны и хранятся в голове одного человека;
• code review отвечает только на вопрос «работает ли»;
• .env, ключи и тестовые пароли время от времени попадают в репозиторий;
• зависимости (composer, npm, pub) годами не обновляются;
• релиз выходит в режиме «надо срочно», без контрольного списка;
• первая проверка безопасности происходит только на официальной экспертизе.

На экспертизе нашего собственного продукта (SaaS-платформы для налогового и финансового учёта) в веб-части было 6 находок, в мобильном приложении — 9. Большинство из них были не сложными атаками, а вещами, забытыми в процессе: страница успешной оплаты показывалась до подтверждения платежа, приложение доверяло заголовку X-Forwarded-Host, в браузер отдавался полный список маршрутов, порты панели были открыты, в мобильном приложении не было обнаружения root и certificate pinning. Мы закрыли всё, но каждую из этих проблем можно было поймать гораздо раньше простым чек-листом.

Почему это важно для экспертизы

Официальная экспертиза проверяет готовый продукт. Каждая находка — это доработка, повторная подача и ожидание. Встраивание безопасности в процесс уменьшает число находок, а оставшиеся позволяет закрыть быстро, потому что команда знает, что где находится. Такой подход рекомендуют документы вроде OWASP SAMM и OWASP ASVS; небольшая команда может взять из них нужную часть.

Принцип: безопасность — это не отдельный этап, а несколько вопросов на каждом этапе.

1. Лёгкое моделирование угроз

Для каждой новой функции (особенно оплата, аутентификация, загрузка файлов, внешняя интеграция) выделите при планировании 15 минут и запишите ответы на четыре вопроса:

1. Что мы делаем? Откуда приходят данные, где хранятся, кому видны. Достаточно простой схемы.
2. Что может пойти не так? STRIDE как вспомогательный список: выдача себя за другого (Spoofing), изменение данных (Tampering), отказ от действий (Repudiation), раскрытие информации (Information disclosure), отказ в обслуживании (Denial of service), повышение привилегий (Elevation of privilege).
3. Что мы с этим делаем? Для каждого риска — конкретная мера: проверка, ограничение, лог.
4. Хорошо ли мы справились? Меры подтверждаются тестом или review.

Пример: для функции «оплата» вопрос «может ли пользователь увидеть страницу успеха до подтверждения платёжного провайдера?» — это была одна из наших находок. Подробнее: страница успеха без подтверждения оплаты.

Храните ответы коротким текстом внутри задачи (issue) или в папке docs/threats/.

2. Чек-лист code review

Добавьте короткий список в шаблон pull request. Для GitHub — .github/pull_request_template.md:

### Безопасность
- [ ] В новых endpoint'ах проверяются аутентификация и права на уровне объекта
- [ ] Ввод пользователя валидируется, SQL только параметризованный
- [ ] При выводе в HTML есть экранирование (Blade {{ }}, в React нет dangerouslySetInnerHTML)
- [ ] При загрузке файлов ограничены тип, размер и место хранения
- [ ] В коде нет секретов, ключей и паролей
- [ ] В логах нет паролей, токенов, персональных данных
- [ ] Если добавлена зависимость: нужна ли она, поддерживается ли

Ревьюер проверяет каждый пункт. Больше всего внимания требуют авторизация (пользователь не может открыть чужой объект), состояния бизнес-логики и внешние запросы. Пример для Laravel:

// Плохо: только по ID
$invoice = Invoice::findOrFail($id);

// Хорошо: проверяется владение
$invoice = $request->user()->invoices()->findOrFail($id);
// или через Policy
$this->authorize('view', $invoice);

Подробнее: IDOR и ошибки авторизации.

3. Гигиена секретов

• .env, файлы ключей, конфигурации вроде google-services.json — в .gitignore;
• в репозитории только .env.example без значений;
• отдельные ключи для каждой среды, production-ключей нет на компьютерах разработчиков;
• если ключ утёк — сначала замена, потом очистка истории.

Добавьте инструмент поиска секретов вроде gitleaks в pre-commit hook и в CI:

gitleaks detect --source . --redact

Проверьте и историю: ключ, однажды попавший в коммит, остаётся в истории git, даже если удалён следующим коммитом. Подробнее: управление секретами и ключами.

4. Проверки в CI

Автоматические проверки запускаются на каждый pull request и ловят то, что человек забывает. Пример для GitHub Actions:

name: security
on: [pull_request]
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - name: Secrets
        uses: gitleaks/gitleaks-action@v2
      - name: PHP dependencies
        run: composer install --no-interaction && composer audit
      - name: JS dependencies
        run: npm ci && npm audit --audit-level=high
      - name: Static analysis
        run: pipx run semgrep --config p/owasp-top-ten --error

Поначалу останавливайте сборку только на находках высокого уровня, иначе команда быстро отключит проверку. Со временем снижайте порог. Для Flutter-проектов дополнительно полезны flutter analyze и dart pub outdated, для Laravel — Larastan (PHPStan). Для регулярного обновления зависимостей включите Dependabot или Renovate.

5. Чек-лист релиза

Перед каждым production-релизом (или хотя бы перед каждым крупным) пройдите короткий список:

• APP_DEBUG=false, APP_ENV=production, на страницах ошибок нет stack trace;
• заголовки безопасности (HSTS, CSP, X-Content-Type-Options) присутствуют в ответе;
• список новых маршрутов и API endpoint'ов просмотрен, тестовые и отладочные маршруты отключены;
• миграции выполняются после создания резервной копии;
• для мобильного приложения: release-сборка, обфускация включена, debuggable выключен, allowBackup=false, cleartext-трафик закрыт, контрольные суммы APK/IPA записаны;
• известен путь отката релиза (rollback).

Быстро проверить можно такими командами:

curl -sI https://example.uz | grep -iE "strict-transport|content-security|x-content-type|server:"
php artisan route:list --except-vendor | grep -iE "test|debug|telescope"

Связанные статьи: заголовки безопасности, debug-режим и раскрытие информации, контрольные суммы APK/IPA.

6. Роли и ответственность

Даже если в небольшой команде нет отдельного специалиста по безопасности, назначьте одного «ответственного за безопасность». Его задача — не делать всё самому, а:

• следить, чтобы проверки CI работали, а предупреждения разбирались;
• раз в месяц проверять обновления зависимостей и сервера;
• отслеживать объявления о новых уязвимостях (в используемых фреймворках и библиотеках);
• быть первой точкой контакта при инциденте.

7. Пре-аудит перед экспертизой

Описанный процесс уменьшает повседневные ошибки, но не заменяет взгляд со стороны. Команда привыкает к своему коду и чего-то не замечает. Независимая проверка перед официальной экспертизой даёт:

• список находок по категориям, которые проверяет экспертиза, с уровнем критичности;
• конкретное исправление и повторную проверку для каждой находки;
• готовность документов и файлов, подаваемых на экспертизу.

Подробнее: зачем нужен пре-аудит и чек-лист перед экспертизой.

С чего начать

Не пытайтесь внедрить всё за неделю. Практический порядок:

1. Первая неделя: настройте .gitignore и gitleaks, проверьте историю репозитория на секреты, замените найденные ключи.
2. Вторая неделя: добавьте пункты безопасности в шаблон PR и включите composer audit / npm audit в CI.
3. Первый месяц: напишите чек-лист релиза и пройдите по нему на следующем релизе; включите Dependabot или Renovate.
4. Следующие месяцы: добавьте статический анализ, сделайте анализ угроз для важных функций привычкой, раз в квартал пересматривайте процесс.

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

Короткий чек-лист

• 15-минутный анализ угроз для важных функций с записанными ответами
• Пункты безопасности в шаблоне PR, review их проверяет
• .env и ключей нет в git, gitleaks в pre-commit и CI
• В CI работают composer audit, npm audit, статический анализ
• Включён Dependabot или Renovate
• Чек-лист релиза (debug, заголовки, маршруты, настройки мобильной сборки)
• Назначен ответственный за безопасность
• Перед официальной экспертизой запланирован независимый пре-аудит

Итог

Безопасная разработка для небольшой команды — это не толстые документы, а несколько привычек, повторяющихся на каждом этапе. Когда они работают вместе, в продукте, пришедшем на экспертизу, неожиданных находок становится заметно меньше. В нашем процессе Claude AI агент быстро просматривает кодовую базу, конфигурацию и настройки CI, а специалист подтверждает находки, исправляет их и помогает вашей команде выстроить процесс.

Если хотите узнать, насколько ваш продукт и процесс готовы к экспертизе, оставьте заявку на сканирование. Мы поможем закрыть уязвимости до официальной проверки.