Код без секретов: почему это важно? К чему приводит наличие конфиденциальной информации в коде продуктов и как с этим быть

BIS Journal №1(56)2025

12 марта, 2025

Код без секретов: почему это важно? К чему приводит наличие конфиденциальной информации в коде продуктов и как с этим быть

ЧТО ТАКОЕ СЕКРЕТ?

ГОСТ Р 56939-2024 под секретами определяет «данные, которые могут использоваться для обеспечения аутентификации и/или целостности и/или конфиденциальности информации (пароли, цифровые сертификаты и т. п.)».

Секреты могут быть представлены также и иными данными, например платёжными: номерами карт, счетов, пинами и прочим. Подобную «живую» информацию хранить в коде, конфигурационных файлах или фикстурах совершенно нежелательно.

 

ПОЧЕМУ ЭТО ВАЖНО

Исходные коды приложений находятся под стражей специалистов по безопасности. Тем не менее приложения, собранные из этих кодов, регулярно разворачиваются на сторонние площадки или публикуются (очевидный пример — мобильные приложения), а сами исходные коды хранятся на рабочей технике разработчиков. Угроза внутреннего злоумышленника и утечки исходных кодов сохраняется актуальной для любой организации.

Наличие чувствительной информации в приложении может позволить злоумышленнику использовать её для получения доступов в целях кражи персональных данных, поддержания цепочки взломов, фишинга, распространения вредоносного ПО или иных целей.

Одним из примеров реализации подобного вида атаки является декомпиляция мобильных приложений из публичных площадок с целью извлечения доступов к его публикации, размещённых разработчиками по неосторожности, что позволяет подменить оригинальное приложение приложением с полезной нагрузкой. Аналогичным образом получаются доступы к API используемых сервисов, SMS-шлюзам, ключам доступа к платёжным сервисам, которые случайно забыла разработка.

 

СТАТИСТИКА

Показательной является статистика открытого кода из свежего отчёта The State of Secrets Sprawl 2024:

  • 12,8 млн новых секретов обнаружено в публичных коммитах на GitHub за 2023 год;
  • 90% секретов оставались валидными и через 5 дней после утечки;
  • каждый десятый разработчик случайно добавляет секрет в код.

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

 

ПОСТРОЕНИЕ БАЗОВЫХ ПРОЦЕССОВ РАБОТЫ С СЕКРЕТАМИ

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

Во-первых, должно быть организовано пространство хранения и предоставления секретов смежным приложениям. Для этого есть специальные системы управления секретами («паролешницы»), например открытый Vault.

Во-вторых, следует настроить блокирующую проверку секретов на стороне разработки. Это могут быть такие открытые и «лёгкие» статические анализаторы, как GitLeaks, TruffleHog, DeepSecrets или иные, которые уже устоялись в экспертной практике и позволяют легко настраивать правила анализа. Независимо от уровня применяемого инструмента следует приготовиться к разбору ложноположительных срабатываний, если не предлагается специальных механизмов интеллектуального анализа. К примеру, наша лаборатория показала, что можно натренировать модель машинного обучения, которая с ходу идентифицирует 50–70% ложноположительных срабатываний. А если проводить дообучение этой модели на контекстных данных проектов, то результат стремится к 90–95%, что существенно экономит время специалистов РБПО на разбор срабатываний.

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

Безусловно, всё, что вы придумаете и настроите, должно быть закреплено в регламенте по работе с секретами. Или наоборот, но регламент должен работать, а не лежать.

 

ВЫВОДЫ

Можно разработчику сильно не доказывать, что секреты в коде — это неправильная инженерная культура. Ошибки совершают все. Но правильный процесс и инструментарий для контроля секретов должны быть реализованы.

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

09.04.2026
Александр Пушкин («Перспективный мониторинг»): «Даже корректно настроенный WAF не способен полностью блокировать все атаки на веб-ресурс»
09.04.2026
Хакеры атакуют американских поставщиков CNI
09.04.2026
Anthropic запускает Glasswing, чтобы бороться с критическими уязвимостями
08.04.2026
Рынок говорит: Кибербез — обязательная часть цифрового бизнеса
08.04.2026
Кибербезопасность в строительстве и ЖКХ станет одной из ключевых тем на Форуме ГосСОПКА
08.04.2026
Платформа Venom Stealer поставила на поток непрерывную кражу данных
08.04.2026
На FINNEXT 2026 обсудили, как ИИ-агенты и экосистемы меняют финрынок
08.04.2026
От адаптации к изобретению: подведены итоги 3-й ежегодной Премии FINNEXT
07.04.2026
Безопасники выявили опасную уязвимость в ChatGPT
07.04.2026
Власти Камбоджи хотят искоренить киберпреступность и работорговлю

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных