Код, который работает, не то же самое, что сервер, который закрыт

Разбор на Habr описывает короткую и типичную историю. Разработчик собрал Telegram-бота для тренировки устного счёта силами Claude Code. Проверка была честной ровно в тех границах, в которых её обычно и проводят: бот запускается, на команды отвечает, считает правильно. Проект выглядел готовым. На третий день, когда пошёл рост нагрузки, выяснилось другое: в файле docker-compose осталась строка, публикующая порт PostgreSQL наружу. База оказалась открыта из интернета, сервер взломали. Логов не сохранилось, точку входа восстановить не удалось — значит, неизвестно и то, что успели забрать. Заголовок источника называет цену случившегося точно: одна строка, открытый порт и взломанный сервер.

Функциональная проверка тут бессильна. Тест «бот отвечает» отвечает на вопрос, делает ли система то, что должна, и молчит о том, делает ли она лишнее: например, отдаёт базу данных первому, кто постучался на нужный порт. Открытый наружу порт — не ошибка кода, а решение по развёртыванию: приложение работает безупречно, поэтому сценарий «напиши боту число, получи ответ» такой дефект не поймает. ИИ-ассистент выдаёт ровно то, о чём его попросили: работающего бота. Про вашу модель угроз он не знает и знать не может, если она не сформулирована отдельным требованием к приёмке.

Здесь и проходит граница из трёх слепых зон. Первая: конфигурация развёртывания — compose-файл, проброс портов, правила firewall, запуск от непривилегированного пользователя. Вторая: доступы — пароль к базе, отдельная учётная запись для приложения вместо суперпользователя, ограничение по адресам. Третья: наблюдаемость — логи, алерты о входе, бэкапы, ротация. Именно третья превращает инцидент из неприятного в неразбираемый: без логов нельзя ответить ни «как вошли», ни «что забрали», ни «кого и по какой процедуре уведомлять». Разбор закончился не выводом, а тупиком.

Считаем не в деньгах, а в часах: точную сумму ущерба в источнике никто не назвал. Проверка конфигурации перед первым запуском занимает часы — пройтись по compose-файлу, посмотреть, какие порты смотрят наружу, завести отдельного пользователя базы, включить логирование и бэкап. Разбор инцидента без логов занимает уже дни, и они не заканчиваются отчётом: сервер нужно пересобрать, доступы сменить, данные восстановить из того, что есть. Разница между «часами» и «днями» не в масштабе компании, а в порядке действий: одно делается до запуска, другое после. То же касается любого ИИ-кода, который малый бизнес ставит себе на сервер: скрипт для отчётов, бот для заявок, автоматизация переписки. Скорость написания выросла, скорость приёмки нет, и узкое место сместилось именно туда.

1. «Бот отвечает на команды»: проверка, которая прошла и ничего не доказала. Она подтверждает, что система делает нужное, и молчит о том, что она делает лишнее. В приёмку нужен второй список вопросов: кто ещё может подключиться к каждому сервису и с какого адреса.
2. «Строка в docker-compose»: не код приложения, поэтому её никто и не читал. Конфигурацию развёртывания проверяют как отдельный артефакт, со своим просмотром и своей ответственностью.
3. «Логов нет»: обнаружилось тогда, когда они понадобились. Логирование, алерты и бэкапы включают до первого внешнего пользователя, иначе инцидент нельзя расследовать, а значит нельзя и ограничить ущерб.
4. «База в интернете»: типовое следствие удобства. Чтобы быстро подключиться к базе с ноутбука, порт открывают наружу, а закрыть забывают. Наружу должно смотреть только то, что обязано: для базы данных это исключение, а не настройка по умолчанию.
5. «Claude Code написал то, о чём попросили»: и это ровно та причина, по которой подпись под развёртыванием ставит человек. Инструмент не знает вашей модели угроз, ответственность за конфигурацию, доступы и безопасность остаётся на том, кто нажимает кнопку запуска.

«Инструмент ускорил написание кода, но не снял с разработчика проверку конфигурации, доступов и безопасности. Этот случай показывает границу ответственности, а не отменяет ценность вайбкодинга.»