«Безопасность как техническая функция давно понятна. Почему же её постоянно откладывают? Дело не в лени разработчика, а в фундаментальном конфликте между работой, которая видна и приносит дивиденды, и работой, которая лишь предотвращает ущерб. Процесс разработки устроен так, чтобы поощрять прокрастинацию в отношении безопасности. Выход — не в новых инструментах, а в перестройке самих механизмов оценки и управления проектом.»
Почему «сделать» всегда побеждает «защитить»
В классическом представлении прокрастинация, это индивидуальная проблема, слабость воли. В корпоративной IT-среде она превращается в системный феномен. Команды не откладывают безопасность потому, что не понимают её важности. Они откладывают её потому, что текущая система стимулов выстроена против неё.
Рассмотрите цикл работы над типичным проектом. Бэклог формируется из фич, багов и «технического долга». Фичи, это то, что видит заказчик или продукт-менеджер, они напрямую влияют на выручку или удовлетворённость пользователя. Баги, это сломанная функциональность, их наличие очевидно и болезненно. Безопасность же редко является ни тем, ни другим. Это превентивная мера. Её отсутствие не ломает текущий процесс, а лишь создаёт рисковый потенциал на будущее. Мозг человека, как и система управления проектом, заточен на решение актуальных, а не гипотетических проблем.
Экономика немедленного результата
Менеджер оценивает прогресс по закрытым тикетам и развёрнутым на продакшен фичам. Вложения в безопасность не дают такого же осязаемого «прогресса». Установка и настройка SIEM, ревизия прав доступа, статический анализ кода на уязвимости, это часы или дни работы, результат которой формулируется как «риск снижен», а не «функция добавлена». В условиях жёстких дедлайнов и ограниченных ресурсов такая работа переносится в конец спринта, а оттуда — в следующий, превращаясь в хронический «технический долг» особого рода.
Миф о «безопасности по умолчанию»
Распространено убеждение, что современные фреймворки и облачные сервисы «из коробки» безопасны. Это опасная полуправда. Хотя платформы действительно решают множество базовых проблем (инъекции, XSS через встроенные экранизации), они не могут учесть логику конкретного приложения. Авторизация бизнес-ролей, валидация сложных бизнес-процессов, корректная обработка цепочек событий, это зона ответственности разработчика.
Прокрастинация здесь проявляется в отказе от глубокого проектирования. Гораздо быстрее набросать рабочую логику, а вопросы «кто и что может делать» оставить на потом, поставив заглушки. Позже, когда логика обрастёт зависимостями, переделывать систему прав доступа станет в разы сложнее. Так рождаются монолиты с привилегированными сервисными аккаунтами, которые имеют доступ ко всему «на всякий случай».
Регуляторика: стимул или имитация?
Казалось бы, требования регуляторов (ФСТЭК, 152-ФЗ) должны стать железным аргументом против откладывания. На практике они часто приводят к обратному эффекту — ритуализации безопасности. Команда воспринимает их не как часть инженерной культуры, а как внешнее бюрократическое бремя.
Вместо того чтобы встроить защиту данных в процесс разработки, создаётся параллельный поток: раз в квартал или перед сдачей проекта собирается папка с документами, генерируются отчёты из сканеров, проводятся формальные собеседования. Безопасность окончательно отделяется от жизни продукта, становясь задачей для «отдельных специалистов», которые приходят «после». Это кульминация прокрастинации, возведённая в процесс: работа отложена настолько, что для её выполнения создана отдельная функция, которая по определению всегда опаздывает.
Разрыв между compliance и реальной защищённостью
Соответствие формальным требованиям (compliance) даёт ложное чувство защищённости. Система может успешно проходить проверки по 152-ФЗ, но при этом иметь критическую уязвимость в логике приложения, о которой стандарты умалчивают. Пока команда выставляет галочки в чек-листах регулятора, атакующий ищет и находит аномалии в бизнес-логике. Фокус смещается с предотвращения реальных инцидентов на подготовку к аудитам.
Технические долги с высоким процентом
Отложенные задачи по безопасности, это не обычный техдолг. Если недописанная фича делает продукт менее удобным, то неисправленная уязвимость создаёт брешь. Проценты по этому долгу выплачиваются не в виде увеличения затрат на рефакторинг, а в виде потенциального ущерба от инцидента: финансовых потерь, репутационного урона, штрафов регулятора. Проблема в том, что вероятность этого ущерба кажется малой и отдалённой, в то время как давление за закрытие видимого тикета — большое и прямо сейчас.
Как разорвать цикл «на потом»
Борьба с системной прокрастинацией требует изменения не поведения разработчика, а процессов и метрик проекта.
1. Безопасность как критерий «готово» (Definition of Done)
Фича не считается завершённой, пока не пройдены ключевые проверки безопасности, актуальные для её контекста. Это не общий список на проект, а конкретные пункты для каждого типа задачи. Например:
- Для нового API-эндпоинта: проверка прав доступа, валидация входных данных, наличие rate-limiting.
- Для работы с персональными данными: аудит логов на наличие чувствительной информации, проверка шифрования при передаче.
Так безопасность перестаёт быть отдельной задачей и становится неотъемлемым шагом в процессе.
2. Сдвиг безопасности влево (Shift Left Security)
Суть подхода — обнаруживать и устранять проблемы как можно раньше в цикле разработки. На практике это означает:
- Статический анализ кода (SAST) не как отдельный запуск перед релизом, а как плагин в IDE или обязательный шаг в pipeline CI/CD, блокирующий мерж при наличии критических уязвимостей.
- Обсуждение угроз (threat modeling) на этапе проектирования новой фичи или сервиса, а не после его реализации.
- Использование безопасных шаблонов и библиотек по умолчанию, чтобы правильное решение было самым простым для разработчика.
3. Измерение невыполненной работы
Вместо того чтобы отчитываться о проведённых пентестах, начните измерять «время жизни» уязвимостей в коде — от момента попадания в репозиторий до исправления. Ведите открытый для команды дашборд с рисками, где каждый пункт имеет понятный приоритет, основанный на реальной критичности, а не на абстрактной «важности безопасности». Когда риски видимы и ранжированы, проще аргументировать необходимость их устранения перед менеджментом.
4. Интеграция регуляторных требований в жизненный цикл
Вместо создания отдельного «compliance-спринта» разбейте требования ФСТЭК или 152-ФЗ на конкретные технические и процессуальные задачи. Например, требование о регистрации событий безопасности превращается в задачу по настройке корректного логирования для нового микросервиса и интеграции логов в централизованную систему мониторинга. Так регуляторика становится не внешним шумом, а частью технического задания.
Итог: безопасность как flow, а не gate
Ключевая мысль: безопасность проигрывает прокрастинации, когда воспринимается как ворота, через которые продукт должен пройти в конце пути. Любые ворота хочется отложить или проскочить, если цель видна прямо за ними. Задача — превратить безопасность в часть самого потока (flow) разработки: в критерий завершения задачи, в автоматическую проверку в процессе, в стандартный шаблон при создании нового сервиса. Когда правильные действия становятся путем наименьшего сопротивления, необходимость в героических усилиях «потом» отпадает сама собой.