Натравил security-аудит из AI-агентов на свой вайб-кодинг: 7 дыр в живом проде за прогон

Короче, я взял мультиагентный security-аудит и натравил его на код своего живого проекта - DnD-бота, в котором уже сидит 500+ игроков. Один прогон, 12 research-агентов, на выходе 19 кандидатов. После разбора осталось 7 реальных дыр: 1 HIGH, 3 MEDIUM, 3 LOW. И да, среди них был захардкоженный продовый пароль, который я сам же и закоммитил когда-то. Рассказываю, что нашлось, что из этого стыдно, и стоит ли вообще так делать со своим петпроектом.

Что такое мультиагентный security-аудит и зачем он вайб-кодингу

Мультиагентный security-аудит - это когда несколько AI-агентов параллельно читают твой код, каждый под своим углом (аутентификация, доступ к данным, инъекции, гонки), а потом их находки сводятся в один список. Для вайб-кодинга это особенно больная тема: по отчёту Veracode 2025, AI-сгенерированный код содержит уязвимости в 45% задач - почти каждая вторая.

Я гоняю разработку с AI постоянно, и цифра меня не удивляет: там же ещё есть данные, что AI-код тащит в 2.74 раза больше уязвимостей, чем написанный руками. Забавно, что модель побольше тут не спасает - проблема системная, а не в размере сетки. Так что я запустил Claude Security: это не один агент с чек-листом, а рой из 12 research-агентов, каждый копает свою поверхность. На выходе 19 кандидатов, из которых половина - шум и ложные срабатывания. Реальными оказались семь. Дальше по каждой.

HIGH: как продовый пароль PostgreSQL оказался в git-истории

Самая опасная находка - продовый пароль от PostgreSQL, закоммиченный в утилитный QA-скрипт. Он лежал в git-истории, а это значит, что удалить файл бесполезно: пароль остаётся в старых коммитах и в любом клоне репозитория. Лечится такое ровно одним способом - ротацией пароля. По данным GitGuardian, за 2023 год на GitHub утекло 12.8 млн новых секретов.

И вот что тут важно понять про механику. Больше 90% утёкших секретов остаются валидными и через 5 дней после утечки - потому что люди в панике удаляют коммит вместо того, чтобы отозвать сам ключ. В GitGuardian это называют zombie leaks: файла уже нет, а пароль живёт и работает. Я на эти грабли чуть не наступил: первая мысль была "ща удалю скрипт и всё". Нет, не всё. Пришлось менять сам пароль на проде. Скрипт-то ерунда, а пароль от боевой базы - это уже нервно.

IDOR-уязвимость: что это и почему её находят чаще всего

IDOR (Insecure Direct Object Reference) - это когда API принимает ID объекта прямо из запроса, но не проверяет, есть ли у пользователя к нему доступ. В OWASP API Security Top 10 2023 эта штука стоит на первом месте (API1:2023) с максимальными оценками: "лёгкая" в эксплуатации и "широко распространённая". То есть найти её просто, а встречается она почти везде.

У меня их было сразу две, и обе честно неприятные. Первый эндпоинт отдавал ростер любого чата вообще без проверки членства - подставляешь чужой id и получаешь чужие telegram_id, ники и персонажей. Классическая утечка через "а кто это будет подбирать id руками". Будут, ещё как. Второй был злее: он позволял перезаписать данные чужого игрока. То есть не просто прочитать, а испортить. Оба лечатся одинаково скучно - проверкой, что запросивший действительно член этого чата и владелец этого объекта. Но пока не ткнут носом, ты про это не думаешь: у себя-то в голове ты всегда ходишь только по своим данным.

Fail-open вебхук и мелочи, которые копятся сами

Fail-open - это когда защита при сбое не блокирует, а наоборот отключается. Мой вебхук при пустом секрете молча переставал проверять подпись входящих запросов. На проде секрет был задан, так что настоящей дыры в тот момент не было. Но я всё равно переписал код на fail-closed: пустой секрет теперь роняет проверку, а не выключает её. Это defense-in-depth, на случай кривого деплоя.

А дальше пошла та самая гигиена, которая по отдельности мелочь, а вместе - характер проекта. Неатомарный check-then-increment недельного лимита: между "проверил" и "увеличил" успевает пролезть второй запрос. TOCTOU на реферальном бонусе - без UNIQUE-индекса можно было словить дабл-начисление, если дёрнуть дважды быстро. И Markdown-инъекция через имя пользователя: человек называется так, что его ник ломает разметку сообщения. Ничего катастрофического, но именно из такого потом вырастают настоящие инциденты.

Что аудит проглядел бы сам: контекст решает

Самое важное открытие было не про код, а про контекст. Аудитор сначала считал проект "петом в разработке" и спокойно занижал приоритеты: ну подумаешь, IDOR, кто там ходит-то. Пришлось руками поправить рамку: это не пет на коленке, это живой ОБТ, где прямо сейчас 500+ реальных игроков. И вот после этой одной фразы приоритеты пересчитались - та же самая находка внезапно стала серьёзнее.

Вывод для меня был отрезвляющий. AI-аудит блестяще находит паттерны, но не знает цену данным без тебя. Он не в курсе, что за этим telegram_id живой человек, а за базой - продовый трафик. Это ровно то место, где human-in-the-loop не опция, а обязательный шаг: ты даёшь модели правильную рамку, а она уже под неё пересобирает риски. Отдашь на откуп полностью - получишь красивый отчёт с неправильными приоритетами.

Стоит ли натравливать AI-аудит на свой пет-проект

Да, стоит - если относишься к результату как к списку кандидатов, а не к приговору. У меня из 19 кандидатов реальными были 7, остальное отсеялось руками. Все семь я закрыл в тот же день: миграция БД на проде, ротация пароля, проверки доступа, fail-closed на вебхуке. Сьют из 4743 тестов после этого остался зелёным, что важно - правки безопасности любят ломать соседнее.

Так что аудит безопасности пет-проекта силами AI-агентов - это не паранойя и не оверкилл. Это способ за один вечер увидеть то, на что сам давно закрыл глаза, потому что "ну я же знаю, как оно работает". В том и фокус: ты знаешь, как оно должно работать, а аудит смотрит, как оно работает на самом деле. Голову он не заменяет - контекст всё равно за тобой. Но подсветить семь дыр за один прогон, включая пароль в истории гита, - это дёшево за такой результат.

А я пойду проверю, не закоммитил ли ещё чего лишнего. На всякий.