Аннотация. В статье «Метод оценки зависимости компонентов и остаточного киберриска» предлагается воспроизводимый метод оценки технологической зависимости внешних программных компонентов и её дополнительного влияния на остаточный киберриск корпоративных информационных систем. Цель — связать автономность, обновление, контроль данных, восстановление, заменяемость и внешнюю инфраструктуру с техническими доказательствами. Используется индекс D из шести групп показателей и формула Rост = Rисх + D − Z. Проверка включает экспертные оценки, контрольные сценарии и схему до и после мер. Ожидаемый результат — приоритизация компонентов, обоснование компенсирующих мер и подготовка замены. Ссылки оформлены в квадратных скобках [1–9]. Метод предназначен для сравнения компонентов одной организации и не заменяет аудит безопасности. Он фиксирует единицу анализа: компонент, версию, конфигурацию, режим эксплуатации и бизнес-процесс.

Аннотация. «Метод оценки зависимости компонентов и остаточного киберриска» атты мақалада сыртқы бағдарламалық компоненттердің технологиялық тәуелділігін және оның корпоративтік ақпараттық жүйелердің қалдық киберқауіптілігіне қосымша әсерін бағалаудың қайталанатын әдісі ұсынылады. Мақсаты — автономдылық, жаңарту, деректерді бақылау, қалпына келтіру, ауыстырмалылық және сыртқы инфрақұрылымды техникалық дәлелдермен байланыстыру. Алты топтан тұратын D индексі және Rост = Rисх + D − Z формуласы қолданылады. Тексеру сараптамалық бағаларды, бақылау сценарийлерін және шараларға дейінгі және кейінгі схеманы қамтиды. Күтілетін нәтиже — компоненттерді басымдықтау, өтеуші шараларды негіздеу және ауыстыруды дайындау. Сілтемелер квадрат жақшада [1–9] рәсімделген. Әдіс бір ұйымның компоненттерін салыстыруға арналған және қауіпсіздік аудитін алмастырмайды. Талдау бірлігі компонент, нұсқа, конфигурация, пайдалану режимі және бизнес-процесс болып белгіленеді.

Abstract. The article titled Method for Assessing Component Dependency and Residual Cyber Risk proposes a reproducible method for evaluating the technological dependency of external software components and its additional impact on the residual cyber risk of corporate information systems. The aim is to link autonomy, updating, data control, recovery, replaceability, and external infrastructure with technical evidence. It uses a six-group D index and the formula Rres = Rbase + D − Z. Validation includes expert ratings, control scenarios, and a before-and-after scheme. Expected results are component prioritization, justification of compensating measures, and replacement planning. References are given in square brackets [1–9]. The method supports comparison within one organization and does not replace a security audit. The unit of analysis is component, version, configuration, operating mode, and business process.

Введение. Корпоративная информационная система редко состоит только из контролируемых компонентов. Операционные системы, библиотеки, облачные сервисы и механизмы активации часто управляются внешней стороной. Обычные меры защиты не показывают, насколько продолжение работы зависит от поставщика. Исследования фиксируют проблемы миграции [1], технического отставания [2, с. 182–192; 3], уязвимых зависимостей [4; 5] и заброшенных библиотек [6]. Управление рисками цепочки поставок требует контроля происхождения и поставщиков [7; 8]. Однако единый компонентный метод, связывающий автономность, обновление, данные, восстановление, заменяемость и внешнюю инфраструктуру с доказательствами, остаётся востребованным. Цель — разработать такой метод и проверить дополнительное влияние индекса D на остаточный киберриск.

Основная часть

Технологическая зависимость понимается как невозможность продолжить, восстановить, обновить или заменить компонент в допустимый срок без внешней стороны. Оценке подлежит сочетание компонента, версии, конфигурации, режима эксплуатации и бизнес-процесса. Индекс D строится из шести равноправных групп: автономность; контроль обновления; контроль данных и экспорт; восстановление из собственных копий; заменяемость и миграция; обязательная внешняя инфраструктура и привилегии управления. Каждый показатель получает балл от 0 до 10 и подтверждается журналом соединений, испытанием без сети, протоколом восстановления, проверкой экспорта или пробной миграцией.

Средние значения групп складываются и делятся на шесть: D = (D₁ + D₂ + D₃ + D₄ + D₅ + D₆) / 6. Веса не применяются, чтобы до эксперимента не скрывать субъективные решения. Остаточный риск предлагается считать так: Rост = Rисх + D − Z. Здесь Rисх — исходный балл сценария, D — зависимость, Z — подтверждённое снижение риска после мер. Результат ниже нуля принимается равным нулю; это балл приоритета, а не вероятность. Правило метода требует не учитывать один признак дважды: например, отсутствие автономности относится к D и не повторяется в Rисх.

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

Эксперимент планируется на 30–40 компонентах разных классов. Для каждого выполняются шесть сценариев, что даёт не менее 180 наблюдений. Научная новизна заключается не в среднем арифметическом, а в совокупности решений: точная единица анализа; шесть групп измеримых признаков; обязательная связь балла с доказательством; простая аддитивная модель без скрытых весов; экспериментальная проверка дополнительной полезности D; повторное измерение эффекта мер Z. Практический результат — прототип, который хранит карточки компонентов, доказательства, расчёты и приоритеты. Изложение учитывает требования журнала [9].

Метод не объявляет внешнее программное обеспечение опасным автоматически. Он показывает, где зависимость допустима, где нужны компенсирующие меры, а где требуется готовить замену. Для корректного сравнения организаций фиксируются версия, конфигурация и режим эксплуатации. Если улучшения от D не будет, исследование должно установить границы применимости и честно описать случаи без дополнительной информации.

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

Шкала от 0 до 10 требует калибровки на пилотной выборке. Специалисты сначала оценивают небольшую группу компонентов независимо, затем обсуждают расхождения и уточняют инструкцию. Согласованность оценок проверяется по доле совпадающих или близких баллов. Если расхождения велики, формулировки признаков уточняются, а не подменяются общим экспертным мнением. Это снижает риск скрытой субъективности.

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

Предлагаемый метод дополняет процессы управления рисками цепочки поставок [7; 8], но не заменяет их. Он не оценивает репутацию поставщика и не прогнозирует намерения внешней стороны. Его задача — измерить фактическую зависимость конкретной конфигурации от внешних условий. Поэтому результаты метода используются вместе с оценкой угроз, уязвимостей и последствий, а не вместо них.

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

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

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

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

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

Практическое внедрение метода предполагает пороги для принятия решений: низкий балл допускает плановый пересмотр, средний требует компенсирующих мер и дополнительных доказательств, высокий предполагает подготовку замены или ограничение зависимости. Результаты включаются в процесс управления рисками цепочки поставок [7; 8], но не заменяют оценку угроз, уязвимостей и аудит безопасности. Карточки компонентов, реестр доказательств и расчёты должны иметь владельца и периодичность пересмотра. Для малых организаций допустима выборка критичных компонентов, однако ограничения такого упрощения фиксируются в выводах, чтобы итоговые оценки не трактовались шире, чем позволяет проведённый эксперимент.

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

Список литературы

1. Opara-Martins J., Sahandi R., Tian F. Vendor lock-in in cloud migration. 2016. DOI: 10.1186/s13677-016-0054-z.
2. Gonzalez-Barahona J. M. et al. Technical lag in software compilations. 2017. P. 182–192.
3. Zerouali A. et al. Measuring technical lag. 2019. DOI: 10.1002/smr.2157.
4. Decan A. et al. Technical lag in npm dependency network. 2018. P. 404–414.
5. Pashchenko I. et al. Vulnerable open source dependencies. 2018. DOI: 10.1145/3239235.3268920.
6. Miller C. et al. Response to npm dependency abandonment. 2025. P. 2355–2367.
7. Ross R. Guide for conducting risk assessments. 2012. DOI: 10.6028/NIST.SP.800-30r1.
8. Boyens J. et al. Cybersecurity supply chain risk management. 2024. DOI: 10.6028/NIST.SP.800-161r1-upd1.
9. Основные требования к публикации статей в журнале [Электронный ресурс]. URL: https://adisteme.kz/trebovaniia-k-oformleniiu-stati.html.