BI.ZONE — о поиске данных в публичных репозиториях

В BI.ZONE Digital Risk Protection обновили раздел мониторинга Github-репозиториев и Postman-проектов на предмет забытых секретов: токенов, API-ключей, паролей, приватных ключей, внутренних доменов и других чувствительных сведений.

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

Дмитрий Кирюшкин, руководитель BI.ZONE Digital Risk Protection, заявил: «Разработчики, DevOps-инженеры и подрядчики публикуют код и примеры интеграций постоянно, и вместе с ними в публичный доступ регулярно попадают фрагменты конфигураций, оставленные «для отладки». Это не теоретический риск: один из недавних инцидентов начался именно с того, что злоумышленники нашли в публичном GitHub-репозитории учетные данные для авторизации. Для них такой набор часто становится готовой точкой входа, поэтому скорость в данном вопросе очень важна.

ИИ-ассистент в лице BI.ZONE Cubi закрывает важную задачу — понимание контекста. BI.ZONE Cubi анализирует содержимое фрагмента целиком и выносит вердикт вместе с объяснением, опираясь на то, как эти данные используются в коде. В результате аналитик приходит не к списку срабатываний, а к приоритизированному перечню данных с подтверждением и рекомендациями по исправлению — автоматическое выставление приоритетов, например, Critical или Info для каждого выявленного репозитория позволяет аналитикам и ИБ-командам сконцентрироваться на анализе самых чувствительных сценариев».

Логика работы осталась двухступенчатой. Первый уровень — поисковый: сервис ищет ключевое слово, например домен заказчика, и дополнительно учитывает контекстные признаки, упоминание пароля, API или токена в том же скрипте или рядом с ним. Такого набора достаточно, чтобы отобрать кандидатов из потока публичного контента, но недостаточно, чтобы отличить действующий ключ от закомментированного примера в README: для поисковой сигнатуры эти случаи выглядят одинаково. Второй уровень — LLM-классификатор: он получает содержимое файла и оценивает его целиком, выявляя захардкоженные учетные данные, API-ключи и токены, приватные ключи, персональные и чувствительные данные, небезопасную конфигурацию, уязвимый код и security-релевантные информационные сигналы.

Если в итоговом файле описаны несколько независимых рисков, категории и теги объединяются, приоритет выставляется по самому критичному из них, а описание и рекомендации оформляются нумерованными списками. Когда проблем не обнаружено, сервис возвращает информационный результат с приоритетом Info и пустыми категориями и тегами — такой ответ тоже экономит время: находку можно закрыть без необходимости детальной аналитики. Таким образом, обновление меняет сам порядок работы с внешними цифровыми рисками: вместо проверки всего, что было найдено, служба ИБ занимается тем, что действительно представляет угрозу. Это особенно важно для компаний с большой распределенной разработкой и несколькими подрядчиками.