Опубликовано: 13.10.2026 | Источник: SecurityLab (RSS)

Безопасность цепочки поставок в ВКР: оценка рисков на примере тайных поставок чипов SMIC в Иран

Введение

Китайский производитель микроэлектроники SMIC оказался в центре скандала: по данным расследования, поставки чипов в военно-промышленный комплекс Ирана шли почти год — напрямую, с техническим обучением персонала и обходом экспортного контроля. Для выпускника ИТ-специальности это не «новость про политику», а готовый полигон для дипломного исследования. Здесь есть всё, что требует современная защита: непрозрачные цепочки поставок, слабая прослеживаемость компонентов, атрибуция угроз и оценка риска в условиях неполных данных. Если вы хотите заказать диплом, который не стыдно вынести на защиту в 2026 году, берите темы, где нужно строить модель угроз и считать метрики, а не пересказывать чужие отчёты.

Основная часть: темы, проектирование и реализация

Тема 1. Методика оценки рисков цепочки поставок электронных компонентов

Актуальность. Кейс SMIC—Иран показывает: формально легальный поставщик может быть звеном обхода санкций. Значит, нужна методика, которая оценивает не только контрагента, но и маршрут компонента.

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

Задачи: классифицировать источники данных (открытые реестры, санкционные списки, отраслевые базы); построить модель угроз; определить весовые коэффициенты критериев; провести валидацию на исторических инцидентах.

Структура: Глава 1 — анализ угроз цепочки поставок и обзор стандартов; Глава 2 — проектирование скоринговой модели и архитектуры по C4; Глава 3 — реализация прототипа и оценка точности.

Тема 2. Модуль мониторинга и атрибуции инцидентов цепочки поставок

Актуальность. Инцидент вскрылся постфактум — почти через год. Задача ИБ-инженера — сократить окно обнаружения.

Цель: спроектировать модуль сбора и корреляции данных о поставках и санкционных событиях.

Задачи: описать источники Threat Intelligence; настроить нормализацию и обогащение событий; реализовать правила корреляции; измерить MTTD и MTTR до и после внедрения.

Структура: Глава 1 — теория мониторинга и стандарты; Глава 2 — проектирование пайплайна и правил; Глава 3 — эксперимент и метрики.

Тема 3. Реестр SBOM и граф зависимостей для выявления «серых» поставщиков

Актуальность. Компонентная прослеживаемость — базовое требование, которое в hardware-цепочках почти не автоматизировано.

Цель: создать прототип реестра компонентов и графа связей «поставщик — партия — изделие».

Задачи: определить схему данных; реализовать загрузку и парсинг; построить визуализацию графа; проверить запросы на выявление аномальных маршрутов.

Структура: Глава 1 — анализ подходов к SBOM и прослеживаемости; Глава 2 — проектирование БД и API; Глава 3 — тестирование на синтетическом наборе данных.

Как встроить материал статьи в главы ВКР

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

Для схем используйте согласованные нотации: контекст и контейнеры — C4, последовательности — UML, обработку событий — BPMN, алгоритмы — ГОСТ 19.701. Атрибуты качества ПО описывайте по ISO/IEC 25010: security, reliability, maintainability. Перечень требований к системе оформляйте по ГОСТ 34.602, стадии — по ГОСТ 34.601.

Пример скоринга поставщика — псевдокод, который легко защитить как «реализованный модуль»:

# risk_score.py — оценка риска маршрута поставки
WEIGHTS = {
    "sanction_match": 0.35,   # совпадение с санкционными списками
    "route_anomaly": 0.25,    # отклонение от типового маршрута
    "docs_completeness": 0.15,# полнота сопроводительных документов
    "country_risk": 0.15,     # страновой риск
    "history": 0.10,          # история инцидентов контрагента
}

def risk_score(features: dict) -> float:
    score = sum(WEIGHTS[k] * features.get(k, 0.0) for k in WEIGHTS)
    return round(min(score, 1.0), 4)

# порог принятия решения
def decision(score: float) -> str:
    if score < 0.3:  return "approve"
    if score < 0.7:  return "manual_review"
    return "block"

Для темы 2 добавьте правило корреляции — его удобно оформить в приложении и защитить как артефакт:

title: Supply route deviation from sanctioned region
status: experimental
logsource:
  category: logistics_event
detection:
  selection:
    destination_country|in: ['IR', 'KP']
    declared_end_user: 'civil'
    transit_hops|gte: 3
  condition: selection
level: high

Чему вы научитесь

• Строить модель угроз цепочки поставок и переводить инцидент в проверяемые требования.
• Считать метрики ИБ: MTTD, MTTR, precision/recall, риск-скор — а не «мне кажется, стало лучше».
• Проектировать архитектуру по C4 и оформлять схемы алгоритмов по ГОСТ 19.701.
• Описывать качество системы по ISO/IEC 25010 и увязывать с ГОСТ 34.602.
• Валидировать модель на исторических данных без утечки тестовой выборки.

FAQ

Источник: Почти год, напрямую, с обучением. Что известно о тайных поставках китайских чипов в военную промышленность Ирана (опубликовано 2026-03-27)