Сегодня разработка ПО все чаще становится целью кибератак — по данным Kaspersky, к концу 2025 года в open source-проектах было обнаружено почти 19,5 т…
О том, почему разрозненные инструменты разработки могут повышать киберриски для бизнеса и как компаниям снижать такие угрозы, эксклюзивно для «СофтТех» рассказал Александр Степчков, директор по техническому развитию и архитектуре платформы «Сфера» (входит в IT-холдинг Т1).
🔹Какие именно киберриски вызывает использование разрозненных инструментов?
Один из основных рисков связан с доступами. У сотрудника могут быть права сразу в нескольких инструментах: в системе задач, репозитории с кодом, сервисе тестирования и системе сборки. Если эти права выдаются и отключаются вручную в каждом месте, легко что-то упустить. Например, сотрудник перешел в другой проект или уволился, а часть доступов осталась активной. Для компании это становится уязвимостью, которой могут воспользоваться злоумышленники.
Еще один риск — старые интеграции. Он особенно заметен, когда компания обновляет инструменты разработки или заменяет часть решений в рамках импортозамещения. Вместе со старыми связками могут сохраняться служебные ключи, токены и временные настройки. Если их не проверить, у злоумышленника может остаться способ попасть во внутренние системы компании.
В разрозненной среде инцидент сложнее заметить и расследовать. События фиксируются в разных системах, и если нет единого аудита, службе безопасности приходится вручную собирать картину произошедшего: где началась подозрительная активность, какие данные могли быть затронуты и какие доступы нужно отключить.
🔹Какие факторы приводят к снижению вероятности киберинцидентов?
Риск возникает тогда, когда компания не видит полной картины. Даже небольшая ошибка — например, старая интеграция или неотключенный доступ — может привести к серьезному инциденту. Поэтому разработку важно выстраивать в единой логике: с централизованным управлением правами и понятным аудитом.
Компании не обязательно отказываться от всех привычных инструментов. Важно, чтобы разработка оставалась управляемой: было видно, как связаны задачи, код и тесты, кто имеет доступ к важным данным и где могут возникнуть слабые места. Это снижает риск, что забытая настройка или разрыв между системами приведут к проблемам с безопасностью.
Подписывайтесь на СофтТех