Код как город без карты: почему это дорого бизнесу

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

Проблема: код как чёрный ящик

В отчётах по ИБ и комплаенсу всё выглядит аккуратно. Есть перечень систем, регламенты, модель угроз, приказы. На уровне документов понятно, где находятся персональные данные, кто за что отвечает и какие меры защиты применяются.

В кодовой базе картина другая:

1. добавлялись новые интеграции и сервисы, не всегда попадая в регламенты;
2. временные «костыли» запускались в прод и так там и остались;
3. логирование и отладочные выгрузки часто содержат больше данных, чем допускают внутренние политики.

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

Нормативный контекст: 152‑ФЗ и реальность

152‑ФЗ и подзаконные акты требуют не только документов, но и фактического обеспечения защиты: ограничение доступа, контроль потоков, минимизацию данных, реагирование на инциденты. Регулятор в случае проверки будет смотреть не только на приказы, но и на то, как система работает на практике.

Если компания не понимает:

1. все точки входа данных в систему;
2. все сервисы и модули, через которые эти данные проходят;
3. все места, где данные логируются, кешируются, выгружаются,

то формальное соответствие превращается в лотерею. Штрафы, простои, доработки «в пожарном режиме» и репутационные потери — это уже не про ИТ, а про деньги.

Возможные решения: от ручного аудита до карт кода

Есть несколько типичных подходов.

1. Ручной аудит силами своих разработчиков.Дорого по времени, зависит от конкретных людей, не масштабируется.
2. Отчёты классических сканеров безопасности.Хороши для поиска отдельных уязвимостей, но плохо работают с цепочками через несколько сервисов и языков. Отсюда известные 80-90% шума и ложных срабатываний.
3. Фокус только на инфраструктуре и интеграциях.Настройки сети, права, сегментация контролируются, но логика приложений и реальные потоки данных остаются «внутренним делом разработки».

На практике этого недостаточно, если говорить о деньгах и комплаенсе. Бизнесу нужна карта: понимать, где в коде действительно возникают риски, сколько стоит их закрытие и что произойдёт при изменении архитектуры.

Место КодГраф (CodeGraph)

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

1. есть точки, где в систему попадают персональные и другие чувствительные данные;
2. есть точки, где они могут быть прочитаны, изменены или утечь;
3. если между ними существует путь без очистки и контроля, это не абстрактная «уязвимость», а конкретный бизнес‑риск.

КодГраф (CodeGraph) строится именно вокруг этой модели. Инструмент не подменяет регламенты и проверки, а даёт то, чего в них обычно не хватает: наглядную картину движения данных и архитектуры на уровне кода.

Что имеет смысл сделать хотя бы в минимальном варианте

Даже без детальных внедрений полезно ответить на несколько прямых вопросов:

1. Кто в компании может по‑деловому объяснить, как движутся данные клиента по системе, опираясь не только на документы, но и на реальный код.
2. Есть ли перечень модулей и сервисов, где обрабатываются персональные данные, и совпадает ли он с тем, что описано в регламентах.
3. Понимает ли бизнес, сколько будет стоить закрыть найденные дыры: по времени разработки, остановкам системы и возможным санкциям.

Если на эти вопросы нет внятных ответов, это не вопрос «красоты кода». Это вопрос того, насколько управляемы риски, которые сидят внутри ключевого актива компании, т.е. её программных систем.

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