Автор статьи проверил 3 800 публичных репозиториев собственным SAST-сканером и нашёл десятки настоящих утечек среди тысяч ложных срабатываний. Главный вывод простой: код, собранный ИИ за вечер, часто тащит за собой токены, пароли, открытые порты и следы старых секретов в истории git.

Зачем вообще смотреть на код, собранный ИИ

Проблема не в том, что ИИ пишет код. Проблема в том, что он слишком легко воспроизводит плохие привычки: кладёт секреты в конфиги, оставляет базы торчащими наружу, отключает проверки и делает вид, что так и надо.

На небольших проектах это долго не видно. Но как только такой код начинает принимать оплату, работать с ботами или хранить доступы, одна забытая строка превращается в утечку.

Именно поэтому подобные инструменты важны не только разработчикам. Они нужны всем, кто хранит деньги, персональные данные или доступ к админкам — от маленьких команд до тех, кто запускает сервисы на скорую руку.

Три подхода к проверке: вручную, сигнатурами и через AST

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

Второй путь — сигнатуры и grep-поиск. Он ловит очевидные совпадения, но тонет в шуме: примерные значения, тестовые ключи, переводы интерфейса и шаблоны конфигов выглядят как настоящие секреты.

Третий путь — разбор кода через AST, то есть через структуру программы, а не по строкам. Такой подход лучше отличает опасный вызов базы от безобидной строки в логгере и сильнее подходит для массовой проверки репозиториев.

Именно на этом строится AigisSAST — консольный сканер без облака и без внешних зависимостей. Он ищет типичные проблемы в Python-проектах: токены, пароли, строки подключения, закоммиченный .env, инъекции, debug=True, verify=False, открытые порты и секреты в переменных фронтенда.

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

Плюсы и минусы

Ручной аудит — самый точный, но дорогой по времени. Подходит для важных систем, где каждый баг стоит денег.

Сигнатуры — быстрые, но шумные. Хороши как первый фильтр, но требуют много ручной валидации.

AST-анализ — сбалансированный вариант для Python-проектов. Он лучше ловит смысл, но всё равно нуждается в настройке и тестах.

Что именно нашёл сканер

В первой версии автор получил 2 012 ложных паролей и потом резко сжал шум после ручной разметки. Дальше он прогнал инструмент по крупным open source-проектам и по небольшим ботам, которые реально приносят деньги.

Чаще всего всплывали одни и те же вещи: токены ботов прямо в коде, пароли от панелей, строки подключения к базам, .env в репозитории, выключенная проверка подписи JWT, небезопасные настройки Docker и публичные базы на открытых портах.

Отдельно важна история git. Даже если разработчик убрал секрет из текущей версии файла, старая копия может остаться в коммитах. Это не гипотеза, а повседневная практика, из-за которой «я же удалил ключ» не спасает.

Кому нужен такой инструмент

Маленьким командам он помогает поймать то, что пропускают на ревью. Особенно если проект собирали быстро и с участием ИИ: там легко забыть про проверку авторизации, защиту токенов и безопасную работу с конфигами.

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

Крупным open source-проектам такой контроль полезен как дополнительный слой, а не как замена ревью. Он не отменяет экспертизу, но экономит время на рутине и вытаскивает опасные мелочи из больших кодовых баз.

Для тех, кто регулярно работает в кафе, аэропортах и поездах, полезно сочетать проверку исходников с базовой цифровой гигиеной. Здесь же уместен инструмент вроде freedome.space как один из элементов защиты трафика наряду с менеджером паролей и двухфакторной аутентификацией.

Что в итоге показал эксперимент

Главный итог у статьи не про отдельный сканер, а про качество современного кода. Когда проект собирается быстро и почти без ручной проверки, секреты утекают не потому, что кто-то «захотел взломать», а потому что разработка идёт слишком быстро для старых привычек безопасности.

Хорошая новость в том, что такие ошибки можно ловить автоматически. Плохая — один инструмент не спасёт, если в команде до сих пор считают .env и токен в репозитории нормой.

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

Практический чек-лист

  • Проверьте, нет ли секретов в текущем коде и в истории git.
  • Уберите .env из репозитория и добавьте его в .gitignore.
  • Посмотрите, не отключены ли авторизация, проверка подписи и отладка.
  • Убедитесь, что базы данных не слушают внешний адрес без необходимости.
  • Прогоните проект через статическую проверку перед публикацией.
  • Для рабочих сервисов добавьте двухфакторную аутентификацию и менеджер паролей.
  • Если вы часто подключаетесь из чужих сетей, держите под рукой отдельный слой защиты трафика.
Поделиться: