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

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

Технологическая зависимость в данном исследовании понимается как невозможность продолжить, восстановить, обновить или заменить работу программного компонента в допустимый срок без внешней стороны или внешней инфраструктуры. Это определение не делит продукты на «свои» и «чужие» по происхождению. Оцениваются фактические свойства конкретной версии и конфигурации. Если внешняя программа способна работать автономно, полностью экспортирует данные и имеет проверенную альтернативу, её зависимость может быть низкой. Если формально собственная система требует неподконтрольного сервиса, её зависимость может быть высокой.

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

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

Цель исследования состоит в разработке простого и воспроизводимого метода оценки технологической зависимости внешнего программного компонента и проверки её дополнительного влияния на остаточный киберриск. Главный исследовательский вопрос формулируется так: будет ли оценка риска точнее и полезнее для принятия решений, если к обычной оценке угроз, уязвимостей и последствий добавить отдельно измеренный индекс технологической зависимости?

Единицей анализа станет не название продукта, а сочетание компонента, версии, конфигурации, режима эксплуатации и бизнес-процесса. Это важно, потому что одна и та же программа может использоваться локально или через облако, иметь или не иметь автономный режим, хранить данные в открытом или закрытом формате. Без фиксации условий результаты разных организаций невозможно корректно сравнивать.

Индекс зависимости D предлагается строить из шести равноправных групп. Первая группа оценивает автономность. Вторая — контроль обновления и сопровождения. Третья — контроль данных и возможность полного экспорта. Четвёртая — способность восстановить компонент из собственных копий. Пятая — реальную заменяемость и трудоёмкость миграции. Шестая — обязательную внешнюю инфраструктуру и недоступные организации привилегии управления.

Каждый частный показатель оценивается от 0 до 10. Ноль означает отсутствие выявленной зависимости, пять — существенную, но управляемую зависимость, десять — критическую. Оценка без доказательства не принимается. Доказательствами могут быть журнал сетевых соединений, результат работы при отключённом внешнем канале, протокол восстановления, проверка экспорта и импорта, сведения о механизме обновления или результат пробной миграции.

Сначала вычисляется среднее внутри каждой из шести групп. Затем средние значения групп складываются и делятся на шесть. Формула имеет вид: D = (D₁ + D₂ + D₃ + D₄ + D₅ + D₆) / 6. Значение D находится от 0 до 10. Веса не применяются. Это решение не означает, что все показатели в природе всегда одинаково важны. Оно означает, что до получения экспериментальных данных исследователь не скрывает субъективное мнение внутри весовых коэффициентов. Если данные покажут устойчивое различие вклада групп, этот результат можно будет обсудить отдельно.

Для включения зависимости в риск предлагается рабочая формула Rост = Rисх + D − Z. Здесь Rисх — исходный балл киберриска сценария от 0 до 10 без учёта зависимости и без эффекта проверяемых мер. D — дополнительный балл зависимости от 0 до 10. Z — фактически подтверждённое снижение риска после внедрения мер, также от 0 до 10. Если результат меньше нуля, принимается ноль. Максимальное теоретическое значение равно двадцати.

Смысл формулы прост. Исходный киберриск показывает опасность самого сценария. Зависимость прибавляется, потому что она способна увеличить простой, затруднить восстановление и ограничить выбор действий. Эффект мер вычитается, потому что проверенная мера уменьшает наблюдаемые последствия. Итоговый Rост является баллом приоритета, а не вероятностью события и не денежным ущербом. Поэтому его нельзя трактовать как «двенадцать процентов риска». Он нужен для сравнения компонентов и выбора очередности действий.

Ключевое правило метода — не учитывать один признак дважды. Например, невозможность автономной работы относится к D и не должна повторно повышать Rисх. Уменьшение времени восстановления после создания локальной копии относится к Z и подтверждается повторным испытанием. Для каждого балла будет составляться карта происхождения, где указано, на основании какого наблюдения он получен.

Научная состоятельность метода будет проверяться несколькими независимыми способами. Сначала разные специалисты оценят одни и те же компоненты по общей инструкции. Если результаты близки, метод воспроизводим. Затем индекс D будет сопоставлен с реальными результатами контрольных сценариев: временем автономной работы, долей сохранённых функций, временем восстановления, полнотой переноса данных, трудозатратами на миграцию и необходимостью обращения к поставщику.

Самая важная проверка состоит в сравнении двух вариантов оценки. Первый использует только исходный риск Rисх. Второй добавляет D. Оба варианта сравниваются с фактически наблюдаемыми последствиями на данных, которые не использовались при настройке шкал. Если вариант с D лучше ранжирует тяжёлые случаи и уменьшает ошибку, будет получено прямое подтверждение полезности индекса. Если улучшения не будет, исследование должно честно установить, для каких компонентов и сценариев зависимость не даёт дополнительной информации.

Дополнительно применяется схема «до — после». Для части компонентов внедряются меры, реально уменьшающие зависимость: локальная копия дистрибутива и обновлений, проверенный экспорт, резервная инфраструктура, запасной механизм активации, ограничение внешних соединений или подготовленная альтернатива. После этого тот же сценарий выполняется повторно. Балл Z определяется по фактическому улучшению, а не по обещанию поставщика или наличию документа.

Эксперимент планируется провести на 30–40 компонентах нескольких классов. Для каждого компонента выполняются шесть сценариев: отключение внешней сети, недоступность активации или обновлений, прекращение сопровождения, перенос данных, восстановление после отказа и пробная замена. Повторение сценариев образует не менее 180 наблюдений и позволяет сравнить разные типы зависимости в одинаковых условиях.

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

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

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

Ожидаемый итог исследования — понятная процедура ответа на четыре вопроса. Насколько организация зависит от конкретного компонента? Какими доказательствами подтверждена оценка? Улучшает ли учёт зависимости оценку остаточного киберриска? Какая мера действительно уменьшает последствия? Если на эти вопросы будут получены воспроизводимые ответы, диссертация даст одновременно научный и практический результат.

Список использованных источников

1. Opara-Martins J., Sahandi R., Tian F. Critical analysis of vendor lock-in and its impact on cloud computing migration. Journal of Cloud Computing. 2016. Vol. 5, Article 4. DOI: 10.1186/s13677-016-0054-z.
2. Gonzalez-Barahona J. M., Sherwood P., Robles G., Izquierdo D. Technical Lag in Software Compilations. OSS 2017. Vol. 496. P. 182–192. DOI: 10.1007/978-3-319-57735-7_17.
3. Zerouali A., Mens T., Decan A., Constantinou E. A formal framework for measuring technical lag. Journal of Software: Evolution and Process. 2019. Vol. 31(8). DOI: 10.1002/smr.2157.
4. Decan A., Mens T., Constantinou E. On the Evolution of Technical Lag in the npm Package Dependency Network. ICSME 2018. P. 404–414. DOI: 10.1109/ICSME.2018.00050.
5. Pashchenko I., Plate H., Ponta S. E., Sabetta A., Massacci F. Vulnerable Open Source Dependencies: Counting Those That Matter. ESEM 2018. DOI: 10.1145/3239235.3268920.
6. Miller C., Jahanshahi M., Mockus A., Vasilescu B., Kästner C. Understanding the Response to Open-Source Dependency Abandonment in the npm Ecosystem. ICSE 2025. P. 2355–2367. DOI: 10.1109/ICSE55347.2025.00004.
7. Ross R. Guide for Conducting Risk Assessments. NIST SP 800-30 Rev. 1. 2012. DOI: 10.6028/NIST.SP.800-30r1.
8. Boyens J. et al. Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. NIST SP 800-161 Rev. 1 Update 1. 2024. DOI: 10.6028/NIST.SP.800-161r1-upd1.